…while developing the blob tool (link hunt courtesy of Silvio Grosso), I was faced with the inevitable question of how many features were enough.
More features is always good, except when it comes at the cost of less features elsewhere.

Since I am only a mere human being, and my time, like anyone else’s, is limited, this is the case.
More time developing one feature is less time developing something else. More is less.
Less time on this means more time for other issues. Less is more.

+ is -
- is +

Visual summary:

Therefore I found a compromise of several points for the Blob Tool.

First, I had to choose between making it a Tool or a Brush Engine. The latter would make it Krita-only, but give me sensors (like pressure sensitivity) and other cool features. I decided to make it a Tool because I am already familiar with Brush Engines and I needed to practice with the Calligra Tool framework. Also, I already started it as a tool, and a brush engine that paints vectors may be confusing to some users and would require further discussion, usability work, etc. Lots of time.
Second, I had to choose what features to add. Short story: only the minimal needed; no sensors; adjustable diameter, but fixed during a stroke; adjustable simplification of control points.

Here’s a visual summary of the GUI:

What do you think?, Please vote on the upper or lower option (“Blueish” or “Greenish”). I don’t want to think too much of how to make the GUI, so I better ask you all. (Of course the background is only to identify them in the screenshot, both will have a default background when finished).

Nothing is set in stone, the brush can keep improving in the future, but finishing this –which after all is only practice work– and going to more pressing matters is very important, I must move fast. Less is more.

~Pentalis over and out.

I’m here to announce an event.

Since this is a personal blog I’ll tell you a little background for this announcement (or you can jump to the TL;DR below…)

========BACKGROUND========

It all began several years ago, when I wanted to give something back to the community that’s given so much to me. I’m talking about those individuals who share their work without asking for anything in return; the work of those individuals makes possible nearly all the software I use, the galleries I watch and the encyclopedia I read.

I have many paths to follow in life, and could follow any of them.
But out of those many ways, there is one that always spins in my head: this project, Krita. I haven’t reached closure with Krita; I opened the book before I even applied to GSoC (in 2010), and I am not done here yet. I’m not done with Calligra, with KDE, with Free Software, yet.
I still want to give something meaningful back.

I don’t want to tell you how much I’ve struggled to learn to be perseverant; this lacking has been my most glaring flaw, the one I eventually just learned to accept as part of me. Fighting it has been a strife as painful and long as healing the scars of adolescence.
But this burden is no longer mine.

This time, I’m here, I have built it; the force of will, the discipline, to do something meaningful. And I want it to be meaningful this time.

I have a full time job, on something I do not love to do. And yes… I could spend my free time playing games, just living, in peace… and lead an empty life; or I could bleed for a dream. I choose the latter this time.

Enough background.

============TL;DR============

Now, onto the announcement.
It begins with a proposal like this.

From today and on I’m going to spend a significant amount of my free time to improve Krita/Calligra, play with the code and improve as a developer.

It’s a marathon, and it actually already started. My scheduler (Hamster!) confirms I’ve been spending about 12 hours a week on the project already. I’ve added a new blending mode to Krita (it’s called “Behind”, If you’ve missed it from other software, now we have it), and a quick feature to add feathering and autoexpansion for the fill and fill selection tools.

After some debate on the mailing list and our IRC channel, we decided I was going to spend some time playing with our vector framework. I will be looking at our most hated bugs (hint: vote on them) and fixing them as I go…
…and as a first exercise I’m implementing the Blob tool for Karbon and Krita; you know that one from other software pack don’t you?, You surely do. I will let you hunt for videos if you don’t know what the blob tool is.

I will just leave this screenshot quietly resting here…

…This is my pre-alpha blob tool brush, the upper left area shows the blobs as they appear currently, the other blobs have been recolored (with the Stroke and Fill dialog in Krita, which I’m considering to give a retouch).

Those blobs are vector outlines, and the blue shape shows the control points (as you probably inferred). It is, indeed, an awful amount of control points —don’t worry, the final version will be clean and crisp, with very few control points: you’ll love it.

