Jump to content
  • Advertisement

Archived

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

HellRaiZer

Terrain Rendering (LOD + Texturing)

This topic is 5274 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

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)

Share this post


Link to post
Share on other sites
Advertisement
HellRaiZer,

I think Yann''s suggestion was to set up the tiling for mid to long range on the base map (which uses your first method) and then on the closest terrain patch shift to a higher tiling with the same texture blend stages and alpha blend the higher octave patch on top of the base map.

This will give you the detail that you want without spending too much of your poly budget. You do have to do the second pass, but it is a relatively small amount of poly''s.

As to the lighting and decals, you could limit the number of textures to 3 and add the lightmap as the 4th texture. The decals are usually rendered on a second (or third in this case) pass anyways, aren''t they? Also, deforming the height field (vertex positions) should not affect the texture coords should it? I am no expert, but I have been trying to implement this same algorithm and it seems to be working ok. Let me know what you think.

Jason Z

Share this post


Link to post
Share on other sites
hehe.. so youre having those "how to get more than 2-3 detail textures and decent texturing going in one pass and with 4 units" problems.

for two its easy:
a base texture with weights in alpha channel
a normal map with light/shadow in alpha channel
2 detail textures

for more a compromise is 4 greyscale detail textures in one rgba texture, but its looking kind of boring (yet lots better than just a base texture)

but after seeing far cry i wouldnt spend too much time on fancy "a dozen detail textures per triangle"-texturing. the vegetation is distracting from it quite nicely and in my eyes adding a lot more to the terrain than textures.

Share this post


Link to post
Share on other sites
Jason Z:
quote:

I think Yann's suggestion was to set up the tiling for mid to long range on the base map (which uses your first method) and then on the closest terrain patch shift to a higher tiling with the same texture blend stages and alpha blend the higher octave patch on top of the base map.



This is exactly what i'm doing. As you can see in the second image the rocky surface near the camera has higher tiling, and the detail is really good. Also you can clearly see a non-repeative crack clear pattern away from the camera. The repeative pattern is clear on the first image. I know i'm not a good "photographer" but i think what i say is clear in the shots.

quote:

This will give you the detail that you want without spending too much of your poly budget. You do have to do the second pass, but it is a relatively small amount of poly's.


Relative can be from too small to too big!!! I mean, where i apply the base layer (for now at least) is on every geomipmap that had been rendered on level 0. This can be high enough to care when you have (e.g.) 4 of these patches, 32x32x2 triangles each. It's not the amount of triangles, but the amount of state changes. E.g. you can have all these triangles rendered only with one texture each (only a few texture binds), or you can have them been rendered with different amount of triangles (lets say, some of them with 4 textures, other with 2 etc.). Finding exactly which triangles must be rendered is a little tricky i think, because i have to re-generate vertex and index buffers every frame or so!

quote:

As to the lighting and decals, you could limit the number of textures to 3 and add the lightmap as the 4th texture. The decals are usually rendered on a second (or third in this case) pass anyways, aren't they? Also, deforming the height field (vertex positions) should not affect the texture coords should it?


I tried it, but the richness 4 textures gives you can't be replaced To say the truth when i set up the compiler to output max 3 textures per face, i forgot to change something relevant to how weights are computed, and everything messed up. So i revert it to 4 textures again! And even if i do that 3 passes instead of 4 isn't much of a performance gain. I think so at least!!! About deformation, i didn't say it's impossible, i said it can be difficult and maybe slow. Because as i said terrain structure is like a mesh, finding which faces and vertices are affected by a certain action can be a little tricky! About decals, the problem is that you must have a dynamic vertex buffer and one index buffer for generating vertices and indices on the fly for them, becuase you can't use texCoord0 for them (texCoord0 is for diffuse textures). And you must apply lod to them, because you don't want them to fly around Or make cracks and z-fight (i'm talking for larget distances, where a certain decal must be visible)

quote:

I am no expert, but I have been trying to implement this same algorithm and it seems to be working ok. Let me know what you think.


I'm no expert too I'm doing my best. When you are saying it works ok, you mean it works fast enough not to care about? It looks good? Have you added any of the "features" i mentioned (lighting/shading, bump mapping, decals, deformation)? Does it work as well with these? I'm very interested on others implementation. What did you do to make it as fast as possible? Have you tried to minimize state changes (texture stages setup/Register combiners), Vertex/fragment program binds, texture binds?

Trienco:
quote:

but after seeing far cry i wouldnt spend too much time on fancy "a dozen detail textures per triangle"-texturing. the vegetation is distracting from it quite nicely and in my eyes adding a lot more to the terrain than textures.


You said the magic word. Far Cry!!! I've been working on this some time before seeing this excellent game in action (and playing with its incredible editor!!!). The reason i post this in first place was Far Cry. I think you are right. Much texture detail isn't required when you have that rich enviroment. But can you imagine Far Cry with better terrain texturing (and without bugs of course ).

Do you have any idea what exactly they do for texturing? I mean are they using only one texture for the whole terrain, and have multiple detail textures depending on the underlying texture type? Are they using more that one texture to acheive better detail? I tried to find out my self and after some time playing with the editor, i couldn't tell! (I couldn't make the f***ing detail texture to disappear!!!)

