- From: Alan Gresley <alan@css-class.com>
- Date: Tue, 04 Oct 2011 18:34:09 +1100
- 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. http://css-class.com/test/css/3/transforms/corners-curves-gradient-virtial-space.htm 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 http://css-3d.org/ http://css-class.com/
Received on Tuesday, 4 October 2011 07:34:43 UTC