Re: [css-shaders] subdivision for transparency

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

With CSS shaders, each of the 6 faces of both cubes (inner and outer) could
be morphed into a 12 spheres. Even if they don't intersect they still need
to be drawn in the correct order to render correctly. But, now you have the
issue that you don't know where the extents of the polygons will be unless
you run the vertex shader on the CPU and check the results of the shader.

Of course again, the spec could say "meshes get sorted as though they are
still planes"

Finally, if you do morph a single plane into a sphere with CSS shaders, even
rendering that itself has to be speced if backface-visibility is set visible
then sorting the resultant mesh from the vertex shader has even more issues.

Right now though, the CSS shaders proposal specifies none of those and given
that Safari both sorts meshes and subdivides them if they intersect it seems
like this behavior needs to be specified, both for 3D css (what is the
sorting algo and subdivision algo) and for CSS shaders.

Without sorting specified even a "Coverflow" type UI will not be displayed
correctly across implementations.

Without all of that specified for CSS shaders the example "flipbook" on the
adobe page linked above would also sort differently on different
implementations.



> In other words, the effect might operate locally in a 3d or pseudo-3d
> environment, but the result is always composited in 2d onto a flat plane.
> Elements should sort the way they do for regular HTML (with CSS 3D
> transforms, which is probably less-than-well-defined). A filter does not
> make an element 3d.
>
> Dean
>
>
>
>
> ps: the live html/css is here
> http://greggman.com/downloads/examples/intersecting-elements-3d-css.html
>
> pps: if you care about Chrome status on this issue you can follow it here<http://code.google.com/p/chromium/issues/detail?id=74204>
>
>
>
>