I hate to be that guy, but what exactly is the purpose of adding 3D transforms to web pages? I mean, beyond nifty demos like this?
Honestly, isn't this just going to add a bunch of dumb cruft to what browser vendors will have to support and probably just for the sake of being 201x's <blink> tag?
EDIT: To clarify--wouldn't it be more useful to focus on faster js engines and better WebGL support?
If the transformations/transitions are handled by the graphics card the faster js becomes irrelevant. For example js performance on IPad is not amazing, but it will run many transitions smoothly.
As far as WebGL, it clearly is important for any serious 3d. But adding a slight 3d effect to a UI element should not require a detailed knowledge of shaders and 3d geometry.
Is lockerz ever not down? And what exactly is their business nowadays, I remember they were scamming people out of "ptz" a couple years ago when it came out.
Very slick, but I'm seeing rampant clipping issues in both Chrome 19 and Firefox 11 with the latest nvidia 560 GTX drivers. Anyone else experiencing that?
I was under the impression that z-fighting was a result of floating point rounding errors when two depth values are very close together. The clipping errors I'm seeing don't seem to be correlated with surfaces that are very close in depth.
If it runs in software without some sort of z-buffer then you'll get z-fighting. It's the same problem that's been around forever when running 3D in software. Hardware acceleration would help with this but I'm not up-to-speed on the current state of browser support for hardware rendering.
If there's interest in playing with such technologies then I suggest reading up on z-fighting because if you understand why it happens then you can attempt to work around it. There are lots of old tips and tricks that still apply today.
It is my understanding that z-fighting occurs when the depth buffer has not enough resolution (due to floating point math). How is that related to whether it's hardware accelerated or not? You can easily get z-fighting with hardware acceleration.
Well, granted this is my experience, but if done properly you would rarely see this sort z-fighting in hardware acceleration. Usually when I saw that it was because of two surfaces trying to exist on the same plane regardless of orientation. Which I believe is what you are describing.
Thinking it over I may be incorrect in referring to this in the way I have. The issue I'm seeing is the back-to-front rendering (I'm assuming this is what the example is doing) of a smaller object being displayed on top of larger object and the renderer getting confused on the draw order.
Edit: ghusbands points out my confusion below
Granted, I'm not a 3D programmer but I built enough levels for 3D engines back in the day to have to be aware of these issues to design around them. This is all from memory so I could be totally off but this what it seems to me.
There seems to be confusion in this thread, caused by this message. Z-fighting is specifically caused by very near, parallel/co-planar polygons having similar z values, which is not the observed issue with the page. The issue with the page is more akin to rendering using the painter's algorithm but sporadically sorting incorrectly.
Honestly, isn't this just going to add a bunch of dumb cruft to what browser vendors will have to support and probably just for the sake of being 201x's <blink> tag?
EDIT: To clarify--wouldn't it be more useful to focus on faster js engines and better WebGL support?