Terrain optimizations

[Huehnerschaender]

Hi people,

I am wondering if anyone of you has experiences with terrain optimizations in runtime.

ROAM is the algorithm I am interested in the most.

Has anyone already implemented it in Delphi? And if so, is it possible to take a look at the source?

Greetings,
Dirk

[savage]

I know ROAM is all the rage, but have you looked at Diamond? It was developed by a South African guy called Henri Hakl, but it seems his university page has been removed :(. It had loads of Delphi/DirectX source code showing various indoor and outdoor algorithms ( including ROAM ) in action and his own one called Diamond.

[Huehnerschaender]

The "newer" ROAM algorithms use diamond structure, too.

I understand what ROAM does, and I know the benefits (read much about it the last days). But I don't want to do extra work which is already done. (Why inventing the wheel again?). If I do it myself, it has to be debugged, tested etc... It will last some time to get it working then. But if anyone here has done it already and don't mind that others use it, that would be a real benefit :) And I guess thats what we all want here. Discussing, learning and using shared ressources.

Too sad the site you mentioned is down...

Greetings,
Dirk

[cairnswm]

I googled the name (because it certainly doe not sound South African) and found this site:

http://www.vterrain.org/LOD/Implementations/index.html

[Sascha Willems]

Since I already did several terrain implementations, including Octrees and Diamond I can tell a bit about them.

For current generation systems I'd go with Octrees. Why? Because nowadays we have very fast GPUs and most of the time the CPU is slower and therefore it's best to use a method that is mostly biased onto the faster of those. Some years back GPUs were slower and so it was better to use methods such as ROAM, which do many calculations on the CPU itself. But as this has changed and the CPU also usually need to do a lot of other stuff in modern games (AI, Physics, etc.) you should go for a method that doesn't need to many CPU cylces at runtime. And for this, an octree is the best way to (as of now). It's calculated offline (or at the start of the application), so except for some distance and frustum calculations the CPU won't be stressed. And since modern GPUs have a very very high vertex throughput it won't be slower than e.g. ROAM, even if you draw more triangles than you would do with a ROAM-based algorithm.
And besides this (I guess this is for the project you showed off here at PGD) you can easily combine this with a Quadtree (2D-Version of an Octree) for your foliage layer.
I also did something like this last year with an Octree for the terrain and the Quadtree for the foliage, I could render huge terrains with a lot of foliage that also was widely visible.

Just my take on this ;)

[NecroDOME]

@cairnswm, we love google :), got teh same site :)

We are also looking for a good terrain LOD algorithm. Also you can check the DanJetX landscape source.

[savage]

I will see if I still have Hakl's source code on my old machine this evening.

[Huehnerschaender]

That would be fine :)

Thanks to you all for the advices and help.

I hope to get something working the next days... Just thought that there is an algorithm which is not bound too much on renderings (DanJetX landscape class needs nearly all other relevant DanJetX classes to work. But I am still trying out to understand it at all :) ).

I will also take a look at the quadtree thing....

[savage]

Good news guys, I got in contact with his professor who forwarded my email to him and he contacted me, and it looks like this site has moved to http://dip.sun.ac.za/~henri.
His Diamond algorithm and source code can be found @ http://dip.sun.ac.za/~henri/terrain.html

Lots of stuff on his page, some may be a little dated, but he informs me that he is working on an

engine and Quake3 rendering system I'm using for my reconstruction project


which are not yet up on that page. So it will be interesting to see what he's working on later.

If anyone has had the time to implement an OpenGL version of the Diamond algo, please let me know. I'm not sure if I'll get round to it.

[Huehnerschaender]

Cool!

I just started reading the site and found tons of very interesting things in some seconds :)

Thank you very much Dom! ;)

Greetings,
Dirk

[technomage]

I have just started looking into the SOAR Algorithm. from the information I have seen this is a nice fairly simple algorithm.

Marek Mauder did and Delphi Opengl demo you can get the source

http://galfar.vevb.net/cms/index.php?serendipity[subpage]=downloads&level=2&thiscat=2

I'm trying to turn this into an object based system ( this is procedural) but it's taking me a while.

Dean

[cragwolf]

For current generation systems I'd go with Octrees.

Yes, especially for first-person perspective games where the camera is close to the surface of the terrain. Then from the perspective of the camera, you could have terrain (chunks) above you and below you(*), and as such, octrees would be very useful. On the other hand, I wouldn't recommend octrees for strategy games where the camera is restricted to viewing mostly top-down, with only a little bit of tilting allowed, and never getting very close to the surface.

(*) not directly above or below you, since there is no degeneracy along the up-down axis in height-field based terrains.