W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css-shaders] subdivision for transparency

From: Chris Marrin <cmarrin@apple.com>
Date: Thu, 06 Oct 2011 10:03:55 -0700
Cc: Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
Message-id: <774D25DC-F8BE-47AF-849A-79B53AC72663@apple.com>
To: Gregg Tavares <gman@google.com> (wrk)

On Oct 4, 2011, at 9:40 AM, Gregg Tavares (wrk) wrote:

> 
> 
> On Mon, Oct 3, 2011 at 8:18 PM, Dean Jackson <dino@apple.com> wrote:
> 
> On 04/10/2011, at 11:10 AM, Gregg Tavares (wrk) wrote:
> 
>> Looking at the CSS shader proposal I wonder what if any story there is about subdivision of polygons to correctly display content.
>> 
>> The current 3D CSS spec does not list subdivision as far as I know but Safari implemented it first and as the implied reference implementation it subdivides polygons where necessary. Chrome currently does not. 
> 
> It's unfortunate that the specification does not describe what to do here. In fact, that was deliberate at the time because we didn't know what was best. Safari originally did not subdivide the polygons, and still doesn't on OS X 10.5. The fact that we do now isn't really something we specify (even at a platform level)
> 
>> What do I mean? Well, in order to correctly display 2 or more semi-trasparent elements that intersect each other in 3d space it's necessary to subdivide the polygons that are used to draw the elements with so that the part of the elements that are behind others are drawn first, then the parts in front are drawn last.
>> 
>> Here are 2 screenshots. The first shows Safari which correctly subdivides the polygons. The second shows Chrome which currently does not.
>> 
>> <correct-3d-css-polygon-sorting-subdivisions-safari.png> <incorrect-3d-css-polygon-sorting-subdivisions-chrome.png>
>> 
>> Arguably Chrome should update its renderer to handle this case so that web developers can count on correct displaying of 3d css content.
>> 
>> 
>> 
>> But, that brings up the question, that's the sorting spec going to be for CSS shaders?
> 
> I'm not sure I understand the question completely. CSS filters (let's not call them shaders - that's just a proposed extension to the current draft) are always a 2d effect, even if they appear 3d.
> 
> The CSS Shader proposal changes this. The proposal allows vertex shaders and specifying a mesh resolution so that you can change the element from a flat plane to any shape your vertex shader calculates. sphere, crumpled paper, whatever.
> 
> See examples on this page
> http://www.adobe.com/devnet/html5/articles/css-shaders.html
> 
> Once you've changed from a plane to say a folding paper the sorting issues get much harder. The only way I know of to correctly render at that point is to actually run the vertex shaders on the CPU to generate the resulting geometry and then start intersecting that resultant geometry with other resultant geometry, subdividing individual triangles where necessary 
> 
> Of course the spec could just say "no sorting happens" 
> 
> You still need to sort individual meshes otherwise this demo would not work.
> 
> http://www.webkit.org/blog-files/3d-transforms/morphing-cubes.html

But that's a separate issue. The faces of the cube do not intersect, so this is just a sorting issue on each element. I was surprised that the 3D CSS Transform spec does not mention this issue at all. I think it should state that non-intersecting elements are required to be rendered according to their depth, with those elements containing the furthest z value rendered first. I believe we can write the spec so that compliant implementations agree in their rendering behavior. But when it comes to intersection, I think we should state results are unspecified. I think this is what Chrome does today. At least it renders the Morphing Power Cubes demo correctly. So I'd say that it's behavior with your example is compliant, if we write the spec like I suggest.

As far as CSS shaders go, just as for picking, I think the transformations on the vertices should be visual effects only and should not affect interactions with other rendered elements. To put it another way, we should look at CSS shader effects as being applied to the flat plane of the element and that plane is composited with other elements on the page. It's as though the element with the shader applied is merely a flat snapshot of the rendered mesh. In terms of CSS, this behaves like a CSS Transformed element with transform-style:flat.

-----
~Chris
cmarrin@apple.com
Received on Thursday, 6 October 2011 17:04:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT