gimp is not a good choise for digital painting because it doesnt have a blending tool. Paint tool sai in the respect is far superior because its brush engine is much more advanced for smooth blending

On Sun, Apr 26, 2009 at 11:37 AM, LightningIsMyName < lightningismyname@gmail.com> wrote:

Hello,

Gimp 2.6 allows to use brush dynamics to control opacity, size, hard and color.
These features greatly increase the drawing capabilities of gimp, and many users find them very useful.
However, we don't have any way to access these from inside the PDB...

I think that it would be nice to be able to access these using the PDB, however
I'm not sure about the right method: Do we want to allow the user to specify velocity, and pressure for each coord,
or should we use the "emulate brush dynamics" feature (the same one we have in
the libart stroking)? Personally, I believe that the "emulate brush dynamics"
is the right method.

I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc.

~LightningIsMyName

Hi LIMN,

On Sun, Apr 26, 2009 at 7:07 PM, LightningIsMyName wrote:

Hello,

Gimp 2.6 allows to use brush dynamics to control opacity, size, hard and color. These features greatly increase the drawing capabilities of gimp, and many users find them very useful.
However, we don't have any way to access these from inside the PDB...

I think that it would be nice to be able to access these using the PDB, however I'm not sure about the right method: Do we want to allow the user to specify velocity, and pressure for each coord, or should we use the "emulate brush dynamics" feature (the same one we have in the libart stroking)? Personally, I believe that the "emulate brush dynamics" is the right method.

We should definitely make dynamics available, but IMO both of these methods is quite unsuitable and would only add to the current inconsistencies of the pdb interface to paint tools.

In my opinion this is what needs to happen: A) Migrate paint tools at least partially to GEGL (so that the actual rendering of strokes is done by evaluating a 1-node GEGL graph). This will help us define a consistent, expansion-compatible way of communicating and storing stroke information. B) Make a system for handling both full strokes (where each point specifies parameters such as brush scale, rotation, aspect ratio, spacing directly) and simple strokes (where each point only specifies the 'source' information -- pressure, velocity, angle, etc.), and converting simple to full strokes
C) Work out a way to pass this information through the PDB, in a backwards + forwards-compatible way
-- so that older scripts work in newer versions because their missing fields are automatically expanded and filled in with sensible default values, and that newer scripts work (in a limited sense) in older versions of GIMP.
D) Provide a method of constructing and communicating GEGL graphs through the PDB.
This can be used by scripts to actually do the required painting. E) Use it (and deprecate the current 'gimp-paintbrush' etc API)

I also think we need to look harder at our current inability to communicate various tool options such as Jitter, Color from Gradient, and Incremental; possibly communicate these via a keyword-argument sort of interface (ala Python)

I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc.

Do you understand that you must not change the api of gimp-paintbrush, gimp-airbrush, etc? Because that would break a lot of scripts and plugins. This is part of the problem with the current PDB interface to tools; supporting new options must be done through additional PDB functions.

David

Hi Theodore,

On Sun, Apr 26, 2009 at 8:00 PM, Theodore Imre wrote:

gimp is not a good choise for digital painting because it doesnt have a blending tool. Paint tool sai in the respect is far superior because its brush engine is much more advanced for smooth blending

Please keep your replies on topic.

This thread is about improving the plugin API to the painting system of GIMP (which is not, anyway, a program for digital painting, but a 'Image Manipulation Program'; naturally tools designed for digital painting, Like MyPaint or Krita, will be better for digital painting.)

As Paint Tool Sai is also not open-source, it definitely has no relevance to this thread, unless it also possesses a programming API for plugins or scripts to non-interactively paint which solves this same problem, and which you will describe.

David

So is your thought to provide a new set of PDB calls with extra parameters like brush scale, jitter, etc? The drawback to this might be that as more brush dynamics get added the functions will get obsoleted, much the current set that provide gradient colouring.

Here is another question... Should the basic paint calls (I.e. Those with the description "using current brush") that have no parameters just be changed to paint respecting all the current brush options, like scaling, jitter, etc. ?

-Rob A>

On 4/26/09, LightningIsMyName wrote:

Hello,

On Sun, Apr 26, 2009 at 1:43 PM, David Gowers wrote:

I'm willing to try to write a patch to add this for gimp-paintbrush, gimp-airbrush, etc.

Do you understand that you must not change the api of gimp-paintbrush, gimp-airbrush, etc? Because that would break a lot of scripts and plugins. This is part of the problem with the current PDB interface to tools; supporting new options must be done through additional PDB functions.

David

I understand that, we obviously mustn't change the old API. What I meant was to create something like gimp-paintbrush-wtih-dynamics.

The question is, when and how do we want to do this? Do we want to give some sort of option now, and we will replace it when we move to GEGL painting, or should we wait? I would like to see it implemented before 2.8 if possible, however If we need to wait with this, i'll wait.

~LightningIsMyName
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Mon, Apr 27, 2009 at 4:42 AM, Rob Antonishen wrote:

Here is another question... Should the basic paint calls (I.e. Those with the description "using current brush") that have no parameters just be changed to paint respecting all the current brush options, like scaling, jitter, etc. ?

We cannot do that, unfortunately, as it would substantially change the meaning and effect of some existing scripts and plug-ins.

David