HellRaiZer



[edited by - hellraizer on May 7, 2004 3:04:46 PM]

Share this post


Link to post
Share on other sites
Here is a shot of my terrain engine in development. Single texture for the whole map, no detail mapping at all. Using a homebrew ROAM style LOD. I think it will look quite nice after adding some distracting greenery and creating some better textures.

I am also curious what method Farcry uses for rendering and LOD, I expect something similiar to what I am aiming for. There is massive popping in that game - use a weapon with zoom and zoom in on a mountain in the distance, I estimate 25-100 pixel size pops.

Share this post


Link to post
Share on other sites
quote:
Original post by HellRaiZer
But can you imagine Far Cry with better terrain texturing (and without bugs of course ).


oh, the textures werent that bad. in the first demo i think i saw at least 6 different detail textures. so i searched the place for transitions and found up to 3 of them touching. so every polygon needs at least 3 detail textures at once (and remembering their ressource file they were colored i think).
so, they did have an awful lot of popping and maybe in that case they could even store the weights for detail textures in the vertex colors (i never ever will do that again, looks horrible with lod). that would mean 1 base + 3 detail. or more than one pass. with two passes you should be able to do quite a lot.

details

the best i could to with either 7 units or not so perfect tiling and 4 units (normal, base, weight and 4 detailmaps in one big). you can see violett parts where the base+detail textures result in weird colors (i move the base map to the range -1,1 and then add it.. allows to either just slightly influence the detail maps result or "paint over it" in case of snow or painted roads...
cave
the cave above is painted like that)

quote:
Do you have any idea what exactly they do for texturing? I mean are they using only one texture for the whole terrain, and have multiple detail textures depending on the underlying texture type?


well, in their files i find one big texture and all the detail textures. they might be using the big texture in general and blended detail textures up close, but i saw their editor coloring the terrain (blueish parts at the beaches), so i guess they are combining base and detail (at least close to the viewer, which would make multiple passes more affordable).

but the bright side: in both demos i only saw 1024x1024 heightmaps. quite a relief to abort a fancy scheme for 4096x4096 maps (that i guess would have ended up being something like chunked lod.. its hard to come up with something new these days). before i had 9x512 but lower view distance (endless terrain, view distance had to be 512 to hide reloading). dropping the endless terrain 2048x2048 arent a problem, on nvidia it even works ok with 4096x4096 (ati has such "flexible" vbos that its not possible in the same way and va is too slow for the huge geometry.. i dont want _that_ obvious and distracting popping).