Victory, not vengeance!.

Pentalis over and out.

PS: The code is available in the branch krita-newvectorframework-pentalis.

Krita, a painting application, offers a collection of brush engines; each of those can be configured to create your own personalized brushes. To do that you simply have to select a brush engine in the Brush Configuration Popup (visible in the screenshots), and set parameters at your leisure. Each fixed set of parameters is what we call a preset, which are known as brushes in other painting software.

Now…

…I present you the new time-saving widget for Krita, in the form of a strip embedded in our brush configuration popup!, ready to load your preset specs.

Look, old popup, without strip:

Now, behold, the same popup, with strip:

Why is this strip exciting or even worth blogging about?, Ho!, For people who use Krita often, the problem of needing too many clicks to modify a set of presets may be all too familiar.

With the old popup, you had to click outside to close it, select your preset in the docker*, open the popup again, and configure your preset inside, that’s 2 extra clicks overhead (to close and open the config popup) and a lot of mouse movement, for every preset: now imagine if you have to personalize a pack with over 30 of those… this new strip saves the artist all that extra mouse work, and looks good while doing it.

* We have a docker (the preset chooser docker) that presents the user with his presets and lets him select and erase some, but to access that docker, the brush config popup must be closed (it’s still a popup even though it’s huge).

See that little red icon at the lower corner of the selected preset?, It’s the delete button; when you click on a preset icon, the delete button will appear, it allows you to delete that preset immediately with a single click. Everything is placed close together such as to save the artist as much time as possible.

For all artists looking for an end-to-end painting application, try Krita!, Our upcoming version is looking very good. For distributions without a prepackaged version, you can take a look at Bugsbane’s install script!.

Short story: didn’t happen.

Long story:

Turns out that creating new height-enabled color spaces for Krita wasn’t as easy as I thought. It began as an horribly mysterious thing that took me really long to grasp from end to end; not the concept of color spaces themselves (that’s crystal clear in my head), but the code that implements them in Krita.

Color spaces are plugins to color engines which are plugins too. Everything here is heavily optimized for speed and full of templates everywhere. So, there’s no way to create a single height-enabled colorspace for testing, because every tool is made to interact with each other. Either one makes a complete set of fully working height-enabled colorspaces, or nothing. Certainly creating such beautiful thing would take more than one week, possibly more than one month, so I didn’t do that.

But then arose the emergency plan!.

It consisted of adding, to a normal image, a hidden greyscale layer working as an heightmap, and a hidden phongbumpmap filter layer doing the magic on top. That was much simpler to do and I was about to make it happen. Until I decided it was going to be a rushed effort, that it was going to generate code MADE to be replaced, and that it wasn’t an easy hack anyway. I often make simple hacks to test things, or to upload working copies while I polish them further. But this approach had several shortcomings. For example it required painting operations to write to 2 devices at the same time.

So, I created a paintop that wrote to 2 layers at the same time to test this feature. It wrote to the normal layer and a secondary layer. It achieved the desired effect but it broke undo, pressing ctrl + Z only undid the painting in 1 layer.

And then came the problem of compositing the bumpmap to the image. What’s the most correct way to composite the bumpmap to the image to achieve a good impasto effect?, and what kind of heightfield should brush engines generate to make it look GOOD?.

Certainly all this testing gave me more questions than answers. And thorough my life I’ve learned that rushing toward a goal without a clear vision is nothing wise to do. At worst I’d get nothing done, at best a patched-together design. So I decided to accept that the impasto effect wasn’t going to be done within the timeframe of this GSoC and will instead design it with time, patience and calm.

Then I switched my focus to completely link the GUI of my filter just to call it “beta complete” right before the hard pencils down deadline!.

I made an ugly heightmap such that if it looks pretty I can blame it all on the filter. Here, enjoy the images and goodbye!.

Here, molten gold, gold paste, you name it. My old and painfully slow python script has grown into a fast filter that applies the Phong Illumination Model on any single channel used as heightmap. It updates fast, enough to work in real time, so it’s almost ready to give people a taste of impasto!. Look at this!:

