a few issues with paintops : bristle and speed

[Boudewijn Rempt]

On Monday 12 March 2007, Cyrille Berger wrote:

> == "bristles paintop" ==
> Currently our paintop are what I call "stamp based", we generate a paint
> device "offline" and then we "bit blt" it on the paint device. If you want
> to see what I mean by bristles, have a look to the presentation of the last
> version of painter, especially the video :
> http://www.corel.com/servlet/ContentServer/us/en/Product/1166553941991 (for
> those who oppose the adobe flash player, you can install the gnash player).

Mwah, it's possible to do much better than that comb-through-the-paint 
simulation!

> I can think of two ways to add "bristles" to krita:
> - with a bristle tool, in fact each bristle can be associated with one
> paintop, the drawback is that you only have "bristles" for a freehand-like
> tool (no drawing circles or lines with it), on the other hand I don't think
> that it makes really senses to use them with something else, and the
> advantage is that you can use any paintop at your disposal (like duplicate
> or smudge)

I don't see this work out, really. Although it'd be fun to do the experiment.

> - or it can be done like in the unfinished cpaint paintop, at each call to
> the paint op, the bristles draw from its previous location to the new one,
> I do find a little bit odd, 

It's a classic implementation of the Strassman Hairy Brushes model. More 
advanced brush simulations do stuff a little more different -- don't paint a 
straight line from bristle pos to bristle pos, but play with the footprint a 
brush deforms to due to pressure and then simulate the fluid outflow of each 
bristle. Of course, in the end, you get yet another potato-stamp footprint 
out of that.

Judging from the video above, I think that Corel Painter uses a single row of 
bristles and paints curved lines in between depending on the curve the brush 
makes makes; a bit like what I wanted to do with the smeary paintop 
(misnamed!).

> and also the cpaint paintop doesn't take the 
> composite op into account

That's not important -- just an artefact of a direct port from the opengl 
simulation I took the idea from. It has always been my intention to take comp 
op into account (and to allow each bristle its own color).

> == speed sensors ==
> One of the component of dynamic paintop are sensors, it's just the name I
> gave to pressure, tilt, etc.. And one of the sensor I would like to add is
> the speed of the pointer, unfortunately it's not as easy as it seems (API
> wise). As, the paintop is called by functions in KisPainter, and it
> received a KisPaintInformation, so the mouse speed should be a field of
> KisPaintInformation, but I don't find it is a good idea to add the speed of
> the mouse as a parameter to KisPainter::drawLine. What do you think ? Any
> other idea ?

Given the delta between the previous position and the current position you get 
the speed, and I think that that is already in the KisPaintInformation, or it 
could be stored in the paintop. Or do I miss something here?

> PS: It's not that much related, but I think the KisPainter API should use
> more QPointF than currently, all those functions with a dozen parameters
> looks really ugly.

Is that related? I mean, using floats instead of integers won't reduce the 
method signatures, will it? Anyway, it's a product of a bygone era, it used 
to be the fashion :-).


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070312/11bf61bf/attachment.pgp