Brush spacing / rotate / scale
boud at valdyas.org
Thu Nov 15 20:51:45 CET 2007
On Thursday 15 November 2007, Matthew Woehlke wrote:
> Not real-time as in 'as I drag the mouse around I see what I could
> paint', but as in 'as soon as I draw this segment, I see what I have so
> far'. Both PS and GIMP have this; Krita does not. Both PS and GIMP also
> allow mixing lines and freehand, and allow you to determine when to
> "lift the brush" (which has the pleasant side effect of making a
> "polyline tool" redundant); again, Krita lacks this.
Ah, I see what you mean here. You want an update while moving the pointer to
the place where you're going to set the next knot. In 2.0, Karbon's path tool
already does that -- so I guess that's going to be really easy to have in
> Oh, and paying closer attention, there are a *lot* of tools that could
> all be folded into one good path tool.
People keep telling me that. However, rather more people keep telling me they
are so glad that Krita gives them lines, ellipses, rectangles etc. out of the
box. So I think we'll keep them for now.
However, if Sven's current work on making the KoPathShape stroke using Krita's
paintops works out (and it looks promising) we might indeed cut them out in
favour of the existing geometric shapes users can drag from the shape
selector. I suspect we'll have some discussion among the developers about
> Whee. Ok, so the hierarchy is really three deep; what the brush looks
> like, what happens when you use the brush, and how strokes are placed.
> And it sounds like the division is still muddied.
I think it's pretty clear, actually, but it is different from other paint
applications: there are paint operations (every paintop is its own paint
engine, varying from stupid gimp/photoshop-like potato-stamping to complex
real brush simulations), and there are tools that help placing the strokes.
The tool tells the paintop where to draw, the paintop does the drawing. "What
the brush looks like" is only relevant for the least interesting subset of
paint operations. Some paintops use .gbr brushes, others don't.
* tools determine the location where painting happens
* paintops determine what painting means
> IOW what I would expect "eventually" is the regular paintbrush, the
> 'pencil' brush, 'digital airbrush', "camelhair brush", "real airbrush",
> "calligraphy pen", etc. Then I'd like to be able to paint "plain", bidi,
> clone, filters, watercolor, etc. with each. It sounds like you are
> indeed moving this way code-wise.
Not really: that would presuppose one painting system. We can have as many
painting systems as we want. A complete Corel Painter or Photoshop painting
system can be added as (rather complex, code-wise) plugin.
> Given two paint programs... one has the tools 'brush, line, polyline,
> square, ellipse, polygon and star', one has the tools 'brush, pen,
> airbrush, watercolor brush, chalk, pencil and palette knife'. Which one
> are you going to take more seriously? Krita's toolset makes it look like
> a glorified KolourPaint, and not the high-end artistic 'real media'
> program we want it to be.
I'm not particularly concerned with that: Krita will have both. Just like
Corel Painter has both. In Krita, you will choose your paintop -- an ordinary
paintbrush that uses gimp brushes, or a chinese brush, or a programmable
brush. The paintop may present sub-choices: the chinese brush has six sizes,
for instance, and the ordinary brush can have gimp brushes (the gimp-style
brush selector should actually be part of the paintop option area, not the
general option area, that's a bit of legacy).
> Ok, Cyrille already talked about persistence, so I'll just mention that
> I agree that persistence is good. (In PS, you have to explicitly delete
> paths, otherwise they are saved with the document.) Hopefully flake will
> give some nice features here for almost-free :-).
It will -- the only thing missing is us calling the flake save routines.
More information about the kimageshop