My question is surely a bit naive but I was curious about other’s opinions about this very simple question: what is in your opinion the most suitable terrain algorithm to be hardware-accelerated using OpenGL?
The ROAM 2 algorithm seems also interesting and suitable to be accelerated by modern GPUs but couldn’t find enough information about its internal working.
What do you think is the algorithm with the best tradeoff between performances and coding simplicity? From this point of view geomipmapping to me seems still the safest choice.
It would be very interesting to know what problems / performance issues other programmers found meanwhile coding their OpengGL terrain engine and what algorithms they use.
depends on the scale of the terrain you’re rendering.
geoclipmapping (the GPU-enhanced version)
pros:
low batch count, very fine controllable incremental updates from system memory to video memory (eliminating frame rate stutters during updates). Altitude makes no difference to CPU overhead. Geomorphing is easy.
cons:
needs SM3.0 hardware, is a bit complicated to code, quite difficult to combine with other types of terrain geometry (like drop-in local terrain meshes).
geomipmapping
pros:
simple to code, easy to combine with drop-in terrain meshes, doesn’t require any particular hardware features.
cons: (only did a quick test implementation years ago, so maybe these things are solvable)
quite high batch counts with altitude, so CPU burden goes up as you go up. Geomorphing is a bit more fiddly.
Thanks knackered,
I also ran into some papers from IRIS about clipmaps and they seem to be similar in some way to John Carmack’s Megatexture algorithm.
Back then, of course, there wasn’t much in the way of shaders, but what really impressed me about this algorithm is that it didn’t lag out when the viewpoint turns quickly, like ROAM implementations and other terrain LOD techniques did. This algorithm leverages the cache rather than looking up data in RAM. It’s rather interesting.
Thanks 147-2, the SOAR algorithm seems very interested also because supports out of core databases which is a feature that I would need at some point. Implementing out of core databases doesn’t seem trivial at all with geometry clipmaps. Another big doubt I have about geometry clipmaps is the management of spherical terrains.
If I’m not wrong also OpenSceneGraph uses a terrain engine that is very similar to (if not based on) SOAR.
This should be no problem at all, you just load the tiles you need. I’m using geometry clipmaps with images larger than two terabytes (>25gb compressed) on commodity pcs. See http://www.zib.de/clasen/?page_id=31 for a general overview on how to update the geometry clipmap.
Thanks Malte! Congratulations for the huge job done! The techniques described in your papers to me seem the more advanced, general and complete terrain system I ever saw till now, it’s basically my dream-terrain-engine made reality! Now I got to study a lot of stuff it seems…
Arithmetic coding combined with trivial predictors wouldn’t do a good job on color or height maps. I’m using JPEG 2000 and ECW, a wavelet based compression by ER Mapper similar to JPEG 2000. ER Mapper provide a SDK including the complete source code which can read and write these two formats. If there was a free implementation, I would also consider Mr.SID.
I’m fortunately living in Europe where we don’t have software patents, so I didn’t have to investigate this further.
Thanks It’s all under the MPL, so you can also use it in commercial closed source projects. If you want to contribute to our terrain renderer, feel free to submit patches. And there’s still a lot to do, e.g. the clipmap updates should happen in small blocks and not every frame for single-pixel-lines. If this is considered off-topic, contact me via email: clasen@zib.de.
I am still at the early stage of investigation of this terrain topic as I plan to write (or integrate) an advanced terrain system in the library I am currently working on (Visualization Library, which is strictly OpenGL based) as soon as I finished with the second alpha release around September hopefully (which will also feature a much more liberal licensing similar to MIT, ZLIB, MPL, BSD, or Apache).
For the next alpha release it would be absolutely great if I could integrate your terrain system with Visualization Library, or at least it seems worth the effort investigating further this opportunity.
Thanks for the email, I will surely contact you soon to gather more information about the whole topic and to examine better the feasibility of such integration.
Split your terrain up into 128x128 sections. This is the maximum that can be rendered with shorts.
Create a 128x128 patch of quads. Render this over and over for all sections of the terrain. Create a vertex attribute in your shader in which a unique height buffer can be stored for each different patch of terrain.
This will render large amounts of terrain very efficiently, and it works well with culling and LOD. You can store an 8 million triangle terrain in about 8 mb.
it’s a defensive patent - i.e. to stop anyone suing microsoft for using it. If they tried to sue anyone else for using it they’d risk being sued in turn by SGI who invented the original clipmap algorithm on which geoclips are heavily based.
It’s all under the MPL, so you can also use it in commercial closed source projects. If you want to contribute to our terrain renderer, feel free to submit patches. And there’s still a lot to do, e.g. the clipmap updates should happen in small blocks and not every frame for single-pixel-lines. If this is considered off-topic, contact me via email: