WebGL Quake 3: 2 years later

Got a great question in the comments on my Quake 3 Tech Talk post today from Daniel P.

It's been almost 2 years since you did this. My question is: how much could you improve the rendering with your knowledge today?

Indeed, both WebGL and myself have improved since I initially did the Quake 3 demo, so it's interesting to look back and see what could be done better today given more expertise with WebGL and the evolution of the API.

Building the Game: Part 6 - Isosurface Landscapes

See the code for this post, or all posts in this series.
See the live editor demo.

Well, it's been a long time coming, but I'm finally back with another official installment in the Building the Game Series! As mentioned previously I'm want to take the series in a different direction now, and as such this post represents a bit of backtracking from the previous one but I'm hoping that it will be a more productive direction in the end.

Building the Game: Part 5.5 - Two steps forward, one step back

So this isn't really one of the "main" posts in the Building the Game series, but I feel it's important to bridge the gap between the last post and the upcoming one, since there's been a significant gap between them and the project's direction is going to change in some important ways. I've already hinted at some of the reasons why the series stalled out, but I want to go into some more detail about it now to give context to some of the decisions I've made.

The big issue that I ran into when trying to build on the last post was visibility culling. As you may have noticed, the live demo of the previous post wasn't exactly speedy, and that's because it was trying to render every piece of a very large scene every frame. The obvious next step is to introduce a visibility testing system that can quickly inform you of what meshes are potentially visible from a given point in the world. This isn't a new concept, and it's one that I've worked with before. Quake 3 and the Source engine both use a pretty straightforward PVS (potentially visible set) system, and I was expecting that Unity would expose similar information through it's APIs.

Unfortunately, it doesn't.

WebGL Texture Utils and Building Require.js libs

Two things to go over today:

One, I've got a new library out. WebGL Texture Utils. It's, as you might imagine, a collection of utilities to assist with loading WebGL textures of several different forms. Actually the repo for it has been available for a little bit now, but it's only today that I feel things have actually gotten to the point where it's really useful.

If I built a physics engine...

So let's be clear about something right from the very start: I'm not a physics guy. I love me a good physics engine, but I will likely never build one because that's just not where my expertise lies. Far be it from me to criticize the algorithms used by your broadphase collision pass, because I only have the most high level of ideas what that actually is. I'm a graphics guy through and through and that's where I'm happy to stay.

However, I do know a thing or two about writing fast Javascript code, which is something that will become fairly important to the new breed of browser-oriented physics engines that are starting to crop up, like Ammo.js, Cannon.js, and the various Box2D ports. Unfortunately, however, I've seen a few common threads within these engines that I think will limit their effectiveness in real-world use, and I wanted to get some of it off my chest while the development of these libraries is still in the early days. Some of these trends are inherited from the underlying C++ libs these libraries wrap (like Ammo.js, which is built from Bullet with Emscripten), but others appear to be self imposed. That's the group I'm talking to.

Javascript memory optimization and texture loading

Over the past couple of weeks I've seen a few great resources about optimizing your javascript. One is a wonderful GCD presentation by Lilli Thompson about best practices when writing code for V8 (Chrome's Javascript engine.) Although the presentation uses Chrome for it's concrete examples, much of the information is very practical for any browser.

GDC 2012: From Console to Chrome

It's a long presentation, but well worth the time. If you simply can't bring yourself to sit and listen for a bit, though, at the very least take a look through her slide deck.

The second resource is a great blog post by Ashley Gullen of Scirra about reducing the amount of time your app spends in that dreaded garbage collecting coma.

How to write low garbage real-time Javascript

I highly encourage you to go through both of those if you are a web developer. Even as an expert dev with years of experience, I'm sure you'll learn something!

Anisotropic Filtering in WebGL

On Google+ this morning Ilmari Heikkinen pointed out that support for the EXT_texture_filter_anisotropic WebGL extension landed in Webkit a little over a week ago. That's awesome, as it's one of the features that I've been waiting for essentially since I first started playing with WebGL.

[Update: To give credit where credit is due I've had several people point out that Firefox had this feature first. Guess I need to follow their commits more closely! Also, while some of the appropriate code is in Chrome I guess the feature isn't officially part of the browser yet. Apparently the fact that it works at all is something of a happy fluke. So I guess that for the time being Firefox is the only browser that actually supports this!]

I put together a really simple demo this morning to show how it works, and if you've got a recent Chrome dev build or Firefox nightly you should give it a try!

Yeah, the demo is ugly but it shows off the effect nicely. For those of you not familiar with the concept, Anisotropic Filtering is an extension of standard mip-mapping techniques that improves the quality of textures when viewed at an angle. A good example of this is the floor and ceiling of the demo above. With standard trilinear filtering (gl.LINEAR_MIPMAP_LINEAR) as the floor gets further away from you it becomes blurry pretty quickly:

By using anisotropic filtering, we alter the way that the mipmaps are queried in scenarios like this one, which can give a much crisper, cleaner image:

There is a performance penalty associated with enabling this, and when you do enable it you can specify how many samples are taken for a performance/quality tradeoff. This has become a pretty common setting available for the user to toggle in PC games, and so it's great that we're now able to take advantage of it on the web too!

Implementation

Turning this feature on is pretty simple in a supported browser. As with compressed textures the first thing we do is query the appropriate extension to see if it's available:

var ext = gl.getExtension("MOZ_EXT_texture_filter_anisotropic");

Obviously with Chrome you would query with WEBKIT_ instead of MOZ_, and eventually the prefix should go away entirely. If it returns null the extension is not supported and we move on, doomed to a life of blurry walls. If it is supported, however, it will return an object containing the required enumerations for the extension.

Since this is a filter mode, we enable per-texture just like we do bi/trilinear filtering or texture wrap modes, but with symbols from the newly queried extension:

gl.texParameterf(gl.TEXTURE_2D, ext.TEXTURE_MAX_ANISOTROPY_EXT, 4);

Here we're enabling 4x filtering (the value used by the demo) on the bound texture. Setting it to 1 effectively turns off this filtering, and your graphics card determines how high you can set it. You can query the maximum supported value like so:

var max_anisotropy = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY_EXT);

This particular API seems a little bugged right now, as I was only able to get it to return 0, but I expect that will be ironed out soon.

So, like I said, a simple API but a great one for bumping up your rendering quality!