Hi Brian Vanderburg II

Maybe you are thinking about something like Mypaint ==>**ee-staff.ethz.ch/~mrenold/mypaint (put http:// instead of **) I advice you to try it. It's better if you have a graphic tablet.

Happy New Year!

Roland (wildhostile).

I joined the list so recently that I hadn't seen the proposal from Brian Vanderburg II, now I looked it up from the archives. The patch that I made addresses basics what is desired as "attributes". He offers and interesting concepts for dynamic adjustments GUI. That and the rest falls into what part 2 of my proposal encompassed, an overhaul to paint-core I believe.

I wrote a proposal to enhance the gimp brush code quite a few years ago, which can still be found here:

http://members.ozemail.com.au/~hodsond/gimpbrush.html

You might want to see if it contains any useful ideas.

On Friday 11 January 2008 01:29:17 David Hodson wrote:

I wrote a proposal to enhance the gimp brush code quite a few years ago, which can still be found here:

http://members.ozemail.com.au/~hodsond/gimpbrush.html

You might want to see if it contains any useful ideas.

Ive read it:) Thanks. It does contain some interesting concepts like having unified rendering code and a filter stack.

Best, Alexia

Alexia Death schrieb:

On Friday 11 January 2008 01:29:17 David Hodson wrote:

I wrote a proposal to enhance the gimp brush code quite a few years ago, which can still be found here:

http://members.ozemail.com.au/~hodsond/gimpbrush.html

You might want to see if it contains any useful ideas.

Ive read it:) Thanks. It does contain some interesting concepts like having unified rendering code and a filter stack.

I agree. :) I have been looking at the GIMP code recently to look for possibilities of implementing some features that could make GIMP more useful for artists that create paintings from scratch (which includes me ;)). A more powerful and flexible brush engine would be near the top of the list.

This would likely also cover the SVG brushes (very appealing idea) and adjustable input curves proposals.

Maybe someone with more insight into the code could give an outline of how it currently works? I am willing to invest some time studying the code myself, but unfortunately it is very scarcely documented and so I am not sure how the various components interact.

Also it would be nice to know if there are already more concrete plans for this (GEGL stuff?), or even if someone is already working on it.

Cheers,

Jörn

On Tuesday 11 March 2008 21:46:41 Joern P. Meier wrote:

I have been looking at the GIMP code recently to look for possibilities of implementing some features that could make GIMP more useful for artists that create paintings from scratch (which includes me ;)).

Yay! Another art buff interested in brushes.

A more powerful and flexible brush engine would be near the top of the list.

So true.

This would likely also cover the SVG brushes (very appealing idea) and adjustable input curves proposals.

And dynamics,,, That's important too IMHO. Ability to bind any brush property to one or more motion dynamics, primary or derived (speed, tilt,pressure, angular speed, etc...) .

Maybe someone with more insight into the code could give an outline of how it currently works?
I am willing to invest some time studying the code myself, but unfortunately it is very scarcely documented and so I am not sure how the various components interact.

Gimp is large code wise. I opted for trying to understand the bits I'm working on and not the whole thing at once ;)

I have been hacking in the event side of things since early this year and I'm slowly starting to get a clue how things relate to each other. Perhaps best for you to learn is to trace events stating from display shell callbacks to the drawing code in various tools to get the overview you need?

As I understand it now paint core handles most of painting related stuff, different brush types are dervates of GimpBrush that overload the functions in witch thy differ. Making a new brush type should not be that difficult, but integrating it to UI... That part is a mystery to me.

Also it would be nice to know if there are already more concrete plans for this (GEGL stuff?), or even if someone is already working on it.

Somebody is working on some gegl stuff but its not really usable yet as far as painting goes.

On Wed, Mar 12, 2008 at 9:21 AM, Alexia Death wrote:

On Tuesday 11 March 2008 21:46:41 Joern P. Meier wrote: > I have been looking at the GIMP code recently to look for > possibilities of implementing some features that could make GIMP more > useful for artists that create paintings from scratch (which includes me > ;)).
Yay! Another art buff interested in brushes.

> A more powerful and flexible brush engine would be near the top of > the list.
So true.

> This would likely also cover the SVG brushes (very appealing idea) and > adjustable input curves proposals. And dynamics,,, That's important too IMHO. Ability to bind any brush property to one or more motion dynamics, primary or derived (speed, tilt,pressure, angular speed, etc...) .

Angular speed? Do you mean 'turning speed', otherwise known as torque?

Maybe someone with more insight into the code could give an outline of

