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

Re: [css-shaders] subdivision for transparency

From: Alan Gresley <alan@css-class.com>
Date: Tue, 04 Oct 2011 18:34:09 +1100
Message-ID: <4E8AB6F1.1030502@css-class.com>
To: Dean Jackson <dino@apple.com>
CC: "Gregg Tavares (wrk)" <gman@google.com>, www-style list <www-style@w3.org>
On 4/10/2011 2:18 PM, Dean Jackson wrote:
> On 04/10/2011, at 11:10 AM, Gregg Tavares (wrk) wrote:

>> 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>

I could not find those screenshots.

>> 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?

What has CSS shaders got to do with this issue?

> 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. 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.

To right. It's virtual 3D display on a 2D flat plane that can trick the 
mind into perceiving such animation as real virtual space.

> 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

I see what could be the problem. I have noticed this myself when 
rotating elements (it happens with background color, gradients and 
backgrounds with transparency). It happened a lot in Safari 5.0. Chrome 
still has some odd behaviors. What happens is that things are not 
painted in how they should be (you can see through walls like some 
glitch in the matrix). One of my test.


An earlier version using a longer translation (a hack) painted the floor 
parts above the bottom part of the simulated curved surface. Like so.

   | | | | | | | | | | | |
   X | | | | | | | | | | X
     X X X | | | | X X X
       X X X X X X X X
         X X X X X X
         X X X X X X
       X X X X X X X X
     X X X        X X X
   X                    X

Now after much reworking, using z-index, translation on the z axis and 
even having the elements for the floor later in the source, I can not 
get them to paint over the bottom parts of the simulated curved surface. 
Like so.

   | | | | | | | | | | | |
   X | | | | | | | | | | X
     X X | | | | | | X X
       X | | | | | X X
         X X | | X X
         X X X X X X
       X X X X X X X X
     X X X        X X X
   X                    X

When hovering each example, you will notice that the roof itself is 
hacked in with a wrong translation (to avoid the same dilemma as a had 
with the floor) but this shows that roof disconnected from the other 
transform elements.

Alan Gresley
Received on Tuesday, 4 October 2011 07:34:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:05 UTC