Texture Compression Mode ETC1S

Mathias_Westerdahl · March 30, 2021, 2:42pm

In the 1.2.180 version we added support for the Basis Universal texture compression.
It supports two modes

UASTC - high quality, larger file sizes (<=8 bits/texel)
ETC1S - low quality, very small file sizes (.3-1.25 bits/texel)

Both modes allows us to use harwdare compressed textures on all platforms, which is a great feature. They modes are also both transcoded at runtime, which will then pick the best format for your GPU.

We initially implemented the UASTC mode since we figure that is the mode most users will use.
However, since that mode still increases the sizes for some of your projects where you want to save every byte possible.

Both compression modes are lossy, and ETC1S is more so (hence the small sizes).

But, before adding this mode to the main branch, I invite you to test it out on your project, to see if it is useful to you.
My concern is that the quality might be too low. And I’d like to hear about (or see) the results from your projects.

Ultimately, testing this feature will help us decide if we want to support the ETC1S mode.

To use it, set the compression to COMPRESSION_TYPE_BASIS_ETC1S.

Links:

(sha1: aa82e11a5e6619fb8634d90df3d42e494678685b)

Here’s an example of the Defold logo:

Uncompressed:

ETC1S:

Mathias_Westerdahl · March 28, 2021, 11:59am

Pkeod · March 28, 2021, 2:52pm

If the size is also low then it can be worth it. On the targets where people would want to enable the low quality, very small file size option, the screens are smaller generally anyway so it’s difficult to notice the differences, especially if we mix in high and low quality assets. For us, we will probably use UASTC for the main UI and things that need to look perfect, and use ETC1S for everything else on the platforms where download size matters. Then on platforms like Steam use UASTC for everything.

I did some tests with various graphics from logos to illustrations to UI and unless I was flipping back and forth between the two versions it’s harder to tell in some cases that it’s much more compressed. I tested with RGBA Best option. It’s more obvious with some kinds of UI there is compression but for the big illustrations where this is most useful it’s much more difficult at a glance to tell it is heavily compressed compared to what it could be - it will look normal for most gamers.

Something I noticed is that doing Best took much longer for ETC1S while UASTC was much faster, something to be aware of for others.

Use ETC1S for Android and Web targets, or anywhere else you need to keep the size down. Use UASTC for everything else, anywhere where download size doesn’t matter as much.

USE ETC1S for large backgrounds and illustrations, anything which the player is not constantly exposed to that can afford to be in diminished quality.

Use UASTC for logos, key art you want to be max quality, main game UI the player constantly sees.

And remember we can combine max atlas size with ETC1S to get to even smaller sizes. In some situations using UASTC with a smaller atlas size may look better too.

For anyone testing textures you should be creating small projects and pulling out textures from your main projects to test different texture options otherwise you’ll waste a lot of time waiting between tests.

2021-03-28%2007_50_11-Window

In conclusion… This is great! This will be useful to many!

Mathias_Westerdahl · March 29, 2021, 7:30am

Thanks for testing and the input @Pkeod!

Ping @Ivan_Lytkin, @GreenArrow and @BunBunBun Please try this build out to see if this works for you!

BunBunBun · March 29, 2021, 11:30am

@Mathias_Westerdahl my results of the texture size:
1.2.179 (webp_lossy) 3.76 MB
1.2.181 (ETC1S) 2.28 MB
1.2.181 (UASTC) 6.07 MB

I followed @Pkeod’s advice to check textures in an empty project. so I have not yet been able to check how it looks visually in live project (I will write in theme of 1.2.181 beta soon) , but results in numbers of ETC1S looks amazing!

Mathias_Westerdahl · March 29, 2021, 3:07pm

@BunBunBun I have now updated the links with a new version of the editor/bob.jar. This version allows you to use Native Extensions.

BunBunBun · March 30, 2021, 6:50am

so, today we’ve checked how looks the graphics in real project:
1.2.179 webp_lossy
http://tinydobbins.com/test/defold/test_textures/textureTest_179_webplossy/

