[GSoC proposal] Airbrush and Calligraphy paintops

[Matthew Woehlke]

Fela Winkelmolen wrote:
> =========== begin ================
> Implement real-media airbrush and calligraphy simulation paint operations in 
> Krita.
> 
> == Expected Results ==
> Real-media airbrush simulation support:
> * usable with a mouse and with graphics tablets both using a graphics pen and 
> a airbrush
> * the engine will work with the following parameters: rate, tilt (only when 
> the input device supports it), distance, size (of the area painted on the 
> canvas)
> 
> Real-media western calligraphy simulation support:
> * usable with both mouse and graphic tablets
> * the engine will work with the following parameters: width, thinning 
> (depending on the speed of the stroke, and optionally on the pressure of the 
> input device), angle, fixation, mass & wiggle (determining how the 
> tool "feels")
> 
> 
> The user interface of both tools should be polished and usable. When using an 
> input device that don't support a parameters directly (e.g. rate of the 
> airbrush when using a mouse) there needs to be an easy way to change that 
> parameter while drawing, for example using the keyboard and/or the mouse 
> wheel.
> ============ end ===============

I've been proposing a paintop system that separates the "stamp" from the 
"pigment"[1]. The idea here is that your airbrush tool would decide 
where the pigment touched the canvas, and then call an ink pigment 
engine with that information to actually manipulate the canvas. The goal 
is to share the pigment engines so that eventually, we can tie the ink 
pigment engine to the airbrush tool, bristle brush tool, calligraphy 
tool, etc, and also to be able to plug other engines into the airbrush 
(or other tools; brushes especially), like charcoal pigment (powder 
coating?), oil pigment, etc.

I guess the calligraphy tool would use the same pigment engine? (What 
instrument are you simulating? A brush? Felt tip? Quill?)

The point of the pigment engine is primarily to simulate bleeding and 
other color interactions. Eventually I'd like a good felt tip tool using 
it, so we can simulate markers.

Anyway, I think it's an excellent proposal and hope it is accepted!

1: http://permalink.gmane.org/gmane.comp.kde.devel.krita/1324

> There are airbrushes that separate the function for air and paint flow (dual 
> action airbrushes), but I'm not sure that makes sense in the digital version. 

What is the effect of these?

> I was also thinking about another parameter for the airbrush. My initial idea 
> was to not simulate the single particles, mostly like the current airbrush 
> looks like, but thinking more about it maybe we don't always want 
> this "infinite granularity", but we want the particles to be actually seen. 

IMO any worthwhile natural media airbrush *must* simulate particle 
density :-), from very low (particles clearly visible) to infinite (like 
we have now, except I assume we are talking about proper conic section 
footprints rather than the current circles).

> So the granularity might be configurable. Actually there may be the need of 
> two parameters: size of the particles and opacity.
> When the particle size is 0 it will use something like the fuzzy circle, the 
> opacity in that case will have the same effect as the rate. If for example 
> the opacity is 100% and the particle size is one pixel if would look a bit 
> like the airbrush of MS paint (if I remember correctly).

I would probably approach this as three parameters; flow rate, particle 
size, and particle density (actual opacity of particles, which does in 
fact need to be a fourth parameter, should come from the pigment, not 
the tool). Rate is mostly a measure of how many particles are deposited 
per unit of time (as you say, with maximum density, this equates to rate 
as we understand it now), and makes sense to be controlled real-time.

The reason I would split this is because someone might want very large, 
sparse particles, or very fine but still sparse particles (painting star 
fields comes to mind). Of course, as density increases, the particle 
size becomes less relevant (but maybe not-quite-maximum density with 
large particles would give smooth coverage with irregular outlines?).

> Another parameter might be how "blurred" the stamp is around the border, or, 
> in the case of particles, how concentrated the particles are at the center 
> compared to the border.

I don't understand what you mean by "blurred", but if it's just the 
relative particle density, that makes sense.

> Also the calligraphy tool may need to be a bit more sofisticated. The way it's 
> described above it behaves mostly like the Inkscape calligraphy tool.

If you are simulating a quill, boud's suggestion makes sense. Also, 
light pressure, and/or depending on the tilt, would result in only the 
edges touching, so you might get a very fine double line at the end of a 
stroke.

I think a quill would be not too terribly hard to simulate; you probably 
want to devise one or several 3d contours for the tip of the quill, and 
then it is just a matter of how the quill responds to pressure, and 
modeling that, and then calculating what part of the quill touches the 
canvas.

Something that we should eventually consider (maybe not for GSoC though, 
i.e. I would suggest not worrying about it until everything else works) 
is handling the 3d aspect of the canvas; height from deposited pigment, 
and also texture of the canvas itself (actual canvas, various papers, 
etc.). The airbrush can mostly ignore this, but bristle brushes, quills, 
felt tips, etc should eventually account for it.

-- 
Matthew
That said, if this is coming out of your posterior then you should 
consider your diet. -- Richard Moore, in response to Aaron Seigo's 
stated source of suggested enum values.