[SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "2.2. The 'perspective' property"

Hello SVG WG,

I think, the relation to transform and the displayed result should be
described and/or the related section of 5. should be referenced.

In detail:

What is the relation between the projection matrix given in 1.1 and 5. and 
the 'perspective' property? How are <px>, <py> and <pd> represented in 
the projection matrix (or elsewhere)? The matrix itself has only one
parameter 'd', other matrix elements are all 0 or 1.
Note that in 1.1 the matrix element with the d is noted to be '1/-d', in 5. it
is noted to be '1/d' - typo? intention? contradiction?

It is defined:
'<pd> specifies the <coordinate> representing the viewpoint distance from the 
X, Y viewing plane. The value is in the current user coordinate system.'

--> Note, that currently the user coordinate system is a 2D canvas in the
referenced SVGT1.2 prose. Something like a z-coordinate is currently available
already in the SVG1.1 filter section or the related filter draft. It is not
obvious, what <pd> represents in this user coordinate system as defined by
SVGT 1.2, therefore I think, the last sentence should be skipped and the roles
of the <px>, <py> and <pd> need to be explained, maybe using an illustrative 
SVG-document ;o)

Typo:
'projeciton matrix' --> 'projection matrix'


As far as I understand the formulas in section 5, the z-information is not 
conserved.

For example in SVG1.1 and SVGT1.2 the following has the same visible effect
(slightly modified sample from the SVGT1.2 specification):


'<g transform="rotate(-90) translate(5,10) rotate(90) translate(-5,-10)">
  <!-- graphics elements go here -->
</g>'

and

'<g transform="rotate(-90)">
  <g transform="translate(5,10)">
    <g transform="rotate(90)">
      <g transform="translate(-5,-10)">
        <!-- graphics elements go here -->
      </g>
    </g>
  </g>
</g>'



But with this projection this is not true anymore, these
are not the same effects, because the z-information is projected to zero for
every g element in the nested-g sample:

'<g transform="rotateX(-90) translate(5,10) rotateX(90) translate(-5,-10)">
  <!-- graphics elements go here -->
</g>'

and

'<g transform="rotateX(-90)">
  <g transform="translate(5,10)">
    <g transform="rotateX(90)">
      <g transform="translate(-5,-10)">
        <!-- graphics elements go here -->
      </g>
    </g>
  </g>
</g>'


Here this especially means, that without vector-effect="non-scaling-stroke"
the graphics elements will not be displayed at all and with only as 1D lines
or a 0D points.

Or does the projection only apply to the final display and the z-information
is still conserved for each element for the complete document? This would 
be pretty useful for many applications. Often it is required to have nested
groups with different transformations. If the z-information is lost, one still
has to compute everything with a server-sided script to get the intended
effect.

Think as a basic application for example about an animation representing 
a solar/planetary system - each planet moves in one plane, but each one in a 
slightly different plane and a planet/moon pair has a submovement in a quite 
different plane again.
If the z-information is conserved, the 3D transforms would be a big progress
and simplification for this example. If not, they are almost useless for such 
samples and one still has to do the complete job with a server sided script 
for each change of perspective the audience wants to see. Or at least one has 
to decompose everything into a set of additive animateTransforms for each 
graphical element, resulting in large files or in a massive use of entities,
defined in a doctype declaration to be able to reuse animation values lists
and without some non trivial user interactivity.
The next non trivial problem of this sample would be the rendering order,
the considered 'near' and 'far' values would already help for some problems,
some z-ordered automatic rendering option would be fantastic of course.
Currently one has to exchange the objects with some animations of 'xlink:href'
of 'use' with a lot of computation for a proper timing. Typically an infinite
proper animation is currently impossible, because those systems are not
periodically at a whole, only each separate animation can be periodically.

Received on Sunday, 22 March 2009 16:31:05 UTC