search

microsoft / DirectXTex

DirectXTex texture processing library
https://walbourn.github.io/directxtex/
MIT License
1.8k stars 442 forks source link

question RXGB dtx5 support? #358

Closed y2keeth closed 1 year ago

y2keeth commented 1 year ago

if so what settings are for that format ?

y2keeth commented 1 year ago

never mind just read no other formats are supported

walbourn commented 1 year ago

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 commented 1 year ago

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

y2keeth commented 1 year ago

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 commented 1 year ago

DXT5nm/RXGB

DXT5nm/RXGB would this work for diffuse maps also?

y2keeth commented 1 year ago

"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 commented 1 year ago

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

walbourn commented 1 year ago

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

y2keeth commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

great thanks a lot

y2keeth commented 1 year ago

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 commented 1 year ago

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

walbourn commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

y2keeth commented 1 year ago

should add minimal compression for everything, and probably max

walbourn commented 1 year ago

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. https://github.com/microsoft/DirectXTex/issues/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 https://github.com/microsoft/DirectXTex/issues/223. This doesn't apply to BC4/BC5 since those don't use color encoding at all, just alpha.

y2keeth commented 1 year ago

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