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.

Cross platform learning tools comes to mind...

- 3D visualization for describing medical conditions to patients.

- representation of drug molecules to prospective doctors and molecular scientists.

- Visualizing spatial trends in big data.

Great demo. I would have used Flash/Shockwave for that in a blink of an eye a couple years back.

I would have used VRML. And get off my lawn!

And it wouldn't have flickered :-)

Before hardware acceleration it would have.

Requirements?

All i am getting is the bottom of a box that i can move around, and high CPU use.

A browser who supports CSS 3D transforms : Firefox 10+, Chrome, Safari (better), Android 4 browser, iOS' browser (even better).

Interesting. The demo worked great in FF, but was just a flat box in Chrome.

same for me

It works perfectly on Safari

The making-of: http://lockerz.com/s/194151945

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.

Strange - buggy here in Chrome (Mac), my browser goes transparent :)

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'm seeing it in Chrome.

Works great in the latest Firefox Nightly on the same machine.

Clipping issues galore, but still a great demo of where things are going :-)

The cows also flicker whenever you hover them.

Yeah, looks like some kind of z-fighting issue?

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.

Does it work on iPad?

Beautifully, yes.