question RXGB dtx5 support?

[y2keeth]

if so what settings are for that format ?

[y2keeth]

never mind just read no other formats are supported

[walbourn]

if I understand correctly, you'd like built-in support in texconv for creating the "DXT5nm/RXGB" variant for normals maps as described here.

Essentially it's just the BC3 compression scheme with the channels swizzled a bit.

[walbourn]

Quick follow-up: Why not just use BC5 which is supported by all Direct3D Hardware Feature Level 10.0 or better hardware?

[y2keeth]

BC5

I know bc3 will work for quake4 not sure about bc5, id tech 4 games support RXGB dtx5 not sure about the nm version

[y2keeth]

DXT5nm/RXGB

DXT5nm/RXGB would this work for diffuse maps also?

[y2keeth]

"The RXGB formal on the other hand, is a DXT5 image with x in the alpha channel, the red channel empty, and the original green and blue channels left in tact. This improves the compression quality for the x component and doesn't require any reconstruction."
is what i am looking for

[y2keeth]

tried bc 5 didnt work
BC3 compression scheme with the channels swizzled to RXGB would be perfect i think

[walbourn]

What do you mean by "didn't work"? I'm guessing the shader in question is not reconstructing the third channel?

[y2keeth]

What do you mean by "didn't work"? I'm guessing the shader in question is not reconstructing the third channel?

bc5 would not load in quake 4 probably to old a engine, bc3 work thats about it except rxgb dtx5

[walbourn]

It appears from some old toolsets that this is specific to Doom 3 and requires a special FourCC value 'R', 'X', 'G', 'B'. I could consider it for legacy loading, but I don't think it makes sense to implement it for writing as such specifically for this engine.

Writing it as FourCC 'D', 'X', 'T', '5' with swizzling is simple to implement, so I can add those to the tool.

[walbourn]

I've added support for both reading and writing RXGB, but by default it will write RXGB as 'DXT5' legacy format for general usage when using -f RXGB. If you want to force the use of "RXGA", you will use -f RXGA -dx9.

This also adds support for -f DXT5nm.

[y2keeth]

great thanks a lot

[y2keeth]

another question this gui for Texconv
https://vvvv.org/contribution/texconvgui#comment-280714
has a iminium compression setting is that a option for rxbg? without the gui of course.

[y2keeth]

"q: Uses minimal compression"- will this work with rxgb?

[walbourn]

The options -bc x (max) and -bc q (quick) apply to BC7 compression where it influences the mode choices evaluated for each block. It has no impact on BC3/DXT5 compression.

If you need a 'real-time' solution for BC3 compression, you should look at this sample which has a SIMD implementation of a Fast Block Compress scheme.

[y2keeth]

The options -bc x (max) and -bc q (quick) apply to BC7 compression where it influences the mode choices evaluated for each block. It has no impact on BC3/DXT5 compression.

If you need a 'real-time' solution for BC3 compression, you should look at this sample which has a SIMD implementation of a Fast Block Compress scheme.

trying to get the best quality rxgb possible without getting to uncompressed size
what is that link? I dont see a sample?

[y2keeth]

thought minimal compression might have been a way to do that bummer it only works on bc7

[y2keeth]

should add minimal compression for everything, and probably max

[walbourn]

I guess "minimal compression" for BC1-BC5 could be a form of Fast Block Compress, although the sample only has SSE/SSE2 intrinsics implementations and not ARM intrinsics, so that's a bit of work that would need done. Also, the quality of this is really poor, so it doesn't really make a lot of sense to do it for an offline compression tool. I had this idea in it's own issue and decided it made more sense as a sample than a library feature. #18

Minimal for BC7 CPU compression just tries mode 6. It doesn't try any other modes. This is generally a bit better than BC1-BC3, but it's error-rate is a lot higher than other modes. This doesn't do anything for BC6H compression.

For "maximal compression" for BC1-BC5, this would require some new algorithm implementation. DirectXTex uses the original D3DX9 compression algorithm. There were some experiments with using alternative algorithms, but none of them did much to improve quality.

Maximum compression for BC7 CPU just means it tries mode 0 & 2 which are slower to evaluate. Otherwise it just skips those and only considers 1, 3, 4, 5, 6, or 7. This doesn't do anything for BC6H compression.

The BC1-BC3 improvement I am consideration adding here is the 'optimal solid color block' algorithm used in libsquish and NVTT. See #223. This doesn't apply to BC4/BC5 since those don't use color encoding at all, just alpha.

[y2keeth]

I guess "minimal compression" for BC1-BC5 could be a form of Fast Block Compress, although the sample only has SSE/SSE2 intrinsics implementations and not ARM intrinsics, so that's a bit of work that would need done. Also, the quality of this is really poor, so it doesn't really make a lot of sense to do it for an offline compression tool. I had this idea in it's own issue and decided it made more sense as a sample than a library feature. #18

Minimal for BC7 CPU compression just tries mode 6. It doesn't try any other modes. This is generally a bit better than BC1-BC3, but it's error-rate is a lot higher than other modes. This doesn't do anything for BC6H compression.

For "maximal compression" for BC1-BC5, this would require some new algorithm implementation. DirectXTex uses the original D3DX9 compression algorithm. There were some experiments with using alternative algorithms, but none of them did much to improve quality.

Maximum compression for BC7 CPU just means it tries mode 0 & 2 which are slower to evaluate. Otherwise it just skips those and only considers 1, 3, 4, 5, 6, or 7. This doesn't do anything for BC6H compression.

The BC1-BC3 improvement I am consideration adding here is the 'optimal solid color block' algorithm used in libsquish and NVTT. See #223. This doesn't apply to BC4/BC5 since those don't use color encoding at all, just alpha.

ok just thought it was a good suggestion, guess not