Before we start, I would like to mention that this is not a tutorial about WebGL. There are a lot of very good ones in the web (check the references at the bottom). Instead, I decided to go in a different direction, writing about my experience with WebGL, both the good side and the bad one.
So, what is WebGL?Simply put, WebGL is a 3D rendering in a web browser (and here comes the good part) without the need of an external plugin. Although it's still a bit green in some topics, most browsers have a decent support for it (except, of course, IE) and there are a lot of very interesting things, like this:
Why WebGL?As a graphics programmer, you'd probably faced situations like this: «Hey, let me show you what I did!!! Just wait a second, I need to compile it first. Oh, you have Windows? No problem, let me tweak this a bit. And that over there. Crap, it doesn't load anymore. Never mind, I have an old one built on my iPhone...». Unfortunately for me, this is quite common.
So, one of the most important benefits that WebGL provides is «availability». I create something, publish it and then everyone can see it. No need to maintain branches of code for each platform. No need to wait for compile time. No need for me to be present when people see it. OK, the last one is a double-edged sword, but you get the idea.
result = a.translate + (a.rotate * b.rotate);
quat4.multiplyVec3(a.rotate, b.translate, tempVec3);
vec3.add(tempVec3, a.translate, result);
In my current project I'm using a component-based approach for extending nodes in a scene and, while I'm basing my design in a previous implementation that uses C++, the JS version of it far simpler. Does the component include an «update» member? If so, call it. If not, continue with the next one. You need to invoke a particular method of your physics component? No problem. Get the component from its own node and use whatever you need without casting it. Really simple.
The WebGL APIHaving worked on iOS for the past four years gave me a good understanding of OpenGL ES, so my first hours with WebGL I felt very natural.
Being a shader-based API, you can move a lot of calculations like vertex morphing or per-fragment lighting to the graphics processor, saving some processing power for other tasks, such as physics or sound. There's no support for geometry shaders as far as I know, though.
The garbage collector could be a problem if not handle properly. You need to be very careful when instantiating new objects or else you will end up with a crappy performance and lots of wasted memory. But then again, this is nothing comparing to what we had dealt before with other garbage collected languages.
One thing that disappointed me is that performance in mobile devices is still not good enough. I have a modern smartphone and it can barely handle relatively simple demos. I guess we're still stuck here with a native code…
AssetsNow here comes THE problem when developing games in a browser: Assets. There are two big issues with assets: asynchronous downloads and loading times.
Concerning the loading times, while we're technically able to render beautiful landscapes with lots of trees and wildlife, keep in mind that you can't expect users to wait 50 minutes to download 1.5GB of data. After all, you're still rendering a web page. This is a true constraint for web-based game. Yes, you can still use some techniques to store data offline in order to avoid re-downloading them again the next time, but users expect to load pages lighting-fast and that limits the complexity of what we can achieve. Streaming is your friend here, loading assets on demand, but these techniques are never easy.
And last, but not least, WebGL does not provide any mechanism to work with known file formats, neither for textures nor for models. You need to code the parsers by yourself, much as you would do in any other OpenGL API.
Closing commentsThis turned out to be a much longer post than I expected. There are a couple of things that I'll talk about in a later post, especially after gaining some more experience. For the moment, I cannot show much of what I'm doing other than the library that I'm working on, CrimildJS, a small WebGL-based game framework that I'm using in my current project. It's at a very early stage of development, but it's growing fast.
Until next time.