Yet another brush interface proposal
mw_triad at users.sourceforge.net
Tue Mar 25 18:07:21 CET 2008
>> 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
>> 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.
ELANG: input is in wrong language (please use English on English lists)
More information about the kimageshop