RAGE WebGL Tech Talk

Wow!

I'm really blown away by the response to the video of my RAGE WebGL demo! It's been getting a lot of word of mouth on Twitter and it's been really fun to follow what people have been saying about it on sites like reddit. And most of what I've been hearing is positive too! Which is awesome... mostly...

..except I think people don't really understand what they're seeing. I'm getting a lot of credit for doing an awesome WebGL demo, and certainly I'm proud of it, but the fact is that the real work done on my part was reverse engineering the format. Once that was done the rendering was pretty trivial. And if the video looks awesome then ALL of the credit for that goes to id Software's incredible art and tools teams! The fact is, outside of some careful management of the textures this project pales in comparison to the complexity of, say, my Quake 3 demo. Of course, to a certain degree that was the point of this whole exercise...

iOS RAGE rendered with WebGL

As promised, here's the new WebGL demo that I've been working on! I won't be posting a live version this time (watch the video to find out why), but I will be demoing it on stage at OnGameStart this September as part of my presentation.

I have several follow up posts to this one that I'll be making soon to post the source code for this demo, describe the file format (at least the bits that I was able to figure out) and talk about some of the rendering techniques used here and why I feel this is a great format for WebGL.

UPDATE: I've now got the file format notes that I kept while building this demo avaliable as a Google Doc.

UPDATE AGAIN!: Tech talk for this demo is up now.

Interleaved array basics

I got a question from Jon in the comments on the WebGL sandbox project yesterday:

Hi Brandon, Using your demo as a starting point, I try to display a pyramid, but this far I've only been able to see one of its four faces. If I use gl.LINES instead of gl.TRIANGLES, then I see only one triangle (i.e. on face). I'm also a bit confused by the way you mix texture coordinates into the vertArray. Can you explain how these coordinates get sorted out in the shader?

Honestly I don't know if I'm the best guy in the world to be explaining this, but I'll give it a try, since there seems to be remarkably little WebGL-specific information about this. Most tutorials prefer to keep the arrays separate for simplicity, but that's not optimal for performance. The concepts all work pretty much the same as OpenGL, but it's nice to see them put to use in the environment you are using. It requires some basic understanding of subjects that don't normally apply to Javascript, like counting bytes, but it's not too hard once you get the hang of it.

Announcement: onGameStart

I've been sitting on this for a little bit, but now my face is on the website so I guess there's no sense in waiting any longer. I've been asked to speak on my Quake 3 demo at onGameStart, an HTML5 Game development conference in Warsaw Poland this September!

I'm still working on the exact subject matter of my talk, but it will most likely involve discussing the optimization challenges I faced while building the Quake 3 demo and things to consider when building a map or model format for use on the web. I'm also working on another surprise project that I want to be able to show off at the conference to contrast with the Quake Demo.

I'm extremely excited by this opportunity to mingle with the HTML5 game development community and share whatever I can about working in this exciting new environment! Hope to see you there!

Teaser time

So I'm taking a bit of a break from my super-secret game project to do a super secret WebGL project! :) I don't know if I'll be able to get this to a functioning point any time soon, but the following screenshot has me SUPER excited!

Hopefully I have more to show in another weeks time or so. Wish me luck!

Update: There's now something a lot more interesting than dots to look at!

WebGL Starter Package

[Edit: Now with 100% less jQuery dependency!]

I've had some sudden urges to jump back into WebGL land again lately, and while gearing up for another project it struck me how much time I was wasting trying to copy one of my older projects, strip out all the project-specific stuff, and get down to a really basic starting point.

Realistically, that starting point is one of the hardest hurdles to jump for any graphically-based program, doubly so for 3D programs. There's just so very many silly little things that might go wrong!

• Is the context and viewport set up properly?
• Is your shader compiling?
• Are your vertices right?
• Are your indicies right?
• Are your matrices right?
• Did you give the right strides and sizes to your vertex layout? 
• Is your geometry rendering in front of the "camera"?
• Is it rendering in a color other than the background color?
• Are you certifiably insane yet?

I decided to save myself some greif and put together a quick and dirty WebGL page that I can use as a jumping-off point for future projects. The goals here were to start with something that was putting geometry on the screen and allowed me to move around the scene, nothing more. This was the result:

Toji's WebGL "Sandbox"

Like I said, very simple. Just enough geometry on screen to know that you're rendering properly and to give you a sense of space. This is certainly not meant to be the foundation of a complex demo, but it sure beats starting out with a blank page! Of course, while I built this for my own use I certainly hope that some other aspiring WebGL developer out there finds it useful, and to that end I've packaged it up in a convenient downloadable bundle:

WebGLSandbox.zip

A couple of quick notes, for those that end up using this: Most of the formats I work with are designed with Z as the "up" axis, so Y is the one that actually points "out" of the screen. I'm using requestAnimationFrame (with fallbacks to setTimeout) for the core animation loop, so hopefully that doesn't cause any issues. I'm also not setting anything like blend modes or geometry culling states, you're on your own there. The page relies on my glMatrix library (included) and also makes use of webgl-debug.js, though you can easily turn that one off.

If anyone finds this useful or uses it as the basis for their own projects I would love to hear about it! Also, if you have any suggestions on how to improve it send them my way! Happy coding!

requestAnimationFrame

On the suggestion of @mrdoob today I reworked the animation loops for my Quake 3 and Doom 3 demos to use requestAnimationFrame (if it's available). This won't really produce a visible difference for most people, but it should utilize the browser event loop more efficiently. Paul Irish gives a good explanation of it at his blog.

A side effect of this that may be of interest to other developers is the simple little jQuery plugin I wrote to support this functionality in a cross platform manner that also provides a few perks to the user. You use it like so:

$('#canvas').requestAnimation(function(event) {
    // Draw frame here...
});

The "event" passed into the callback function contains the following values:

timestamp: Current timestamp, equivalent to new Date().getTime()
elapsed: Milliseconds elapsed since the animation started
frameTime: Milliseconds elapsed since the callback was last called
framesPerSecond: Rough count of the number of times the callback has been called over the last second. Only updates once per second.

If you wish to stop animating, return false from your callback.

I recognize that this may not meet everyone's needs, and probably is a little buggy at the moment, but it should provide a quick and easy way to do a basic animation loop in a way that plays well with your browser. If you have any suggestions for improving it let me know!