a few issues with paintops : bristle and speed

[Cyrille Berger]

On Monday 12 March 2007, Boudewijn Rempt wrote:
> 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!

sure, but still if we can reach their level for krita 2.0, it will be really 
nice ;)

> > 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.

funny I see it works out much more easily than paintop bristles :D But I don't 
see the point of having both, so I will rather starts experimentating with 
one of the idea.

>
> > - 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.

and don't forget if your paper isn't flat, the bristle are affected by that 
too ;) So the "bristles" should draw on a temporary layer, that would serves 
as a stamp to be compose on the layer ?

> 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!).
I think there is more than on line, I think there are bristles on the whole 
circle outline, and you can control the density of bristles.

> > == 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?
I thought so too :) But it's not reliable (especially if you start to use the 
line tool...), you need the time to make it work well.

> > 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 :-).

no sorry it doesn't affect paintLine :/ as it allready uses QPointF (even if 
paintline still has too many paremeters),
but stuff like
    void bitBlt(qint32 dx, qint32 dy,
                const KoCompositeOp* op,
                const QImage * src,
                quint8 opacity,
                qint32 sx, qint32 sy,
                qint32 sw, qint32 sh);
could be reduced to 
void bitBlt(QPoint dstPoint, const KoCompositeOp* op, const QImage * src, 
quint8 opacity, QRect srcRect);

-- 
Cyrille Berger