im more worried about all the fillrate that will be burned by the vegetation ,-(

[edited by - Trienco on May 8, 2004 1:42:45 AM]

Share this post


Link to post
Share on other sites
quote:

I am also curious what method Farcry uses for rendering and LOD, I expect something similiar to what I am aiming for. There is massive popping in that game...



From what i can tell after spending some time with their editor, they must be using geomipmaps or Chunked LOD. It doesn''t look like ROAM, but i''m not very sure about that because i haven''t implemented any ROAM algo. Only what i have seen from demos. Is it geomipmaps or CLOD? I can''t tell for sure, unless i see how they are traversing the quad-tree. I''m saying that, because nothing from the things presented by Thatcher Ulrich in "Rendering Massive Terrains using Chunked LOD Detail Control" is visible. I mean, they are not using skirts for connecting patches, they aren''t "compress" the terrain and obviously they aren''t avoid poping with the way presented in the paper. Other than that, i can''t remember any difference between the two papers (goemipmapping and the above), besides tree traversing. Their LOD isn''t something fancy at all. Thinking of it again, i think it is geomipmapping (with no geomorhing ) If you examine how nodes are being discarded by occlusion culling you''ll see what i''m mean.

quote:

oh, the textures werent that bad. in the first demo i think i saw at least 6 different detail textures. so i searched the place for transitions and found up to 3 of them touching. so every polygon needs at least 3 detail textures at once (and remembering their ressource file they were colored i think).
so, they did have an awful lot of popping and maybe in that case they could even store the weights for detail textures in the vertex colors (i never ever will do that again, looks horrible with lod). that would mean 1 base + 3 detail. or more than one pass. with two passes you should be able to do quite a lot.



In the manual they say that you can use up to 7 "Surface Types". Every surface type has a detail texture, a bump map, and some material related stuff (sounds etc.). So you are able to have up to 7 detail textures. Definetely multipass is required for all of them on the same face, and i think that PrimaryColor.rgba + SecondaryColor.rgb would be perfect for this job!!! But they are using only the secondary color, and in fact they are using all of its 4 channels! If you take a look at their shaders, you will see that they have shaders for up to 4 texture layers (1 base + 3 detail). They also have shaders for only 4 detail textures. I can''t say exactly how they do it because it''s a little messed up (using the same weight for two different detail textures???) but the idea is the common way of blending detail textures with the base map. Detail textures are colored.

This brings something else up. 7 bump maps on one face?!?!? To say the truth, i haven''t seen any of them in the game, but i think this has to do with the non-moving light (sun). I haven''t reached a dark outdoor level yet to see how it looks with the flashlight.

About storing weights in vertex colors, i agree it looks terrible with lod. At least with Yann''s multi-layer algorithm, it doesn''t look good. As for detail textures, i don''t think it can be so terrible if you keep you lod level to higher values for some distance. I couldn''t check if they are applying detail texture at lower LODs because i haven''t found an option to freeze the view at a specific position in the editor, so i can only see how thinks look like from one point of view at a time!

quote:

...allows to either just slightly influence the detail maps result or "paint over it" in case of snow or painted roads...



Why don''t you "bake" snow and roads on the base texture?
Answer : For more detail, maybe?

quote:

but the bright side: in both demos i only saw 1024x1024 heightmaps. quite a relief to abort a fancy scheme for 4096x4096 maps (that i guess would have ended up being something like chunked lod.. its hard to come up with something new these days).



Everything is relevant. You can have a huge, very detail heightfield (e.g. 4096x4096) with extreme detailed texturing, and if you put one huge tree on it, everything start to look too small!!! Except the detail you can achieve with more polygons, you can''t make it look big, unless everything else make look big (or if you are making "Ants : The Game"). In a game like Far Cry, you don''t need that huge maps. If you are surrounded by the ocean, where do you want to go? Not far enough because the enemy has helicopters that will bring you down

Speaking of games, does anybody know how IGI 2 render the terrain. I don''t have the editor, so i can''t investigate it myself. Their terrain is excellent too. And i meant this terrain, when i said "Far Cry with better texturing". It seems so detailed (and endless), with no poping, and artifacts in general. The only artifact i can see is that you can recognise texture tiling. Any ideas about that?

Thanks for repling and sorry for the long replies!

I''ll try the multiple-detail-textures with a good looking base texture and i''ll be back with comments.

HellRaiZer

Share this post


Link to post
Share on other sites
quote:
Original post by HellRaiZer
In the manual they say that you can use up to 7 "Surface Types". Every surface type has a detail texture, a bump map,


*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.

quote:

Why don''t you "bake" snow and roads on the base texture?



thats what i do. the only thing special is that i cant just add or multiply the base map to the rest so im making sure colors range from -1 to 1 before adding them.

Share this post


Link to post
Share on other sites
HellRaiZer:

quote:

I''m no expert too I''m doing my best. When you are saying it works ok, you mean it works fast enough not to care about? It looks good? Have you added any of the "features" i mentioned (lighting/shading, bump mapping, decals, deformation)? Does it work as well with these? I''m very interested on others implementation. What did you do to make it as fast as possible? Have you tried to minimize state changes (texture stages setup/Register combiners), Vertex/fragment program binds, texture binds?



Unfortunately, I think your implementation is more advanced than mine is. I just started learning about terrain rendering algorithms about two weeks ago and I am still reading through some of the papers. By "ok" I meant that it _worked_ in my test application. However, I am only using a max of two textures in the base map and then a detail map (tiled like Yann''s suggestion). I have yet to implement the extras that you mentioned.

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?

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

Trienco, what methods are you using? Both of your terrain looks pretty good. Hopefully I will get mine up and running at the same level soon...

Jason Z

Share this post


Link to post
Share on other sites
quote:
Original post by Jason Z
Trienco, what methods are you using? Both of your terrain looks pretty good. Hopefully I will get mine up and running at the same level soon...


pretty primitive ones. plain old geomipmaps without any morphing. one big vertexbuffer per 512x512 heightmap and a bunch of index buffers for different body and linking pieces. also using triangles strips for the bodies (most likely extremely pointless except resulting in some headache til it worked). the rest is some blending like above and per "pixel" lighting via normalmap.

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!