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

Robert,

At 19/11/2009 07:17 AM, Robert O'Callahan wrote:
>On Wed, Nov 18, 2009 at 10:33 PM, Steve Withall 
><<mailto:steve@withallyourequire.com>steve@withallyourequire.com> wrote:
>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!)
>
>
>I think those are really quite different 
>features with very different use-cases and 
>implementation requirements. Explicit 3D lets 
>you do a lot of cool stuff, but as Dr Olaf 
>pointed out, one of the first things you're 
>going to want to do is introduce 3D transforms 
>so that an object can have varying depth, and 
>then you need 3D rendering with z-buffers etc.

Taking a few careful steps in that direction doesn't mean going the whole way.


>On the other hand, some use-cases for reordering 
>2D layers are not addressed by "true 3D" 
>features. For example, jwatt raised the case 
>where you have an SVG fragment that wants to 
>reorder some of its children within a container, e.g. using CSS z-index,

But what does 'reorder' its children mean if not 
move them in the z dimension? In the real world, 
moving something in front of something else means 
it's nearer. I haven't encountered anyone for 
whom this behavior is insufficient, and who needs extra use cases.  :)

It's intrusive and inconsiderate to introduce a 
feature (changing rendering order) that barges 
its way into the third dimension, at best doesn't 
help with 2.5D stuff at all, and at worst wants 
to claim the third dimension exclusively for 
itself. (I thought this debate might be fun, but 
I didn't imagine it would turn into Star Wars!)

><svg>
>Â  <g style="z-index: 10">...</g>
>Â  <g>...</g>
>Â  <g>...</g>
></svg>
>Suppose you want to copy that fragment into the 
>context of some larger SVG document that 
>contains its own uses of z-index. With CSS you 
>can just set "z-index:0" on the <svg> fragment 
>and you get the results you want. With other 
>proposals, including yours, to avoid layers in 
>the outer document being interleaved with layers 
>in the fragment, you have to renumber the 
>z-values in the fragment and/or the outer document.

I grant that the z values across multiple 
documents used together need to be compatible. 
But you can say that about x and y values too. 
And I would argue that authors are more likely to 
understand and mesh multiple sets of z 
co-ordinates than multiple sets of z-indexes.


>Another point that jwatt raised which I'll 
>repeat is that certain effects make no sense if 
>they can be "split" into different layers. E.g.
><g opacity="0.5">
>Â  <g z="0">...</g>
>Â  <g z="10">...</g>
></g>
><g z="5">...</g>
>The group opacity model assumes you'll be able 
>to paint the entire contents of the translucent 
>group atomically. But here you can't, so what 
>would the rendering be? Similar problems occur with 'mask' and 'filter'.

It *is* possible to apply all the styling of the 
enclosing groups, even if parts are rendered in 
different orders, as in your example. (I'm 
grappling with an implementation of this at the 
moment. I've made a couple of false starts to 
improve efficiency, but I think I'm getting there.)


>CSS z-index solves this with the concept of 
>"stacking contexts" and saying that certain 
>properties other than just 'z-index' can 
>introduce a stacking context. But a concept like 
>that doesn't make much sense if you're using 
>true 3D geometry to do your z-ordering.

I agree with you there.


>Rob
>--
>"He was pierced for our transgressions, he was 
>crushed for our iniquities; the punishment that 
>brought us peace was upon him, and by his wounds 
>we are healed. We all, like sheep, have gone 
>astray, each of us has turned to his own way; 
>and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

Steve. 

Received on Thursday, 19 November 2009 08:55:05 UTC