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
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
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: * 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: 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
