Creating 3D worlds with HTML and CSS
keithclark.co.uk
keithclark.co.uk
The primary issues are touch handling and clipping. The safari team nailed clipping (or they just relied on the GPU to do it for you) and touch handling has always been a little bit hit or miss, fortunately not huge for our requirements (although I did end up writing my own raycasting to compensate in some unreleased things). Chrome has been somewhat of an utter disaster with clipping and based on the current demo, still is (things flicker in and out randomly). They've come a long way (Android Chrome was locked around v18 or so for a while which was completely unusable for this sort of thing), but the fact that Chrome supports both real GPU accelerated and acceleration in software appears to have somewhat muddled their implementation.
Also, if you thought Chrome did clipping badly, you should try Firefox!
If you actually want to implement 3D graphics in production, please learn it first from a proper source.
This free online course get's you up and running on the basics of 3D graphics with WebGL: https://www.udacity.com/course/cs291
There are fairly decent books on WebGL available as well which also run you through the basics.
To get coherent 3D stuff going you need to actually understand what is going on at a fairly deep level, or you will just ruin everyones day who is a stakeholder in your project. Learn to use Blender at least on a rudimentary level. Learn WebGL. Figure out how to get the 3D content from Blender to your renderer. Then reconsider this.
[Note: I have a few years of professional graphics programming under my belt so I think I know what I am talking about.]
What major mistakes are the author doing due to not knowing (as you seem to infer) 3D graphics well enough?
I, for one, was impressed (after grudging a bit about the talk about rectangles in the intro, which I think should be triangles to be more specific but I could be wrong, it's been a while).
IMO, there are no "mistakes" in implementing how the graphics behave as they are. I'm not putting down the author, the demo is cool like I said. No, sorry, it's friggin awesome.
But! It's not an advisable production environment prototype.
First of, the content path is a bit more non-obvious than using more established methods. The extension mechanisms to the technique, as the author himself stipulated, are quite tricky.
WebGL was created specifically for rendering 3D graphics on the browser. I'm not an expert on the exact state of the art browser rendering implementations but I would expect the OpenGL context would offer a more consistent rendering on a larger set of end user devices/browsers than depending on the correctness of implementation of CSS transitions, or, on mobile devices, at least more battery friendly.
Now, if someone is looking into implementing a realtime 3D rendering solution to ones non-hobby webpage, it would make sense to research established techniques and understanding what someone is actually doing rather than jump in with this technique since to use it properly, I think you still need to grok all the stuff about linear algebra and shading models that are exposed in a structured manned e.g. in the course I linked.
I began my computer graphics hobby stumbling with vague hacky techniques years ago until I found out there was an entire well established field that teaches and extends this stuff at which point I cursed I had not found the courses and the books earlier. Just trying to save anyone's time who finds this sort of thing fascinating.
I have known a legacy codebase that would be _a_lot_better_ in every aspect had the original authors used well known graphics concepts to structure the system rather than kludges they made up along the way while re-inventing the wheel. The core concepts in 3D graphcis are not among the most complex technical things. However, there are lots of tricks and such you either need to discover on your own or read up. If you just ignore the established literature and best practices you will probably lose a lot of time hitting your head against a wall that would have been better used in drawing pretty pictures :)
I remember thinking how huge it was going to be.
What we really see here is a JavaScript 3D engine with a CSS backend. Impressive - yes. A good idea - not so much.
Some people just enjoy an odd challenge!
Is it slow for you? It's totally smooth for me, rendering full screen on a big retina display. I not sure I can imagine there's any way you could write a software renderer in JS to do that.
In Chrome, though, it's buttery-smooth with only small glitching.
Still, both are glitchy. I'm glad I went with THREE.js and not CSS 3D transforms for my latest 3D web project. THREE.js just works.
I guess this should be a nice test case for lots of work fixing z-indexing/z-buffering glitches for the Chrome developers, because I get constant z-fighting between the objects.
The fact that this works at all is a testament to how amazingly powerful modern DOM rendering engine are. All this from something that was initially designed to layout text on computer screen!
What? Knowing how to transform each object though is the hard part - especially as scaling needs to change if you are only using rectangles. The demo is a little wonky for me but I am also on an old FF system currently so I will look again when I get home.
I think this is really cool, and could be really interesting - I am mostly wondering how you transform 3D objects into the CSS dimensions.
Also, the CSS syntax seems very straightforward as compared to the WebGL I've seen, which I haven't ever really been able to understand just by glancing at it.
Regarding scalability, my previous experiences with similar rendering techniques is that this will definitely not scale on current GPU architecture.
The problem here is that with each polygon, your GPU api performs a draw call, an expensive operation you don't want to abuse. Also, updating matrix and other uniforms with each polygon is expansive. In a certain sense, your browser has to upload your entire geometry to GPU every single frame.
I can see this approach being useful for simple scenes with relatively flat objects. For an actual 3D geometry, I would never think using this in production.
My first impression is that there is no z-buffer (or anything like it). With this you'll end up with some objects popping in-front of others ("fighting" who to be drawn). Nothing bad with it, but subdivision helps in there. That's how the Playstation 1 used to work and many other PC chips at the time.
I haven't even dared to look at the source, because as I've said I don't know much about it (and heard of DOM, but that's about it).
But then - HOW IS THAT EVEN POSSIBLE! That's fuckin incredible!
Thanks!