A Guide to Texture Optimisation

Optimisation, the art of squeezing as much performance as possible from your hardware, is one of the most fundamental skills in game development. Unfortunately, with Game Guru being very appealing to inexperienced developers and it being so easy to obtain high quality media for our games, it means optimisation often gets overlooked, with catastrophic results. We often see Game Guru games that run terribly because they are poorly-optimised, and many of us have experienced difficulty creating games of any length, particularly once our levels start getting more complex and detailed.

In this three part guide, we'll be looking at how to optimise one of the biggest culprits of poor performance: textures. We'll look at why optimising textures is so important, and how tweaking two simple parameters can massively improve the performance and stability of your games. Sit tight, grab a cup of tea, this is a long one...but so, so worth it!

Part 1: The cost of textures
Textures are the single biggest drain on your graphics card during a game. When your game loads, your models and textures are passed to your graphics card to store and display. Your graphics card has a finite amount of GPU memory (called VRAM) available - these days most consumer cards have between 2GB and 8GB of VRAM - and every pixel and vertex you send to it has a cost in memory terms. To work out the cost of a texture, we need to know 1) its dimensions, and 2) its bit-depth. Let's take this texture as an example:


An example of a 1024 x 1024 texture

The first part is easy; any program will tell you it's 1024 pixels wide by 1024 pixels high. In total, it's made up of just over a million pixels (1024 x 1024 = 1,048,576 pixels).


Each pixel is made up of a red channel, green channel, and blue channel (and sometimes an alpha channel)

Now, bit-depth. Each of those pixels has a colour which is made up three channels, red, green, and blue, and each channel has a value between 0 – 255. A pixel with the colour R42,G102,B128 has a little red in it, and a lot more green and especially blue. Rather than say there are 256 possible values of each channel, we instead express this as 2^8 (2x2x2x2x2x2x2x2 = 256), and call this 8-bit colour.

Since all three channels have values somewhere between 0 and 255, we're actually dealing with three lots of 2^8. Bit-depth is the number of bits per channel x the number of channels. We have three channels here (red, green, blue), so our bit-depth is 8 x 3 = 24.

Once you know your dimensions and bit-depth, you can work out how much VRAM it will take to display your texture.

1024 x 1024 = 1,048,576 total pixels
1,048,576 x 24 bits in each pixel = 25,165,824 total bits in the image
25,165,824 bits / 8 bits in every byte = 3,145,728 bytes
3,145,728 bytes / 1024 = 3,072kb
3,072Kb / 1024 = 3MB

So, our 1024 x 1024 texture uses exactly 3MB of the VRAM on offer. It doesn't sound a lot, but it can soon add up. If your model takes advantage of Game Guru's PBR workflow, it may have six texture maps (_color, _normal, _metalness, _gloss, _ao, _illumination). If each is 1024 x 1024, that's 18MB just on textures for one model! The problem is only multiplied with higher resolutions. Six 2048 x 2048 textures will take up 72MB. And saving with an alpha channel (alpha channels control transparency) adds another 8-bit channel to factor in, giving a bit-depth of 32, and adding 25% to the GPU requirements of your texture (in reality, the only texture you should ever save with an alpha channel is the _color map, it's all wasted information if used on the other maps).

When it comes to adding unique assets to our levels, we're spoilt for choice. Between the numerous DLC packs, the TGC Store, and other third party sites like Turbosquid and CGTrader, it's pretty easy to get hold of high quality assets for your game. Artists will often provide textures in the highest quality because they a) want to present their work in the best quality, and b) they don't know how or where their work will be used. The problem is that many inexperienced developers will take these high resolution, high quality textures and use them as-is, without any thought for optimisation. If they start using 4K (4096 x 4096) textures on every asset, it won't be long before they run out of VRAM, at best causing a drop in framerate but at worst causing full game-ending crashes. Since the artist can't know where their asset will be used, the onus is on the developer to optimise the textures they are provided with.


Your graphics card, struggling under the weight of all those 4K textures

Myth #1: But my texture is a jpg, and only takes up 6kB of disk space.
The filesize of your texture has no bearing on how much VRAM it takes up. It could be a 6kB jpg or 3MB bmp, it will always take up the same mount of VRAM, although – as we shall see later – file format is still a factor in optimisation but for different reasons.

Myth #2: But my object is offscreen, doesn't that free up resources?
Sadly, no. Game Guru is very traditional in its approach to loading textures; every texture used by every asset in a level is loaded to the GPU during the loading of your level. In contrast, many modern games support texture streaming, where textures are loaded and unloaded as needed on the fly. I found a great concise explanation of texture streaming on reddit:


An explanation of texture streaming

Because Game Guru doesn't support texture streaming, it doesn't matter whether your texture is onscreen or not, or even in the same room; if it's in the level, it's loaded and uses up VRAM.

Myth #3: My game is slow because there's too many polygons onscreen.
Unlikely, as 3D meshes are infinitely cheaper than textures. A textured 3D model (static, not animated) costs 48 bytes per polygon. A single 3MB 1024 x 1024 texture takes up as much VRAM as a 65K polygon model, and most models in Game Guru are under 10,000 polygons anyway.

With this in mind, it's clear that every Game Guru developer should be looking at ways to minimise the cost of their textures on the GPU. There's two parameters you can adjust to do this and to get the best results you'll need to look at both. The first is relatively straightforward; resolution.

Part 2: Resolution
If you halve each side of your texture, you shrink the area of your texture (and the amount of VRAM it requires) by 75%. Take our 1024 x 1024 texture as an example; we already worked out it needs 3MB of VRAM. But let's halve each side, reducing it to 512 x 512.

512 x 512 x 24 = 6,291,456 bits
6,291,456/8 = 786,432 bytes or 768kB

It's clear that resizing our textures can save considerable memory, but the question is; how small should we go? That depends on many factors, but one way to look at it is in terms of screen space; how many pixels will that texture actually take up on a player's screen in-game?


How high res does this milk carton really need to be?

Here I have a simple milk carton entity. It's pretty small and because it's on a table, I know the player will only ever be able to get so close to this entity; there's a limit to how much detail they will ever see. I need to consider how many pixels that entity will take up on a player's screen. Given that 84% of Steam users still run a monitor that is 1920 x 1080 or less, it seems sensible – even in 2020 – to assume I need to make my textures look acceptable for that resolution.


I used an art package to measure the physical number of pixels this carton takes up at my screen resolution

Here I've taken a screenshot on my 1920 x 1080 monitor at the closest distance a player will ever get to the milk carton. You can see the carton itself is less than 500 pixels high. Whatever texture size I use will be squashed into those 500 pixels. Therefore, players will not see any benefit in a 1024 x 1024 texture or a 2048 x 2048 texture for this entity, because it will always be squeezed down to around 500 pixels of screen space during the game.

By default, this entity comes with 512 x 512 texture, which might seem like a sensible option; it's slightly bigger than a player at 1920 x 1080 will ever need so detail will hold up well. But here's the thing; the player doesn't actually need to discern every pixel on the milk carton. So long as they can see some of the detail, their mind will fill in the blanks. The milk carton is also not that important to gameplay; it's not a pickup, most players will just run past it. There's also a lot of contrast in the texture itself, the red stands out a lot against the white. All of this means we can get away with making the texture smaller.


Effect on visuals of reducing texture size

If we reduce it to 256 x 256, the texture now costs just 192kB of VRAM and the majority of players won't notice the difference, especially if the object is far away, tucked in a corner, only partially visible, or the room is dark. We could go one step further and reduce the texture to 128 x 128, which only costs 48kB. For me this is a little too far, but if the object was less visible or took up less screen space, this might also be fine. Another practical upshot of reducing texture size is it usually results in a smaller filesize too.


Effects on filesize and VRAM requirements of reducing texture size

Make sure you go through every asset in your game and play around with the texture sizes. Keep resizing them until you reach a level of detail that is both acceptable quality but also low memory, you'll be surprised how much you can get away with. I made this switch with a 2048 x 2048 texture to begin with, but found a 512 x 512 texture was perfectly acceptable. Only at 256 x 256 did the detail start to get blurry.


I was surprised how far I could reduce this texture

Same with this table I downloaded from CGTrader. It came with beautiful 4K textures but I experimented with different sizes to see what I was prepared to accept. Anything below 1024 was too blurry, with 1024 itself being a good trade-off between detail and performance. Even if I just dropped the texture from 4096 to 2048, I'd save 36MB of VRAM, or enough to have twelve 1024 textures elsewhere in the level.


Ultimately, texture reduction is always done to personal preference

One of the few advantages of Game Guru Classic's haphazard interpretation of PBR is that each texture that makes up a material (_color, _metalness, _gloss etc.) is specified separately. This means you can tweak the size of each texture individually to save precious memory with little to no noticeable loss in overall quality. You can usually reduce the size of your _metalness and _gloss textures more than you can your _color and _normal maps.


