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.

Someone requested me to restate what this project was about; he missed my first post in PlanetKDE because I was actually not aggregated on it when I made the first post. The best way to know what I should be programming is looking at my GSoC proposal:

GSoC proposal, comic artist Krita brushes for Krita and impasto implementation

And this is a link to my first post in my blog

<start digression>
Before I go on, let me do a little apology about comments not appearing: I’m completely new to blogging and I didn’t know there was a special section in Wordpress to approve or reject comments. Now that I found it, I was surprised to see so many SNEAKY Spam messages, things like “very interesting project” and the title says “Chanel handbags”, and the URL points to an online shop, hah!.
</end digression>

If you didn’t skim over the timeline, you may have noticed I’m way out of my own schedule. That’s nothing new considering the person we’re talking about (me), I’m terrible at respecting timelines, specially my own. Now, I haven’t just let time pass hoping code writes itself. I’m in a constant struggle against my inability to focus… and…

…chaos.

While it’s true that I’ve been fairly active designing classes and algorithms in my head, I am yet to write a single line of code. And well, at this point in time, I think I’ll have to agree with my mentor when he said (before even being my mentor):

“Your distro shouldn’t get in the way of your coding”.

And, considering I’m running Debian Stable, I think that sentence applies.

For those unfamiliar, it means I have KDE3 as my desktop. But Krita is founded upon KOffice, KOffice is built upon KDE, and the current version (2.X) uses KDE4.

So how did I manage to submit my first samples of code and actually develop for Krita?.

Please, take a look at this aberration:

I had to decide between using virtualization, another linux installation, updating Debian to Unstable, getting a new computer, etc.

I appreciate the stability of Debian Stable, so I didn’t move to Unstable. I had no disk space available for another installation –to repartition would’ve required moving a ton of documents and files that I didn’t want to touch– and finally, for the same reason, virtualization was out of the question.

In the end I used debootstrap, schroot and another pile of tricks I learned in the net and forgot the source (the links must be saved somewhere in the chaos of my document folders).

What I did was create a new Debian installation inside my Debian installation, a frankenstein Debian Stable/Unstable growing like a tumor inside Debian Stable and containing the KOffice source, upon which I could work, compile, _EXECUTE_ (ever seen a KDE4 application running inside KDE3?, well, now you have!), and work. This system was fairly fine for a few modifications to the source of Krita, but it’s horribly messy. And now I need to use a SVN account to make my commits, and I really can’t draw the strength to tinker enough to make the SVN account work seamlessly inside this cancerous Debian Unstable. A system reinstall is needed, urgently.

Did I mention I have a dead Windows Beta 7 installed in one of my partitions, a variety of old bootless installations and some other vestigial organs in my hard drive?. Definitely this needs a clean start. A clean start for a clean state of mind. Now… I’m trying to decide for a distro to use.

So Google, KDE, please excuse me while I disappear for a day*, this is for the good of Krita! (and my mental health) >_> .

*or more if things go wrong.

PS: somewhere in my project proposal you must’ve read I was going to take this with the same responsibility as a full time job. I’m serious about that, but well, one thing is theory, the other is practice… but from experience we learn. I have never really tamed the inner monster of procrastination, it was about time I learned to focus on something for real. This should be a lesson for life.

PS2: a little help for those looking to replicate this trick, the obscured parts of the screenshot say:
~$ export KDEDIRS=$KDEDIRS:/KOFFICE/inst
~$ export PATH=$PATH:/KOFFICE/inst/bin
~$ export LD_LIBRARY_PATH=/KOFFICE/inst:$LD_LIBRARY_PATH
You also have to do a ~$kbuildsycoca if you’re issuing those commands for the first time, for it to work.

The purple blob called algorithm?, It has taken shape. It’s a relief to have deviced it completely in my head, as that was the part that had me the most concerned about the program. I felt that if I couldn’t device one quickly, I would not finish the program in time.

That way of thinking has accompained me since I learned to survive in higher education: my disastrous ability to get distracted from study (or anything that resembles work or isn’t pleasing) meant that I had to device ways to get myself to do things in time or at least before the final deadlines.

That role as been fulfilled by my conscience, that evil overlord with a whip that keeps reminding me of aaaaaaall the things I still have to do, with the highest priority targets earning me more mental whipping per unit of time.

Look at the images below, can you distinguish which direction the lines are moving?. Can you find a difference between both?.

(a)

(b)

Truth be told, they’re indistinguishable. One animation was made by moving the image 1 pixel down every frame, and the other by moving 1 pixel left every frame. But other than the filename, both files are identical, their size and every frame is identical to each other.

Here is a jerky animation with a red dot serving as a guide. Note that if you carefully cover the red dot and only focus on the remaining space of the animation, you may start seeing it go to a different direction than the dot used to be moving.

(c)

(d)

This is the first step of my reasoning that led me to conclude that for any regular line pattern, vertical and horizontal movements are equivalent, and related by a factor of x. x depends on the angle; for example, for a pattern composed of lines with a tilt of 30°, a movement of 2 pixels to the left are equivalent to 1 pixel toward bottom. Look at the images below, they were created by stretching animations (a) and (b) (both are equivalent so it’s the same than if I chose to stretch (a) or (b) twice instead):

