Re: [Inkscape-devel] [Inkscape-user] Equivalent to Illustrator's Gradient Mesh?
[CC:ing the -devel rather than the -user list]
Hi Chris,
Thanks for following up on this!
I'm not sure what to do about folding, where the triangles overlay each other. Its hard to forbid it (but see below).
The combination of non-full-scene antialiasing (as in many popular rasterizers like cairo) with self-overlapping shape presents some *extremely* difficult rendering problems with respect to alpha, to the point where I'd say it rules out any scheme permitting folding[1].
So, as far as the other scheme goes:
<colorGrid xml:id="foo" gridUnits="userSpaceOnUse"> <dot dcolor="#27D" dopacity="0.5" x="12.7" y="3.5"/> <dot dcolor="rgb(123, 254, 37)" dopacity="1" x="8.4" y="17.2"/> <dot dcolor="#F0D" dopacity="0" x="3.2" y="14.1"/> </colorGrid>
How about:
<mesh xml:id="foo" meshUnits="userSpaceOnUse"> <vertex vertex-color="#27D" vertex-opacity="0.5" x="12.7" y="3.5"/> <vertex vertex-color="rgb(123, 254, 37)" vertex-opacity="1" x="8.4" y="17.2"/> <vertex vertex-color="#F0D" vertex-opacity="0" x="3.2" y="14.1"/> </mesh>
This approach has some advantages:
- the xml is way shorter
- there is never any folding
- its simpler to author
- no messing about with ID and IDref to construct a linked data structure
- no chance of getting any of the links wrong
- adding a new point or deleting a point is stable and causes a local
change; the mesh is never in an invalid state
- animating x and y never produces overlap
I consider all of these to be extremely desirable properties. I'd also add:
- it has a very obvious user interaction model
The interaction model offered by simply placing colored vertexes, letting the triangulation fall out naturally, is a LOT better than e.g. manipulating coons patches (as in Illustrator), which I've always found incredibly twiddly and tiresome to do.
In Inkscape specifically, implicitly triangulated meshes could be handled by a very simple extension of the existing UI we have for gradients, where gradient stops are simply nodes on the canvas.
disadvantages
- implementation has to perform the triangulation. Although its not
very hard or computationally intensive.
It's probably more of a people issue than a technical -- having developers on hand with the requisite experience. I've found it's harder than I'd expected to get people who are good with computational geometry stuff in general. But Delaunay triangulation is pretty well-understood and well-documented; by way of contrast, the boolean operations required by SVG vector effects represent a _much_ higher implementation burden than triangulation would.
- if you want overlaps/folding, or to hook up coincident points in a
particular way to get sharp transitions, you can't have it.
Those effects should usually be possible to reproduce using multiple meshes (subject to some caveats with non-FSAA rendering again[2]).
- animating x and y of a vertex may be slower than in the explicit
case, because the triangles may re-form
That shouldn't be too big a deal, so long as a triangulation method suited to incremental triangulation is used. In terms of existing vector tools, meshes are also much rarer in animation tools than in static tools.
And its possible to start with this vertex-only form, triangulate, and write out the verbose, explicit form.
I'm not sure I see a much value in permitting both forms, in SVG itself. More important to me is the fact that (assuming we specify Goraud interpolation for the colors) the triangulated form of either is directly translatable to a Type 4 shading in PS/PDF.
So, yeah, I'd have to say that I'm very interested in giving the Delaunay approach a try.
-mental
[1] Usually the individual triangles of a mesh can be composed with each other using an alpha-saturating operation to eliminate seams between them, but this fails if they overlap and are semi-transparent, since the alpha will not accumulate as expected
[2] Seams are unavoidable in cases where the edges of separate meshes are precisely congruent
On Tuesday, May 22, 2007, 2:42:07 AM, MenTaLguY wrote:
M> [CC:ing the -devel rather than the -user list]
M> Hi Chris,
M> Thanks for following up on this!
I'm not sure what to do about folding, where the triangles overlay each other. Its hard to forbid it (but see below).
M> The combination of non-full-scene antialiasing (as in many popular M> rasterizers like cairo) with self-overlapping shape presents some M> *extremely* difficult rendering problems with respect to alpha, to the M> point where I'd say it rules out any scheme permitting folding[1].
I agree. I only mentioned it because I have seen it used to get hard edges.
M> So, as far as the other scheme goes:
<colorGrid xml:id="foo" gridUnits="userSpaceOnUse"> <dot dcolor="#27D" dopacity="0.5" x="12.7" y="3.5"/> <dot dcolor="rgb(123, 254, 37)" dopacity="1" x="8.4" y="17.2"/> <dot dcolor="#F0D" dopacity="0" x="3.2" y="14.1"/> </colorGrid>
M> How about:
M> <mesh xml:id="foo" meshUnits="userSpaceOnUse"> M> <vertex vertex-color="#27D" vertex-opacity="0.5" x="12.7" y="3.5"/> M> <vertex vertex-color="rgb(123, 254, 37)" vertex-opacity="1" x="8.4" y="17.2"/> M> <vertex vertex-color="#F0D" vertex-opacity="0" x="3.2" y="14.1"/> M> </mesh>
Yes, mesh is better (I avoided it because it hasn't been meshed, when specified). I wasn't sure if they were really vertexes, but thats fine too. I think trimesh would be even better, as it allows for other types later ... or alternatively, keep the name mesh, add an attribute that has just a single value for now, triangular, and make that the default if unspecified.
I'm assuming the list of vertices is in random order and that altering the order would have no effect on rendering.
This approach has some advantages:
- the xml is way shorter
- there is never any folding
- its simpler to author
- no messing about with ID and IDref to construct a linked data structure
- no chance of getting any of the links wrong
- adding a new point or deleting a point is stable and causes a local
change; the mesh is never in an invalid state
- animating x and y never produces overlap
M> I consider all of these to be extremely desirable properties. I'd also M> add:
M> - it has a very obvious user interaction model
I agree.
M> The interaction model offered by simply placing colored vertexes, M> letting the triangulation fall out naturally, is a LOT better than e.g. M> manipulating coons patches (as in Illustrator), which I've always found M> incredibly twiddly and tiresome to do.
Yes, instead of fiddling with control points you just add, move, or remove vertices.
M> In Inkscape specifically, implicitly triangulated meshes could be M> handled by a very simple extension of the existing UI we have for M> gradients, where gradient stops are simply nodes on the canvas.
(Which I like) yes. With some care for the object bounding box case. Re-use of trimesh paint servers
disadvantages
- implementation has to perform the triangulation. Although its not
very hard or computationally intensive.
M> It's probably more of a people issue than a technical -- having M> developers on hand with the requisite experience. I've found it's M> harder than I'd expected to get people who are good with computational M> geometry stuff in general. But Delaunay triangulation is pretty M> well-understood and well-documented;
Yes, it is.
M> by way of contrast, the boolean M> operations required by SVG vector effects represent a _much_ higher M> implementation burden than triangulation would.
Although Inkscape still seems to implement most of them, while calculating the resulting geometry itself rather than writing out the vector effect. but that should be a separate thread.
- if you want overlaps/folding, or to hook up coincident points in a
particular way to get sharp transitions, you can't have it.
M> Those effects should usually be possible to reproduce using multiple M> meshes (subject to some caveats with non-FSAA rendering again[2]).
Yup.
- animating x and y of a vertex may be slower than in the explicit
case, because the triangles may re-form
M> That shouldn't be too big a deal, so long as a triangulation method M> suited to incremental triangulation is used. In terms of existing M> vector tools, meshes are also much rarer in animation tools than in M> static tools.
True, but we still want to be sure that animation give expected results and is tractable.
And its possible to start with this vertex-only form, triangulate, and write out the verbose, explicit form.
M> M> I'm not sure I see a much value in permitting both forms, in SVG itself.
Right. I started off the mail with the explicit form and by the end had pretty much convinced myself that the implicit triangulation was better. But I left the working so that others could check the reasoning.
M> More important to me is the fact that (assuming we specify Goraud M> interpolation for the colors)
I would guess so; flat shading is unlikely to be good enough (although in effect thats what linear and radial gradients use currently - again, extensions there are probably best left to a separate thread) and Phong shading may be too complex.
Note for those googling along, its spelled Gouraud :) http://medialab.di.unipi.it/web/IUM/Waterloo/node84.html
M> the triangulated form of either is M> directly translatable to a Type 4 shading in PS/PDF.
Yes, which is a handy feature when SVG (often with XSL-FO) is converted into PDF. http://www.adobe.com/products/postscript/pdfs/PLRM.pdf (page 261 onwards)
M> So, yeah, I'd have to say that I'm very interested in giving the M> Delaunay approach a try.
Cool.
I would be glad of other comments or questions on the feature set or proposed syntax, and look forward to feedback from your prototyping.
M> -mental
M> [1] Usually the individual triangles of a mesh can be composed with each M> other using an alpha-saturating operation to eliminate seams between M> them, but this fails if they overlap and are semi-transparent, since the M> alpha will not accumulate as expected
M> [2] Seams are unavoidable in cases where the edges of separate meshes M> are precisely congruent
On Tue, 2007-05-22 at 05:36 +0200, Chris Lilley wrote:
M> by way of contrast, the boolean M> operations required by SVG vector effects represent a _much_ higher M> implementation burden than triangulation would.
Although Inkscape still seems to implement most of them, while calculating the resulting geometry itself rather than writing out the vector effect. but that should be a separate thread.
The thing is, the code we brought in to implement that is pretty problematic -- the author vanished on us, the licensing status is a little fuzzy, and the code quality is so poor as to be nearly unmaintainable. I couldn't recommend that anyone else use it, and the only reason we haven't replaced it ourselves is that there simply aren't any other computational geometry libraries with the required features (and numerical stability!) available under a liberal enough license. Unfortunately writing a robust implementation of those operations requires a great deal of very specialized domain knowledge.
Until we see other open source implementations of vector effects (and until there's a finalized standard, which realistically probably depends on that), I don't think I can sell implementing vector effects to the other developers. We've discussed approaches using <switch> to deal with user agents that don't implement them, but the consensus was that such approaches would introduce too much complexity to the UI code for working with paths.
-mental
On 5/21/07, MenTaLguY <mental@...3...> wrote:
<mesh xml:id="foo" meshUnits="userSpaceOnUse"> <vertex vertex-color="#27D" vertex-opacity="0.5" x="12.7" y="3.5"/> <vertex vertex-color="rgb(123, 254, 37)" vertex-opacity="1" x="8.4" y="17.2"/> <vertex vertex-color="#F0D" vertex-opacity="0" x="3.2" y="14.1"/> </mesh>
Certainly this approach is a lot more practical for the implementor compared to the one where you explicitly specify all the edges and faces. Automatic triangulation should be relatively easy.
However, I'm concerned that this approach may not be too useful for the designer. Yes, it is very easy to drag around the vertices and the mesh will respond intuituvely. But the result won't look like _anything_ in the real world. It will be too linear, too clunky, with too visible vertices and edges. That's inevitable if you go with straight line edges and linear color transitions between nodes, as your plan implies.
The only way to use this to render something real-life-like is by using a LOT of vertices so that the triangles are too small to be visible. But IMHO that makes the whole affair rather meaningless. It is unthinkable to create such tight meshes manually, so Inkscape developers will have to provide yet another UI level on top of this - using, most likely, bezier-based meshed like in Adobe Illustrator - and then approximate the results using such a triangulated mesh. This will blow up the size of SVG files considerably, and the mapping from the triangulated approximation to the higher-level curvilinear representation and back will be far from trivial to implement. Actually, the proposed triangulated mesh in SVG won't buy us much at all, because we can just as well approximate a bezier-based AI-like mesh with small triangles or (better) beziergon paths right now (see http://inkscape.org/screenshots/gallery/inkscape-0.45-gradient-mesh-experime...), and it won't be _much_ worse or less efficient than if we used the triangulated mesh.
Xara X has, along with elliptic and linear gradients, the "three-color" gradient fill which looks exactly like one cell from a triangulation that you propose. Since it's just a single cell it's not an entirely fair comparison, but I can say that in several years of my using Xara for a lot of different design projects, I have never once found use for such gradients. A few times I thought I might use them, but when I actually tried, they always turned out too awkard, too sharp near the corners, too linear. So in the end I usually made do with something like several overlapping elliptic gradients instead. To my knowledge, other Xara artists are not often using this gradient type either - so much so that I could not even google up any example image to show you. On the other hand, it is well known that the lack of bezier-controlled gradient meshes like those in AI is one of the most frequent complaints of Xara users and is what drives some of them to defect from Xara to AI. For me, it is obvious that three-point gradients will never truly fulfill that need even if I can do a whole triangulated mesh of such gradients. Smooth *curvilinear* controls are absolutely crucial if you're doing any photorealistic art (and photorealistic art is what gradient meshed in AI are most often used for).
On Fri, 25 May 2007 20:24:33 -0300, "bulia byak" <buliabyak@...400...> wrote:
Actually, the proposed triangulated mesh in SVG won't buy us much at all, because we can just as well approximate a bezier-based AI-like mesh with small triangles or (better) beziergon paths right now (see http://inkscape.org/screenshots/gallery/inkscape-0.45-gradient-mesh-experime...), and it won't be _much_ worse or less efficient than if we used the triangulated mesh.
There's a decent chance of being able to exploit hardware acceleration for the triangulated mesh case; we don't get the same advantage from blurring a grid of shapes that had to go through the full SVG rendering pipeline.
found use for such gradients. A few times I thought I might use them, but when I actually tried, they always turned out too awkard, too sharp near the corners, too linear.
Hmm, I was a bit worried about that being an issue -- that is a known shortcoming of Gouraud interpolation. If we're wiling to sacrifice direct PS/PDF compatibility, we could possibly use a different interpolation function.
-mental
On Fri, 2007-05-25 at 20:24 -0300, bulia byak wrote:
It will be too linear, too clunky, with too visible vertices and edges.
As already noted, this may mean we need to use instead a non-linear blending function. I'm not yet convinced that we need to abandon triangle meshes, and I dislike the interaction model for coons patches (the major alternative proposed).
Perhaps the next thing for me to do is to rig up a very minimal application oriented to a specific task (say, reproducing a photograph) where we can assess the practicality of different blending functions and variations on the mesh idea. That way, we aren't also worrying prematurely about how meshes ought to be encoded in SVG (or implemented in Inkscape).
-mental
I think Igarashi's technique would be nice to have in Inkscape. http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/rigid/index.html (you can download a java applet to play with there.)
It is triangle based however, so discontinuities in the texture can be apparent with a mesh res that's too low. But you know the mesh the user's manipulating and the method used to map the texture based on that don't have to be the same. For instance you could take the coarse triangulation and refine it with a cubic-bezier subdivision rule a few times to get the texture coordinates. Or you could do some kind of cubic interpolation on the triangle verts to get the texture mapping. Using subdivision is probably the best way to improve the texture mapping from a coarse triangulation, though. You'd only need one or two extra subdivision levels to make it look smooth, and all you have to store in the svg file is one number -- how many subdiv levels to apply for for texture mapping purposes.
--bb
On 5/26/07, MenTaLguY <mental@...3...> wrote:
On Fri, 2007-05-25 at 20:24 -0300, bulia byak wrote:
It will be too linear, too clunky, with too visible vertices and edges.
As already noted, this may mean we need to use instead a non-linear blending function. I'm not yet convinced that we need to abandon triangle meshes, and I dislike the interaction model for coons patches (the major alternative proposed).
Perhaps the next thing for me to do is to rig up a very minimal application oriented to a specific task (say, reproducing a photograph) where we can assess the practicality of different blending functions and variations on the mesh idea. That way, we aren't also worrying prematurely about how meshes ought to be encoded in SVG (or implemented in Inkscape).
-mental
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2007-05-26 at 15:28 +0900, Bill Baxter wrote:
Using subdivision is probably the best way to improve the texture mapping from a coarse triangulation, though. You'd only need one or two extra subdivision levels to make it look smooth, and all you have to store in the svg file is one number -- how many subdiv levels to apply for for texture mapping purposes.
I think what I'd want to do is simply specify the interpolation function, and it should be left up to the user agent to choose the approach used to render it.
One possibility certainly would be to approximate the blending function via further subdivision of the specified mesh, but it should probably be adaptive -- a fixed level of subdivision may be overkill for some areas at the same time it's insufficient for others. Anyway, I think that's something we should leave to the user agent rather than specifying in the SVG.
-mental
participants (4)
-
Bill Baxter -
bulia byak -
Chris Lilley -
MenTaLguY