Can anyone point me to some information on some of the do's and don'ts when it comes to optimizing textures for batches? I can't seem to find any practical information on the subject, just tech papers. So far, I gather that you should try to group textures together on larger pages, reducing the number of batches being sent. But wouldn't that also mean that you would be loading more texture data into memory than necessary? Some practical examples of what to batch and what not to would help.

Very interesting subject that i'd like to know too.

http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

quick reference on the subject I found useful

http://wiki.splashdamage.com/index.php/Batches

http://wiki.splashdamage.com/index.php/Texturesheets

How batch optimization is done really needs to be handled from the ground up.

The basic premise is that draw calls (which send a set of polygons to the card) are expensive, and state changes (using a different texture, using a different shader, drawing from a different vertex buffer, etc.) make that even more expensive.

Texture sheets and atlases are used to allow drawing objects that use different textures while not actually changing texture.

And no, you're not typically loading more texture data in, because the atlas/sheet is filled up with a bunch of stuff you're using anyway. Merging two textures into one takes up no more VRAM than two textures containing the same amount of data.

Why can't we just make a unique texture (let's say a 2048x1024) that contain a 512x1024 bumpmap, a 512x1024 diffusemap, a 512x1024 specularmap, and finally an additive/filter or whatever-we-want one... then scale and offset it in the material definition.

This wouldn't add extra loading cause you must load each stages of a material anyway, and this could save some batches? or am i missing something?

6th Venom wrote:

Why can't we just make a unique texture (let's say a 2048x1024) that contain a 512x1024 bumpmap, a 512x1024 diffusemap, a 512x1024 specularmap, and finally an additive/filter or whatever-we-want one... then scale and offset it in the material definition.

This wouldn't add extra loading cause you must load each stages of a material anyway, and this could save some batches? or am i missing something?

The issue isn't the number of textures you're using at any given point, the issue is that CHANGING textures is expensive. There isn't really any advantage to putting several aspects of the same material in one texture, in fact it's actually WORSE because it means you run up the hardware limits on each texture and can't merge together the individual components for several textures.

i.e. if you had 2 models with a 512x512 base texture, bump, diffuse, and specular, then if you merge all of those on to one texture, you've got a 1024x1024 texture. Thus, the number of models you can draw with the same texture changes from the number of 512x512 textures you can cram into one texture to the number of 1024x1024 textures you can cram into one texture. Obviously, the second number is smaller.

Most hardware uploads the entire state (including all bound textures) if anything changes, and needs to do some other work like verifying the state is sane too, so changing 2 or 3 textures isn't really particularly expensive compared to changing 1, but changing 1 is a hell of a lot more expensive than changing none.

So, could you just give some exemple of batch good/bad uses?

I suppose the if/else materials checks are bad? (like the one used for parm7 on monsters deaths)
Using 1 material with parm for Red, Green and Blue, and change it on each monster rather than making some differents materials with static values?

I mean, what the better, using many materials, or using one but allow scripts to change it on each entity? (with parms)

Doom 3 specificly, i don't really understand how to handle the best way batches... :roll:

EDIT: Ho! And what about Batches vs Polycount? (using texturesheets for exemple)

I really need to check here more often so I can stop necroing 2-week old threads.

6th Venom wrote:

So, could you just give some exemple of batch good/bad uses?

The general rule is that the more stuff you can make use the same material, the better.

Quote:

I suppose the if/else materials checks are bad? (like the one used for parm7 on monsters deaths)
Using 1 material with parm for Red, Green and Blue, and change it on each monster rather than making some differents materials with static values?

I'm not familiar with Doom 3's rendering architecture enough to tell you what that'll do.

The problem is there are two ways they may be doing it. If they're processing everything in software (the Quake 3 way), then it doesn't matter, it's still able to be merged. If it's being done by changing a shader uniform, then that means it'll require a separate draw call and a uniform update.

Quote:

EDIT: Ho! And what about Batches vs Polycount? (using texturesheets for exemple)

Poly count and batches are really separate discussions that have little to do with each other. Batching is a discussion of how to minimize state changes for a given set of geometry, not what that geometry consists of.

Okay, that's cool.
I managed myself to understand how it works for ETQW, and i suppose, for all IdTech4 games.

Thank you anyway!