(e)

(f)

From looking at them you can visually perceive that even if the angle of the lines is changed, you can still obtain any possible configuration of the pattern by simply moving in a single direction. If moving in a single coordinate lets us obtain any possible configuration of the pattern, moving in 2 coordinates will as well.

If you play with those principles in your mind, you will conclude that what I say is true (but hell if I’m going to show an entire demonstration of it here, that’d make the explanation take longer than the deduction).

That’s the basis of my algorithm. Which I’ll describe below. And I know it’s not the best solution, but it’s real and it works for any dab* shape, and I hope it doesn’t take too much processing power. I have understood every step involved in my head and now all I need is to implement it. Allow me to explain.

*look at my previous blog entry to visually understand what a dab is in digital brush parlance.

Filling an arbitrarily sized rectangle or ellipse with lines of any thickness, separation, angle and base point (the just discussed X, Y position within the pattern) is not a simple task. Many things can go wrong if you’re too restrictive, much processing power and memory will be wasted if you take an easy path. So I tried to reach a compromise, look below:

Image (g): Well, this image is an example of what would happen if you apply the algorithm I describe below. I can’t really explain the image, as it explains itself as you read the algorithm. The dotted black border is imaginary, it doesn’t exist anywhere, it’s just my way to see “see?, it’s like a square” (see algorithm). The dotted inner square (red color) represents the limits of the rectangle containing the dab. The tilted rose one is there only to show people visually that I used the diagonale as the length of the lines.

Image (h): Even here the image is self-explaining, you’ll see what I mean with “oops”.

Well, that should serve as a visual guide for the algorithm, now the steps:

1-Determine the diagonal size of the dab –> length
2-Obtain the line angle from the properties class –> angle
3-Create a new empty bitmap to draw the stuff inside… grrrr, I just realized I missed this step to understand this process as a whole. Forget all I said about understanding everything in its entirety. I don’t know if it is or isn’t possible to draw a line that stretches out of the bitmap with the available functions. If not possible: causes an error. If possible: only draws the part of the line within the bitmap. Imagine it throws an error for the sake of this example. Imagine this bitmap is just the right size for this “border overload” to not occur.
4-Trace a line with the brush tool over a path describing a line of length length and angle angle.
5-Trace parallel lines to that, separated by a distance s off the original line, measured by a segment perpendicular to it.
6-The last line drawn will be line number int(length/s), such that the area covered by the lines will be a square at lim(s->0).
————6b-Now, the problem is that if I trace that many lines, and the origin point is too far (almost about to start a new cycle, meaning I’m back to a configuration identical to that with the origin point at coordinate [0;0]), it could result in an “oops”, as seen in the image. This shouldn’t be a problem, except for certain limit cases that may arise. Just in case, the solution is just adding 1 line more. Meaning the last line is line number int(length/s)+1
7-Locate the dab inside this square as seen in Image (h), the point of origin (left-top corner of the rectangle containing the dab) depends on the base point (X and Y position) in user preferences. (I haven’t thought the exact formula to locate a consistent origin but it’s not difficult to determine).
8-Cut.
9-Paste as filler (step 5 in The Schematics).

There is a lot of room for improvement in this algorithm, but it’s a base I can work upon. Wasted processing time increases as the dab’s dimensions deviate from a square and as the angle approaches 45°, as a lot of things will be drawn that will be ultimately not be used (as in cut, see step 8).

I think, depending on the functions at hand, that I can optimize this to draw directly on the dab, such that the bitmap (or “canvas”) of step 3 will be only in my imagination, and such that every line that attempts to be drawn outside the limits of the dab will simply not be drawn outside without throwing an exception or error. I may even go and create the functions I need to do that. It all depends on the tools I find in my way.

So, there you have, my hatching algorithm. The algorithm is the most difficult step; after it is finished, the rest is a cakewalk. The GUI, the preferences class, communication, none of that is difficult. I can confidently say the algorithms (plural) will ultimately represent more than 60% of the time spent programming and designing this new brush, probably close to 80%.

I’m too tired to give more personal comments. But I’ll say one thing!, I started using heating. I can’t work with cold hands, cold feet and cold knees!, I told you, it’s winter here!. If it were summer, it’d be so MUCH easier to focus, with light and warmth!. Who wants to work when not feeling in a ZEN state?, certainly not me. As long as my body is whining about cold or hunger or sleepyness, I can’t sustain focus on work (sometimes not even on games)     .

Salgan al sol!.

Endnotes:

…Err, I gave an entire demonstration of why vertical and horizontal movements are equivalent in a parallel line pattern and then forgot to explain why it is the basis of my algorithm: it is because, within that square made of n lines of length length, the only way I can be sure that I won’t get out of the boundaries of this “square”, is by moving along the axis of space s, that is to say, perpendicular to the lines. The idea is that I’ll be able to achieve any pattern configuration that the user requests (depending on the origin point he desires) by simply moving along that axis, which is a combination of vertical and horizontal movements, but which, in the end, can be equivalent to any other movement along those axes.

And if you don’t know what I mean with origin point, imagine that the different animations I made, like (a) and (b), where created by moving the origin point 1 pixel at a time toward the left or up.