CLOD is great if you don't mind wasting tons of CPU and memory for the sake of saving a few polygons.
A better solution is to just pre-compute an optimized mesh for your terrain instead of trying to do it every frame. This gives you the best of both worlds. First you don't waste memory or CPU on computing the LOD every frame, and second, you render a greatly reduced mesh that frees up your bus and saves tons of memory because you only need to keep the verts you render! I have seen this ton in many games and have tried it my self. It yields awsome results and you will never have to VTune your CLOD terrain again!
What is the latest favored technique for terrain rendering?
Brute force could be enough for medium sized terrains since the GPUs in fact do some 'CLOD' for you now (with mip-mapping and displacement maps for instance). But it's very limitated.
Else the best is to understand every 'public' technique in depth more than in (implementation) details or even better sometimes, reinvent the wheel that is anticipate the papers. This way you totally handle the underlying concepts and not just the strict boundaries of the "universitary" reference algos. I would even say that most papers on the web lack of "hacking" spirit, most made by scholars. Most of the lower algorithmic details denote a lack of concern on implementation efficiency.
There is no absolute exclusivity between ROAM, GMM, Chunked LOD, fractals, nurbs, etc... In fact you can take some bits of each, rearrange the whole and have the best of each technique in a new hybrid form. This helps seeing the various issues in a more abstract and generic way.
For instance any variation around GeoMipMapping seems the obligatary response to pop-up artefacts whenever you have CLOD. I used it well before I found the papers on the www, because that's the logical way to go (not because I am any genious). I was just happy to take the terminology, expressive semantics. You can't reduce such a concept to the way it's described in a reference implementation.
What OrangyTang concludes is relative to his experience. But for instance in my case, I use on the fly generation of infinite fractal details for infinite terrains and huge fields of view (60 km). It does not require memory (the low constant pixel/texel/triangle ratio Carmack discussed once), 2Megas of video mem for me. Geomipmapping is quasi free. Anyway I prefer the term trilinear filtering in my case, more general. This helps thinking in terms of signal processing octaves, etc ...
I also used ROAM in a very special way. I found something similar on the web well after I had coded it, once again. This just means it was a good idea. It's specializing ROAM inside patches with some luts and code tricks. Infinitely faster than the original algo. ROAM is the only terrain algo I found on a www paper. But I changed the implementation totally. Only the characteristics of the output, that is the final tesselation was kept, nothing from the original algo.
I also use specialized algos for nearly free static or dynamic self-shadow casting. No need for more than a TNT or GeForce2 for it. You can also find some tips on the web.
The general algo is very similar (a variation mostly) to chunked LODs.
I don't intend to be pontifying or pretentious. My message is just to tell, if you want to learn something really worth, be as open minded and explorative as you can. Try some unit tests of your ideas. Don't just take papers or sample codes to transform em. Try your way, find and test ideas on paper before coding. Else just find and try to link pre-made and already tested libs.
It's better to 'reinvent the wheel' in the field of the ideas, because it's never exactly the same wheel. Rewriting something that already exists, is far less constructive to me, because it only produces at most the same (or slightly better) output in the end ... if you are a good coder.
Also there should never be a definitive conclusion on a preexisting algo. There are very often elements of a 'deprecated' algo that can be reutilized in a different context or under a different form.
So that's my general conclusion to your question. There is no bad terrain algo per se, since even brute force is now more and more advised ! ROFL. As if what was feasible on 200MHz CPUs was too expensive for the 4GHz CPUs of today, not mentionning shaders.
Else the best is to understand every 'public' technique in depth more than in (implementation) details or even better sometimes, reinvent the wheel that is anticipate the papers. This way you totally handle the underlying concepts and not just the strict boundaries of the "universitary" reference algos. I would even say that most papers on the web lack of "hacking" spirit, most made by scholars. Most of the lower algorithmic details denote a lack of concern on implementation efficiency.
There is no absolute exclusivity between ROAM, GMM, Chunked LOD, fractals, nurbs, etc... In fact you can take some bits of each, rearrange the whole and have the best of each technique in a new hybrid form. This helps seeing the various issues in a more abstract and generic way.
For instance any variation around GeoMipMapping seems the obligatary response to pop-up artefacts whenever you have CLOD. I used it well before I found the papers on the www, because that's the logical way to go (not because I am any genious). I was just happy to take the terminology, expressive semantics. You can't reduce such a concept to the way it's described in a reference implementation.
What OrangyTang concludes is relative to his experience. But for instance in my case, I use on the fly generation of infinite fractal details for infinite terrains and huge fields of view (60 km). It does not require memory (the low constant pixel/texel/triangle ratio Carmack discussed once), 2Megas of video mem for me. Geomipmapping is quasi free. Anyway I prefer the term trilinear filtering in my case, more general. This helps thinking in terms of signal processing octaves, etc ...
I also used ROAM in a very special way. I found something similar on the web well after I had coded it, once again. This just means it was a good idea. It's specializing ROAM inside patches with some luts and code tricks. Infinitely faster than the original algo. ROAM is the only terrain algo I found on a www paper. But I changed the implementation totally. Only the characteristics of the output, that is the final tesselation was kept, nothing from the original algo.
I also use specialized algos for nearly free static or dynamic self-shadow casting. No need for more than a TNT or GeForce2 for it. You can also find some tips on the web.
The general algo is very similar (a variation mostly) to chunked LODs.
I don't intend to be pontifying or pretentious. My message is just to tell, if you want to learn something really worth, be as open minded and explorative as you can. Try some unit tests of your ideas. Don't just take papers or sample codes to transform em. Try your way, find and test ideas on paper before coding. Else just find and try to link pre-made and already tested libs.
It's better to 'reinvent the wheel' in the field of the ideas, because it's never exactly the same wheel. Rewriting something that already exists, is far less constructive to me, because it only produces at most the same (or slightly better) output in the end ... if you are a good coder.
Also there should never be a definitive conclusion on a preexisting algo. There are very often elements of a 'deprecated' algo that can be reutilized in a different context or under a different form.
So that's my general conclusion to your question. There is no bad terrain algo per se, since even brute force is now more and more advised ! ROFL. As if what was feasible on 200MHz CPUs was too expensive for the 4GHz CPUs of today, not mentionning shaders.
Quote:Original post by Metron
Personally I tested it out with a 120k triangles terrain (untextured) which rendered at an impressive 560 FPS on my Ati 9800 pro. That's ~67 million triangles. Adding texture would bring that down but the raw power is there (on modern cards).
but that still pretty much depends on the size of the terrain and most of all your fov and view distance. for a really good (read: absurdly high) view distance there is no way to get around lod. ok, i can look from side of a 1kx1k terrain to the other side with 1.2mill triangles visible and get my 50mill/s (ie, about 40fps), but the 350fps i get with lod (for the price of minimal overhead and slight popping here and there) probably means i will get to render other stuff as well ,-)
(talking about textured with simple vertex/fragment shader to combine offsets, general x,z coords and heights, generate tex coords and apply a bunch of greyscale detail textures).
but yes, for a more or less smallish frustum size it seems that any lod scheme is just wasted effort today.
so ask yourself what you need it for. for levels in a typical shooter where you get away with a 512 or even 256 heightmap and relatively low viewdistance? or a big rpg world with huge view distance? (for the latter i wouldnt use gmm, but maybe look at geoclipmapping.. i like the idea behind it, maybe because i had the same while the paper was still being written and hate myself for not pulling through with it and being first *lol*).
arg.. ok.. thats it.. where is that darn automatic login checkbox i ALWAYS forget to check..
If you have an academic or hobby interest in terrain rendering, by all means read all about ROAM2, the latest in CLODs, maybe VIPMs and clipmaps.
If, however, you want to make a game, or just a demo, which needs to have a terrain, use brute force. Cut the terrain in some sensible size square chunks (depending on the game), cull them against the view frustum and render them with a single draw call each. You want to draw on the order of 100-300 such chunks per frame - more than that, you're taxing the CPU too much with draw calls, less than that, you're probably losing too much by not culling.
Texture them with a single huge texture, drawn by hand by an artist in Photoshop, cut in 2048x2048 pieces, mipmapped and compressed. Overlay a detail texture on the nearest chunks.
Then forget about terrain and move on to other things - you can always come back and optimize (e.g. geomipmap the distant chunks, or build the texture by splatting, or even splat at runtime).
If, however, you want to make a game, or just a demo, which needs to have a terrain, use brute force. Cut the terrain in some sensible size square chunks (depending on the game), cull them against the view frustum and render them with a single draw call each. You want to draw on the order of 100-300 such chunks per frame - more than that, you're taxing the CPU too much with draw calls, less than that, you're probably losing too much by not culling.
Texture them with a single huge texture, drawn by hand by an artist in Photoshop, cut in 2048x2048 pieces, mipmapped and compressed. Overlay a detail texture on the nearest chunks.
Then forget about terrain and move on to other things - you can always come back and optimize (e.g. geomipmap the distant chunks, or build the texture by splatting, or even splat at runtime).
Quote:Original post by Lutz
Also, clipmaps are very hardware friendly, see Hoppe's homepage.
That's very nice indeed. How does that method deal with important details a long way away? For example, Olympus Mons on Mars is visible even when it's over the horizon because it's so tall.
[Edited by - teamonkey on October 3, 2004 1:49:55 PM]
Quote:Original post by teamonkey
For example, Olympus Mons on Mars is visible even when it's over the horizon because it's so tall.
there can be only one answer to this mystery: CHEATER *lol*
yet, im curious about that, too ,-)
Quote:Original post by teamonkey
That's very nice indeed. How does that method deal with important details a long way away? For example, Olympus Mons on Mars is visible even when it's over the horizon because it's so tall.
That's no problem since my clipmaps are not flat as in the original paper. They are indeed a more or less rectangular part of a sphere. So even if Olympus Mons is behind the horizon, it's still visible. It's polycount depends on the actual size on the screen. That's a nice feature of clipmaps (and indeed of all LOD algos ;-) ) that large things in the distance get the same polycount as small things nearby.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