And look on what it becomes!

For you observant people, those are 2 filter layers there, right?. One of them is Gaussian Blur. Gaussian Blur mixed with Phong Bumpmap really creates the feeling of paste mixing. But the Gaussian Blur filter is too slow to see this effect in real time, so you’re not missing much in those screenshots.

This is the configuration interface. I tried to do the most with the widgets I had at hand. If I went overboad trying to design a cool GUI, for example making a new widget, then I’d have run out of time.

Many of you may be wondering what this funky bumpmap filter has to do with Impasto. Well, you don’t need all the features of this filter to give the feeling of paint volume, it’s enough with just one white light source, but I thought many would appreciate the ability to make very interesting surfaces with just this filter and the many brushes that Krita provides. I think it can even work as a basis for textures to be used in 3D.

The pencils down date is approaching, and now all my effort will be focused on two fronts to get a working pre-beta Impasto out there:
1.- Finally complete at least one height-enabled colorspace.
2.- Give brush engines the ability to write to the height-channel in addition to the normal channels, or at least create a sample brush engine that does so!.

I hope you liked the screenshots.
I could tell you stories about how I took 2 hours to fix a stupid bug that consisted of a missing comma, or how I broke my Fedora with a custom kernel package but I’ll spare you the details of those frustrating things

Being a self taught coder (like many out there), I had to actually learn and grasp for the first time what a template really is and how to read templates calling templates calling templates, as well as actually getting to understand and grasp how polymorphism works.

The other hard step is understanding the way Krita works internally. I learned about unit tests, singletons (I’ve used them before but I didn’t know they had a name and a specific purpose in programs), the colorspace registry, CMake building (specifically how to link libraries), filter building (not complex, it’s simpler than paintops brush engines in my opinion), and many other things.

Overall a week full of learning.

This new week (26-31) I’m going to put those things to work. Stay tuned!.

1. A hatching and halftones brush for Krita.
2. Implementing impasto in Krita.

Part 1 is virtually complete, there’s no halftones brush yet, but it’s trivial to create one from the hatching brush which is now beta!. That’s right!, all GUI is linked and you can start toying with it and have fun, change the settings to anything you like without touching the source code! =D here’s a little picture reminding you of what it looked like:

Halftone Brush Beta!

Documentation!

How to install Krita trunk and start playing!

Remember there is no way to download only Krita, you have to download all of KOffice’s source code and then you can specify the applications you want to build. If you wonder why this is so, you can check the mailing list.

And now take a look at this…

Bumpmapping Script in Action!

Source code!

References!

• Phong Illumination Model!
• Cg bumpmapping tutorial!

Ah, the story behind this script is so long. But to not bore you with a huge blog entry that will take as long to write as the script (hah… nah, that’s not going to happen =) ), I’ll summarize it try to be brief and hope it helps you when you find yourself facing a brick wall:

1. “So… impasto… um… where do I start?” ===> e-mail to the community
2. “Community gave feedback!, yay!, hhm, bumpmapping… so… um… how do I bumpmap anyway?, where in Krita’s code do I even begin hacking?” ===> divide and conquer, get a bumpmap working first, then put this into Krita’s code!.
3. “Alright, let’s just make a bumpmapping algorithm…” at first I thought about raytracing, Google search… “Phong, what is this Phong thing about?… ooh!, looks interesting!…”, I tried to begin implementing it, but after realizing I was very stupid that night, I went to sleep. The next day I should be able to think clearly.
4. Checking the notes I went on with my research. I tried to immediately turn what I was doing into a program. And you know what?, In the end that was just what I needed. Because after I started making the problem program, I discovered what I was missing, I discovered new KEYWORDS!: “Heightmap” and “Bumpmapping“, of course I was looking for a bumpmapping algorithm, but I looked for mixtures of “bumpmapping” and “Phong”, and “raytracing“, but not “bumpmapping” and “heightmap” together!.
5. So again I was faced against many webpages saying essentially the same things I was reading a couple days ago. The difference is that I could actually understand what I was reading now, because I was already doing it. — Note that while I am well versed in the natural sciences, my problem was sadly my poor ability with math; when I saw so many formulas I couldn’t immediately grasp them, I couldn’t grasp those uses of vectors or the (now obvious) fact that the dot product of two unit vectors is the cosine of the angle between them. — But thanks to the NEW KEYWORDS (please always remember that part), I found a place which solved my vector problem much more elegantly!. That’s the second source I quoted!, the Cg bumpmapping tutorial; they were bumpmapping a bitmap, which is exactly what I wanted to do!, and they already had a solution to my exact problem!, and it was so simple, minimal, and mathematically beautiful, that I felt stupid =) but I learned, I learned math is something I need to improve upon.

