Altitude0 WebGL Track Editor

DareM 102 Dec 18, 2013 at 10:18

Discuss link: Altitude0 WebGL Track Editor (


These days we’ve been finishing up web browser based track editor for our upcoming game Altitude0. It allows you to create your own tracks the way you want and share your creation. It runs in any modern web browser that supports WebGL (like Firefox or Chrome). Currently Altitude0 Track Editor is available here:

Certainly the idea of 3D games running in a web-browser is exciting but I hit a bunch of issues along the way. The editor has high quality terrain mode that I am still looking for a browser that won’t freeze on me. You can try it out yourself, I assume there are strict memory limits or maybe library I’m using - three.js is too memory hungry.

I wonder how usable some of you may find WebGL to be in the current state.

enter image description here

4 Replies

Please log in or register to post a reply.

TheNut 179 Dec 18, 2013 at 16:04

Freezing can occur for any number of reasons, but most often I found it’s because web developers are loading everything in one pass. JavaScript is a synchronous platform and when you make a request to compile a shader, create a VBO, FBO, or texture, it can freeze the browser. Some drivers take longer to compile shaders as well, so these people end up waiting several seconds longer. The more shaders you have and the bigger they are, the longer it takes to compile.

Last I looked at Three.js, all the shaders are defined in JS files, which will be pre-downloaded by the browser and executed in one shot. If all the shaders are being compiled at that point, then it’s going to cause lock-ups. In my engine I take advantage of JavaScript’s asynchronous XMLHttp calls to fetch resources and load them when they download. This allows for breaks between JS frame updates and helps to prevent locking the browser. This also lets my apps have a smaller footprint and enable me to show a loading screen while resources are downloading.

DareM 102 Dec 18, 2013 at 17:19

About loading everything in one pass, I think I handled that one.

Building terrain (grid size 1024x1024) freezes browsers - Firefox & Chrome. Terrain is loaded in chunks but still. There were no problems when I decreased terrain resolution to 512x512. Looks like both browsers have to be restarted after failing to load 2M triangles. I wonder if these are browser limits or three.js has a lot of allocation overhead. Are there absolute memory allocation limits in browsers?

TheNut 179 Dec 19, 2013 at 07:57

A 1024x1024 heightmap will create a VBO with more than 1 million indices. The OpenGL ES 2.0 specification (which is what WebGL is based off) only allows a maximum of unsigned short, or 65536 indices. Since you’re going well beyond that limit, you’re likely to run into issues. 512x512 shouldn’t work either, but you may see the first 65536 indices before the rest gets cut off. If you’re seeing more, than there’s probably a driver bug that’s allowing that (FYI driver bugs are a dime a dozen).

An optimized heightmap engine will produce (width x height) vertices. This means the maximum heightmap you can support on OpenGL ES 2.0 is 256x256 = 65536 indices. Even if you were using standard OpenGL, you generally don’t want to use integers for indices because it will consume twice as much video memory compared to using shorts. In these cases, just render a set of 256x256 patches. This is also better on performance because you can quickly cull non-visible patches. A large singular heightmap would be difficult to cull because it has a larger view radius and thus wastes GPU cycles to process non-visible polygons.

– Edit You may also want to look into Geo Clipmaps. It’s a fairly easy technique to implement and gives you the quality and performance for rendering highly detailed terrain.

DareM 102 Dec 20, 2013 at 13:49

Thanks for your tip, I’m new to WebGL and OpenGL in general. I’ve been stuck in DirectX land for too long. It never occurred to me to check on some specs for OpenGL ES 2.0. I checked the code and I already display terrain in chunks of 8x8 mesh objects. Therefore each mesh uses sub-grid of (128+1)x(128+1) vertices, well below 65536 indices (by pure coincidence). Cutting into multiple meshes was done for culling reasons. Otherwise for now I skipped advanced terrain rendering (like you mentioned Geo Clipmaps). Probably PCs should be able to handle at least 512x512 grid (1M triangles). Not sure about handhelds.

But I will read on OpenGL ES 2.0 specs.