Yet another brush interface proposal

[Matthew Woehlke]

Valerie wrote:
>> Er... why? I still think the "brush" and "paint" should be separated... 
>> so, all the color jitters and color fades would apply to some sorts of 
>> "paint", regardless of the brush, and all the size/position/etc jitters 
>> would apply to some types of "brush", regardless of the paint.
> 
> Oh I have nothing against your idea. I just have no idea what you're
> talking about. :P

I suppose I should (finally) do that (re-)write-up of my thoughts on 
brush architecture :-).

> As long as all the options are concentrated in the 
> same place, I'm fine with what you're doing underneath (BUT, 
> they need to be in the same place, else the user won't understand
> what's going on any more than they understand why the hell Gimp
> has "opacity" and "brush editing" in completely different panels.
> Please, spare us the internal architecture mumbo jumbo).

Why? I'm actually pondering architecture based on how things work in 
real life. Do you really think it's so hard to understand that how many 
bristles your paintbrush has is unrelated to how translucent your paint is?

My idea basically goes; in real life, four independent things determine 
what a particular brush stroke does; the stroke itself (i.e. how I move 
my hand), the tool I used to make the stroke, the "paint" (or charcoal, 
or chalk, etc...) I had on the tool at the time, and the canvas itself 
(more to the point, any "paint" that was already on the canvas, that may 
react to my stroke).

Thus, my idea is to separate the architecture along the same lines. You 
have a "stroke" that represents "how the hand moved". From this, you 
apply a "paint tool" that determines what part of the canvas was 
directly touched by the tool. Then you apply a "paint operation" that 
takes that information and combines it with the "paint" used and the 
canvas to produce the final result. There are many ways to make a 
stroke, many tools with which one might paint, and many "paints" (or 
charcoals, or chalks, or...) that one might use... none of which are 
tightly related, and therefore IMO should be interchangeable.

(On further thought, I'm not sure if having a single PaintOp that has to 
be able to deal with whatever is on the canvas is better than trying to 
have one class to apply new paint and one class to modify existing 
paint. Neither really seems ideal.)

>> The basic problem with this is that it's a stroke that cannot be done in
>> real-time, because you can't calculate any given part of the stroke 
>> until the entire stroke is completed. (At best you can hope it's fast 
>> enough to have a dynamically-updating preview.) Not to say that it 
>> shouldn't be done, just that this is a fairly significant caveat in 
>> terms of how it could be implemented.
> 
> Which is why the tool forces you to switch to bezier mode. :)

Gotcha; you're OK with the stroke being non-real-time.

At any rate, this sounds like a good argument to keep strokes separate 
from everything else. (As I understand, things more-or-less already work 
that way...)

>> I use boxes for pencils :-). And I've got an old powerdrill box
>> that I made layers and compartments in for my oils. Brushes go into
>> peanut butter jar, inks into the drawer of my great-grandfather's
>> desk, etc. But then, I don't really have a work place for working
>> with real media.
> 
> Behold! The "peanut-butter jar" concept! (now observe the user's
> utter confusion). It'd make a good joke though. Maybe on day, for
> April's fool, the Krita coders can make a joke announcement on
> renaming the tools and options. :P

Heck, no! I want the interface to actually *change* on April 1. Every 
April 1 ;-). Easter egg, anyone?

I mean, all we need is a few extra strings and an extra icon...

> - but a raster/brush solution is also helpful: you may not be
> wanting to do a simple line, but say... dots. Or tomatoes.
> You get the idea? Gimp's "stroke to path" option basically has an 
> entry for brush.

I consider stroking a path a mandatory feature :-). Anyway, it's just 
another type of

(Now... if we could save arbitrary stokes as well, which should be 
do-able... then we can add a mode where *all* strokes are saved, and 
suddenly we have a scalable raster graphics program, like the really old 
one someone was talking about a while back. And that I think would 
*seriously* rock. Because now you have infinite and persistent undo, can 
add strokes anywhere in the stack, re-render at higher resolution, and 
all sorts of Very Cool stuff.)

> - that said, this Could be a dedicated tracing tool aside from the
> generic brush, with presets (such as double-fade) that take
> specific values, and that you can only use in Bezier mode.

If it's only in Bezier mode anyway, I'd implement it via 'fake 
pressure'... so what you're actually manipulating in the stroke is the 
reported pen pressure. It's up to you to have your PaintTool set to 
respond to that as you want it to.

> This sounds like the node-based approach though that the rest of
> you were discussing a while back, so each stroke is basically
> generated from position nodes that can be edited no matter how
> far along you've been. Is that it?

Yes and no. It is, because everything starts as a Stroke, which is 
nodes, yes... but initially I wouldn't expect every Stroke to be 
persisted. (Some, i.e. paths, would be, but Strokes from e.g. the 
freehand tool probably would not; or again, not right away.) But as 
noted above, I think that has some sweet potential.

> What's the interface though?
> (because if I start drawing, I kind of really don't want to 
> think of the blob of paints on my canvas as vectors :P It can be
> that architecture-wise, of course, but the interface should make
> sense to an artist)

Just like it is now. You start painting, and paint appears. Most Strokes 
  should be able to call down to the PaintTool and PaintOp in real-time 
or near-real-time (I could understand for smoothing if the last few 
pixels aren't updated). Basically, as you say, I'd do it architecturally 
without making any easily noticeable changes in the user experience. In 
fact, I would make it an implementation requirement that the freehand 
tool seems to the user to behave the same. Stroke persistence is 
something for later.

-- 
Matthew
ELANG: input is in wrong language (please use English on English lists)