Well, that’s as far as I’ll tell the story, the lesson I want you to never forget is KEYWORDS. Keywords are KEY! (no **** Sherlock!). When you’ve finished studying, 10 years later, what do you remember about your college days?, the KEYWORDS, You know where knowledge is, you know the elements you have, the elements you require, and the elements you are missing; every one is linked to a source where you can research, and to find that source you already have all you need: the keywords.

Keywords I said!.

Until next time!

PS:

The odyssey also included a quest for the perfect IDE to develop in Python, because I wanted to have something better than just an editor.

At the moment I’m using Eclipse with PyDev, but let me tell you something: I MISS KDevelop’s highlighting of syntax!, It’s the BEST highlighting I’ve ever seen, there’s no application I have ever used that compares to it, and I’ve used commercial applications too (and I’ve searched in screenshots for equivalents). The fact that they highlight every parameter in a function with a unique color is PRICELESS.

Don’t get fooled by appearances, don’t you ever think KDevelop is “just another KDE app”, it is THE KDE APP, It’s a JEWEL that completely reverted my bias against KDE. Seriously guys, if you’re still reading to this point, and you’ve taken part in developing KDevelop, just let me tell you: Good Work.

PS 2:

Dmitry Kazakov helped me with the bumpmapping previews (all those with a blue titled PyGame window). The angel girl is a digital painting in Krita made by Deevad, can you spot which bumpmap it is?.

And the brush has been advancing steadily. This time I don’t want to give details on how I overcame each step, it’s just the same than before. I had to learn new things about Krita codebase, I made mistakes, someone corrected me, I learned more, and then a new feature was born.

This time I learned to change the default values of brushes, even the curves (I had to hard code them). I also benefited from my previous weeks of preparations and, thanks to my now much cleaner code and nearly completely linked GUI, I managed to slip in many new features in a seemingly short time. But never get tricked by those apparent bursts of productivity, it’s just a result of what was built before behind the scenes.

So this will be just a short opening the curtain for you all to see how the brush is looking. If you are curious and want to try it, you can download Krita’s lastest source code and build it according to this tutorial!

http://wiki.koffice.org/index.php?title=Building/Building_KOffice

When the brush reaches beta I’ll finish documenting it, and then my blog post will be just a link to the documentation full of images and (hopefully) entertaining explanations.

Next week I’ll be making preparations to work on implementing Impasto for Krita. The Halftone brush will remain on hold until the Hatching brush is completely done. Why?, because the logic of both brushes is so similar, that once the hatching brush is polished and ready, I can copypaste the code and create the new brush with just a few changes

And now, TO THE SNEAK PEEK!, Image barrage!, RAWR!:

Till next time!, Stay tuned!

The final results:

In the first image you can see how to customize the thickness, angle and separation of the lines. Origin X and Origin Y represent the coordinate of the base line to render the lines. The term “base line” is tricky to explain, in my next blog I’ll send you all a link to the brush’s documentation where it will be explained.

