Creating 3D worlds with HTML and CSS(keithclark.co.uk)
keithclark.co.uk
Creating 3D worlds with HTML and CSS
http://keithclark.co.uk/articles/creating-3d-worlds-with-html-and-css/
48 comments
Oh wow, Safari has indeed mastered clipping. It looks fantastic in Safari with zero issues.
Also, if you thought Chrome did clipping badly, you should try Firefox!
Also, if you thought Chrome did clipping badly, you should try Firefox!
This is a very, very cool performance benchmark for CSS operations but for the love of god, don't ever even think about using it in production if there is a slightest chance a) someone else would need to maintain your code b) modify the content.
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.]
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.]
I think it would help decrease your snarkiness meter reading if you also provided some specific, constructive, criticism.
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).
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).
Sorry about the snarkiness, I was aiming rather for "opinionated".
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 :)
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 :)
OT: Anyone remember VRML?
http://en.wikipedia.org/wiki/VRML
http://en.wikipedia.org/wiki/VRML
Glam is the 'spiritual successor' of VRML:
https://github.com/tparisi/glam
http://www.youtube.com/watch?v=e_eSWkYJ0j8
https://github.com/tparisi/glam
http://www.youtube.com/watch?v=e_eSWkYJ0j8
I remember an online VRML pseudo-MMO that pre-dated SecondLife and friends by quite some time in the late 90s. I think it was called CyberCities or something.
I remember thinking how huge it was going to be.
I remember thinking how huge it was going to be.
Cybertown was great. You could import your own VRML created objects to sell in the market for virtual currency; e.g. furnishings for people's homes.
Fondly, I was amazed at its scope. Too much too early I guess. The only viable market at the time was high end businesses (I remember a famous demo of an in-browser car design vrmlet: colors, coating). But it was a niche.
Yes, at least 26 people
https://www.facebook.com/PortBookFaceToVrml
https://www.facebook.com/PortBookFaceToVrml
I remember not just VRML, but noticing vwww.domain.com (or something similar) and thinking how it was going to be the future. Then I started using some random "3d" browser that allowed you to see webpages in a cube-like (compiz-like) environement. This was about 2001, which was the start to my interest in cgi and animation.
Oh nice! I started a VRML parser in Action Script (Flash), but never finished. Worked with Papervision3D at that time.
I do. I had assignments in VRML when doing my BSc degree, I remember doing a SMB clone in 3D. I don't have very good memories from that period...
This is probably the most insane way I've ever seen a 3d environment created (look at the DOM), but it really is incredibly well done. The performance is of course not nearly as good as WebGL, but it is a great proof of concept and could possibly be used a a polyfill for simple 3d effects and objects in browsers where WebGL is not supported or broken.
It sure is a fun way to do things. I have my own little CSS 3D demo: http://ajf.me/demos/200blocks
I'm going to offer a contrary opinion here and say that while the work is technically impressive, it's also crap. It's purely a case of "if the only tool you have is a hammer, everything looks like a nail". It is also NOT just HTML and CSS. Most of the real work is done in JavaScript. Given that, you might get better performance writing a software rasterizer that puts the whole image into a single rectangle and put that on a single div without 3d transforms. Another more "pure" implementation would use XSLT to convert XML into SVG with 3d transforms along the way.
What we really see here is a JavaScript 3D engine with a CSS backend. Impressive - yes. A good idea - not so much.
What we really see here is a JavaScript 3D engine with a CSS backend. Impressive - yes. A good idea - not so much.
Well...sure. The correct answer is "use WebGL, it's designed for this." Looks like the guy learned a lot about 3D engines though. His next goal (to make a CSS output for Three.js) is similarly silly, but the history of computing is full of ridiculous side projects.
The correct answer is not to use HTML5, JS and CSS whatsoever and just use proper native tools.
I think you might be misunderstanding why this was made, it wasn't made to be a good idea or even an actual engine that people use. The person made it because they could, because it's fun to do neat stuff for no other reason that to just do them.
Agreed. I've done several silly things just for the technical challenge.
Nothing wrong with trying to make linux run on a toaster
Some people just enjoy an odd challenge!
Some people just enjoy an odd challenge!
"Given that, you might get better performance writing a software rasterizer that puts the whole image into a single rectangle and put that on a single div without 3d transforms."
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.
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.
I found it to be horribly slow and really weird in Firefox (sometimes see-through walls, z-sorting somehow flipping with barrels behind columns being drawn in front).
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.
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 see things like this and am immediately humbled. Impressive work, the bar just got raised a bit.
This is awesome!
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!
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!
In many ways this makes dealing with 3D easier, as there’s no complex math to deal with — just apply a CSS transform to rotate an element around an axis and you’re done!
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.
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.
What I find more interesting is the intention to make a THREE.js renderer for it. It's an interesting exercise to work out how to make the 3D objects, and the lighting was particularly impressive. But presuming that something like THREE.js is available to you, then what advantage does this provide over the already available WebGL or Canvas2D renderers? Getting access to hardware accelerated texture mapping in the exceedingly rare cases where a particular browser version on a particular set of hardware with a particular OS has hardware acceleration for rendering DOM but has for some reason failed to implement--or intentionally blocked--WebGL?
This is interesting - it opens up the possibility of the usual design/coding separation of concerns that web development has had entering into web browser game development.
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.
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.
Amazing work!
I would never have imagined someone will take CSS 3D rensering this far.
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.
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.
I don't know much about html/js or css, but I've spent decade in a video game shop (generalist).
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!
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!
Really cool, although it seems to break a bit in my browser(s). Chrome ran it fast with some flickering, but in firefox it was a mess -- really slow and a lot of artifacts. Anyone else see that?
I had exactly the same issue.
He gave a great talk on this at the HNLondon meetup in September 2013, he was a really engaging speaker as I recall.
I really like seeing examples that illustrate how the more limits are imposed, the more creativity thrives. Not that CSS/HTML are that limited, but as far as creating a full blown 3D environment they would definitely not be something I'd even think about, and then I see this...
This is pretty cool. Has there been any performance comparisons between this new technique and HTML5 WebGL?
Nice proof of concept. But I think there is no advantage in comparison to webgl.
This is very cool. It reminds me of what Famo.us does, as a wrapper for CSS3-transforms that abstracts away the painful math parts.
Here's simple code for 360 Product Visualizer with CSS and HTML http://codepen.io/samarkandiy/pen/sLzmn
That is completely different and pretty much entirely unrelated.
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.