|
Author Topic:   Blending Multiple Textures onto a Terrain
JamesC
Member
posted June 24, 2000 08:02 PM            
Just throwing around some ideas of the best way to do this. What approaches do you guys take? I'm thinking of this in terms of tile based terrain texturing. Here are some of my thoughts: Any more than 4 textures is probably a waste (Lightmap, tiled Detail Texture, tiled surface texture 1 and tiled surface texture 2)thoughts? Has anyone played around with random alpha values in each texture, for example, add random alpha values to a grass texture, then blend it with a rock texture onto a polygon, or is it best to just evenly blend the grass and rock texture together? What do you guys think of blending each texture based on some other value such as height? What blending options give the best performance across most cards?

IP:

Bryan T
Member
posted June 26, 2000 01:54 AM            
JamesC,

Multitexturing is usually done by drawing the polygons again with each texture. Considering the many polygons that are being textured, it would probaly be worth the extra time and effort to make as few passes as possible.

I am working with terrains in the >10,000 polygon range. At 60fps, that's >60,000 polys a frame. At 4 textures each, that's >2,400,000 polys... way too many for the consumer graphics cards today.

Now, if you create textures with the lightmap already applied (you have to generate it anyway, might as well apply it to the ground texure while you're at it). This is called 'baking' the lighting onto the texture map, and reduces the redraw by one.

Next, only draw the detail texture on close polygons. By definition, a detail texture just gets fuzzy more than a few meters out. We could consider this a 'half-draw'. So we're down to 2.5 redraws.

That last one (terrain texture 2) may be redundant for today's engines. Multitexturing with > 2 textures is purely eye-candy level stuff. For instance, HALO uses 4 textures on it's game objects. But as far as I can tell, no more than two on the landscape.

The actual ground texture may be a blend of two textures, but it should only be applied as one texture (see Klaus's paper in another thread). I think that thread also answers your other questions about blending two textures together.

(I see you've found it already.. here it is for any latecomers) /forums/archive/ubb/Forum3/HTML/000149.html

--Bryan

IP:

Prophylon
Member
posted June 26, 2000 03:20 AM            
If I recall correctly, Quake 3 uses up to 8 passes to render stuff... They can use less if the FPS drops too much though. B&W uses something similar. Multitexturing is pretty standard on all cards after (including) the TNT... Though it is a bit nasty to implent with OpenGL, if you get it to work it works great. Check out : http://www.lionhead.co.uk/forums/Forum5/HTML/000314.html

Of course multitexturing still decreases performance and as Bryan said, you should avoid it when it it is not needed.

Joris.

IP:

JamesC
Member
posted June 26, 2000 01:14 PM            
Thanks for the reply guys.. I really feel green when it comes to this kinda thing, I'm an oldschool 2d programmer, and have only been doing 3d for about a year and only terrain rendering for a few months . On some of the more modern cards I've been testing I havenít seen too much of a hit because of single pass multitexturing, but the project I'm working on must also work on older cards which make all of your points very valid. So are we talking about stretching 1 big texture across the entire terrain? Won't this cause a more of a performance hit because of the large texture size being uploaded? I've been playing around with this idea some, but it always seems to look bad when on the terrain, seems to stretch badly if I use a texture the same size as the heightmap and anything bigger eats too much bandwidth. In Klaus's paper, though it didn't go into actually applying textures it seems he did use a tiling system blended at runtime.. or am I misunderstanding and he actually built 1 large texture out of the smaller ones at runtime? Or another idea is to build 1 large texture in system memory as big as you want it to be then chop it up and apply say a 512x512 texture to each "block" of terrain and only pull the textures that you need onto the video card. Anyone know how they did it in Ground Control? Thoughts?

IP:

JamesC
Member
posted June 26, 2000 07:25 PM            
Ok, time to make myself look dumb I went back and re-read the thread on texturing where Klaus talked about his texturing method, and he does use 1 big texture, that that issue is cleared up. I'm still not understanding though how using 1 large texture won't gag the program, if you keep it in system memory, you have a bandwidth problem, if you keep it in video memory, then thats about all your gonna keep there if your targeting old cards (such as I am)I can see chopping it up and sending it to the card out of system memory as needed, but when you are uploading say, 8 chunks, at even 256x256 thats a lot of information to transfer, and thats only counting your terrain data, not even any of the other data. Please enlighten me...

IP:

Prophylon
Member
posted June 27, 2000 03:54 AM            
Well there are a few problems with using large textures (dimension > 256)... First of all not all API directly support such big textures, like OpenGL can not handle textures bigger then 256x256. Of course you could create 4 of those, but then certain effects are rather hard... Besides that it is very hard to keep that much data into yer gfx card memory, because a 24bit 1024x1024 picture would eat about 3MB. Of course you have way more textures so if you have too much to fit in yer gfx card mem the API must swap textures from your memory to yer card, which is slow.

Since I want my game to be able to run in one type of landscape without texture swapping on a 16 MB TNT card, I am not going to use large textures, instead I will use smaller textures and go play with blending, multitexturing etc...

JamesC I think you might have a prob if you want to to use that big texture on 'older' (before TNT) cards.. They simply do not have that much memory. Since those cards will likely not support multitexuring (not hardware anyway) you might be have to creative... Maybe you could do something with realtime noise effects to lessen the tile effect?

It has been awhile ago since I read Klaus paper (and my brain is pretty crappy) but I can harly imagine why he uses one big texture? It might be easier if you preblend the lighting, the debris, etc, but it eats memory... Besides if you make one big texture how do you keep your landscape from looking tiled after all? Because if you precalc lighting, either you must have a lot of 1024x1024 for your entire terrain, or a real small terrain or it looks kind of uh strange?

Or am I seeing something all wrong here?

I am going to read Klaus paper now and I will give you MvHO once I am done hehe

IP:

MarkBatten
Member
posted June 27, 2000 08:40 AM            
First, it's not true that OpenGL can't handle textures greater than 256x256. GL imposes no limit itself; the card may, and GL provides a query for that.

On the question of how to do this, what I do is synthesize a single large texture based on height and other variables, using an algorithm much like Klaus's, and then split that large texture up into smaller pieces to improve texture memory use. Since the mesh in a given frame might cross texture boundaries, I also maintain separate LOD trees, which doesn't add much to overhead.

IP:

Bryan T
Member
posted June 27, 2000 10:48 AM            
JamesC,

You can do it either way. Using one large texture is fine if your landscape is small enough. Otherwise you'll run out of texture memory on the card. So after a certain point, you have to go with smaller patches.

When using smaller patches, however, you get visible seams along the borders between the patches. In order to fix this, you have to overlap the textures by a pixel. This leads to a simplified model of texturing:
- Load a large buffer with the landscape texture (the texture being n*(TextureSize - 1) + 1 in dimension).
- Cut the texture into patches of "TextureSize" in dimension such that they all overlap by one pixel on each side.
- Apply these textures to the polygons such that the texture coordinates are always within the borders of the texture, never actually using the border pixels.

This is a simple way to do it, but for yet larger terrains even this is impossible. Take Black & White, for instance. You cannot keep a 65000 Kilometer terrain map and texture map in memory all at once. This leaves them with no choice but to generate these texture maps on the fly.

To do this, start with a small texture map of the entire terrain (say, 256x256), placing it at the highest node in a Quad Tree of textures. Create equal size textures (256x256) for each quad under the highest node. This gives twice the resolution from the first. Continue this down to the maximum resolution you want for your project, then pick which texture you need at runtime.

Now, instead of storing all those textures in memory, dynamically generate them and add or remove them from the tree as needed. This is what B&W does.

Here are some links: [URL=http://www.vterrain.org/LargeTextures/index.html]http://www.vterrain.org/LargeTextures/index.html http://www.tashco.com/terraintexturing.html

--Bryan

[This message has been edited by Bryan T (edited June 27, 2000).]

IP:

JamesC
Member
posted June 27, 2000 12:28 PM            
I'm basically planning on keeping my terrain for this project down to about 1024x1024 meters, so it looks like using a method similar to Klaus's to generate 1 huge texture, say 4096x4096 and apply it in 512x512 blocks to the terrain. Doing this, I could bake the lighting into this texture and then only have to apply 1 texture per 1 poly patch of terrain. I could even get cute with it and let older machines choose smaller textures, say a 2048x2048 main texture split up into 256x256 blocks instead. I dont plan on support anything older than a TnT 1, which is what I consider old. This all seems like it would be fairly easy to implement, though I'll prob get a reality check when I do Thinking about it, the hardest part will probably be deciding what textures to keep on the card and what to swap...

IP:

Prophylon
Member
posted June 28, 2000 04:16 AM            
Mark: I have never been succesful in using textures larger then 256x256 in OpenGL. If I remember correctly it is stated in some official OpenGL docs that you can not use textures greater then 256x256...
(btw my card supports textures up to 2048x2048)

Bryan pretty much sums the different possibilities up

Ow btw texture management can be done by DirectX and OpenGL, I think you should consider using that because if you have a total of 2048x2048x3 = 12.5MB on landscape textures, some swapping is needed I think.

IP: