Compression artefacts in custom background for main menu

[Dragofer]

For some reason, my custom main menu background image has huge compression artefacts when seen in the TDM menu. I took it from an ingame location using TDM's F12 screenshotting tool, then opened it in GIMP and exported as either .tga or .dds. Also tried .jpg.

If I open one of my .jpg briefing images from the internet in GIMP and convert it to .tga, that's perfectly sharp in the TDM menu.
Definitely quite weird, since I've seen plenty other missions with reasonably sharp ingame screenshots, and my screenshot looks good while it's still in GIMP. AMD driver issue?

This is a screenshot of the foggy sky in the TDM menu, which should be completely uniform:

Compared to a screenshot of the same area in GIMP:

 

[duzenko]

1. What is your image_compression cvar?

2. Tried it in the .dds format?

[Dragofer]

46 minutes ago, duzenko said:

1. What is your image_compression cvar?

With a currently .tga background and default darkmod.cfg cvars from updating to the main menu beta:

Can't see an image_compression cvar in my darkmod.cfg, and the console doesn't seem to know it. My other seemingly compression-related cvars are:
 

seta s_decompressionLimit "6" > seems to be something for audio files (max uncompressed sample length), so I didn't experiment with it
seta image_usePrecompressedTextures "1" > setting this to 0 has no effect on the background and turns pretty much everything else into black rectangles/screens
seta image_useNormalCompression "1" > setting this to 0 has no effect
seta image_useAllFormats "1" > setting this to 0 has no effect

seta image_useCompression "1" > setting this to 0 cures the problem. As sharp as ingame.

 

52 minutes ago, duzenko said:

2. Tried it in the .dds format?

Yes, I tried it in .tga, .dds and .jpg and made sure I didn't have both a .tga and a .dds in valid locations simultaneously.

[duzenko]

9 hours ago, Dragofer said:

With a currently .tga background and default darkmod.cfg cvars from updating to the main menu beta:

Can't see an image_compression cvar in my darkmod.cfg, and the console doesn't seem to know it. My other seemingly compression-related cvars are:
 

seta s_decompressionLimit "6" > seems to be something for audio files (max uncompressed sample length), so I didn't experiment with it
seta image_usePrecompressedTextures "1" > setting this to 0 has no effect on the background and turns pretty much everything else into black rectangles/screens
seta image_useNormalCompression "1" > setting this to 0 has no effect
seta image_useAllFormats "1" > setting this to 0 has no effect

seta image_useCompression "1" > setting this to 0 cures the problem. As sharp as ingame.

 

Yes, I tried it in .tga, .dds and .jpg and made sure I didn't have both a .tga and a .dds in valid locations simultaneously.

Right, I meant image_useCompression

So you're saying that your particular image looks bad in the compressed texture format, both auto-compressed on the fly by the graphics driver and pre-compressed with presumably superior tools.

I think we have a material flag for textures to force compression off but @stgatilov is it applicable to GUI images?

[stgatilov]

1 minute ago, duzenko said:

I think we have a material flag for textures to force compression off but @stgatilov is it applicable to GUI images?

GUI accepts material path, just like any other place in the engine.
If you put path to image, then material is auto-generated. Of course you can create material manually instead.

[Dragofer]

It's maybe a bit buried in my last post, but setting seta image_useCompression 0 actually cures the problem: no more compression artefacts.

[duzenko]

17 minutes ago, Dragofer said:

It's maybe a bit buried in my last post, but setting seta image_useCompression 0 actually cures the problem: no more compression artefacts.

No, I just thought you wanted a universal solution

You might run out of VRAM with just that cvar fix, like I do on a 1GB card

[stgatilov]

1. I don't understand what's in the images that you posted. I see gray rectangle in the second one, and gray rectangle with some outlines in the first one.
2. Almost surely this is the problem of DXT compression in OpenGL driver, since you provide non-DXT data, and engine uploads it as DXT. It is possible that the problem does not happen on drivers of other vendors. You can workaround it by forcing high quality in material, or providing DXT-compressed DDS (it should work).
3. It can be related to the problem with DXT compression on AMD that you had before you turned image_useTexStorage off.

 

[OrbWeaver]

I don't think there's any bug here. DXT is a cheap and cheerful texture compression algorithm that works OK for most images if you don't look too closely, but it doesn't handle smooth gradients very well. If you want a large and smooth background image filling the whole screen, you need to disable DXT compression.

Setting image_useCompression to 0 will work for you (although it will disable compression for all images, so might increase GPU memory usage), but it won't help other users if you are using this image as part of a released mission. If you are planning to release this image and you want it to look good for everybody, you probably need the forceHighQuality material keyword.

[Dragofer]

On 6/26/2021 at 9:58 AM, stgatilov said:

1. I don't understand what's in the images that you posted. I see gray rectangle in the second one, and gray rectangle with some outlines in the first one.
2. Almost surely this is the problem of DXT compression in OpenGL driver, since you provide non-DXT data, and engine uploads it as DXT. It is possible that the problem does not happen on drivers of other vendors. You can workaround it by forcing high quality in material, or providing DXT-compressed DDS (it should work).
3. It can be related to the problem with DXT compression on AMD that you had before you turned image_useTexStorage off.

 

1.    I’m only showing a section of the sky in this thread in order not to spoiler.
2/3.  Yes, I tried opening the same FM with a .tga background on my Intel GPU PC and the compression artefacts are less severe. The quality is like when I use a .dds image.

46 minutes ago, OrbWeaver said:

I don't think there's any bug here. DXT is a cheap and cheerful texture compression algorithm that works OK for most images if you don't look too closely, but it doesn't handle smooth gradients very well. If you want a large and smooth background image filling the whole screen, you need to disable DXT compression.

