Discuss link: Altitude0 WebGL Track Editor (www.altitude0.com)
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: http://www.altitude0.com/a0editor
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.
Please log in or register to post a reply.
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?
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.
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.
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.