Comment by hartror | Hacker News Reader

Comment by hartror | Hacker News Reader

A grain of salt, cannot fault the article except it skimmed over a couple of areas. Keep these things in mind, especially if 3D graphics is something new for you:

Why you shouldn't use WebGL

* Performance: This is the big one. In 3D graphics and in particular games performance, both execution speed and memory usage, is everything. You can do some great stuff in WebGL but fitting lots of complex stuff (physics, AI, motion) in 1/60 of a second is hard enough when you can scratch around in ASM if you have to, let alone being constrained to javascript.

The Three.js demos are fantastic examples and a great learning tool. But they do feel to me like 90s demo scene[2] stuff. Working within strict limitations and using all the tricks of the trade to produce more than the sum of its parts.

* Libraries: the leading library Three.js is great and getting better and I enjoy using it. But I have a background in 3D graphics and know my way around 3D and OpenGL. Alternatives such as Unity hold your hand and have larger communities from which to draw help from if you don't know much about 3D.

[1] http://mrdoob.github.com/three.js/

[2] http://en.wikipedia.org/wiki/Demoscene

A lot of people are underestimating what this stuff can be used for, IMO. It goes far beyond traditional games. I myself have been doing a lot of work with WebGL-driven articles [1]. With nothing more than nginx and Jekyll, I have an incredibly efficient pipeline to get 3D math lectures out to thousands with less than 20KB of JS per graph and 200KB of shared libraries. I can edit the content anytime I want and rsync an update. I got a 100k hits on that article last month, my little linode didn't break a sweat.

I've also been working on setting up GLSL based computational chains easily, allowing me to implement a fluid dynamics solver [2] with a dozen lines of JS and a hundred lines of GLSL [3].

It's not as demoscene-like as it seems, I don't have to work very hard to get it to run well, as JS is rarely the bottleneck.

Dedicated game engines will always be the realm of optimized native code, but there is an entire field outside that of rich 3D content. Between GLSL, Web Workers and fast JITs, there is a lot that can be done here. With JS, you not only get a platform you can deploy easily, but you get live access to a fully introspective VM at the same time. I expose all my JS to the console, and do most of my prototyping in there. All for free.

It's also the only platform that has a chance to be available universally, from pockets to desks to living rooms. I know I'd much rather restrict myself to techniques that are a couple years old, if it means it actually runs well on modest hardware—which a lot of demoscene stuff does not do.

[1] http://acko.net/blog/how-to-fold-a-julia-fractal

[2] http://acko.net/files/never-seen-the-sky/git/

[3] https://github.com/unconed/NeverSeenTheSky/blob/master/js/fl...

Exactly, you need to understand the trade offs, which I don't feel the article touched on.

I did say that I won't talk about the gotchas in this article up front though :)

It's already a wall of text, I think it's better to pick one topic and limit its scope for one post.

Performance: How fast is fast enough? We may not be able to make Battlefield 3 run in a browser yet, but there is a whole host of games that are possible, and are still a step-change in graphics compared to the 2D flash games.

We've got demos that are full rigid body simulations[1], 3rd-person shooters[2], fun little arcade games[3] and more[4]

Libraries: Three.js is great, but it's not a game engine. For games, the tool chain does exist though! At PlayCanvas[5] we've got a engine, visual editor, asset management, and publishing support. No WebGL knowledge required :-)

And because we're doing everything hosted in the browser, it gives us some cool bonuses, like real-time collaboration, cross-platform/device support, access from any browser.

[1] http://apps.playcanvas.com/will/ammo/vehicle

[2] http://apps.playcanvas.com/playcanvas/scifi/latest

[3] http://apps.playcanvas.com/playcanvas/apocalypse/latest

[4] http://playcanvas.com/demos

[5] http://playcanvas.com

Well you don't need a lot of CPU for doing AI and motion. In modern games, game logic like this usually takes not even 1% of the CPU time.

And more complex stuff than 90ies demo scene stuff is possible easily. There are lots of sophisticated 3d libraries to choose from, take a look at the demos of CopperLicht for example: http://www.ambiera.com/copperlicht/

But you are right: Physics is a major bottleneck. Fortunately, you don't need real rigid body physics engine in most games. In most situations, you can live with a small subset of it.

Well you don't need a lot of CPU for doing AI and motion.

Motion means collision detection and keeping the right data structures up to date. AI means things like path finding. Both sets of problems require lots of loops with lots of maths.

I've looked at Copperlicht and it is nice (looks like you work on it?), but still very limited when you compare it to the non-WebGL competition. The demos are all small largely static scenes that can be loaded onto the card and left untouched in memory.

I don't mean to say that WebGL isn't usable or that people shouldn't use it. I was providing a grain of salt to what was a very good write up.

btw. I like the doco for Copperlicht, nice and accessible and the octtree implementation impressed me when I was reviewing Copperlicht last weekend.

>Motion means collision detection AI means things like path finding.

There are many game types/genres which don't require collision detection or realtime AI.

Yup but people need to be aware of the limitations of the platform, something the article was very light on.

Reply on news.ycombinator.com