Setting image_useCompression to 0 will work for you (although it will disable compression for all images, so might increase GPU memory usage), but it won't help other users if you are using this image as part of a released mission. If you are planning to release this image and you want it to look good for everybody, you probably need the forceHighQuality material keyword.

The real problem I believe is that I’m giving the game a .tga image in hopes of optimal quality, but it automatically gets compressed at startup. On my AMD GPU the result happens to be even worse than when I use a .dds image.

I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.

 

[cabalistic]

6 minutes ago, Dragofer said:

I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.

This is by design. Anything dds is uploaded as-is (i.e. compressed), but the remaining textures are auto-compressed unless forced to high-quality if image_useCompression is enabled (and similarly, image_useNormalCompression for normal maps). We can talk about whether or not that design is good, particularly given that compressing textures on the fly is slow and produces driver-dependent quality. But it was done intentionally (probably to save VRAM on older cards, I suppose).

[nbohr1more]

34 minutes ago, cabalistic said:

This is by design. Anything dds is uploaded as-is (i.e. compressed), but the remaining textures are auto-compressed unless forced to high-quality if image_useCompression is enabled (and similarly, image_useNormalCompression for normal maps). We can talk about whether or not that design is good, particularly given that compressing textures on the fly is slow and produces driver-dependent quality. But it was done intentionally (probably to save VRAM on older cards, I suppose).

Does the "forceHighQuality" material keyword still work? If so, that should be usable to force menu's etc to bypass compression.

[duzenko]

3 hours ago, Dragofer said:

I suppose you can work around it by making a material with forceHighQuality, but it doesn’t make sense to me that TDM compresses my .tga images. If I wanted that I’d use .dds images.

 

And how would you suggest to use the forceHighQuality flag in that case?

I think it's good that users have a choice here. Would anyone prefer hi-quality GUI backdrops over in-game stutter and freezes? It's not just VRAM issue, but also system RAM/pagefile too.

Your particular .tga might not make a difference, but there could be dozens in other maps.

[Dragofer]

4 hours ago, nbohr1more said:

Does the "forceHighQuality" material keyword still work? If so, that should be usable to force menu's etc to bypass compression.

Yes, it works here.

1 hour ago, duzenko said:

I think it's good that users have a choice here. Would anyone prefer hi-quality GUI backdrops over in-game stutter and freezes? It's not just VRAM issue, but also system RAM/pagefile too.

Your particular .tga might not make a difference, but there could be dozens in other maps.

Mappers do have that choice already, and that's when they provide either .tga or .dds images. But it gets overruled by default when the .tga's are compressed to .dds at runtime. As cabalistic says this is slow for loading and driver-dependent, and mappers might not be aware it's happening.

Maybe it's still considered a poor decision for mappers to use many custom .tga's, but maybe once we have pre-compressed normalmaps there'd be enough budget left to allow any .tga's to remain as they are by default?

[peter_spy]

Ideally TGAs should be used only for prototyping materials. And one of the downsides of TGAs is that they will be treated by the engine aniso filter, which is subpar to highest quality mipmap filters used with DDS. This affects both game world and 2d menus (e.g. inventory icons made with TGAs will always be blurry in comparison to high quality DDS).

Perhaps texture compression options could make their way to video options, although IMO for players the texture size (image_downsize stuff) would be more important. Basically all games have texture quality options, and it's quite weird TDM never had it.

[OrbWeaver]

22 minutes ago, Dragofer said:

Mappers do have that choice already, and that's when they provide either .tga or .dds images. But it gets overruled by default when the .tga's are compressed to .dds at runtime.

Mappers do have a choice, but that choice is made via the forceHighQuality keyword. The engine has never used the image format on disk to make per-image compression decisions.

The original engine expects all textures to exist on disk in TGA format, which it then decides to compress or not compress according to the image_useCompression option. If compression is enabled, it can optionally look for a precompressed DDS file on disk, but this is just a performance optimisation — if the precompressed image isn't there, or the image_usePrecompressedTextures option is disabled, the engine will compress the TGA image at runtime. This is why there are separate dds and textures trees with a parallel layout. The dds tree is just a cache of the textures tree, storing precompressed images which the engine can load faster than compressing at runtime.

The way we are using the engine — supplying only DDS files for many textures — was not intended or anticipated by the original developers, but it does happen to work even in the closed-sourcd Doom 3. Now that we have the source code we could improve this behaviour to make it clearer and more flexible. For example, we could ditch the separate dds and textures trees, and have both DDS and TGA files in a single tree, with the engine loading whichever format happens to be used for each image. It could then be smarter about enabling compression based on the source format, rather than assuming both compressed and uncompressed versions are available and choosing between them based on game options.

[duzenko]

2 hours ago, Dragofer said:

Mappers do have that choice already, and that's when they provide either .tga or .dds images. But it gets overruled by default when the .tga's are compressed to .dds at runtime. As cabalistic says this is slow for loading and driver-dependent, and mappers might not be aware it's happening.

Maybe it's still considered a poor decision for mappers to use many custom .tga's, but maybe once we have pre-compressed normalmaps there'd be enough budget left to allow any .tga's to remain as they are by default?

Maybe I'm missing something here, so correct me when I'm wrong

For 'regular' materials users have a choice if they want the .tga go onto the GPU raw or compressed. This is the normal workflow for most textures.

When the mapper wants a particular .tga be used always uncompressed, they slap the forcehiQuality flag on the material. In this case the user's preference is ignored. This flag must not be abused no matter how important the mapper considers the difference in looks. Only a handful, <1% of all materials, should fall in this category.

Do you have a lot of textures you think must be always uncompressed, no matter how slow and limited user's system is? If so, think again.

If it's just a couple of textures that you have singled out as exceptions, then use the FHQ flag and everyone's happy.