From: Christian Mayer <Vader@t-online.de>

Date: Fri, 09 Jun 2000 23:51:20 +0200

Message-ID: <394166D8.6773237E@christianmayer.de>

To: Jon Ferraiolo <jferraio@Adobe.COM>

CC: Dominik Lenné <dominik.lenne@uumail.de>, www-svg@w3.org

Date: Fri, 09 Jun 2000 23:51:20 +0200

Message-ID: <394166D8.6773237E@christianmayer.de>

To: Jon Ferraiolo <jferraio@Adobe.COM>

CC: Dominik Lenné <dominik.lenne@uumail.de>, www-svg@w3.org

Jon Ferraiolo wrote: > > Dominik, > I believe that the gradient mesh feature that is in PostScript Level 3 and > PDF 1.3 would satisfy your needs. Think of this feature as a warped grid of > vertices on top of a 3D surface, and each line segment in the grid is a > cubic bezier path segment (i.e., two end points and two control points). > Each vertex can have a different color. Basically, a gradient on steroids. This sounds very powerfull... (but looks rather complicated in the PS specs; but I'm no PS expert) > The SVG working group decided to leave gradient meshes out of SVG 1.0 > because only a handful of tools supported this feature at the time we > drafted our requirements document. Now that time has passed, more tools are > supporting this feature. It is unlikely that such a major feature would be > added at this late date for SVG 1.0, but it seems like a strong candidate > feature for a future version of SVG. Fair enough. But I hope that the addition of such a feature will extend the current version in a way that a simplistic shading (e.g. per-vertex colouring) can be done by trivially modyfing a SVG file. (A more complicated one will need a more complicated format anyway). CU, Christian > At 07:56 PM 6/7/00 +0200, Dominik Lenné wrote: > >Christian Mayer wrote: > >> What I'm missing is the ability to have a per vertex colouring as you > >> can do in OpenGL. > > > >Hi, > >I have been following the discussion here for quite a while quietly and have > >thought a lot about this aspect, too. The result is a suggestion like > >Christians, but more generalized. I would baptize it "edge defined colour > >distribution". > >The idea is, to define the colour inside an area just by the colour on the > >surrounding path. A logical extension of this idea would be to calculate the > >colour distribution on a path by the colour of the path defining points > >(vertices), linearly or in some other manner. > >In the case of a tri- or quadrangle with linear colour function on the > >edges, the colour inside can unambiguously and fast be calculated by a > >bilinear formula (seperately for each colour component). If the surrounding > >path is more complex, there is an additional condition or rule or algorithm > >needed. > >One crude example of that is the linear interpolation along straight lines > >between the points of intersection with the border. This can be more refined > >by using several directions at a time and caring somehow about the > >discontinuities that occur in the case of island or concave parts of the > >border. > >The intuitively best approach is IMO to calculate the solution of the two > >dimensional heat conduction equation with the colour on the border as > >boundary condition (as above, for each colour component seperately). There > >are a lot of fast algorithms available to do that. "Fast" means, that the > >computation time scales with n log n (n = number of inside pixels). But if > >it is really feasible with the computational power of average machines has > >to be evaluated. In the case of tri- or quadrangles, this approach leads to > >Christian's bilinear forms. > > > >I see the following advantages of such structures: > >- The output of numerical simulation software is given as "values on > >vertices". With this structure, very simple SVG-backends could be coded for > >those applications. > >- The SVGation of photographs would be simplified. Just take a smart choice > >of paths and vertices in the photograph, and you get pretty fast a fine > >reproduction without any steps. The level of detail transmitted could be > >managed depending on the enlargement. > >- The generation of smooth images by hand would be simplified. No more > >juggle with start and end values of colour vectors - just manipulate the > >vertices and get smooth, steady transitions. > > > >Two more thougths: > >o For this kind of element, one has to be able to assign a colour value to > >each vertex. For the modelling of steps, it would be useful to allow the > >assignment of two colour values to each vertex, one for the "left" and one > >for the "right" side. > >o The introduction of "difference colours" in additon to difference > >coordinates, that is the deviation from a given background colour, would > >allow to use decreased colour depth for details and lead to a pretty > >efficient image compression format. > > > >I am aware, that the order of the day is to get SVG up and running as it is, > >but I put out my suggestion anyway, hoping, that there is some kind of "idea > >pool", in which it will float until the time is ripe. > > > >Yours > > > >Dominik Lenné, Berlin > >Received on Friday, 9 June 2000 17:49:08 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:12 UTC
*