I found very little difference in overall quality when reducing _gloss, _ao, and _metalness maps

By reducing the physical size of your textures, you reduce the resources required to display them, and therefore their impact on performance. This is the first major optimisation you can make, the second is compression, more specifically, understanding what format to save your textures in.

Part 3: Compression formats
Inexperienced developers may be tempted to save textures in a compressed format like jpg to save filesize, believing this increases performance. I'll say it again: the filesize of your texture has no bearing on how much VRAM it takes up.

The jpg format itself is also a lossy format, meaning the way it saves filesize is to throw away data from the image. It does this by reducing the number of colours in your image, and grouping them together. You can never get this data back after saving, it's gone forever – by saving in jpg, you permanently degrade your image. Never use it for textures.

Other developers may be tempted by the png format as it offers superior quality whilst maintaining a relatively small filesize. It also supports alpha channels (transparency), which jpg does not. Png is a lossless format, meaning data is never thrown away, instead clever algorithms encode and decode the image data at either end. This requires extra processing but results in a smaller filesize. Png is a popular format for artists to supply textures in because it is lossless, but it's not ideal for game engines because it requires extra processing.

In truth, there is only one format you should be saving your textures in; Direct Draw-Surface, otherwise known as dds. It is the format native for directx, meaning your graphics card will convert any other image format to dds in order to display it. Jpg goes in, dds comes out. Png goes in, dds comes out. You can actually see the effects of this conversion process in action in Game Guru. Here's a comparison between an asset using png textures vs. using dds. Despite dds being a lossy format like jpg, the details appear sharper when using dds because your graphics card isn't having to convert a png to dds.


Comparison of PNG vs. DDS

The tool you use to save dds files matters. Nvidia do a free DDS plugin for Photoshop which is widely considered the best tool out there in terms of the quality of the textures it produces. If you don't own Photoshop, a decent free option is Paint.net, which is what I've used here. Regardless of the tool you use, you'll quickly realise dds comes in a huge variety of different flavours and compression types, so it's vital we consider which one is best for which type of texture.

To see how each compression format affects a texture, we'll use this stress-testing texture I made.


The stress-tester texture has graduated coloured bands and high detail areas designed to find compression artefacts

The dds format is lossy, it compresses your texture by chopping it up into 4x4 blocks, finding the two most contrasting colours in the block, and estimating the colours of the other fourteen pixels in the block must all have values somewhere between the two outliers. To stress-test this, our test texture has a band of tightly-packed multicoloured pixels which are impossible to arrange on a straight line from one colour to another.


A pattern impossible to replicate with 4x4 block compression

BC1
BC1 is the oldest format and offers the most compression and least strain on the GPU. It has a bit-depth of 16 rather than 24. Instead of using 8-bit colours per channel, BC1 compresses colours using 5:6:5 compression; this means that instead of 256 possible values in each channel, there are 32 for red (2^5), 64 for green (2^6), and 32 for blue (2^5). The lack of available colours causes a noticeable 'step' from one shade to the next, this is called “banding”.


Colour banding in DDS BC1

Because there are more available shades of green than of red and blue, you'll also find BC1 textures struggle to replicate greys well; often producing green or purple tinted pixels.


Green and purple artefacts are common in many DDS formats

It also totally falls apart when dealing with complex colour blocks.


Well...I guess that means our stress-test works

BC1 does support an alpha channel, but only a 1-bit alpha channel; a pixel is either fully opaque or fully transparent, there is no way to have smooth transitions between the two. This can still be useful for instances where you need a clear separation between opaque and transparent, such as on foliage and wire fences.


1-bit alpha channels in DDS BC1

By squeezing all this information into 16-bits, BC1 offers the greatest saving in terms of VRAM at the cost of outright quality. If your texture doesn't have too much grey in it, doesn't need a complex alpha channel, and isn't too tightly-detailed, BC1 is a viable option.

512 x 512 x 16 = 4,194,304 bits
4,194,304 / 8 = 524,288 bytes or 512kB VRAM

BC4
BC4 is a grayscale format that offers the same benefits of filesize and VRAM usage as a BC1 texture but with significantly better quality. Being grayscale, it only has to store one channel of data, not three, allowing us to have the full compliment of 256 shades of grey. BC4 is ideally suited to grayscale textures like _metalness, _AO, and _gloss, but it does not support alpha channels.


BC4 is excellent for grayscale textures