The second screenshot shows some interesting options. The Scratch Off algorithm should solve the problem of lines thickening due to incremental passes: you can see I used 1px thick lines, but they look instead 2-3px thick, that’s the problem I’m talking about the algorithm is what I’m going to do this week.
About the screenshot —>
The first pass shows antialiasing and subpixel precision activated.
The second pass shows only subpixel precision on.
The third has everything deactivated.

If you decide to download from SVN and test this toy, a little warning for you: Origin X and Origin Y are working as “width” and “height” of the brush at the moment. I’ll change that during this week when I link the “BrushTip” config dialogue (it’s title is visible in the screenshots).

That’s all for now, see you next time!.

Here are a couple crummy and heavily edited webcam shots of the paper work behind the code I wrote:

(a)

(b)

Like homework, many sheets of paper were required for a relatively terse answer (in this case, I think around 80 lines of code if I don’t take comments or spaces into account).

All the output for my original code was text sent to the console with std::clog() and printf() to confirm there were no holes in its algebra and geometry.

The algorithm in its current state can be summarized as follows:

1.- Take settings from the user, including the origin point.
2.- The origin point + angle requested by the user constitute the base line of the hatching, the position of all other lines is calculated relative to that line.
3.- Convert point+angle of the base line into intercept b and slope p. Make an exception for angles = 90 or -90 (I used that notation which is less ambiguous to the user). [Reminder: Any line can be described with a point and an angle, or with the algebraic expression: px + b (as long as angle is different from 90 or 270 degrees). ]
4.- With lots of geometry-fu (see the code for details), calculate what are the dy and dx distances separating each line. We know that moving through the axis of separation s is equivalent to moving in the x or y axis, and moving through the y axis is the most convenient way (which implies only varying the intercept of the base line to discover new lines).
5.- With more geometry-fu and algebra-fu (including the floating point modulus operation), determine the intercept of the lines contained in the hatching area and their intersection points, then trace them. This is done in a cycle that goes line by line.

Much more complex (for me) than the other algorithm, but easier on the processor (I haven’t tested, but common sense tells me that it is; math is cheap, rasterizing unused space isn’t), and looks cleaner.

I first had a paint operation that painted nothing, and instead dumped data to the console, describing all the points in it. Then I compared its results with my paper results. When I solved all annoying bugs including one uninitialized variable that wasn’t spotted by the compiler (very uncareful of me), and I was sure the algorithm did what I intended it to do, I ventured into trying to draw. When doing that, I discovered an omission in my algebra (I wasn’t considering the relative position of the brush, only the origin point determined by the user). Then I fixed that and obtained this brush:

Screenshot 1

Some lines are thicker than others. The thickness of the lines should be 1 px, but I’m using subpixel rasterization. Which causes some areas to be painted gray, and then when the mouse passes over again, they become black and make the line look thicker.

Appart from that, I noticed that some lines seem to get out-of-sync by 1 pixel with respect to the others. I believe that glitch too is caused by problems with sub-pixel rasterization. For example, if I trace a straight line using alt+mouse (I thank an IRL friend with no programming background for suggesting this), I get an homogeneous hatching (but still with thick lines); unlike the sometimes heterogeneous hatching I get when I use freeform angles. See below.

Screenshot 2

Screenshot 3

I believe the solution to the thickening lines (which look pretty cool anyway, kind of like “hand-made hatching”) is either not using sub-pixel precision, or using the “wash” painting mode instead of “build up”. Either way I plan to leave the user the option to use the mode he prefers, including this one. Sometimes a glitch becomes a feature, *wink wink nudge nudge*.

Screenshot 4

Now, this glitch is a disaster that tells me something is very wrong, but NOT in the algebra, but in the few painting code lines involved in my brush.

With certain paintop settings (like these above), as I pass the brush over the canvas, randomly a whole new hatched square appears close to the normal one, out-of-sync with respect to the others, causing this flawed pattern. I’ll have to investigate where the error is (I have a hunch of where). Maybe I could even explain the most extreme cases of the first glitch after I discover the cause of this one

When I link the GUI controls to the brush I’ll be able to show you some cross-hatching as well as many different patterns in the same image.

Till the next time.