W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: Pseudo3D by distorting the bounding box

From: Andreas Neumann <a.neumann@carto.net>
Date: Mon, 01 Sep 2008 23:15:17 +0200
Message-ID: <48BC5B65.5080003@carto.net>
To: Manuel Strehl <svg@manuel-strehl.de>
CC: www-svg@w3.org

fyi - there was just a paper and presentation at the SVG Open on the 
topic of achieving 3D effects in SVG at the SVG Open 2008 in Nuremberg.


The authors, Jun Fujisawa and Anthony Grasso, intend to write a spec 
proposal for a separate module for perspective transformations in SVG. 
You could participate in this effort as part of the SVG interest group 
if you want.


Manuel Strehl wrote:
> Hi,
> formulas: Sorry, I don't do this usually, so it will not be quite
> usable. In fact it's just a thought. I don't know, if it would display
> correctly and in the sense intended.
> * expand/contract the referenced path to meet width and height of the
> element's bounding box
> * P(x,y) an undistorted point of the element
> * A displayed point P'(x', y') will depend on the deviations of the
> bounding box from the border of the referenced path
> * If the two deviations, say, at the top and at the bottom are equal, y'
> = y, same for left/right and the x axis
> * otherwise x' = x + (deviation_left - deviation_right), y' = y +
> (deviation_top - deviation_bottom)
> It is quite probable, that one has to take the x deviation for y into
> account, since there can be dependencies for complex paths (leading to
> some kind of convergence calculation). That's not respected by the above
> instructions. Also for twisted paths, spirals and so on, I guess you'll
> have a hard time to define the deviation clearly.
> On implementor's side in the linear case (see below) it should be
> possible to look at how, e.g., GIMP is doing it for pixels or,
> for a simple example in SVG (only trapezoids), Inkscape's plugin
> "perspective.py", usually living at /usr/share/inkscape/extensions or
> %ProgramFiles%\Inkscape\share\extensions. It does it with a simple
> python based geometry library (~250 lines code).
> The path structure would not neccessarily be conserved (the "non-linear
> case"). Consider some "waving path" like a "rectangular" with sinusoid
> curves as borders as the source for the distortion. Then a distorted
> "normal" rectangular would take on this shape, hence the linear borders
> get "waved". This, however, is not implemented in any of the above
> examples. But I think, it would be a very powerful feature.
> For sake of implementing, the feature could be restricted to a path with
> four straight lines, but I think, it would hugely diminish the power of
> the idea.
> Best,
> Manuel
> Dr. Olaf Hoffmann schrieb:
>> Having some experience already with 3D transformations
>> and different projections from 3D to 2D, I'd like to ask some
>> questions or to give some suggestions about this, just to 
>> get a personal impression:
>> Maybe it would already help to have some formulas to see,
>> how such transformation can be implemented?
>> If you have it for some examples or even some simulations,
>> how this works this could help. For example PHP-scripts doing 
>> the  transformation and presenting the result in current SVG,
>> this could be already used to explore the behaviour
>> and possible difficulties and applications ...
>> Especially do this conversions conserve the structure
>> of the path (straight lines are still straight lines or points,
>> cubic beziers are converted just in other cubic beziers 
>> just by conversion of points and control points etc) or
>> does it create completely new paths, a viewer has to
>> calculate for each device pixel?
>> I think, with such a simple approach the viewer has
>> not to care in a specific way about the rendering order
>> as this happens for non trivial 3D-2D projections?


Andreas Neumann
Böschacherstrasse 6
CH-8624 Grüt (Gossau ZH)
Phone: ++41-44-2736668
Email: a.neumann@carto.net

Web: http://www.carto.net/neumann/
SVG Examples: http://www.carto.net/papers/svg/samples/
SVG.Open: http://www.svgopen.org/
Received on Monday, 1 September 2008 21:16:01 UTC

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