1.2.181 ETC1S
http://tinydobbins.com/test/defold/test_textures/textureTest_181_etc1s/

about ETC1S interesting that some colours looks okay (on the shark and boat’s part) but other (palms / clouds / grounds) have artifacts, in webp_lossy - all looks amazing.

and one more thing, the building time, on my PC (Win 10, Core i7-7700K CPU 4.20GHz (8 CPUs) with 16GB RAM and GeForce GTX 1080)
in 1.2.179 webp_lossy ~22 seconds, in 1.2.181 ETC1S ~720 seconds (yes, 12 minutes) same projects that on links above (12 atlases with different sizes, just as example of published game)

my personal opinion, webp_lossy = one love fast buildiing, and super weight and looks good, and no idea for what builds need to use ETC1S compression… it would be nice to look at the results of other users with graphics from real projects.

Mathias_Westerdahl · March 30, 2021, 7:36am

Thanks for testing @BunBunBun!

Yes, the problem with the alpha seems like a deal breaker for me to be honest.

And, as for the compression time, I had it set way above the default, to try to improve quality. I didn’t notice those long compression times on my computer though.

Also, there’s the engine size aspect for using etc1s+uastc. These transcoders are ~400kb/300kb respectively (varies on platform ofc).

Relevant to this discussion is also the fact that I’m about to add the optimization parameters to the UASTC compression. This will affect the lossyness/compression ratio for the different levels. And we’ll do another test round there as well, to see if we can come close to something that’s closer to what the 1.2.179 sizes.

Pkeod · March 30, 2021, 10:31am

The first time I tested I only tested on black background and it didn’t make some of the alpha issues as obvious. It seems to work for some kinds of designs better than others.

I wonder if there would be a way to split the alpha to be able to be higher quality? Back in the day that’s what we would do. Color would be JPG, alpha would be PNG as separate images and then put together when loaded.

Mathias_Westerdahl · March 30, 2021, 2:54pm

I’ve updated this test build with new links for download (sha1: aa82e11a5e6619fb8634d90df3d42e494678685b)

In this version, I’ve added the new optimization flags for Basis Universal in the UASTC mode.
In my own tests, I cannot get close to the WebP lossy sizes without getting too annoying texture artifacts. But, I’d like your input as well.

The question is, are the new compression ratios of UASTC acceptable?
(Or do you still need the WebP compression? )

Some numbers from my tests, to clarify what the BEST, HIGH, NORMAL and FAST compression levels should give for Uastc (size/time). The size will of course vary with the images you have (mine were pretty noisy)

BEST: test_uastc(image, uastc_level=2, uastc_rdo_l=0.25, uastc_rdo_d=16384) # 64.88% size, 47.977 dB, 3.139894 s
HIGH: test_uastc(image, uastc_level=1, uastc_rdo_l=1, uastc_rdo_d=16384)    # 52.31% size, 45.047 dB, 2.310900 s
NORMAL: test_uastc(image, uastc_level=1, uastc_rdo_l=2, uastc_rdo_d=8192)   # 49.82% size, 42.927 dB, 1.243244 s
FAST: test_uastc(image, uastc_level=0, uastc_rdo_l=3, uastc_rdo_d=8192)     # 43.79% size, 40.481 dB, 0.778897 s

BunBunBun · March 31, 2021, 1:26pm

@Mathias_Westerdahl just to clarify when I’m talking about “building” time, I mean building via “Project -> Budle -> HTML5 application” as release version

my results:

UASTC_BEST:				size 5.77 mb	| time ~7m
UASTC_HIGH:				size 5.39 mb	| time ~6m
UASTC_NORMAL:			size 5.33 mb	| time ~4m
UASTC_FAST:				size 4.95 mb	| time ~3m

DEFAULT_HIGH:			size 9.12 mb	| time ~12s

WEBP_LOSSY_HIGH:		size 3.76 mb	| time ~22s
WEBP_LOSSY_NORMAL:		size 2.65 mb	| time ~22s
WEBP_LOSSY_FAST:		size 2.30 mb	| time ~20s

