![](https://secure.gravatar.com/avatar/03e0d5cf6f173f88af40808ef41b599c.jpg?s=120&d=mm&r=g)
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