B Info 2D Texture optimization: some fine print.

Users who are viewing this thread

xenoargh

Grandmaster Knight
I've been getting a fair number of questions about optimization over the last few months, so I thought I'd set down some things that I think are generally very important to know about (but probably get ignored).

Basically, the way the engine works, most of the shaders are optimized for DXT1 textures, without alpha.  The alpha isn't even being read; yet if it's there, it's a significant amount of data.  Lose it, and you can improve performance throughout the engine, whether we're talking about hitting RAM limits, time to load a scene change, or FPS during the biggest fights.

Keeping textures lean and mean is a big deal.  I'm not quite sure why it took me so long to polish this part of the mod; I think that a lot of it's just that until I figured out the sound-glitch error, and how it is (somehow, very mysteriously) tied to RAM / VRAM use, I wasn't thinking mainly about textures, both in RAM and VRAM.  Further research about how to improve stability has led me to conclude that this, along with getting total vertex counts down (mainly, we're talking about good LODs here, unifying vertexes on your artwork, and so forth) is a major factor in terms of stability.

Let's look at sizes, to get a good idea of how much memory you can save.  Let's say that you have 50 suits of armor, assembled from the usual OSP hodgepodge, plus your own work.  Your armors have 1024 skins.

If you use DXT5 (soft alpha) or DXT3 (interpolated alpha), that suit of armor is eating up over 1MB in size, per skin.  1048KB, more or less.  Since each suit of armor needs 3 skins, that's 3X50X1048 KB, or 153.5 MB in skins, just for your 50 suits of armor.

If you use DXT1 (1-bit alpha), you go down a lot, to 683 KB.  That gives you 100 MB, almost exactly.  A 50 MB reduction.

Now, I don't know for certain how much this will improve stability, for users who are crash-prone.  But my experience thus far is that every time I find another way to optimize, the engine gets a little more stable.  Having seen the results of this, I'm pretty tempted to even do it with the more common Taleworlds textures, as it would really save a lot of space (they were kind of on-again, off-again about doing this in-house). 

How much space?  Probably almost 100MB.  I'm a bit chary about shipping out that much of the game's content, though, so I may offer that as a side-thing, instead of integrating it with Blood and Steel, for people who want an ultra-optimized version of the game's content.

[EDIT]Corrected silly error--> me turned off mip generation for some strange reason.  Thanks to Barf for pointing it out![/EDIT]
 
BTW, you can do this with a batch process in Photoshop pretty easily.  Set up an Action with Save As... set up for DXT1 no alpha, then File-->Automate-->Batch and set the folder of files you wish to convert and the destination. 

Just make sure you don't include any DDS DXT5 files that have to remain DXT5, and of course, don't do this without backing up your files first!
 
Are you sure you are generating the mip-maps when you are converting the textures?.
That would be the only way to reduce the size further from Dxt1a.
 
Sorry for reviving: But does this mean you were mistaken on this one in general, xenoargh? (I don't mean to show you up, just want to know and lack serious knowledge about mip maps yet)

And another thing with transparency I noticed is that in some cases it seems that black pixels of 255 255 255 are transparent for some reason (even in native textures) could it have been a converter issue or is there any reason behind it? I keep finding transparent pixels in tree trunks for example and it puzzles me quite a lot.  :neutral:
 
You want to build the mip maps, absolutely.  I goofed up; I forget what I was doing, but I'd turned off generation for something, probably a chunk of UI  :lol:

Anyhow, the cost savings are still very substantial, I just goofed up in terms of final numbers.

Black pixels frequently get turned to black in the alpha, yes.  This can be a problem, but with most of the shaders, the alpha is ignored (regardless of what OpenBRF shows- it's shader is a bit one-size-fits-all atm).  So for tree trunks, unless you've assigned it flora_shader instead of dot3_alpha_biased, it should be just fine.
 
Back
Top Bottom