PDA

View Full Version : Best OpenGL-friendly terrain algorithm



HollanErno
06-11-2008, 09:50 AM
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?

I am at the point of deciding what terrain algorithm implement for my OpenGL project and the two most probable solutions I found are:
1- Geometry Clipmaps: http://research.microsoft.com/~hoppe/#gpugcm
2- Plain Geomipmapping like Ogre3D and Irrlicht do: http://www.flipcode.com/archives/Fast_Terrain_Rendering_Using_Geometrical_MipMappin g.shtml

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.

knackered
06-11-2008, 11:30 AM
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.

HollanErno
06-12-2008, 02:40 PM
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.

See for example:
http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Texturing/Clipmap.pdf
http://developer.download.nvidia.com/whitepapers/2007/SDK10/Clipmaps.pdf

I think there should be an OpenGL extension that supports clipmaps (like DX10 does) but couldn't find it.

Did anyone tried the clipmaps-megatexture kind of approach using OpenGL?

Nicolai de Haan
06-12-2008, 03:10 PM
http://www.gamedev.net/community/forums/topic.asp?topic_id=497288

147-2
06-12-2008, 03:31 PM
When I was working with terrain, I found that the SOAR terrain technique was rather well suited. http://www.cc.gatech.edu/~lindstro/software/soar/

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.

HollanErno
06-13-2008, 06:15 AM
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.

Malte Clasen
06-13-2008, 07:06 AM
Implementing out of core databases doesn't seem trivial at all with geometry clipmaps.
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.


Another big doubt I have about geometry clipmaps is the management of spherical terrains.
This has been solved two years ago, see http://www.zib.de/clasen/?page_id=6 .

And if you want to download the source code for all of this, check out https://svn.zib.de/lenne3d/ . Binaries are available at https://svn.zib.de/lenne3d/install/current/win32_vc9/ .

Malte

HollanErno
06-13-2008, 09:05 AM
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...

Thanks again and keep up the great job!

HollanErno
06-13-2008, 09:11 AM
Malte: just one question, does your program uncompress on the fly the database? If so, what compression scheme do you use, arithmetic coding?

About the paper on arithmetic coding you published: aren't there patent issues on using such algorithm?

Thanks

knackered
06-13-2008, 10:48 AM
you could also just look into ray casting into a clipmap stack.

HollanErno
06-13-2008, 02:30 PM
Hi knackered, I never heard/read about this technique, do you know any references/links/papers where I can look for more details?

Malte Clasen
06-13-2008, 04:28 PM
Malte: just one question, does your program uncompress on the fly the database? If so, what compression scheme do you use, arithmetic coding?
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 (http://www.ermapper.com/ProductView.aspx?t=28) 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.


About the paper on arithmetic coding you published: aren't there patent issues on using such algorithm?
I'm fortunately living in Europe where we don't have software patents, so I didn't have to investigate this further.

Malte Clasen
06-13-2008, 04:37 PM
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...
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.

HollanErno
06-14-2008, 06:51 AM
Thanks :) It's all under the MPL, so you can also use it in commercial closed source projects.
I must say this is absolutely great news :)


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.
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 (http://www.visualizationlibrary.com), 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.


If this is considered off-topic, contact me via email: clasen@zib.de.
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.

Cheers,
Michele

Leadwerks
06-16-2008, 10:41 PM
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.

knackered
06-17-2008, 01:22 AM
...at ground level. Your batch count would go through the roof after your plane takes off. Not to mention geomorphing.

Dark Photon
06-19-2008, 06:41 AM
I am at the point of deciding what terrain algorithm implement for my OpenGL project and the two most probable solutions I found are:
1- Geometry Clipmaps: http://research.microsoft.com/~hoppe/#gpugcm

Not that novel, but nevertheless patented by Microsoft (IIRC). Be sure to pay them money first.

knackered
06-19-2008, 09:59 AM
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.