Re: [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