Re: Proposed Paint Core changes to support textures
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > > > The major problem with having different texture maps for each pressure > > is the amount of memory necessary to store them. Texture tiles > > ... > > But you can have different effects if you have the choice to use > pressure-mapped-brushes as song as we don't have mathematical brushes > because some tools (in reallife) behave quite differently when one applies > bigger pressure to them. I agree completely to supporting changing the texture bitmap depending on pressure. At the time I wrote the last email, I could not think of a practical use for it. Today I had a burst of inspiration: it could be used to simulate table texture beneath paper. The higher the pressure, the more the table shows through. Of course, you could also use other more exciting textures underneath: coins, leaves, grass, wicker, etc. Such textures would be great for pencil-rubbed backgrounds. In general a texture will not be modified by pressure. Textures normally don't deform due to greater applied pressure (barring the simulation of actually destroying the medium!) What does change is the amount of pressure exerted by the brush at all points of contact. GIMP already accounts for these changes by modifying the brush mask (its hardness, size, and opacity).* What is unclear at this point is how to generalize the texture composition function. It has two parameters, brush mask and texture, and returns a new brush mask. A good composition function for crayons, pencils, chalk, and pastels is subtraction using saturation arithmetic.** A potentially useful function for some types of media (which ones???) is the multiplication function. There may be other composition operators that specifically address certain drawing implements. - David * Technically, The GIMP does not modify the brush mask's opacity by pressure. It optimizes the operation by multiplying the stylus pressure (treated as an opacity) by the tool's opacity hscale. It then passes that new value to the paste_brush function. This optimization needs to be disabled when a texture is used, since the two opacities have different semantics. ** Saturation subtraction is based on the fact that drawing with a pencil lightly will not fill the paper's pits no matter how many times one goes over the same spot. Multiplication could simulate the amount of ink deposited from a marker, pits get more ink than peaks.
Re: Proposed Paint Core changes to support textures
On 7 Feb, Sven Neumann wrote: >> Hm, generating a lookup table and getting the pressure from there >> instead directly from the driver would be trivial to implement and >> seems like a worthy feature to me. > What driver are you speaking about? The standard Intuos Win driver. > The code to use a LUT to map brush pressure to a more sophisticated > curve is already in the paint_core (only #ifdef out). Look for the > FANCY_PRESSURE define. Actually this is not what we want... Why not? Finegrained control is never bad. For example I have to press too hard to get maximum pressure which is really annoying. With Win I can easily change that. So I'd like to have a per-tool-LUT. > Currently Mitch is working on the previews and selection dialogs for > data objects. IMHO there is a need for at least two more things to > think about: > - A cache mechanism to avoid holding all the data objects in memory. Positive. I'd propose just keeping the previews in memory and loading the brush on demand. This way we'd just have to keep small icons in memory and load the big brushes/pipes just when someone wants to see the complete brush or use it. > - A mechanism to select different data from the same object depending > on paint_core parameters (like the brush-pipe we have now, only more > general). This does not imply that all data has to be stored on disk > as pixmaps, it could also be the result of applying a transformation > on pixmap data or could even be completely calculated (think > generated brushes). Think mathematical brushes calculated in realtime depending on toolfeedback and an UI. > The paint_core should be changed to work with abstract data objects > instead of distinguishing between brushes, patterns, textures and > images. While this might be a good way of sorting things for the user, > there is no reason why I shouldn't be able to paint with an image, > using a pattern as texture. The paint_core doesn't really need to know > the difference. Correct. -- Servus, Daniel
Re: Proposed Paint Core changes to support textures
Hi, [EMAIL PROTECTED] writes: > > I think a better solution would be a definable pressure curve, much > > like Wacom's Windows driver has. That'd probably be a feature of the > > general mechanism you described and perhaps what you have in mind. > > Hm, generating a lookup table and getting the pressure from there > instead directly from the driver would be trivial to implement and > seems like a worthy feature to me. What driver are you speaking about? The code to use a LUT to map brush pressure to a more sophisticated curve is already in the paint_core (only #ifdef out). Look for the FANCY_PRESSURE define. Actually this is not what we want... > I made an entry into bugzilla so we don't forget that. I'd like to wait > for Sven and Mitch to complete the changes so we don't have to implement > this in several places hopefully. Currently Mitch is working on the previews and selection dialogs for data objects. IMHO there is a need for at least two more things to think about: - A cache mechanism to avoid holding all the data objects in memory. - A mechanism to select different data from the same object depending on paint_core parameters (like the brush-pipe we have now, only more general). This does not imply that all data has to be stored on disk as pixmaps, it could also be the result of applying a transformation on pixmap data or could even be completely calculated (think generated brushes). The paint_core should be changed to work with abstract data objects instead of distinguishing between brushes, patterns, textures and images. While this might be a good way of sorting things for the user, there is no reason why I shouldn't be able to paint with an image, using a pattern as texture. The paint_core doesn't really need to know the difference. Salut, Sven
Re: Proposed Paint Core changes to support textures
Hi, "David A. Bartold" <[EMAIL PROTECTED]> writes: > I think a better solution would be a definable pressure curve, much like > Wacom's Windows driver has. That'd probably be a feature of the > general mechanism you described and perhaps what you have in mind. A > user (or a brush designer) can define their own function and the mechanism > would be usable for all tools, not just ones that draw by copying from > bitmaps. Pressure curves are indeed a good idea and should be implemented generally. > The major problem with having different texture maps for each pressure is > the amount of memory necessary to store them. Texture tiles generally are > much bigger than brushes to reduce visible repetition. A texture of size > 256x256 is not uncommon, and if there were 8 copies of that texture stored > in a brush pipe file, each bitmap corresponding to a different pressure, > then the file will be ~500k. That's a big download (and a lot of cache > misses) just for one texture. Since many people download their copies of > GIMP, that's a lot of bandwidth, too. And do not forget that Gimp holds all patterns and brushes in memory regardless if they are ever used. This is one of the main points why I'm asking for spending some thoughts about a better data system for The GIMP before adding just another data type like textures. Salut, Sven
Re: Proposed Paint Core changes to support textures
On 6 Feb, David A. Bartold wrote: > I think a better solution would be a definable pressure curve, much > like Wacom's Windows driver has. That'd probably be a feature of the > general mechanism you described and perhaps what you have in mind. Hm, generating a lookup table and getting the pressure from there instead directly from the driver would be trivial to implement and seems like a worthy feature to me. I made an entry into bugzilla so we don't forget that. I'd like to wait for Sven and Mitch to complete the changes so we don't have to implement this in several places hopefully. > A > user (or a brush designer) can define their own function and the > mechanism would be usable for all tools, not just ones that draw by > copying from bitmaps. Absolutely. > The major problem with having different texture maps for each pressure > is the amount of memory necessary to store them. Texture tiles > generally are much bigger than brushes to reduce visible repetition. > A texture of size 256x256 is not uncommon, and if there were 8 copies > of that texture stored in a brush pipe file, each bitmap corresponding > to a different pressure, then the file will be ~500k. That's a big > download (and a lot of cache misses) just for one texture. Since many > people download their copies of GIMP, that's a lot of bandwidth, too. But you can have different effects if you have the choice to use pressure-mapped-brushes as song as we don't have mathematical brushes because some tools (in reallife) behave quite differently when one applies bigger pressure to them. > I'm not convinced creating bitmaps specific to certain values of > parameter subsets (such as angle, pressure, velocity, random, ordering, > etc) is really the proper solution. It works okay if you want to > change a tool depending on the value of one variable, but each time a > parameter is added, the number of bitmaps increases manyfold. > Basically the whole mechanism explodes in an exponential disaster. ;) Sure, but since this is optional I don't really see the problem. > For example: a 256x256 texture with 9 angles and 8 pressure levels > will require more than 4 megs of memory. Who cares? People that like to use such a beast (have you ever tried the speed of HUGE brushes with any graphics application?) also have the necessary memory... it's like people that can afford a 1.4 GHz P-IV probably also have the necessary money but this is also just optional. :) -- Servus, Daniel
Re: Proposed Paint Core changes to support textures
"David A. Bartold" <[EMAIL PROTECTED]> writes: > I'm not convinced creating bitmaps specific to certain values of > parameter subsets (such as angle, pressure, velocity, random, ordering, > etc) is really the proper solution. It works okay if you want to change > a tool depending on the value of one variable, but each time a parameter > is added, the number of bitmaps increases manyfold. Basically the > whole mechanism explodes in an exponential disaster. ;) you are right. period. But that leads to the question, if the whole pipe mechanism shouldn't be expanded in a general way. I think of something like this: Currently we have a multi-dimensional thing, where each point in that space is represented by a bit/pixmap. What I think of is the possibility to map a dimension to a supplied function instead of giving the pixmaps explicitely. One could think of something like threshold, rotating, scaling e.g. This should of course be coupled with a LRU Cache of the generated brushes. Just a wild thought too early in the morning (OK, it's 12.20 now, but still too early for me) jtl
Re: Proposed Paint Core changes to support textures
> > deeper crevases of the texture. Is there a practical benefit for storing > > multiple copies of a texture for differing amounts of pressure inside a > > brush pipe file? > > yes. a) not another special case > > b) you can easily implement any function between pressure and > change-in-texture without changing the core > > c) not another special case. I think a better solution would be a definable pressure curve, much like Wacom's Windows driver has. That'd probably be a feature of the general mechanism you described and perhaps what you have in mind. A user (or a brush designer) can define their own function and the mechanism would be usable for all tools, not just ones that draw by copying from bitmaps. The major problem with having different texture maps for each pressure is the amount of memory necessary to store them. Texture tiles generally are much bigger than brushes to reduce visible repetition. A texture of size 256x256 is not uncommon, and if there were 8 copies of that texture stored in a brush pipe file, each bitmap corresponding to a different pressure, then the file will be ~500k. That's a big download (and a lot of cache misses) just for one texture. Since many people download their copies of GIMP, that's a lot of bandwidth, too. I'm not convinced creating bitmaps specific to certain values of parameter subsets (such as angle, pressure, velocity, random, ordering, etc) is really the proper solution. It works okay if you want to change a tool depending on the value of one variable, but each time a parameter is added, the number of bitmaps increases manyfold. Basically the whole mechanism explodes in an exponential disaster. ;) For example: a 256x256 texture with 9 angles and 8 pressure levels will require more than 4 megs of memory. - David
Re: Proposed Paint Core changes to support textures
"David A. Bartold" <[EMAIL PROTECTED]> writes: > The brush pipe idea sounds interesting as it'd support tilt. That'd > be useful for modelling textures that have larger features than > the tool size. I could see the benefit there for simulating drawing > on corrugated cardboard. For finer textures (i.e. paper) one mask is fine. > The texture code would modify the brush mask at runtime using the current > texture and pressure. Higher pressure desposits more pigment into the > deeper crevases of the texture. Is there a practical benefit for storing > multiple copies of a texture for differing amounts of pressure inside a > brush pipe file? yes. a) not another special case b) you can easily implement any function between pressure and change-in-texture without changing the core c) not another special case. I don't know what Sven and Mitch are currently planning to do, but from my limited insight into paint core I would propose a general mechanism to provide color/texture/brush/pattern depending on the current input parameters (so having a single pipe interface that can be subclassed to provide all relevant dataobjects for painting in a dynamic way). just a thought... jtl
Re: Proposed Paint Core changes to support textures
The brush pipe idea sounds interesting as it'd support tilt. That'd be useful for modelling textures that have larger features than the tool size. I could see the benefit there for simulating drawing on corrugated cardboard. For finer textures (i.e. paper) one mask is fine. The texture code would modify the brush mask at runtime using the current texture and pressure. Higher pressure desposits more pigment into the deeper crevases of the texture. Is there a practical benefit for storing multiple copies of a texture for differing amounts of pressure inside a brush pipe file? - David On 6 Feb 2001, Jens Lautenbacher wrote: > "David A. Bartold" <[EMAIL PROTECTED]> writes: > > > I dug into the paint core to see what needs to be changed to support > > drawing on textured media. Here's the basic modifications necessary: > > > > * enum BrushApplicationHardness: > > Add a new value "TEXTURE" which applies both pressure and > > texture to a brush mask. It doesn't make sense to apply > > only texture. Rationale: much of the realism afforded by > > textures is due to the interaction between them and the > > pressure an artist exerts on the medium. > > I don't know how your stuff will work, and how you "apply pressure" in > your code. but, as I wrote in my other post, using a brushpipe for the > textures would maybe help with this, too as you could use changing > textures with regard to the pressure applied (or e.g. tilt) > > jtl >
Re: Proposed Paint Core changes to support textures
"David A. Bartold" <[EMAIL PROTECTED]> writes: > I dug into the paint core to see what needs to be changed to support > drawing on textured media. Here's the basic modifications necessary: > > * enum BrushApplicationHardness: > Add a new value "TEXTURE" which applies both pressure and > texture to a brush mask. It doesn't make sense to apply > only texture. Rationale: much of the realism afforded by > textures is due to the interaction between them and the > pressure an artist exerts on the medium. I don't know how your stuff will work, and how you "apply pressure" in your code. but, as I wrote in my other post, using a brushpipe for the textures would maybe help with this, too as you could use changing textures with regard to the pressure applied (or e.g. tilt) jtl
Re: Proposed Paint Core changes to support textures
Hi, "David A. Bartold" <[EMAIL PROTECTED]> writes: > * new function gimp_context_get_texture: > Returns a GPattern * from the specified context. Heeding Seth's > advice not to create a new file format without good reason, I've > determined the .PAT format to be suitable for this purpose: it > supports grayscale data and description text. Also, it provides > an already existing API framework, GPattern. which has just disappeared from CVS. We are in the middle of migrating all data types. The brush code will change a lot too. It might be better to wait until this is finished... Once we have cleaned up the object hierarchy it should be easy to reuse the code from the brushpipe that changes the brush to make it change texture patterns in a similar way. Overall I'm very positive that your texture additions will make it into The Gimp very soon. Salut, Sven
Re: [gimp-devel] Proposed Paint Core changes to support textures
Simon Budig <[EMAIL PROTECTED]> writes: > David A. Bartold ([EMAIL PROTECTED]) wrote: > > I dug into the paint core to see what needs to be changed to support > > drawing on textured media. Here's the basic modifications necessary: > > > > * enum BrushApplicationHardness: > > Add a new value "TEXTURE" which applies both pressure and > > texture to a brush mask. It doesn't make sense to apply > > only texture. Rationale: much of the realism afforded by > > textures is due to the interaction between them and the > > pressure an artist exerts on the medium. > > Have you considered making the texture dependant of the direction > in which the user strokes the tool? This would be awfully cool. > one could use texture pipes much the same way as brush pipes. All of the selection code could be shared. jtl
Re: [gimp-devel] Proposed Paint Core changes to support textures
David A. Bartold ([EMAIL PROTECTED]) wrote: > I dug into the paint core to see what needs to be changed to support > drawing on textured media. Here's the basic modifications necessary: > > * enum BrushApplicationHardness: > Add a new value "TEXTURE" which applies both pressure and > texture to a brush mask. It doesn't make sense to apply > only texture. Rationale: much of the realism afforded by > textures is due to the interaction between them and the > pressure an artist exerts on the medium. Have you considered making the texture dependant of the direction in which the user strokes the tool? This would be awfully cool. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Proposed Paint Core changes to support textures
I dug into the paint core to see what needs to be changed to support drawing on textured media. Here's the basic modifications necessary: * enum BrushApplicationHardness: Add a new value "TEXTURE" which applies both pressure and texture to a brush mask. It doesn't make sense to apply only texture. Rationale: much of the realism afforded by textures is due to the interaction between them and the pressure an artist exerts on the medium. * function paint_core_get_brush_mask: Add "TEXTURE" to the switch statement. It will call the function paint_core_texturize_mask (mask, x, y, pressure). * new function paint_core_texturize_mask: Calls paint_core_pressurize_mask. Next, it calls gimp_context_get_texture (). Last, it applies the texturing algorithm described in the previous email using the x and y arguments as an offset into the texture. * new function gimp_context_get_texture: Returns a GPattern * from the specified context. Heeding Seth's advice not to create a new file format without good reason, I've determined the .PAT format to be suitable for this purpose: it supports grayscale data and description text. Also, it provides an already existing API framework, GPattern. I have Makefile.am and configure.in modifications for a new textures directory. Also, I have some texture tiles that may be added to the new directory. The autoconf/automake diffs will be sent in a seperate email along with a pointer to the new tiles. - David
