Re: [Gimp-developer] Paint core beyond 2.6
On Sunday 08 June 2008 03:07:15 David Gowers wrote: * support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box); A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these? In my vision you could choose arbitrary number of these including the same item twice and then apply different curves to both instances. I'm not 100% how that can be implemented tho. * If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ? They would all have range of 0.0...1.0 just like random, velocity etc now in SVN. I think sin and cos could be implemented as a subcase of 'custom': a custom curve input. All these calculated axis would be a sort of custom. Allowing a free formula type is an option as well but It may be harder to implement. * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? I mean both. The dream is that paincore would only need to worry about painting a stamp at a given event, the where? part is all handled by paint core. The distance in this case is the stamp spacing. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for event mixed influence. Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and unsaved tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent. -- Alexia P.S redirecting back to list, ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint core beyond 2.6
Hi Alexia, On Sun, Jun 8, 2008 at 6:18 PM, Alexia Death [EMAIL PROTECTED] wrote: * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? I mean both. The dream is that paincore would only need to worry about Yes, that's what I meant, sorry. painting a stamp at a given event, the where? part is all handled by paint core. The distance in this case is the stamp spacing. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for What you describe is redundant if you expose those separately... since they currently effect either color or opacity according to distance from start of stroke. That's why I said replicate. I think you could improve this idea a lot by making some mockups, where you can easily spot and eliminate unnecessary redundancies. (I'm certain that there are quite a few neither of us has noticed.) Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made This sounds pretty good! I'd like to suggest the use of bottom-scaling as well as top-scaling here: that is, allow the quick adjustment to either scale down like 0..1 becomes 0..0.5 (scale == 0.5) or scale down like 0..1 becomes 0.5..1.0 (scale - 0.5). I can certainly vouch that I've wanted this a lot of times for Size -- the minimum size ends up far too small sometimes. are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and unsaved tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent. Yes, mockup sounds like it would help. I think what you describe above doesn't yet warrant the description of creating new user-tools. Mainly because it does not support some things that are important at a tool-level: Hard Edge, Clone-like behaviour. Consider talking to peter specifically about this -- he has the 'Dabs of paint' idea, which IMO is more correct than associating settings with either a brush or a tool; In the same way that acrylic paint on a brush has quite different physics than watercolor paint on the same brush. What you are talking about might be called something more like a tool-tip (yes, unfortunate but accurate; how about pen-tip? paint-tip?) IMO a good distinction is like: * tool : what you are doing and how you are doing it * tip : the precise effect that occurs when painting * brush: the area and amount in which it is applied. * paint : all of the actual pixels that end up being applied. HTH, David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Paint core beyond 2.6
This is a planning idea for new PaintCore for GIMP 2.8 or beyond. 1: The Why?. Current paint core is just not flexible enough and migration to GEGL based paint core is planned anyway. So why not do the best possible paint core since we are redoing it anyway? 2: What is the goal? In general: Best possible digital painting tools. That should NOT include any natural painting things like watercolor emulation or alike but full featured tool for use on digital medium for image processing, touch-up etc. What does the above mean? * Easily extensible framework for creation of painting tools * Fully dynamic painting, meaning that every adjustable aspect is user input controllable * Easily distributable paint tool presets that allow a the complete tool context to be saved and loaded either on same or different machine How I see that happening? Step one: Event handler for paint tools. This is a very important bit for fully featured tools. All devices have some dynamic properties that are useful in painting on the digital canvas. * Mice have velocity(and acceleration), cheap tablets add pressure, more expensive ones may add even more axis. * All movement has direction * Purely calculated axis like random can be extremely useful. * Paint tools want events at a constant distance or at a constant distance AND rate. Devices will never provide exactly what is needed so adjustment is required. The extra events need to be discarded and events that are missing interpolated. The method of interpolation depends on the axis in question. So event handler should: * be able to handle a number of device axis and apply per device curves * support calculated axis based on what device provides and also support applying device curves * support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box); * be able to deliver constant distance and constant rate events Step two: Paint Core Paint core should provide framework for interacting with the canvas, controlling the event handler and the saving and loading of paint tool contexts as Paintbrushes, Erasers, Sponges etc with previews. Paint core should also facilitate curves based mapping of event handler axis to tool parameters. All paint tools expose parameters that may be mapped to any axis event handler can provide. Step X: Paint tools: Brush tool: Simple painting tool, support for all current brush formats is a must. Must support at least scaling and rotation of brushes. Airbrush tool: Almost the same as brush tool but orders constant rate of events from event handler. etc tools: Use paint tool framework, only the paint action itself differs. That's just my Idea for the step two of my last piece from a while ago on brushes in GIMP. Sven, Pippin, Peter, everybody - comments? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Paint core beyond 2.6
Hi Alexia, On Sun, Jun 8, 2008 at 5:52 AM, Alexia Death [EMAIL PROTECTED] wrote: This is a planning idea for new PaintCore for GIMP 2.8 or beyond. [...] * support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box); A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these? * If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ? I think sin and cos could be implemented as a subcase of 'custom': a custom curve input. * be able to deliver constant distance and constant rate events You mean events at a constant distance spacing or a constant time spacing? According to what you wrote above, a 'distance' axis might be good. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
