Skip to main content
gamedev.net
🔒 Locked 🎮 Unity

Texturing Optimization

Started by Christopher Harris 2 replies 950+ views
Original Post
Christopher Harris
Christopher Harris
Would it be possible to optimize texturing by combining all textures in to one(or more) textures and updating the texture transform state instead changing the texture itself? If so, how would one go about combining textures.
Pure
Pure

Heya,

There's a few constraints regarding this AFAIK.

Modern graphics cards have a max. texture size of 4096x4096. So your texture could not be bigger than this. And if you are targeting older cards...the limit is even lower I think.

Basically, your'e going to create one big texture in direct3d. Lock it and obtain a pointer to its memory. Now you start copying your texture data. How you copy it depends on how you want your smaller textures to be placed in the big one, their color depth and so on. Afterwards unlock it and use it like a normal texture.

To be honest, because of the texture size limit...your'e bound to end up changing textures at some point even if your'e using this technique unless you can fit your entire game ( or levels, whatever textures your'e going to to use ) into one texture.

Rather focus on rendering your stuff batched by texture.

- Pure


Framerate is LIFE.
Jonas B
Jonas B
It's often a good idea to pack textures; because of less texture changes, and because video mem can often be used more efficiently.

I use this technique:
http://www.blackpawn.com/texts/lightmaps/default.html
VladR
VladR
The technique is called "Texture Atlas". Google it up or try nVidia (or was it ATIs?) utility.

Also, you could sort-of bypass the problem if all your textures don
t fit into one huge texture. Provided you dont need more than 1 or 2 texture stages (for example outdoor objects usually dont need additional lightmap texture), you would just bind the huge textures untill all available texture units are filled. Then you would just use SetTextureStage commands so that it doesnt blend with previous / next stages, and just switch Vertex shader which would output the specific objects text.stage tex coords. This requires sorting by texture anyway, so its easy to just switch to different shader (or use branching if you can).

4 textures of 4096x4096 dimension give you the equivalent of huge 8192x8192 - that
s a pretty massive amount of texture data. However, thats also a pretty massive amount of video memory - 128 MB at 16-bit quality and no mipmaps, so DXT compression is necessary (but its artifacts are invisible for most purposes, so youll use it anyway). With DXT, it shouldnt take more than ~26 MB internally (+mipmaps), so that could be acceptable these days when new games refuse to run an anything with less than 64 MB of VRAM.

EDIT: I forgot to add the most obvious thing: Always test whether the object REALLY needs the current dimension of its texture because it might not get bigger on screen than, say, 300x300 pixels and so it definitely doesn`t need texture bigger than this (or 1024x1024 "just to add more detail" which is invisible anyway).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.