Multitexturing for terrain quads?

OpenGL Development
#1

Hi im working on my first terrain, and its kindof working, but now needs real textures.

Id like to use a texture field, similar to a height field image. Each pixels color determines the amount of my 4 base textures.
So each vertex in the quad might have different amounts of each texture.
As im building each terrain quad into a display list, im assuming blending 4 textures over it will be pretty cheap.

Now if this terrain texturing method totally sucks feel free to sugest something better! me gl nebie :slight_smile:

Thanks heaps!
Harley.

#2

Terrain texturing is quite hard to get fast and nice at the same time, but if it helps, I currently use a technique known as texture splatting. More info at

http://cbloom.com/3d/techdocs/splatting.txt

It uses multipass rendering which is somewhat slow and fillrate consuming. Should improve once pixel shaders become common though.

  • elias
#3

on a structure point. do you think its worth using a quad tree lod? ( im already using a quad tree for objects, and leaf nodes are terrain )

from what ive read recently, its faster to use brute force, and just have one high quality terrain for each sector.

would you aggree?

the game in mind is pretty much top down view, rotated abit on z axis. so the field of view is pretty small.

what about just using one large terrain texture, with a detail texture? i’ve seen a detail texture make a big difference on terrain.

thanks.

#4

If your field of view is small, say some 50*50 metres, I’d definitely go for brute force. However if you need horizon view of your terrain (500-1000 metres view distance), LOD is crucial. The ROAM seems to be a popular choice, I’m using terrain mipmapping as described in

http://www.flipcode.com/tutorials/geomipmaps.pdf

with success. One big texture stretched over the landscape combined with a detailtexture actually gives quite good results (compared to the complexity of implementing it). I started with that and only recently implemented splatting. However, given a small viewing area like yours, your mileage might very well vary, because the simple one texture method gives best results at a distance, while techniques like splatting really improves short distance terrain (and is actually disabled for terrain at a long distance).

  • elias
#5

I will say this - hardware is fast enough to go pure brute force without you noticing. Morrowinds entire terrain system is based on terrain paging of high quality terrain fragments and it worked out just fine. While I myself am a strong advocate for going with ROAM or some of the modified ROAM algorithms, many developers in production shops are still saying that its almost a non-issue unless you’re trying to support machines on the low end.

I remain mixed on the topic because its very problem centric. I personally have more problems occluding stuff ON the terrain than I do with the terrain itself (think cityscape with large numbers of irregularly shaped buildings).

#6

I found that the disadvantages of ROAM far outweighed the advantages for a game - it’s just another one of those technology-for-technology’s sake things like psuedo-realistic behavioural AI. Complex, very big overhead, and prevents you from easily texturing the landscape in squares and doesn’t add very much to a game. My terrain thing was brute force and I thought it looked good enough.

Cas :slight_smile:

#7

Yep, my experience is the same as Cas’. I started working with ROAM to handle a very large terrain dataset, but what I found was that if I rethought the problem in terms of being sensible about texture pages or simply swapping in high quality texture pages for low quality ones, that it worked better, didn’t have bizarre hole conditions, was easier to build tools with which the artist could predict the results, and didn’t have me pulling my hair out.

I think ROAM is a nice algorithm and it has some uses in the gov’t vis sim world - but I have yet to encounter any practical reasons for using it. I’ve always found my bottlenecks to be elsewhere.

CLOD terrain is also impractical for many multiplayer situations because you can never predict how the terrain will be subdivided for each player so while player A can see player B, player B cannot see player A. In a peer to peer environment this can be resolved better than if its a server managed environment because the server will be looking in things from yet a different perspective.

At the moment I’m more worried about using imposters for cityscapes than I am with CLODing my terrain. Profiling my application just doesn’t suggest that there is any value in doing it yet.