@bkaradzic Could you merge this one first? and I can do the rest part.

Hi, sorry for the radio silence, I've been slammed and I forgot about the email notification.

The astc lib changes look ok to me on a once-over. I've synced them and I'll test them later today.

The library-ised version of the ARM code bimg uses lives here: https://github.com/andrewwillmott/astc-encoder. So it's be good to get these changes there too. I'll just check they haven't diverged already first.

@andrewwillmott Do you need me to create the same PR (Adding ASTC_RA) to https://github.com/andrewwillmott/astc-encoder ? or you can merge it by yourself.

@cloudwu Yeah, it's better to create first PR for astc-encoder, and merge it there, and then copy changes here (workflow should be the same as if bimg used submodules).

Yeah, tell you what -- if you could create a PR against astc-encoder, I'll merge it and test it and then handle the updating of the bgfx copy.

Actually, never mind, you can leave it to me, the normal map patch applies to the original without the update at least.

I've added your changes to https://github.com/andrewwillmott/astc-encoder and then slightly refactored them, to allow RA->XYZ decoding, and the encode-for-normal to be independent of the quality. (Though of course they set some of the same things.)

I'm going to hold off on updating from https://github.com/ARM-software/astc-encoder for now. Some of the recent changes are about ripping out 32-bit support and requiring C++11, and I suspect some bgfx/astc_lib users are not ready to accept that yet. Also there're a lot of changes that have gone in in the last month, after it has been fairly inactive for a long time prior to that, so it might be an idea to let them settle. The only bugfix I can find is to astc_toplevel which isn't used in the library variant, so I don't think we're missing anything.

I'll bring these changes across to bimg and in doing so have a look at how they should be called from image_encode.cpp. I'm guessing by adding more TextureFormats, though the number of block formats in ASTC makes this annoying.

I'll close this PR after @bkaradzic copy the changes from https://github.com/andrewwillmott/astc-encoder , or @andrewwillmott may create a new PR ?

I'll create a new PR, yeah, with the texturec changes.

Did you find one of the normal map encoding options was better than the other? It'd be easier to expose just the one in the tool due to the API.

I'll create a new PR, yeah, with the texturec changes.

Did you find one of the normal map encoding options was better than the other? It'd be easier to expose just the one in the tool due to the API.

I am porting https://assetstore.unity.com/packages/essentials/tutorial-projects/viking-village-29140 this scene from unity to bgfx these days. I'll compare two encoding options next week. I think one option is ok , we can choose the better one by default.

Some comparison for your information :

I use a normal map from https://github.com/fmod/Viking-Village/blob/master/Assets/Textures/Terrain/terrain_01_n.tif (A 2048x2048 tangent-space normal map)

• I strip the blue channel for all the results and then use astcenc -compare to calcuate (only two channels) PSNR.
• EAC_RG11 has the best PSNR , but etcpack is very very slow (It cost a few minutes to encode this texture) .
• I think we can use -normal_percep for astcenc by default, becuase etcpack has a similar option by default.

btw, @bkaradzic Could you add an option to use stereographic projection for two-channels normal map ? See https://www.nvidia.com/object/real-time-normal-map-dxt-compression.html (3. Tangent-Space Normal Maps)

btw, etcpack use a very slow algorithm to encode EAC format, my implemention is much faster (reduce from O(n*n) to O(n) ) . bkaradzic/bgfx#1392

I have this working in bimg/texturec, but I'm finding the astc code is giving me compression artefacts on this test image.

Still digging into that. One thing to note is the astc -normal options overlap with -fast/-thorough etc., this is why the difference between the fast/thorough options is small. The normal map modes tend to force very thorough encoding modes, maybe to try to deal with the artefacts?

From looking at the table, I've added just ASTC_4x4N and ASTC_6x6N as the normal map encoding options.

I traced the block artefacts to zero encode weights for gb, epsilon values fixed them. I think this may have been the reason for the high encode thresholds the -normal mode sets in astcenc, which override some of the compression mode settings. Hence I'm now leaving the those to the compression speed setting, so the two things are independent.

I've just opened #24 which brings bimg up to date with my astc_encoder fork and makes it so the -n/-normalmap option triggers the ASTC_ENC_NORMAL_RA mode. Unfortunately I initially went down the path of doing this by adding corresponding bimg TextureFormat enums, before realising that would require a fair few changes to bgfx, due to the enum shadowing, and switching to using Quality instead.

I think we may change the prototype of imageEncodeFromRgba32f by adding an additional options bit flags to support more encoding algorithm.

btw, @bkaradzic bgfx haven't support BC3nm/DXT5nm now, could you add it ? At least we can support encoding BC3nm in bimg as BC3 by channel swizzling .