Questions on how the engine uses textures

[SanadaUjiosan]

I think this is a good spot for this. If it isn't, my apologies.

I was just curious on some texture issues, wanting to know the most efficient way to do some things.

A good while back jK informed me of the fact that texture dimensions play a huge factor in performance. Makes sense.

So I was wondering, how the engine uses said textures. To cut to the chase, I'll use my situation. For the various bullets, missiles, bombs, and all of that, I made one 512x512 texture and all 8 of those models use that one texture. Is this efficient, because the engine just loads one 512x512 texture for those models (which get drawn quite a bit of course, being projectiles)?

Or, would it be more efficient to make 8 16x16 or whatever the smallest texture I could make textures for each projectile, so that instead the engine is using a bunch of tiny files?

This example may not be the best, as it is comparing a medium sized texture with super small ones, but I'm interested in both an answer/opinion on this situation, and on the principle. AKA, would a group of units benefit from using one 512x512 texture or individual 512x512 textures? That is, Is the engine loading the image just once, or for each unit that uses it.

This may be common knowledge but there is no such thing as a dumb question

[FLOZi]

1 512x512 texture is better than several 512 x 512 textures (S44 infantry do this, as well as BAR units and EvoRTS legos).

The example with the projectiles is a more interesting question and I await jk or kloot's response.

[SpliFF]

Most spring models share the same texture code. The relevant part of the code to your question is the part where it loads and caches textures.

When loading models:

Each Spring model has a "tex1" and "tex2" texture path defined in the model and/or the model metadata file. These textures are typically found in unittextures/ but the engine will search under the Spring directory if it isn't found there. The textures are cached together using the name model->tex1 + model->tex2 so for a model defined with:

tex1 = "foo.png"
tex2 = "bar.dds"

the cache key is "foo.pngbar.dss"

Once cached, the same tex1/tex2 combination will not be reloaded regardless of the number of models using it.

When drawing models:

The engine loops over the cached textures and for each texture it gets a list of models using it, like so:

Code: Select all

for each state in normal, cloaked do
    setup this state
    for each texturename do
        tell opengl to use this texture
        for each model using texturename that is visible do
            draw the model
        done
    done
done

Overall it's very efficient. There is also a system for drawing "FarTextures" (2D "sprites" of units in the distance) but I won't go into it here.

[jK]

Projectile sprites & 3do textures are collected in an atlas.
These atlases cannot use mipmapping at all, making texture sizes even more important.
(I worked on adding mipmapping to it via a semi complicated shader, but I couldn't notice any performance increase, so stopped working on it further).

[FLOZi]

But that doesn't address the question over projectile models?

Or rather, the question as I see it:

Is size all important or is there significant overhead from loading? Is GPU memory allocated contiguously so that there might be an advantage in having smaller files to fill gaps?

e.g. is one 128x128 better than four 64x64?

[SpliFF]

Loading has almost no overhead since it happens once per texture per game. I don't believe using an atlas/shared textured has any real benefit on a game with as few textures as a typical spring game either. Modern (last 5 years) GPUs have plenty of VRAM and no real issues accessing parts of textures as required. You could try it and see but I'd be very suprised if it makes the slightest bit of difference. Square/Powers of 2 textures are generally better than non-square/no-pot textures but that seems to depend wholely on the graphics chipset and driver. I'd say most modern GPUs couldn't care less but I'd suggest doing some tests to be sure.

Speaking personally I'd just do whatever makes your job easier and then optimise only if you're seeing poor performance.

Last I checked most modern GPU optimisation comes from good alignment of "cache lines" but they are basically impossible to optimise manually, it's more of an internal thing.

[jK]

lag

[jK]

Maybe it's just my extremly slow 10yo HDD. But texture sizes can cause minimal lags. E.g. with CA I had a long time a micro lag when the game was started and the commanders placed their factories, this caused to load ~8 unit textures in a very short interval.
In worst case this caused: 4MB uncompressed images * 2 (tex1 & tex2) * 8 units = 64MB to be loaded.

Another example is "/give all" here texture loading is the most time eating part (~3-5sec here).

Stuff that influences texture loading times:

• loading the parts from disk
• unpacking the loaded parts of the sdz/sd7
• in case of non-dds: devIL/image decompression
• uploading (currently is CPU blocking instead of DMA)

[Kloot]

For the various bullets, missiles, bombs, and all of that, I made one 512x512 texture and all 8 of those models use that one texture. Is this efficient, because the engine just loads one 512x512 texture for those models (which get drawn quite a bit of course, being projectiles)?

yes

Or, would it be more efficient to make 8 16x16 or whatever the smallest texture I could make textures for each projectile, so that instead the engine is using a bunch of tiny files?

no: projectiles with models follow the same rendering logic as units, and it is even more important to use atlasing for them because projectile spam can incur a huge number of texture switches otherwise (which has a much greater impact on FPS than their load time does, since the latter is only a factor when a texture is first requested)

[SanadaUjiosan]

For the various bullets, missiles, bombs, and all of that, I made one 512x512 texture and all 8 of those models use that one texture. Is this efficient, because the engine just loads one 512x512 texture for those models (which get drawn quite a bit of course, being projectiles)?

yes

Or, would it be more efficient to make 8 16x16 or whatever the smallest texture I could make textures for each projectile, so that instead the engine is using a bunch of tiny files?

no: projectiles with models follow the same rendering logic as units, and it is even more important to use atlasing for them because projectile spam can incur a huge number of texture switches otherwise (which has a much greater impact on FPS than their load time does, since the latter is only a factor when a texture is first requested)

Thanks, this is exactly what I was wanting to know! Looks like I did the right thing the first time (score!) so I'll try and remember that.

Glad I could stir some discussion

[moutandihami]

Maybe I shouldn't ask this here, but what's the best way to uv map the models to all use the same texture? Do you just plan in advance the uv mapping coordinates, and apply them in wings3d or blender or what have you, then later you just make all the textures in one picture?

[Anarchid]

If you model first, then texture on a tiny picture, then you want to use that picture as part of atlas, you can usually just scale and translate your UV's for that particular model around for wherever you glued the texture on the atlas.

In blender, for example, select all -> edit mode -> in UV editor, select all faces, "s" for scale, "g" for grab, and move them to the new place.

(might be a bit trickier with larger number of pieces though)