> how it currently works?
> I am willing to invest some time studying the > code myself, but unfortunately it is very scarcely documented and so I > am not sure how the various components interact. Gimp is large code wise. I opted for trying to understand the bits I'm working on and not the whole thing at once ;)

I have been hacking in the event side of things since early this year and I'm slowly starting to get a clue how things relate to each other. Perhaps best for you to learn is to trace events stating from display shell callbacks to the drawing code in various tools to get the overview you need?

As I understand it now paint core handles most of painting related stuff, different brush types are dervates of GimpBrush that overload the functions in witch thy differ. Making a new brush type should not be that difficult, but integrating it to UI... That part is a mystery to me.

The UI is a mystery because no one has worked it out yet. The current design, with two places to control brush behaviour (brushes dialog, and brush editor)
is clearly unsatisfactory. The design seen in mypaint is capable, and it uses up far too much space.
Personally, I envision a GUI like

[target selector] list | this
of | source's
sources | parameters
[add] [remove]

(keeping in mind that it would be very helpful for the dialog to be small enough to be a dockable.

for example, the first item in Brian's first mockup would show like this

[Opacity] Pressure % | CURVE
| HERE

The second would show up like [Size]
Pressure -+ | CURVE
| HERE [1]

and the last would show up like

[Angle] Direction =| CURVE
| HERE [1]

Doubleclicking on an item in the list of sources ought to allow it to be changed to another kind (different source, or different kind of modification).
There should be a quick way to set a single constant value for the curve. shift+click?
There should also be a quick way to enable or disable a particular adjustment

Such a dockable should include targets such as

size opacity
hardness
color from FG/BG (need way to specify opacity for color mix) color from gradient (see above)
dissolve (yes, this sets a percentage of the pixels to transparent, just like dissolve does. I used this once in Pixia and found it a very useful fundamental adjustment)
jitter (replacing the jitter options from paint tool options) rate/exposure (note: ignored for tools that have neither) airbrush pressure (note: airbrush normally inverts the size adjustment. how to account for this?) torque (as suggested by you, Alexia. Well, torque is the technically correct term, however none of the candidates, including 'torque', are very meaningful to a casual inspection.. the final name might be something different again.)

and sources such as time (need some way to set length) -- this would allow you to do 'fade' in a more flexible way.
speed
tilt (note: this is a hardware-provided value, from eg. Wacom Intuos tablets) angle
pressure

This still leaves the matter of VBR editing and later, SVG brush editing. I think we could put them in an expander underneath the main part, in recognition of the fact that they are going to be accessed less often. We also need to ensure that only the things that really are specific to individual brush types go there. eg aspect ratio, rotation, hardness are things that make sense in context of any brush, not only VBRs or SVG.

Oh yes, the UI separation of brush types.. IIRC it's more or less a hack (VBRs are the only editable type, and editing a brush brings up a VBR editor)

When I get my system fully working again, I plan to prototype various UI possibilities in this area using PyGTK, and post the source+screenshots. A UI spec would be helpful, and probably not very possible until there is some UI to try.

Also it would be nice to know if there are already more concrete plans

> for this (GEGL stuff?), or even if someone is already working on it. Somebody is working on some gegl stuff but its not really usable yet as far as painting goes.

Yes. At this point, it would be possible to implement eg. brush rotation using GEGL ops. That would be getting ahead of ourselves, I just want to point out that it is currently possible to do -- and would even be relatively simple.

Joern P. Meier wrote:

Maybe someone with more insight into the code could give an outline of how it currently works? I am willing to invest some time studying the code myself, but unfortunately it is very scarcely documented and so I am not sure how the various components interact.

That isn't easy. I suggest, very strongly, that you start by picking a single, relatively simple, type of change you would like to make, instead of thinking in general terms. This will make it possible to point you to the relevant parts of the code, and perhaps even to describe how those parts work. Once you have learned from this experience, it will be much easier to go on to other things.

(You could perhaps suggest two or three changes you are interested in, and we could tell you which of them might be best to start with.)

-- Bill

Hi,
00ai99@gmail.com (2008-03-12 at 1824.16 +1030):

The UI is a mystery because no one has worked it out yet. The current design, with two places to control brush behaviour (brushes dialog, and brush editor)
is clearly unsatisfactory. The design seen in mypaint is capable, and it uses up far too much space.

2+1, if the brush is hose kind (.gih), you have another control place (and very well "hidden", to the point of making those brushes rather tiresome or "mere experimental toys").

GSR

Alexia Death wrote:

Gimp is large code wise. I opted for trying to understand the bits I'm working on and not the whole thing at once ;)

That would only be the ultimate goal, of course. ;)

