Terrain Rendering (LOD + Texturing)

Jim Drygiannakis · 2004-05-12T03:26:03

Hello... I''ve been working on terrain rendering (LOD + texturing) the past few weeks (maybe months) and after trying some different "paths", it''s time to decide which one to choose. That''s why i want your opinion and your experience on that. I think most of the issues i''ll address here have been discussed previously, but i''m hoping on a clearer discussion/explanation. My first attempt was on texturing, and i tried to implement the algorithm described by Yann in "Creating detailed terrain under severe limitations..." thread. I don''t have the url right now (i''m writing this off-line), but you can find it by searching the forums. For those who haven''t read it, it''s a multi-layer algorithm where all layers are blended together using precomputed weights for each one (based on topographic properties or hand-made typemaps). I used up to 4 textures per face, for making it faster (no multipass on a 4-texture-units GPU). It''s an excelent algorithm, and it gives very good texturing resolution at any distance (from 1m to 1km). But, it has its problems too! The biggest one is this. Despite the fact that you can limit the number of textures applied on a face, the algorithm is by nature multipass. What i mean? For every detail layer (see Yann''s explanation), you must do an extra pass. So minimum is 1 base layer, plus 1 detail layer (you can''t get away with only the base or detail layer because then everything seems strange). And you can''t stop here, because there are some faces with 4 textures on them, so you don''t have room for lighting/shading! So you must do an extra pass for shadowmap/lightmap. You can also add bump mapping on it in this pass. And what if you want your terrain to be a little dynamic. Imagine a granade exploding, and leaving a decal on the ground. You must do an extra pass for all the decaled faces. You will say, that all these extra passes can be limited to a small amount of faces near the camera, but... the overhead will be still visible. Another problem is that (at least in my implementation), after the preprocess step (weight calculations, face grouping based on # textures (layers) and texture IDs (batches), etc.) the terrain is no longer a simple heightfield, where you can do LOD on it using common ways (geomipmaps, CLOD, etc.). It''s a mesh. So if you want to do any kind of lod on it, you must do it when the heightfield is still lod-friendly or try an other (more generic) LOD scheme. Don''t mentioning that you must perform all weight calculations for all the lod levels (e.g. geomipmaps). And this brings a memory/storage problem! And things like terrain deformation is very difficult because of that (imagine the above granade making a hole on the ground!). Also geomorphing is difficult/slow to be performed. The second implementation, was based on a single texture stretched on the whole terrain. This way texturing sucks!!! Even with a huge 4096x4096 RGB uncompressed texture (!!!), resolution is really bad. To make it better, i generated 1024x1024 textures for parts of the terrain, in order to achieve higher resolution (storage/load-time problem). This way, you have 3 free texture units to apply shadowmaps/lightmaps, bumpmapping, and decals (decals can be burned on the diffuse texture, so you can apply a detail texture as the 4th texture!). Geomipmapping is easier, and faster because you can have a few index buffers (one for every mipmap level, and some special buffers for connecting patches together). Geomorphing is easier too (one geomorph parameter for the entire patch, and an extra float (final height) for every vertex). Deformation is much more straight forward, and finally state changes and texture binds are minimal. But, as mentioned earlier, texturing resolution isn''t good enough. Finally, i tried to combine the above two approaches, but the results are still dissappointing. I used the single texture for the base layer and the multi-layer approach for mipmap levels equal to 0 (near the camera). This way, performance was better, but the problems of the multi-layer algorithm are still here!!! What''s your opinion? Would you sacrifice detail for performance? Have somebody else implemented Yann''s algorithm? What''s your experience from that? If you are currently using one texture for the whole terrain, what are you doing to increase detail? Thanks for reading it, and i hope on comments. HellRaiZer. PS. Here are two shots from the first algorithm. ScreenShot 1 (62 kb) (Only the detail layer is rendered, with N.L shading) ScreenShot 2 (443 kb) (Base + Detail layer, no shading (impossible without pixel shaders)

Graphics and GPU Programming Programming

Started by HellRaiZer May 07, 2004 09:10 AM

15 comments, last by HellRaiZer 19 years, 11 months ago

HellRaiZer

1,001

Author

May 08, 2004 02:56 PM

Jason Z:

quote:
So you are using geomipmapping? Have you added geomorphing or no? And do you use skirts around the patches or do you deform the polys around the edges to match neighboring patches? I have been trying to decide on which algorith to use, and I think I am going to go with parametric surfaces with geomorphed LOD changes. Do you have any suggestions or experience with this type of terrain? What made you choose geomipmapping?

For now, i''m trying to fully implement geomipmaps. I haven''t finished all the details because i had my mind on texturing, but yes the direction i''m following is to geomipmaps. About filling cracks, i think that both ways are possible (skirts and "special" triangles), and i''ll decide when i implement them both. Also i haven''t fixed popping yet, but i think that it can''t be hard to implement as described in the CLOD paper (one geomorph parameter for every leaf, and an extra float for the final height). The only problem is that (as i said before) the rendered terrain is no longer in its initial form. I mean i can''t render one quad-tree leaf with one call, as i could if i had only one texture on it. I must render it in batches based on # of textures per batch and based on the actual textures IDs. More like how you would render an arbitary mesh. That''s why i said that both crack-filling techniques are possible. Because you must handle them in the preprocess step ("terrain compiling"), it''s no problem to add skirts or extra triangles.

About parametric surfaces, i can''t say anything. I haven''t used them, and the main reason for that is that to make something with parametric surfaces look good (e.g. look like terrain!) you need someone with skills, that i don''t have. I''m not an artist, and i don''t have anyone to make them for me

Heightmaps are more programmer-friendly. But i think that the result will be better than heightmaps, if you use them right. And probably faster. But as Yann said, this texturing algo suits to every terrain represantation.

quote:
Sorry for all the questions, I am just getting into the higher level algorithms and am trying to understand better.

Why are you sorry

I would be pleased to help,... if i could!

Trienco:

quote:
*cough* 7 detail textures + bump map? hmm.. maybe by using a heightfield in the alpha channel instead of a normal map. else id really love to see how the hell they managed to make that work with decent speeds.

I don''t know how they handle it, but from what i read in the manual and what i saw in the editor this situation is possible to happen if you don''t be carefull when designing a level.

I tried the multiple-detail textures this afternoon, and i can''t make it look good. I think i''m going to dump the idea, and stick with the multi-layer approach. I''ll try to make it as good looking as possible, with bump mapping and shading, even with 4 passes (or 8 texture "image" units and pixel shaders!!!). Then i''ll try to find ways to optimize it. And if i don''t find any, then i''ll just increase "lowest requirements"!!!! GeForce FX support 16 textures!!! Why don''t use them all?

HellRaiZer

HellRaiZer

Fingers_

410

May 10, 2004 01:07 AM

The method I use for filling the cracks in geomipmap patches:

Use indexed vertices. Generate a new index buffer for each patch when its (or one of its neighbors'') LOD changes.

When generating an index buffer for the patch, start exactly as you would if you weren''t bothering to fix the cracks. But, if an index is to an edge vertex and the neighboring patch in that direction has a lower LOD than the current patch, change that index to the closest vertex that matches the neighbor''s LOD (e.g. If the neighboring LOD is one step lower, every other vertex of this edge will match one in the neighboring patch).

This keeps the index buffer generation a clean linear process and the topology of the patch is always the same at the same LOD; some of the triangles just collapse to degenerates. It''s much less code and easier to understand than (e.g.) filling in the middle of the patch with border polys removed and then adding special strips for the borders. It also allows arbitrarily large jumps between neighboring LODs.

Trienco

2,555

May 10, 2004 02:50 AM

quote:Original post by Fingers_
Use indexed vertices. Generate a new index buffer for each patch when its (or one of its neighbors'') LOD changes.

wait. are you saying each and every patch in your terrain has its own index buffer and you keep regenerating them all the time something changes?

and i was worried about my line-rasterization occlusion-rectangle culling taking too much time.

f@dzhttp://festini.device-zero.de

Fingers_

410

May 10, 2004 02:35 PM

Basically, yes. At normal movement speeds, this happens a couple of times a second on average and takes a negligible amount of time (as in <0.1ms). After all, generating the index buffer is just a simple for-loop. It''s obviously faster than methods that require generating and uploading an index buffer every frame (or using one that''s in RAM).

This also saves VRAM compared to pre-built index buffers for every possible LOD combination (since I always have fewer patches visible than there are possible combinations)... YMMV of course.

Trienco

2,555

May 11, 2004 01:28 AM

quote:Original post by Fingers_
Basically, yes. At normal movement speeds, this happens a couple of times a second on average and takes a negligible amount of time (as in <0.1ms).

i have to move slower. i often forget that the speed during working on it is much higher than it will be when its done.

quote:This also saves VRAM compared to pre-built index buffers for every possible LOD combination (since I always have fewer patches visible than there are possible combinations)... YMMV of course.

*thinking* 16 combinations per level, 6 levels for a 32x32 patch, 96 body parts and a whole lot of link pieces.
2048 terrain, 4096 patches. about 8.5mb for index buffers if i didnt make a mistake. so i guess we have different methods for different goals ,-)

f@dzhttp://festini.device-zero.de

Fingers_

410

May 11, 2004 02:01 PM

Ah yes, it''s basically a tradeoff between lots of small patches and fewer, larger ones. Mine go up to 64k polys (a triangular 256x256) so there are more levels and it''s more likely to have neighbors more than one LOD lower, which increases the number of combinations. The idea behind huge patches is that then the average (LOD-reduced) number of triangles is near the optimal batch size (around 4k-16k) and they never reduce to just a handful of polys.

Of course, as soon as I have time to work on this "engine" again and implement proper lighting and better texturing, I''ll be limited by fillrate rather than geometry.

Trienco

2,555

May 12, 2004 12:19 AM

i hate that trade off. larger patches means less drawing calls with a ridiculously slow number of triangles, while smaller ones allow for better culling and saving memory. but if your patches are that big i guess youre working on terrain for worlds rather than levels?

edit: let me rephrase that. i hate all those trade offs ,-) just causing head ache and cost a lot of time figuring out which one is more acceptable for your situation.

[edited by - Trienco on May 12, 2004 4:26:03 AM]

f@dzhttp://festini.device-zero.de

Terrain Rendering (LOD + Texturing)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Terrain Rendering (LOD + Texturing)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines