[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