I like this. It's well thought out, and practical. One part I wonder
if you considered, is that only the last 'absolute' modifier for a
target would apply; the ineffective controls should be marked as such.

A tree visualization could work better:

Opacity <-
   Pressure [percent] [0][1.0]
Size <-
   Pressure [relative] [-20][50]
Angle <-
   Direction [absolute] [0][360]

Then it would be clear; the uppermost [absolute] entry for a target
would take effect.

Another thing to consider: eventually, we'd probably want to move
towards using curves to control pressure/direction/.. responses.

Consider bringing your idea up on the gimp-developer mailing list, or here:
http://bugzilla.gnome.org/show_bug.cgi?id=119240


On Jan 6, 2008 4:55 PM, Brian Vanderburg II <[EMAIL PROTECTED]> wrote:
> This is an idea that I think would be very nice to have in GIMP.  It
> would probably take a bit of programming, and I can't do that unfortunately.
>
> Definitions:
> I'm not sure of the proper terms, so I will define what I mean:
>
> Controller - A source of data that is used to modify an attribute of the
> brush
> Attribute - Part of the data for a brush, such as size, color, opacity,
> angle, etc, etc.  Can be modified by a controller.
>
> Problems:
> The current control-to-attribute has few features and does not offer a
> great deal of control to the user.  It only supports one control and a
> few attributes.  Additionally, for the attributes, there is no
> specification for how much the attribute is affected.  What I mean is,
> in the toolbox you can check to have the pressure affect the opacity,
> but not by any given range.
>
> Each attribute connected to a control should have some parameters.
> Three important ones are start-adjustment, end-adjustment, and
> adjustment-type.
>
> adjustment-type can be 'absolute', 'relative', or 'percent', and
> start-adjustment/end-adjustment would the the absolute, relative, or
> percentage of adjustment caused to the selected attribute based on the
> value of the controller.
>
> If adjustment-type is 'relative', adjustment-start is '-10',
> adjustment-end is '10', the selected attribute is brush-size, and the
> brush size is currently 76, then the controller would cause the brush to
> go from 66 to 86. if the controller value at the time the data is
> sampled is 0, then it would be 66, if the controller value is 1, it
> would be 86.
>
> If adjustment-type is 'absolute', adjustment-start is '50',
> adjustment-end is '75', the selected attribute is brush-size, and the
> brush size is currently 76 (that does not matter since it is absolute),
> then the controller would cause the brush to go from 50 to 75. if the
> controller value at the time the data is sampled is 0, then it would be
> 50, if the controller value is 1, it would be 75
>
> If the adjustment-type is 'percent', then it is relative but by
> percentage. If adjustment-start is '50% (0.5)', adjustment-end is '150%
> (1.5)', the selected attribute is brush-size, and the brush size is
> currently 76, then the controller would cause the brush to go from 38 to
> 114. if the controller value at the time the data is sampled is 0, then
> it would be 38, if the controller value is 1, it would be 114
>
> adjustment-start can also be larger than adjustment-end, to cause the
> opposite affect.  For example, to have the opacity be higher with a
> 'soft' pressure than with a 'hard' pressure
>
> Controller-attribute chain:
> The design could be such that for each controller, the user can select
> which attribute(s) is modified, and set the parameters, the problem is
> that one controller can only be connected the attributes and shares the
> parameters
>
> GUI:
>     [Checkbox] - Controller1 Enabled
>        [Checkbox] - Attribute1 affected
>        [Checkbox] - Attribute2 affected
>        ...
>        [Checkbox] -AttributeN affected
>        ___
>        [RadioBox]-Adjustment Type
>        [NumberBox]-Adjustment Start
>        [NumberBox]-Adjustment End
>
> This would allow the user to enable the controller, tell it that the
> controller affects this attribute and that one, and the parameters.  But
> the parameters are the same for  Controller1->Attribute2 and
> Controller1->Attribute2.  It would be desired to have separate
> parameters for different controller->attribute links.  For example,
> pressure may vary opacity by a certain amount, but size by an even
> greater amount, for this to be, they can't share parameters.
>
> A controller-attribute chain is really just a list of what controller
> affects what attribute, and parameters for that specific item:
>
> struct ControllerAttributeSomethingOrAnother
> {
>     int controllerSource;
>     int targetAttribute;
>     AdjustmentType type;
>     double start;
>     double end;
> }
>
> When a given brush is applied, each item in the chain would be applied
> to the 'original' brush attributes, modifying it by some manor:
>
>
> BrushAttributes b = GetCurrentBrushAttributes();
>
> foreach item in chain
> {
>     // interpolate the controller value with the start/end range
>     // so that controller value 0 represents the start value and
> controller value 1 represents the end value
>     double control_value = GetControllerValue(item.controllerSource) *
> (item.end - item.start) + item.start;
>     double value;
>
>     switch(item.type)
>     {
>         case 'absolute'
>            value = control_value;
>            break;
>        case 'relative'
>            value = control_value +
> b.GetAttributeValue(item.targetAttribute);
>            break;
>         case 'percent'
>             value = control_value *
> b.GetAttributeValue(item.targetAttribute);
>              break;
>     }
>
>     b.SetAttributeValue(item.targetAttribute, value);
> }
>
> It would also be possible for the same attribute to be affected by two
> different controllers.  Order does matter for such things, such as
> Pressure->Opacity percent 0%-100%
> Direction->Opacity relative -0.2-0.2
> Inital opacity: 75% (0.75)
> Pressure controller: 0.75
> Direction controller: 0.75
>
> Results:
> 1. opacity becomes 56% (0.5625) from Pressure->Opacity
> 2. opacity becomes 66% (0.6625) from Direction->Opacity
>
> Results if order is switched:
> 1. opacity becomes 85% (0.85) from Direction->Opacity
> 2. opacity becomes 63% (0.6375) from Pressure->Opacity
>
> Additional types of controllers and attributes:
> I also think it would be nice if there were some additional controllers
> and additional attributes:
>
> Controllers:
>     pressure - Same as usual, represents the pressure, only specialized
> devices can use it (tablets)
>     tilt - Again only special devices can support it
>     rotation - Not the same as 'direction' below, but some devices can
> detect the rotation of the pen on the tablet, or so I've heard
>     direction - Based on sampling the position of two points, determine
> the direction of the line from the first point to the second point
>     speed - Determine timing between the sampling of two points
>     noise - A random source from 0 to 1. This can allow the 'jitter'
> option to be applied to other things, such as jitter the color or size
> as well.
>               Note that a 'noise' controller is different than a
> 'jitter' attribute  It allows an attribute to be 'randomly' changed.  It
> can even be connected to the 'jitter' attribute to allow the jitter
> radius to be random.
>
> Attributes:
>     opacity
>     size
>     color
>     hue
>     saturation
>     lightness
>     gradient - When using a gradient for a stroke, normally it is based
> on the movement of distance.  This would allow a controller to select
> what part of the gradient to use.  The valid range would be from 0
> (start of gradient) to 1 (end of gradient).  The initial value of this
> attribute would be computed as normal (distance into the stroke and the
> length), and adjustment types would still work, absolute specifying an
> exact position, and relative/percent specifying a position offset from
> where it is 'supposed' to be in the gradient
>     angle - One useful combination would be to connect a 'direction'
> controller to the 'angle' attribute, so it seems that the brush is
> rotating with the stroke.  This means that 'direction' and 'angle' would
> need to be in the same orientation, either both clockwise or both
> counter clockwise.
>     jitter - The position of the applied stroke.  Default value is 0
> (draw where the cursor is), but it can be adjusted by by a controller if
> desired.  For example, a light pressure can draw directly at the given
> position and a hard pressure can increase the jitter radius.
>
> GUI interface:
> A new dialog would exist which would allow the creation of the
> controller-attribute chain.  Some features would thus be removed from
> the toolbox.  It may still be desired to have a separate 'chain' per
> tool, similar to how the settings of one tool can be difference from the
> other tool, and when selecting the first tool, it will restore it
> settings like blend mode/etc.  It may be desirable to implement separate
> chains per tool, so when the user selects one tool, it's chain is used,
> and when selecting another tool, it's chain is reloaded and used.
>
> This new dialog would consist of a list-like control that is by default
> empty, with a +/- button to add a new item to the chain.  Pressing '+'
> would insert a new item with default values, '-' would remove the
> selected item, also maybe a '*' to clone the current item.
>
> Attached is a small mock-up of an idea for the interface. It shows 3
> items in the list chain.
>
> *Pressure will adjust the opacity by the current value from 0 to 100
> percent.  If the brush opacity is 75%, then it will vary from 0 to 75%
> based on the pressure.
> *Pressure will adjust the size by the current value from -20 to 50.  If
> the brush size is currently 45, it will vary from 20 to 95 based on the
> pressure
> *Direction will adjust the angle by an absolute value from 0 to 1.  (0
> to 360 degrees of direction will adjust the angle of the brush from 0 to
> 360 degrees).  Since it is absolute, the current brush angle is
> disregarded.  If it was relative, it would be added to the current brush
> angle.  More often, relative would probably be the desired setting and
> not absolute, as the initial 'angle' for the brush may be properly set.
> Also, how this would work for bitmap brushes would be unclear, (the
> bitmap would be rotated, and may loose quality), but if it was a vector
> brush, it would probably work fine as rotation would not cause bad
> quality..
>
> Again this is just an idea that I think would be useful and would love
> to see in a future version.  The code shown is just the idea for
> operation, I don't know much about the actual GIMP code.
>
> Brian Vanderburg II
>
> _______________________________________________
> Gimp-user mailing list
> Gimp-user@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
>
>
_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Reply via email to