Re: [Rendering order] z-depth and 3D effects

Jonathan,

No, I didn't receive your proposal email, despite getting the rest of 
the flurry of related emails on 26 October. Oh well ...

The biggest question on the subject of z is conceptual: should we 
regard it as abstract (and solely to enable us to render objects in 
the order we want), or should we regard it as a dimension one can 
move around in in the same way as the first two (and to use for a 
range of exciting other purposes)? (How's that for slanted phrasing!)

Your proposal, Andrew Emmons' and HTML/CSS all fall on the abstract 
side of the fence. I am on the dimension side (and claim the support 
of the Transforms specification). Here's a simple example for you of 
how I see it:

<svg width="100mm" height="100mm">
   <title>z example for Jonathan</title>
   <rect x="5mm"  y="5mm"  z="20mm" width="30mm" height="20mm" 
style="stroke:red; fill:yellow"/>
   <rect x="25mm" y="15mm" z="10mm" width="30mm" height="20mm" 
style="stroke:red; fill:tan">
     <animate attributeName="z" attributeType="XML" begin="0s" 
dur="2s" fill="freeze" to="40mm"/>
   </rect>
   <rect x="45mm" y="25mm" z="30mm" width="30mm" height="20mm" 
style="stroke:red; fill:plum"/>
</svg>

What could be easier and more natural than that?  :)

Maybe there are ways of getting the best of both worlds, but for the 
moment there is a disconnect. Andrew's proposal could reconcile the 
two by using z-positions (co-ordinates in the z dimension) instead of 
z-indexes. But your stacking contexts extend the abstraction down 
into individual groups (self-contained sub-universes, if you like), 
which means reconciling local z-indexes with z-positions isn't possible.

If you want to introduce a range of pseudo-3D effects to SVG, 
z-positions would enable them directly (such as the animation in my 
example above). Integer z-indexes don't help at all. Andrew's 
proposal as it stands could be augmented by a mapping table (perhaps 
within the <defs> element) of z-indexes to z-positions, but it'd be 
unpleasant and of limited value.

We should also not forget what document authors are likely to find 
easiest to write and to understand. They all already deal with x and 
y positions in SVG and get around in the three dimensions of the real 
world. So I'm sure they'll have no trouble working comfortably with 
z-positions (and the Transforms specification expects them to). But 
z-indexes are artificial, and stacking contexts even more so. Are you 
in danger of allowing considerations of performance and ease of 
integration with HTML to come at the expense of usability and 
flexibility? Take off your programmer's hat for a minute!

A further issue that might be worth pondering sometime is the effect 
of the introduction of z-ordering (however it's achieved) on document 
structure. To date, rendering order has dictated document structure. 
Control over z-order will give authors a lot more freedom. Will it 
let them write better organized (for their purposes), more modular 
documents? Or could much more messy documents emerge? Might authors 
use z-order much more extensively than they need to, in large SVG 
documents, and impose a greater processing burden than expected? 
Could lazy authoring tools spit out documents with different 
z-indexes on everything? Could this have consequences no one has foreseen yet?

Regards, Steve.


At 17/11/2009 04:33 AM, Jonathan Watt wrote:
>Hi Steve,
>
>Have you looked at the alternative z-index proposal that I made:
>
>   http://www.w3.org/mid/4AE510F6.6050404@jwatt.org
>
>It practice it's similar to the "SVG Rendering Order" proposal you 
>refer to, but
>more general. Rather than just being able to position sibling 
>elements relative
>to each other in the z-axis, you can position elements relative to other
>elements in entire element trees.
>
>If this doesn't meet your needs, I'd be very interested to hear about it. A
>small concrete example (with code) would also be very useful in that case.
>
>Regards,
>Jonathan
>
>On 2009-11-11 1:56 AM, Steve Withall wrote:
> > Esteemed experts,
> >
> > The recent draft "SVG Rendering Order" specification makes a few 3D
> > effects easier to achieve. So does the draft "Transforms"
> > specification. They add to what can be done using filters (drop
> > shadows and lighting, in particular). But all these effects are
> > independent of one another. There's no underlying 3D model, so it is
> > possible merely to *contrive* to make individual objects appear 3D.
> >
> > Of course SVG is a format for 2D graphics, and should stay that way.
> > For your consideration I suggest that a 3D model sufficient for SVG
> > could be achieved by allowing a *z-depth* to be defined for each
> > element: its distance above (or below) a datum plane. (I avoid
> > calling it z-height because heights in SVG mean the y dimension.)
> > This single value would be a sufficient basis for calculating
> > consistent drop shadows and consistent perspective transforms across
> > many or all elements.
> >
> > Alternatively a z-depth could be defined for each z-order value.
> > That's probably sufficient in some situations, but not in others.
> >
> > An additional use case I have is displaying multiple SVG canvases
> > layered one above the other. I want each *canvas* to have a z-depth,
> > so I can throw well-positioned drop shadows from objects in one
> > canvas on to objects in canvases below. This can be regarded as the
> > ability to define the "absolute" (wider world) z-depth of the datum
> > plane for each canvas.
> >
> > Finally, is it worth the Working Group making a formal statement of
> > the extent and limits of SVG's 3D ambitions? (Forgive me if this
> > exists somewhere that I don't know about.) It could be something
> > along the lines of treating each element as two dimensional, but
> > offering ways to make collections of these 2D elements appear as if
> > they exist in a 3D environment.
> >
> > Thanks, Steve.
> >
> >
> >
> >

Received on Wednesday, 18 November 2009 09:34:50 UTC