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>

```
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.

https://www.svgopen.org/2008/papers/86-Achieving_3D_Effects_with_SVG/

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.

Andreas

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
>> 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)
Switzerland
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, 8 March 2017 09:47:15 UTC