Re: [Inkscape-user] Equivalent to Illustrator's Gradient Mesh?

On Saturday, June 23, 2007, 4:29:26 AM, MenTaLguY wrote:

M> On Sat, 2007-06-16 at 14:17 +0200, Chris Lilley wrote:
>> I would be interested to see your results. What artefacts are you
>> seeing - sharp edges (I would not have expected that from Gouraud)?

M> The source of the problem is second-order discontinuity at the edges of
M> the triangles (i.e. the color is continuous, but its rate of change is
M> not).  The general visual effect is of "rays" connecting the vertices of
M> the triangulation, making the triangles fairly evident:

M>  http://www.rydia.net/~mental/trymesh.png

So yes, Gouraud gives you a continuous gradient within each triangle and very visible discontinuities between adjacent triangles. Thinking about it some moore, that is the expected result; Gouraud evaluates the lighting model only per vertex, then interpolates the resulting colors across each triangle. This is typically improved, at increased computational cost, by using the Phong lighting model; the vertex normals are evaluated and the normals are interpolated across each triangle and the lighting recalculated.

It sounds expensive and it is, although there are speed-ups such as Blinn-Phong, or optimisations involving forward differencing.

M> So, unless we want to force the SVG author to manually create very
M> finely divided meshes (which bulia rightly vetoed),

Rightly as you say

M>  we will need to
M> select a different shading function which takes into account neighboring
M> triangles and can give us higher-order continuity.

M> The "friendlier" function can be then approximated in OpenGL or
M> Postscript by automatic subdivision.  [Actually, with OpenGL on modern
M> hardware, the shading function could probably even be implemented
M> directly as a fragment shader.]

OpenGL uses Phong lighting for vertices but doesn't implement Phong shading directly:
http://www.dgp.toronto.edu/~patrick/csc418/notes/tutorial6.pdf

Phong-like shading can be simulated using OpenGL shaders. Here are some notes about Blinn-Phong and OpenGL, and using shaders to do this:
http://www.lighthouse3d.com/opengl/glsl/index.php?ogldir2
http://www.ozone3d.net/tutorials/glsl_lighting_phong.php

The other interesting thing about Phong-like normal interpolation is that this is exactly what the SVG 1.1 lighting filters do. In that case there are no vertices; the input is a greyscale image (the alpha channel, for example) which is treated as a height map and then lit. The surface normal at each pixel is estimated by comparing small deltas in x and y. So its a surface with per-pixel normals.

Its possible, then that a Phong-like lighting model could be implemented using OpenGL shaders, and used to hardware accelerate *not only* the trimesh gradients but also the diffuse and specular lighting filters. 

Linear gradients can also be implemented, if desired, as a trimesh with four (for two stops) vertices arranged in a rectangle, with pairs of vertices having the same color. And we might want to offer an option to use the same shading model for linear and radial gradients, which also currently suffer from artifacts due to second-order discontinuity.

Also, it would be good to check what colorspace the interpolation is happening in. I have seen some hardware-accelerated linear gradients that were incorrect because the wrong colorspace was used.


M> Here's the current state of the test harness (shown above in the
M> screenshot); I'm not too proud of the code, but I may as well post it so
M> people can start playing with it.  The code is public domain.

M>  http://www.rydia.net/~mental/trymesh-20070622.tar

Thanks for the demo, it ran fine once I had all the dependencies installed (all available as packages in kubuntu 7.04).

M> Planned still are:

M>  - an "eyedropper tool" for picking node colors
M>  - the ability to load a background image
M>  - miscellaneous UI improvements
M>  - alternate gradient functions

I look forward to an option to try some Phong shaders.

In terms of authoring ease, I do notice sometimes some 'flipping' where a small change to the position of a vertex causes a large visual effect as it re-triangulates. Its hard to know if that woukd be a problem without first addressing the discontinuities, though.

Lastly, seeing that your demo starts off with a rectangle of four vertices to delimit the area (and seeing what hapens when these are moved, which often gives a poor result) I wonder if the trimesh gradient should have a minimum four vertices at fixed points. These could be attributes on the main trimesh element. Other vertices would be children. This avoids having to describe what happens for parts of the gradient not covered by the triangles.


M> I'll post newer archives periodically, but the very newest version will
M> always be available via git:

M>  git://git.inkscape.org/projects/trymesh.git

OK, I'm not proud. Whats the git protocol?



-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 4 July 2007 21:03:40 UTC