I have been hacking in the event side of things since early this year and I'm slowly starting to get a clue how things relate to each other. Perhaps best for you to learn is to trace events stating from display shell callbacks to the drawing code in various tools to get the overview you need?

Thanks for the hint, I will try this approach. :)

As I understand it now paint core handles most of painting related stuff, different brush types are dervates of GimpBrush that overload the functions in witch thy differ. Making a new brush type should not be that difficult, but integrating it to UI... That part is a mystery to me.

Maybe adding a new brush type wouldn't be difficult, but actually implementing a component based "brush synthesizer" (to use David Hodson's ARP 2500 analogy ;)) might be.

The problem with a selection of hardcoded brush types seems to be that artists cannot really be creative with creating brushes since they would have to be developers at the same time.

Where hard coding is required in the brush engine, it should be done using dynamically loadable modules (or plug-ins, if you will).

The real power of such a system would come from combining the predefined components in ways the developers had never thought of, which means not just twisting knobs on predefined brushes, but also pushing the components around on a filter stack and being able to configure which parameters are affected by the filter (much like in David's proposal).

But I do understand that this would be quite a huge task (especially with a GUI to match).

David Gowers schrieb:

On Wed, Mar 12, 2008 at 9:21 AM, Alexia Death

And dynamics,,, That's important too IMHO. Ability to bind any brush property to one or more motion dynamics, primary or derived (speed, tilt,pressure,angular speed, etc...) .

Angular speed? Do you mean 'turning speed', otherwise known as torque?

Angular speed actually is the correct term ;) (torque is what causes angular acceleration). The angular speed would be obtained by approximating the motion of the brush with a circular curve and calculating the change of angle along this segment per time unit. It actually would be a data source to be mapped, rather than a target.

Bill Skaggs wrote:

That isn't easy. I suggest, very strongly, that you start by picking a single, relatively simple, type of change you would like to make, instead of thinking in general terms. This will make it possible to point you to the relevant parts of the code, and perhaps even to describe how those parts work. Once you have learned from this experience, it will be much easier to go on to other things.

You are right of course. But it is difficult to suggest even simple changes without having a good general understanding of the code (I am just referring to the brush right now and how the chain progresses from the actual input to the brush image appearing on the canvas).

Anyway, I think I am progressing, slowly, with a general idea of how things work. I am currently trying to figure out:

1) How to add a new tool (say, my own hardcoded brush) including widgets for setting options to the UI. The ChangeLog suggests that bits of code have to be added all over the place (gimp-tools.c, gimp-paint.c for the tool, where the UI gets added I have currently no idea).

2) What changes in the state if a new tool is selected.

3) How the tool is invoked. I think I have a general idea, that is, the button_press/motion/button_release events get passed down from the gimp_display_shell to tool_manager, to the active tool (brush,_tool, which is a paint_tool in this case), to the paint_core, to the brush core (paintbrush in this case).

4) How the brush gets applied to the canvas. Right now I think a mask is obtained from whatever brush is selected and this is then pasted to the canvas using the various options.

Souichi TAKASHIGE schrieb:

I'm recently working on developing new PaintBrush extension framework. It's on early development stage, but I'd like to get comments about the framework.

I would be happy to play around with it, if it can be applied to a current version of GIMP. :)

I do not quite understand what the blend brush actually does, but it looks cool. ;)

Cheers,

Joern

Joern P. Meier wrote:

Maybe adding a new brush type wouldn't be difficult, but actually implementing a component based "brush synthesizer" (to use David Hodson's ARP 2500 analogy ;)) might be. [...]
The real power of such a system would come from combining the predefined components in ways the developers had never thought of, which means not just twisting knobs on predefined brushes, but also pushing the components around on a filter stack and being able to configure which parameters are affected by the filter (much like in David's proposal).

But I do understand that this would be quite a huge task (especially with a GUI to match).

That's right, and that's pretty much where I got stalled and ran out of free time to work on it. The first step would be to demonstrate the power of the approach by duplicating (then replacing) all the existing brush types, using fixed filter stacks and fixed control attachments. Then add code to read and write the stack configuration, and it would be easy to add a whole set of fancy brush types just by thinking up new arrangements of filter stacks - you would want these anyway (in libraries, like patterns or gradients), for artists who didn't want to go behind the scenes. You could write a lot of useful code before needing to tackle the editing GUI.