• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Twyzz

LOD terrain with minimal memory usage

1 post in this topic

Hey, I've recently moved on from my typical 2D / 3D closed environment games to a more open environment 3D game but as everyone else I'm stuck on terrain rendering. I've read a lot of papers on the subject and most people seems to agree that the best way to go is with a streaming LOD/geoclip mapping type of system to minimize the amount of memory needed etc but then I also seen alot of threads about world of warcraft and how they're doing their terrain rendering and I checked it out myself with a trial account.

 
I took some screenshots on the terrain and what I've heard they're using some type of lod streaming system but how can they know that it's a mountain far far away without saving the entire heightmap in memory :/ and how can they do it so smooth? Is it because XNA is slower than directx ? 
 
Because when I checked this one out http://msmvps.com/blogs/valentin/archive/2008/09/30/smart-terrain-rendering-with-xna.aspx and tried to run in on my computer you see how the terrain changes when you walk around its ugly as fk, maybe because XNA is too slow to keep up?.
 
 
Just by looking at the two screenshots it seem they're using something close to the billod system but with a much longer LOD range (forgot the name but I ment the range between the LOD levels) because the graphics seems to work the same way except it's much smoother in wow but I don't understand how they can have this information in memory :/
 
Maybe someone who knows more then me can show me the directions and maybe answer the question about how you can manage memory with big height maps?
 
My own thoughts is to use a tiled lod system where you've nine heightmaps like this(1,5 and 9 is not loaded yet.)
 
1 |  2   3   4
5 |  6   7   8
9 | 10 11 12
 
and when you move from square 7 to 6 square 4,8 and 12 will be unloaded/switched for squares 1,5,9 but I guess this will take up too much memory since you've to store nine height maps in memory? This would aslo make it much easier to create rectangular maps, since you're not restricted to one quadtree etc and I already got a nice idea how to make an editor for it. Any thoughts about this? or should I just forget it and find another way?
 
Maybe it's time to move from XNA C# to C++ directx, always wanted to learn c++ but I never took any time to do it :/ and since I'm only developing for windows anyway.
 
Wow only used around 930mb of memory when I took these screenshots.
 
Mvh Tobias, sorry for wall of text and my poor english sad.png
Edited by Twyzz
0

Share this post


Link to post
Share on other sites

First of all. Profile to see what's your problem.

Without hard data, what I have written below is pure speculation.

 

Is it because XNA is slower than directx ?

This question makes no sense. DirectX is the API below XNA.

 

Anyway, there are several problems when streaming stuff. Granularity, latency and pressure.

  • Granularity is basically as follows. You know you can spend X ms in computing a tile. By testing we figure out that our "terrain tile" might be... say 200x200 heightmap pixels / model vertices. This of course is a function of the algorithm used.
  • Latency management involves pulling stuff from mass storage. Even with a SSD, it will still be massively slow compared to RAM, let alone VRAM. In general, we will need deferred texel loading. Waiting for the disk to seek is rarely acceptable. If loading is assumed syncronous, it will erode processing time from the LODding algo.
  • Pressure. How much of the above you'll need to do per-frame and per-second.

In my experience the only way to deal with pressure on low-end hardware is to have precomputed LOD representations. Let me elaborate.

 

 

Maybe someone who knows more then me can show me the directions and maybe answer the question about how you can manage memory with big height maps?

Your example lacks a key feature. The tiles are not homogeneous because of construction.

 

That is, let's assume 4,8,12 require LOD 0. Let's say even 3,7,11 ended up in LOD 0.
By constrast, 2,6,10 are at the edge of the viewport. They cannot be at LOD 0, because this would imply you're bruteforcing everything. Now, there are various cases to manage this which depend on the algorithm we use.
In the case of octree-simplified terrains, the cell size would stay constant and reduce the polygon count (a thing I actually don't like at all for modern HW but let's carry on).

Many people just load LOD 0 anyway for 2,6,10 and then decimate polygons. This is not going to work as the work involved in generating a LOD n (n>0) is superior to generating a LOD 0 tile and it gets worse with a growing n. I guess that's what you're doing?

 

It's worth noticing the article you're referring to is concerned to optimizing the representation (visualization) of a terrain node. Loading LOD 0 each time to run decimation is unacceptable. There must be a way (before the visualization algorithm runs) that figures out what to work on.

 

So what do we do?

Personally I'd suggest to pre-compute everything (oops, that's impossible for a viewpoint-dependent method) or switch to a regular grid method which allows easier decimation (less compute for same granularity).

Alternatively: use smaller tiles (less computation, but more pressure).

Anything requiring non-trivial per-vertex work will have issues sooner or later, that's it. I'm very surprised the algorithm you refer to speaks about a per-vertex visibility test.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0