@ThomasEgi: No, I did not try collision detection, and I would not advice to do so. SOAR creates one mesh, with a single primitive. If I understand Panda3d collision detection right it would be very slow to do so. But there are other ways. The refinement camera in the demo “walks” on the ground. The way Ranger MkII is implemented allows to query the terrain height, fast and computed from the true elevation data, not the current (optimised or not) mesh.
@Laurens: The “higher resolution” stuff is a bit complex. The heightmap (pudget sound) from the Ranger MkII demo is 1024x1024. The terrain that is rendered is 65k x 65k, that is 16 (2^16=65k) levels of refinement. The first 10 refinement level are computed from the heightmap data, the last 6 levels are random perlin noise. That’s what the detail elevation map is for.
This is just a trick to keep the disk size of the terrain data small and still have a nice looking terrain with lots of details. Anyway, the processed terrain data for a 1024x1024 heightfield is 16M. For performance testing I scaled the original 1024x1024 heightmap up to 4k x 4k, and the terrain data grew to about 260M. And 65k x 65k would be around 10G disk space. This is not surprising, since the Ranger MkII implementation of SOAR stores four 32bit floats per heightmap pixel (Not much, but I wonder what kind of terrain data representation games like Oblivion or Gothic 3 use, for storing their huge terrains, with certainly more than 4k x 4x).
Filling in perlin noise is fine for visualization or for flight simulators, but for a ground based game… I don’t know.
ThomasEgi is right. SOARX is an old algorithm, from pre-GPU time, when using CPU time for reducing the number of vertices was more efficient than sending great numbers of vertices to the GPU. Today’s graphics hardware allows other approaches, like Chunked LOD or geomipmapping. Still, it has been fun and a nice exercise to do this small wrapper 