Re: RFC: unified system of PaintObjects (long)
On Wed, Feb 14, 2001 at 02:00:28PM +, Austin Donnelly wrote: On , 9 Feb 2001, Jens Lautenbacher wrote: Therefore I propose to completely rewrite everything that can be considered a "PaintObject" into a generic provider form, where the paintcore for each operation asks the provider for it's data. It would be nice to be able to use loadable modules to implement new "providers", so that the first cut can ignore natural media, but then (eg Raph?) can add them later as a module. Basically, make it a nice harness for the people playing with watercolour simulators etc to use. or painting on to other surfaces that are not flat (ie, 3d paint thingy) or having a bump/displacement map "paint filter"... just throwing ideas... Austin
Re: RFC: unified system of PaintObjects (long)
On , 9 Feb 2001, Jens Lautenbacher wrote: Therefore I propose to completely rewrite everything that can be considered a "PaintObject" into a generic provider form, where the paintcore for each operation asks the provider for it's data. It would be nice to be able to use loadable modules to implement new "providers", so that the first cut can ignore natural media, but then (eg Raph?) can add them later as a module. Basically, make it a nice harness for the people playing with watercolour simulators etc to use. Austin
RFC: unified system of PaintObjects (long)
Hi all, This mail comes from some discussions I had with Sven around the time just before 1.2.0, the recent discussion about textures and natural painting and a chat on IRC yesterday with Sven. He told me to write down what I said there and post it to the mailing list as a RFC --- I assume, just because he's limited on time, as anything he could have written would be much more informed and better grounded on reality than all I can come up with. When we (sven and me) rewrote the pipe code to handle pixmap/bitmap pipes and rewrote the pixmap brushes to drop the old format, we became aware of what a mess the current handling of brushes vs. patterns vs. pipes and so on is, as all of these objects are totally different or at least the inheritance structure is counterintuitive (at least for me) Therefore I propose to completely rewrite everything that can be considered a "PaintObject" into a generic provider form, where the paintcore for each operation asks the provider for it's data. E.g. a brush pipe is a provider that gives back a tempbuf of grayscale data (a brush) or a pixmap brush when asked for it. Besides providers that give back pixmap data, there will be scalar providers, which can be used for example to return color values. Painting with the color selected from a gradient will be just using a color provider object, that uses a gradient as it's LUT for color values. All the providers will get as an input parameter the current global state of the input device, so all providers will be able to select matching output data much the same way the current pipe does. As David already pointed out, it doesn't make sense to only provide for the possibility for a pipe to select from a fixed set of pregenerated pixmaps. this is nice for the current limited pipe, but when using a general pipe as a provider for textures/patterns/brushes one wants to have the possibility to match certain or all dimensions of the data space to a function. Here the question naturally arises: what kind of functions should be possible? Only transformations? Only some set of functions that are predefined in the core? Or could there be some possibility to handle user provided functions? How would these (if possible) be specified in a fileformat? or just LUTs that are used by functionality that is special to the object (e.g. for textures, there needs to be some special functionality on how to map the input state (mainly pressure I assume) to the final buffer returned. Here a LUT or a simply scalar function seems to be the way to go. For performance reasons, all ProviderObjects should automatically have a LRU Cache (or some tuned variant of it) to store already computed values. This of course can be handled in a base class for them, so implementing another provider doesn't need the programmer to cope with this anymore. Another thing that should be really well thought about is how far this abstraction is presented to the user. Having all of the paintobjects fulfill a generic interface w.r.t the paintcore it makes it possible to e.g. use a texture as a brush and vice versa. I would still strongly argue against presenting such a possibility to the user. From his/her point of view, a brush is NOT a pattern, nor a texture. I'd think that a user wishing to use a brush as a pattern can always load the brushfile in the gimp, and save it as a pattern (remember that we talk about general pipes here already: laoding a brush and saving it as a pattern will result in a pattern that changes according to the input state in the same way as the original brush does.) Another thing that's important when talking about brushes, patterns and stuff is the way they are presented to the user (in grids or lists). As Sven told me, Mitch is already working on this, so maybe my comments are way off here, but anyway: All of these providers should fulfill another contract with some ViewContainers so they are able to draw representations of themself into such a container. As far as I understood Sven, Mitch already has some kind of a GimpViewable object and a general container type to handle them. My suggestion goes along the line that this functionality should be put into the same object as the PaintProvider, so one object is able to do the work it's supposed to do AND draw it's representation to the screen. Ok, I hope this is not too mixed up, I wrote it at work with a lot of people distracting me with things that pay my bills :-) I would like to hear comments one some of these suggestions from you. regards, jtl
Re: RFC: unified system of PaintObjects (long)
On 09 Feb 2001 11:32:16 +0100, Jens Lautenbacher wrote: Hi all, This mail comes from some discussions I had with Sven around the time just before 1.2.0, the recent discussion about textures and natural painting and a chat on IRC yesterday with Sven. [ SNIP ] As David already pointed out, it doesn't make sense to only provide for the possibility for a pipe to select from a fixed set of pregenerated pixmaps. this is nice for the current limited pipe, but when using a general pipe as a provider for textures/patterns/brushes one wants to have the possibility to match certain or all dimensions of the data space to a function. Here the question naturally arises: what kind of functions should be possible? Only transformations? Only some set of functions that are predefined in the core? Or could there be some possibility to handle user provided functions? How would these (if possible) be specified in a fileformat? or just LUTs that are used by functionality that is special to the object (e.g. for textures, there needs to be some special functionality on how to map the input state (mainly pressure I assume) to the final buffer returned. Here a LUT or a simply scalar function seems to be the way to go. For performance reasons, all ProviderObjects should automatically have a LRU Cache (or some tuned variant of it) to store already computed values. This of course can be handled in a base class for them, so implementing another provider doesn't need the programmer to cope with this anymore. [ WARNING: This mail contains some scary ideas ] This would be neat, I bet some pretty fancy natural effects could be done with this stuff too. I also tend to think that we dont yet know what to demand from the thing before we can play with it. Even the current brushpipe stuff was good enough so that it could do some really amazing things with the multidimensional stuff (have, for example, some brush strokes that take the direction from the pen direction, and choose a different stroke shape depending on the pressure, for example. Or wood-carving brush, you could have a shaded bevel-thing that scales according to pressure and stuff. Another thing is I really wouldnt want to *lock* the parameters to the brush file. It would be nice if the options dialog had a checkbox to "[x] use default values" but unchecking that would make it possible to remap the XInput modifiers to different things. It would also be good if one could then save this new resulted brush in a new file. Another thing that should be really well thought about is how far this abstraction is presented to the user. Having all of the paintobjects fulfill a generic interface w.r.t the paintcore it makes it possible to e.g. use a texture as a brush and vice versa. I would still strongly argue against presenting such a possibility to the user. From his/her point of view, a brush is NOT a pattern, nor a texture. I'd think that a user wishing to use a brush as a pattern can always load the brushfile in the gimp, and save it as a pattern (remember that we talk about general pipes here already: laoding a brush and saving it as a pattern will result in a pattern that changes according to the input state in the same way as the original brush does.) So would this mean one could have something like multilayer XCF files as patterns, that "dig in" the layerstack if one uses more pressure? This would be pretty awesome. The "Tommer" example comes to mind first: Have something like this: Layer 1: skin pattern Layer 2: some red goo Layer 3: some tissue layers Layer 4: guts and stuff Layer 5: rib bones or something Yes. This is a gross example, but it demonstrates the idea pretty well. So then you can draw "wounds" to a image, and depending on your pen pressure you get different stuff. Maybe I am on crack with this, who knows. But it doesnt sound like too impossible. Then the brush shape could be used as a transparency mask when composing the strokes together. Think of the brush as a layered "box" of soil, that has different stuff on different depths. Then the brush stroke can be tought as a shovel digging into this "box". I dont know if I made myself clear with this though :o( Ok, maybe it was gross example, but we could do something else like this too. Ever did the crayon trick as a kid, when you first painted a paper full of different bright colors and then took the black grayon and painted a black layer on top of everything. Then you took a sharp stick and used it to draw shapes on it, so the black layer was scraped off and you saw the bright colors underneath. Something like this would be another good example of what this could achieve. And less gross too :o) Also oil painting, maybe some 3D effects even? We dont even need any real calculation, but have a multilayer image with layer 1 having totally flat, thin, nearly transparent paint, then gradually going towards a very bumpy, textured and rough
Re: RFC: unified system of PaintObjects (long)
Tuomas "\"spectrolite\"" Kuosmanen [EMAIL PROTECTED] writes: On 09 Feb 2001 11:32:16 +0100, Jens Lautenbacher wrote: Hi all, This mail comes from some discussions I had with Sven around the time just before 1.2.0, the recent discussion about textures and natural painting and a chat on IRC yesterday with Sven. [ SNIP ] [ WARNING: This mail contains some scary ideas ] [ SNIP ] Another thing is I really wouldnt want to *lock* the parameters to the brush file. It would be nice if the options dialog had a checkbox to "[x] use default values" but unchecking that would make it possible to remap the XInput modifiers to different things. It would also be good if one could then save this new resulted brush in a new file. Yes, one thing that would be really needed is a good interface for the multidimensional providers. Actually all of them could be edited with the same interface, and just on save time you would decide if it should be saved as a texture, brush or pattern (or anything else we want to come up with) I'd think that a user wishing to use a brush as a pattern can always load the brushfile in the gimp, and save it as a pattern (remember that we talk about general pipes here already: laoding a brush and saving it as a pattern will result in a pattern that changes according to the input state in the same way as the original brush does.) So would this mean one could have something like multilayer XCF files as patterns, that "dig in" the layerstack if one uses more pressure? This would be pretty awesome. The "Tommer" example comes to mind first: Have something like this: Layer 1: skin pattern Layer 2: some red goo Layer 3: some tissue layers Layer 4: guts and stuff Layer 5: rib bones or something exactly. and it is actually quite a good and funny example. Yes. This is a gross example, but it demonstrates the idea pretty well. So then you can draw "wounds" to a image, and depending on your pen pressure you get different stuff. Maybe I am on crack with this, who knows. But it doesnt sound like too impossible. Then the brush shape could be used as a transparency mask when composing the strokes together. Think of the brush as a layered "box" of soil, that has different stuff on different depths. Then the brush stroke can be tought as a shovel digging into this "box". I dont know if I made myself clear with this though :o( if I understand you correctly, this means using a multidim. pattern provider and a multidim. brush provider (aka a brushpipe) [ SNIP ] Again, I understand I cant even imagine _what_ one could finally do with this stuff, so it is best to leave some freedom there. what you said were good examples how this stuff gives new possibilities from the user perspective. But the main motivation for such a work should be clean, elegant source code first... jtl
Re: RFC: unified system of PaintObjects (long)
On Fri, Feb 09, 2001 at 02:28:57PM +0100, Jens Lautenbacher wrote: Tuomas "\"spectrolite\"" Kuosmanen [EMAIL PROTECTED] writes: On 09 Feb 2001 11:32:16 +0100, Jens Lautenbacher wrote: Hi all, This mail comes from some discussions I had with Sven around the time just before 1.2.0, the recent discussion about textures and natural painting and a chat on IRC yesterday with Sven. [ SNIP ] [ WARNING: This mail contains some scary ideas ] [ SNIP ] Another thing is I really wouldnt want to *lock* the parameters to the brush file. It would be nice if the options dialog had a checkbox to "[x] use default values" but unchecking that would make it possible to remap the XInput modifiers to different things. It would also be good if one could then save this new resulted brush in a new file. Yes, one thing that would be really needed is a good interface for the multidimensional providers. Actually all of them could be edited with the same interface, and just on save time you would decide if it should be saved as a texture, brush or pattern (or anything else we want to come up with) The ideas that were tossed around circa a year ago was a "mixing board" type of interface where you build up combinations and relations. To some degree, there are alot of parallels to analog synths as well, where you have this dozen input sources, and a dozen filters, and a dosen places to hook them to. Lots of power there. Of course, this is far from a intuitive interface. If your've ever played with an old analog synth and spent 20 minutes making it go "swoooshkkkakckakkcacacaaaoo" before, and then actually try to make useful sounds with it, you knwo what I mean. For 99% of users, the best interface would probabaly just be a list of "presets" of already written and saved "patches". I belive this is how Deep Paint, works for example... So would this mean one could have something like multilayer XCF files as patterns, that "dig in" the layerstack if one uses more pressure? This would be pretty awesome. The "Tommer" example comes to mind first: Have something like this: Layer 1: skin pattern Layer 2: some red goo Layer 3: some tissue layers Layer 4: guts and stuff Layer 5: rib bones or something exactly. and it is actually quite a good and funny example. heh, indeed. what you said were good examples how this stuff gives new possibilities from the user perspective. But the main motivation for such a work should be clean, elegant source code first... Adrian
Re: RFC: unified system of PaintObjects (long)
On 9 Feb 2001, Jens Lautenbacher wrote: Here the question naturally arises: what kind of functions should be possible? Only transformations? Only some set of functions that are predefined in the core? Or could there be some possibility to handle user provided functions? How would these (if possible) be specified in a fileformat? or just LUTs that are used by functionality that is special to the object (e.g. for textures, there needs to be some special functionality on how to map the input state (mainly pressure I assume) to the final buffer returned. Here a LUT or a simply scalar function seems to be the way to go. Those are good questions. A texture won't need to be modified by pressure in most cases since pressure modifies the brush mask. However, if tilt and/or stroke angle is available to the PaintObject, a texture theoretically could be mathematically modified by bumpmapping it. The stroke angle becomes the bumpmap light source azimuth and perhaps then the resulting bumpmap is multiplied by the original texture. Then the tilt can be used as a reinforcement. That way high points facing the direction of the stroke get more deposited pigment. The texture stuff probably wouldn't benefit from user functions. Having one or two good built-in defaults ought to be good. If user supplied functions were supported, it'd seem they would need to be compiled if they work on pixels. If they are used for defining transform matrices, then they could be interpreted in Scheme. Another thing that should be really well thought about is how far this abstraction is presented to the user. Having all of the paintobjects fulfill a generic interface w.r.t the paintcore it makes it possible to e.g. use a texture as a brush and vice versa. I would still strongly argue against presenting such a possibility to the user. From his/her point of view, a brush is NOT a pattern, nor a texture. I'd agree with this. If for some odd reason a creative user wishes to use a texture as a pattern, then he/she can save a copy as a pattern. If there is one file format for patterns/brushes/texture/etc they could even copy or soft link as needed. - David