only WebP still looks suitable for HMLT5 builds for quality/size

Mathias_Westerdahl · March 31, 2021, 12:52pm

Thanks for these numbers @BunBunBun!

I see you don’t include WEBP_LOSSY_NORMAL / WEBP_LOSSY_FAST in the tests. Are they too low quality?

Mathias_Westerdahl · March 31, 2021, 1:19pm

I have to say I’m a bit surprised by the compression times for Uastc.
This is a project with or without any native extensions?
The time is referring to the time it takes to bundle via “Project->Bundle->HTML5” ?

Also, how many atlases do you have, and what are their sizes? (roughly)

BunBunBun · March 31, 2021, 1:25pm

just updated, added WEBP_LOSSY_NORMAL and WEBP_LOSSY_FAST, we’ve decided to use HIGH option some time ago but NORMAL looks fine too:

http://tinydobbins.com/test/defold/test_textures/textureTest_179_webplossy_high/
http://tinydobbins.com/test/defold/test_textures/textureTest_179_webplossy_normal/
http://tinydobbins.com/test/defold/test_textures/textureTest_179_webplossy_fast/

britzl · March 31, 2021, 1:27pm

@BunBunBun Would it be possible for us to get a project with just the atlases so that we can experiment a bit ourselves? It would really help us get to the bottom of this. You can share with bjorn@defold.se or mathias@defold.se

BunBunBun · March 31, 2021, 1:36pm

Nope, I tested in blank projects with atlases only for saving time.

Yes, this times when I do “Project -> Budle -> HTML5 application”
also Release mode

12 atlasses with different sizes (most of 2048x2048)

Done!

Mathias_Westerdahl · March 31, 2021, 1:40pm

Thanks!

AGulev · April 7, 2021, 10:08pm

I found it’s possible to control quality for ETC1S compression. What settings are you using in this experimental build?

Because this example from @BunBunBun looks almost as good as webp_lossy example. Just interesting if it’s possible to tweak it a bit to get a bit better result.

Mathias_Westerdahl · April 8, 2021, 5:08am

we currently only use the “quality” setting for etc1s:

github.com

defold/defold/blob/basis-etc1s-support/engine/texc/src/texc_enc_basis.cpp#L35-L54


if (compression_type == CT_BASIS_ETC1S)
{
    // Tests: % of original .png, psnr
    // quality=96,  comp_level=5 -> 8.541663 %, 36.705 dB
    // quality=128, comp_level=5 -> 9.822941 %, 37.346 dB
    // quality=160, comp_level=5 -> 11.901549 %, 38.054 dB
    // quality=196, comp_level=5 -> 13.591924 %, 38.320 dB
    // quality=224, comp_level=5 -> 15.319630 %, 38.407 dB
    // quality=256, comp_level=5 -> 16.339599 %, 38.428 dB


    comp_params.m_compression_level = basisu::BASISU_DEFAULT_COMPRESSION_LEVEL;


    switch(compression_level)
    {
        case CL_FAST:   comp_params.m_quality_level = 128; break;
        case CL_NORMAL: comp_params.m_quality_level = 160; break;
        case CL_HIGH:   comp_params.m_quality_level = 196; break;
        case CL_BEST:   comp_params.m_quality_level = 256; break;
        default:        comp_params.m_quality_level = 160; break;
    }

Also note that there is the “basisu” command line tool here. which allow you to control these parameters.
Please try them locally to find a set of parameters that work as a replacement.

AGulev · April 8, 2021, 11:52am

I think I found the reason of bad quality of ETC1S. It’s because of pre-mult alpha!
Here is example:
test-premult-alpha_unpacked_rgba_ASTC_RGBA_0000

test-keep-transperent-pixels_unpacked_rgba_ASTC_RGBA_0000

I tested these 3 options in Texture Packer when created atlas from png images

All the tests:
ETC1S -comp_level 6.zip (3.4 MB)