Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

creative1

fastest terrain algorithm for huge landscape

This topic is 5275 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I have been reading lot of drafts and documents about different terrain rendering algorithms but I can''t find any website that compares them all. I saw alot of cool algorithms that consumes alot of cpu and almost don''t use any gpu power. Nowadays the average video card renders a couple million triangles per second meanwhile the cpu can''t handle that work well. So, althought some algorithms look great in paper, once implemented they are not that much faster than the supposedly slow ones. Anyone has a comparison in an average computer of current algorithms for big terrains? I want to know, for huge landscapes (200 km from side to side) what is the fastest algorithm. quadtrees, geomipmapping, roam, soar, roam 2.0 ?... what brings the fastest rendering in an average video card today? Alot of people suggest this or other algorithm, but I can''t see any real measurements anywhere and no consensus at all.

Share this post


Link to post
Share on other sites
Advertisement
The thing with such algorithms is that there really isn''t a "fastest" one. If you have spare CPU cycles, ROAM (and more recently ROAM 2.0 and SOAR) are pretty good, but require sending dynamic data to the GPU. Also ROAM (and I think the other two) supports deformable terrain, that you won''t get from Chunked LOD and the like.

However, if you have enough memory, Geomipmapping or Chunked LOD are pretty good for the GPU. Because they switch between static vertex buffer patches, the data (at least, that data which fits in GPU memory) is static. There''s not much CPU involvement (much less than in ROAM/SOAR), and no dynamic data is being sent. So it''s faster, but it does have tradeoffs: that ever-classic tradeoff of size vs. speed. Chunked LOD terrains (at high resolution) can get pretty big. But, if I remember correctly, it''s also disk-pageable. I''m not sure if ROAM et al. can do that.

So the reason there''s no consensus or actual measurement is that there''s no real best. It depends on what types of landscaping you want to do, and what kind of other requirements you have.

For my project, I''ve gone with a Chunked-LOD-ish algorithm, if only because I knew I won''t have much CPU to spare. But you may decide otherwise.

Also, the sampling of the landscape matters. You say 200km on a side, but what''s the detail? 1m^2 samples? Or 100m^2? These things matter, also.

Josh

Share this post


Link to post
Share on other sites
what about dev time? you should look into that too.

Having an OK implementation in 1 month of free time, or having a KICK ASS implementation in 8 months time?

Is that a factor?? I mean, you could learn so many other things in the 7 other months.

Share this post


Link to post
Share on other sites
About implementation time... i don''t care about it, i want a cool and fast algorithm. it is for personal pleasure.

Share this post


Link to post
Share on other sites
You should look into geometry clipmaps (http://research.microsoft.com/~hoppe/)
It''s very new, and the video is by far the most impressive terrain rendering I''ve ever seen in terms of sheer quantity.


"Math is hard" -Barbie

Share this post


Link to post
Share on other sites
For the sampling... I would like it to be 1 or 2 meters sampling.

As for Geomipmapping or Chunked LOD, which one would you consider the fastest between both?

I know geomipmapping but I didn''t read chunked lod into detail.

Joaquin

Share this post


Link to post
Share on other sites
Personally, I believe Chunked LOD is better for large scale landscapes. With geomipmapping, since each patch only covers a fixed area of terrain, as the view distance increases, due to the perspective projection the size of the patches approaches zero. This means the number of distant patches in the view goes up dramatically, typically with only a couple of faces in them. It kills batching efficiency. Chunked LOD does not suffer from this problem.

Share this post


Link to post
Share on other sites
Don''t know of any implementations. You could always e-mail and ask, but I don''t know how that would go over. He works for microsoft, so there''s a chance it will show up in d3d some time in the future (as some of his past work has).

"Math is hard" -Barbie

Share this post


Link to post
Share on other sites
well, its ment to be appearing at ACM SIGGRAPH 04, so maybe one will appear shortly after or at that.
I quickly skimmed the paper earlier, there seems to be enuff infomation that you could go out and make your own i guess

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!