Those without an SVN build of Inkscape are invited to visit the recently updated gallery of 0.45 screenshots:
http://inkscape.org/screenshots/
The exhibits demonstrate the two photorealistic car renditions, a demo of the proposed gradient mesh approach, and a mini-tutorial on creating life-like shading for arbitrary rope-like shapes. All examples use Gaussian blur, and the source files of all examples are in share/examples in SVN.
Enjoy!
bulia byak wrote:
The exhibits demonstrate the two photorealistic car renditions, a demo of the proposed gradient mesh approach, and a mini-tutorial on creating life-like shading for arbitrary rope-like shapes. All examples use Gaussian blur, and the source files of all examples are in share/examples in SVN.
Those are really interesting examples to choose.
I think the beautiful soft shading on the cars strongly suggests that gradient meshes are not as crucial as you might think for shading. What artists really need are the tools to mask and blur and composite, using the techniques in the rope example, which can be combined and layered to produce complex shading as with the cars.
I don't want to disparage but I don't think gradient meshes are achievable in a useful way with SVG. Even if they can be approximated it will produce an SVG file which is read-only in SVG editors other than Inkscape, which surely defeats the object of SVG compliance.
Within a gradient mesh, the whole patch needs to be subdivided to the size of the smallest subdivision but this size could approach zero, so the number of subdivisions required could approach infinity. Imagine a degenerate bezier patch which is triangular, for example. If there is some limit on the degree of subdivision, this could either cause block-like artifacts on large patch divisions or blur out the detail in small patch divisions, depending on how you clamp the blur radius. One of the reasons we use vector graphics is to avoid artifacts and get perfect rendering in all situations.
I would prefer more powerful features along the lines we already have: to work with multiple paths with blurring (ideally with different composite operations additive/subtractive/multiplicative etc), all within one clip region - a clip region that might also be edited on the fly. This can be edited equivalently - usefully - in SVG tools other than Inkscape.
Either way, I think we should allow time for artists to become familiar and competent with clip/mask & blur, implement additional composite filters, and wait to see if gradient meshes remain such a priority with these other features available.
While I'm on the subject of things that would be more useful to me than gradient meshes, I can think up a pile of suggestions for more inventive tools: an airbrush tool using the marching squares algorithm to generate nested isocurves; a paintbrush tool that works like the calligraphy tool but unions as it goes, and an eraser that differences as it goes; or a spray version of the tile clones tool that sprays clones onto the page in some kind of random distribution around the cursor.
Dan
On 11/10/06, Daniel Pope <mauve@...1559...> wrote:
I think the beautiful soft shading on the cars strongly suggests that gradient meshes are not as crucial as you might think for shading. What artists really need are the tools to mask and blur and composite, using the techniques in the rope example, which can be combined and layered to produce complex shading as with the cars.
I tend to agree, in general. However, a lot of vector artists swear by gradient meshes, because they were widely popularized by Adobe Illustrator. So implementing meshes will give us a great competitive advantage, especially considering that not many other vector editors have them (for example Xara does not).
I don't want to disparage but I don't think gradient meshes are achievable in a useful way with SVG. Even if they can be approximated it will produce an SVG file which is read-only in SVG editors other than Inkscape, which surely defeats the object of SVG compliance.
I don't think read-only is such a big problem. We're not going to make our SVG non-standard in any way, and if someone wants to implement Inkscape-like gradient mesh editing, they're free to borrow from us - we are open source. Otherwise, Inkscape is free and cross-platform, and even if you use some other tool for editing other parts/aspects of SVG, you can always use Inkscape to edit the mesh, without breaking the rest of SVG.
Within a gradient mesh, the whole patch needs to be subdivided to the size of the smallest subdivision but this size could approach zero, so the number of subdivisions required could approach infinity. Imagine a degenerate bezier patch which is triangular, for example. If there is some limit on the degree of subdivision, this could either cause block-like artifacts on large patch divisions or blur out the detail in small patch divisions, depending on how you clamp the blur radius.
I thought about it, too. But I don't think it's indeed an unsurmountable obstacle.
First, you don't need to have all segments the same size. Instead, we might define the allowed approximation error, and make each segment as big as possible but so that the color steps at its edges do not exceed this error. This way, smoother patches will have less segments than those with sharp color transitions.
On the other hand, the size of the segment can be limited from below. If you have a small patch with a sharp color transition, you don't want it to have the same large amount of segments as a similar but larger patch. Very small patches can have just one subdivision (2x2 segments), allowing the blur do most of the work. This, by making sement sizes less varying across the mesh, will also to some degree address the problem of choosing blur radius.
Overall, by balancing the two opposites - limiting the number of segments when color transitions are smooth, and limiting the size of segments from below when patches are small - we can achieve a workable compromise (not too many segments, and their sizes are not too different so a sensible blur radius can be chosen) in most practical cases. Of course this needs more experimenting, but I think it will work.
It is important to understand that we're not aiming at perfect mathematical abstraction. Our meshes will likely have artifacts or look funny when stretched beyond their limits. But the main users of the meshes will be artists, not mathematicians :) For them, I'm sure, this will be a valuable tool which can easily give results that are difficult or impossible to achieve in any other way.
One of the reasons we use vector graphics is to avoid artifacts and get perfect rendering in all situations.
That's true only for some uses. In a lot of situations, especially artistic drawings, "good enough" is sufficient. For example, the car renditions in our screenshot gallery are by no means perfect - in fact, they are pretty crude approximations - yet you liked them :)
I would prefer more powerful features along the lines we already have: to work with multiple paths with blurring (ideally with different composite operations additive/subtractive/multiplicative etc), all within one clip region - a clip region that might also be edited on the fly. This can be edited equivalently - usefully - in SVG tools other than Inkscape.
You can already group any number of paths, blur and/or clip the group, and still edit the paths inside freely. As to editing the clip path without unclipping, I'm planning to add this feature soon, it's not too difficult.
Either way, I think we should allow time for artists to become familiar and competent with clip/mask & blur, implement additional composite filters, and wait to see if gradient meshes remain such a priority with these other features available.
Sure, it's not like we're starting it tomorrow. Adding more filters is certainly something easier to do and with higher priority.
While I'm on the subject of things that would be more useful to me than gradient meshes, I can think up a pile of suggestions for more inventive tools: an airbrush tool using the marching squares algorithm to generate nested isocurves; a paintbrush tool that works like the calligraphy tool but unions as it goes, and an eraser that differences as it goes; or a spray version of the tile clones tool that sprays clones onto the page in some kind of random distribution around the cursor
These ideas have been proposed already (except the marching squares/isoclines - can you please give an illustration?) and are certainly doable. We just need interested developers to take them on :)
participants (2)
-
bulia byak
-
Daniel Pope