BC3
BC3 is essentially a combination of BC1 and BC4. It stores RGB colours in the same 5:6:5 compression as BC1, but stores an alpha channel in full 8-bit grayscale like a BC4. BC3 is a popular choice for any texture that requires a full alpha channel in order to simulate semi-transparency, or graduations. With 16 bits for colour and 8 for alpha, it has a bit depth of 24.

512 x 512 x 24 = 6,291,456 bits
6,291,456 / 8 = 786,432 bytes or 768kB VRAM


BC3: The best of both worlds?

BC5
BC5 is sometimes recommended for tangent-space normal maps. It uses two grayscale BC4-style channels to store X and Y information, with Z being reconstructed later in the pixel shader itself. The upside of this is increased fidelity in the normal map (compared to BC1 or BC3 where you don't have the full range of 256 colours), the downside is the extra memory required to load the texture, since it is has a bit-depth of 16+16 = 32, and the additional processing required in the pixel shader.

512 x 512 x 32 = 8,388,608 bits
8,388,608 / 8 = 1,048,576 bytes or 1,024kB or 1MB VRAM


'Signed' or 'unsigned' defines which channel is reconstructed in the pixel shader

BC6 and BC7
These two newer formats are only supported by D3D11-level hardware (directX11 and above), and only became an option to us Game Guru-ers since the DX11 update in 2018. These exotic and complicated formats use sophisticated techniques to pick the best compression method for each 4x4 block instead of just applying one to the entire image. The specifics are a little too complex to go into here (plus I'm not sure I fully understand them myself!) but I will link to a fantastic blog post at the end of this guide where you can do further reading if interested (it's where I learned most of this!).


BC7 compression is designed to take advantage of DirectX11 hardware

BC6 and BC7 do better with our stress test with BC1 and BC3, but it's important to remember we're stilling dealing with a lossy format so inevitably the results won't be perfect. In most real-world scenarios, BC7 will produce the best results, almost indistinguishable from a png original. BC6 is designed for storing floating point data as used in HDR images. Since Game Guru doesn't support HDR textures, you can probably ignore this format.


Stress-test comparison

The main downside to BC6 and BC7 is the increased encoding time required to save these textures in the first place. Paint.net offers different compression speeds, with slower being more accurate but taking longer. The resulting images are full 32-bit RGBA, making them twice as costly both in terms of filesize and VRAM usage.

512 x 512 x 32 = 8,388,608 bits
8,388,608 / 8 = 1,048,576 bytes or 1,024kB or 1MB VRAM

Despite the increase in quality, surprisingly very few AAA games use more than a handful of BC7 textures. This may be partly down to their increased filesize and memory footprint, but it also may have something to do with compatibility on older consoles that don't support the format.

B8G8R8
You'll notice that none of the block compression methods so far give a 100% accurate rendition of the png stress-test image. Both the Nvidia photoshop plugin and Paint.net do feature various other uncompressed formats of dds which are less commonly used because of their large filesize. If you really want 100% accuracy, your best bet is B8G8R8, which uses full 8-bit colour channels to save an uncompressed 24-bit colour image.


B8G8R8: I don't know why the channels are swapped around and not R8G8B8

512 x 512 x 24 = 6,291,456 bits
6,291,456 / 8 = 786,432 bytes or 768kB VRAM

Whilst it smashes the competition in terms of accuracy, the lack of compression triples the filesize compared to a BC3 or BC7 image. Over the course of an entire game, this will add up. I don't recommend using this method.

But seriously though, which format do I pick?
Now that you're aware of the different compression formats available, the question is which one do you use? This is really dependent on the texture itself but, in general, I would stick to the following rules:

PBR:
_color (no complex alpha needed, and not much greys/muted colours) = BC1
_color (complex alpha needed, or lots of greys/muted colours) = BC7
_normal = BC1
_gloss = BC4
_metalness = BC4
_ao = BC4
_emissive = BC1
_illumination = BC1
_surface = BC1 (Game Guru Max only)

DNS:
_D (no complex alpha needed, and not much greys/muted colours) = BC1
_D (complex alpha needed, or lots of greys/muted colours) = BC3
_N = BC1
_S = BC4
_I = BC1

It's always a balancing exercise between texture quality versus GPU memory requirements, and this has to be decided on a case-by-case basis. But this is also why you need to optimise both resolution and compression, as it buys you more VRAM to play with for your more important assets. Saving a few megabytes on background props might allow you to spend a few more megabytes textures closer to the player.

Hopefully this in-depth look at texture optimisation will save you lots of performance and enable your games to run more smoothly on a wider variety of hardware.

Further reading (and sources):
Understanding BCn Texture Compression Formats
http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/

Torque 3D texture compression
http://docs.garagegames.com/torque-3d/official/content/documentation/Artist%20Guide/Formats/TextureCompression.html

DDS Files and DXT Compression
https://w3dhub.com/forum/topic/417101-dds-files-and-dxt-compression/

Steam hardware survey – December 2020
https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam

Great information , well explained and laid out. Thank you for taking the time to do this

Dave

Very informative and in depth a lot to look into now.. Thanks for the effort to do this tut Avenging Eagle...

Thank you Avenging Eagle for your superb tutorial.

If you consider that my question is not out of topic, I would like to know your opinion about the textures mapping the terrain in Game Guru Max. Is it a good choice for the performance of the engine ?

Hi mikeven, I'm afraid I haven't bought into Game Guru Max yet so I haven't seen how the terrain textures work. If it's the same as classic, the _D map uses an alpha channel to control roughness. This does seem like an efficient method. Other assets in Max use the _surface texture, where the red channel = ambient occlusion, green = roughness, and blue = metalness. Since terrain almost never needs an AO or a metalness map, a _surface texture would be wasted on terrain, so using the roughness map in the alpha channel of _D seems like a efficient use of resources. DDS BC3 would be the most efficient format to save a terrain texture in, though BC7 would offer the best visual quality.

AE

Hi Avenging Eagle.
Thank you for having taken the time to answer so fast to my question.

The creation of digital artworks requires more and more technical knowledge.
This is demonstrated by Dghelneshi in her tutorial about DDS files and DXT Compression (the link provided in your tutorial : https://w3dhub.com/forum/topic/417101-dds-files-and-dxt-compression/ ).

Thanks for this thorough tutorial AE.

I've quoted a part from your tutorial because i do have a question about that part.
It would seem that if indeed polygons are cheaper, actual displacement (more dense mesh for added geometry) would be faster then parallax occlusion which means multiple passes of a texture.
In terms of memory, i think it certainly is cheaper to have more polygons, but rendering them seems to me to be an extra cost in terms of performance and more so than those extra passes.

At least this is how i have picked it up though i might be wrong.

You're probably right Earthing45, otherwise why would games bother with displacement mapping? Unfortunately, I have no data on the relative performance hit of displacement mapping versus doing it all "for real" using geometry.

AE

Maybe due to loadtimes because a low poly model is going to load and render much faster and with all the detail through textures we have lod through mipmaps i think.

Sadly mipmaps in GG are only 5 steps i believe due to those lines becoming visible on terrain and models with tiled textures.

This video gives a good comparison i think of several techniques.

There is a certain amount of processing "per poly" that cannot be avoided and is relatively constant regardless of the size of the polygon.
(things like mapping that particular polygon to a part of a texture map) (tF)

There is also an additional amount of processing which varies on the size of that polygon (how much of a texture map it covers for example). (tA)

So if you have 100 polygons you get 100 * tF + 100 * tA

If you now have another bit of extra processing to add 'fake' depth (based on normal maps for example) it will add a little bit to tA but not make tF any longer.

So it is all down to that fixed overhead per poly, if that is substantial then adding more polys may make it more expensive overall than doing the 'fake' depth processing. (and it's not really an 'if' because we know that is the case )

Very useful info here, detailed and well explained. Avenging Eagle thanks for the tuto.

There might be some other factor on the equations to take into account as well, the texel density is well explained on those 2 links below.

here and here.

Is there some texel density tools such as Texel Density Advisor for Maya.

texel density tool for 3ds max

Understanding Texel Density

Just want to add something that maybe has nothing to do, but it worth knowing. imho.

Edit: fixing links.

Any chance for a tutorial part on multi materials per object?

@AE-thanks for going out of your way to produce these tuts. Will have a good read later.

Avenging Eagle, thank you so much for this guide !
Written very clearly, understandably and with illustrative examples, I learned more about dds formats, before reading I used only BC5 method, now I can save some more memory.

For the _surface texture, you suggest BC1, however you menton earlier that BC1 is good for "no complex alpha needed, and not much greys/muted colours", but a _surface texture is three channels of greyscale; AO, Roughness, and Metallic, all of which are entirely grey scale, so surely BC1 is not good for those? Wouldn't BC7 be better?

@Belidos

BC1 is not very good at replicating grey colours because greys require an equal split of red, green, and blue channels. Since the red and blue channels have half as many possible shades available to them as the green channel, you end up with green or purple tinted greys (a RGB value like 45,43,45 is not uncommon).

Now consider the _surface texture. Each channel is used independently by the shader. The shader only uses the red channel for AO, only the green channel for roughness, and only the blue channel for metalness. It's not necessary to combine the values of the red, green and blue channels with a surface texture. So then the question becomes, why that order? Why not red for roughness, or green for metalness? You're an artist, you'll probably have experienced first-hand that when making a metalness map, it's often either black or white, and an AO map is usually mostly white with a little bit of grey. You can quite convincingly compress both of these from 256 colours per channel to the 32 colours per channel of a BC1. Roughness/Gloss on the other hand has more nuance, lots of areas of grey in between black and white; BC1 give the green channel 64 possible values. OK it's not perfect, certainly not as accurate as full 256 colours, but it's good enough.

BC7 is also 32-bit, it has an alpha channel. Surface textures currently don't make use of an alpha channel for that's wasted information IMO.

AE

Fair enough, just thought i would check.

Reading the links provided it is obvious that some conversion utilities make a bad job compare to others, any idea what GG uses?

I'm wondering if a lot of the complaints people have about their models not looking as good in GG is because they are using .png textures and GG is doing a poor job of converting them to the appropriate DDS equivalent.

I assumed the conversion was done by the graphics card rather than by the engine, but I guess it could be all handled in-engine. Except for lightmaps, they are created by the engine and are saved in an extremely compressed dds format. You can often see green and purple banding in the falloff of lights, which points to the lightmaps being BC1 compression, but whatever is creating them is doing a terrible job compressing them. It would be nice if they could be saved in BC7, but that might be a bigger resource overhead.

AE

@Avenging Eagle - great read.

So for a rounded out tutorial, it would be interesting to add the pros and cons of _illumination maps.

OldFlak....

Sorry OldFlak, what do you mean? Surely you either want to have self-illuminating parts of your asset, or you don't. AFAIK, _emissive and _illumination do the same thing so no need for comparison there. I would recommend BC1 for _emissive and _illumination maps because of the reduced bit-depth, although some users may want to stretch to BC7 if they want more accurate colour rendition; it just means wasting 8 bits on an unused alpha channel.

AE

AE Thanks for reply

So like what are the trade-offs if you have say a 2048 texture with just one small part requiring illumination, as opposed to one with lots of parts.
So is the rendering hit for a texture with very little detail less, as opposed to one with lots of detail, or is it always the same hit no matter the detail on the map.

OldFlak....

Ah I see, well the contents of the texture itself is irrelevant from a memory perspective; the full texture needs to be loaded into memory and the number of bits per pixel is the same regardless of whether it's a black pixel or a coloured pixel. Even compressing to BC1, your 2048 x 2048 _emissive or _illumination map will require 8MB of texture memory on top of all the other textures that asset has.

AE

AE - thanks for that.
I thought that would be the case.
I have been keeping my larger textures free of illumination in leu of putting multiple illuminated entities on the same texture, as long as they are meant to be used together on the same map.

OldFlak....

Great guide just thought I would share some info if someone has problems with BC4:
BC4 exported from Gimp does not show up in GG at all (with my Nvidia card at least). Importing Gimp BC4 file into Paint.net and exporting as BC4 fixes the file for GG

This is a great info-tutorial, thanks.

In terms of textures consuming vram it’s actually worse as the engine also auto calculates mip maps for each loaded. These are a series of smaller resolution textures based on the primary loaded one that are displayed when models are in 3D distance of the scene. So this uses extra gpu memory on top of the base texture requirements.

Cheers.

I was actually quite surprised to learn Game Guru auto-generates mip maps (I've come across them before). Paint.net gives you the option to create these automatically when saving to DDS, but I don't bother since Game Guru does it automatically. Apparently it adds about a third to the filesize and, presumably, the VRAM consumption.

Wizard of id's recent post on the Live Broadcast #40 thread casts fresh doubt on some of the maths I've used in this tutorial. It turns out the VRAM consumption may not be as high as first thought, which is actually quite relieving! Regardless, the advice on how to optimise your textures remains valid and, as far as I can tell, best practice.
https://forum.game-guru.com/thread/222699#msg2640752

AE

This compression tool might help people out

https://developer.nvidia.com/nvidia-texture-tools-exporter

Dave