Thursday, May 17, 2007

World Wind Java terrain code goodies

I've had a look at the WWJ SDK terrain source and found some very refreshing code - especialy after strugling for two years with the C# version we know.

Terrain / images separation

One of the nice feature of this terrain engine is the separation between the terrain geometry and the images layers. It solves a lot of problems we have with WW.

ZBuffer and blurry islands

Each image layer in WW has its own multi-level terrain geometry that is rendered one on top of the other. But they dont have all the same level of detail, so part of one layer would pop out of an other layer... and the depth buffer (ZBuffer) had to be cleared between layers to avoid blur islands.

Then big triangles appear on the horizon when close to the ground. Other rendered objects could not trust the ZBuffer. Things where overlaping in some situations... a lot of problems really. Not long ago i was thinking of porting some of the terrain viewer shadow casting code (to make a shadow plugin), but i wouldnt have been able to apply it properly on the terrain.

In WWJ there is only one terrain geometry segmented into tiles - not necessarily square (more on that later), which are rendered multiple times with the different textures they individualy intersect. Texture transforms does the trick. All images are 'painted' on one terrain model. Much cleaner. Shadows could just be easily painted over - no ZBuffer issues or blurry islands (at least inter-layers islands).

Fine terrain with low res images

Another benefit of the separation is that he terrain level of detail is not dependant on the images resolution so that even low res imagery (like BMNG) can be rendered over detailed relief.

In WW, the terrain only gets better when higher res images have loaded, even if the elevation data is available. And it doesnt get better past the best images level, even if there is better elevation data.

www.organicvectory.com
Icosahedron globe

The terrain geometry being disconnected from the images, it can be anything - not necessarly the regular lat/lon grid that is very inefficient at the higher latitudes and awful at the poles. As a matter of fact there is an 'icosahedron tesselator' in the works in WWJ.

The icosahedron 20 faces can be recursively split to approximate a sphere with no 'polar' preference - every latitude has the same vertice density. That will make for a much more efficient model for planets - and asteroids... and clean poles too. However, the move may be challenging with the triangle tesselation introducing a lot of discontinuities (seams) into the terrain mesh. This may be a problem at some point. (Image from www.organicvectory.com)

I still have to discover most of the WWJ SDK code, but so far it is promising...