Agreed, the naming is an issue. You could try to add “-v” to bob (if you’re using it that is), to perhaps see which atlas becomes which texture.
If it doesn’t, I should add it 
Unfortunately, the editor is more “clever” and merges all output that has the same checksum (not sure how often that happens though), so the same .texturec could potentially have multiple source files.
Since @Jerakin asked for some numbers from my testing.
Thanks to this I found a thing I had forgot to change, add the LZ4 compression on the textures(!). It was previously turned off since minimal impact on the WebP compressed textures.
Build times
WebP (lossy) 14.808s
WebP (non lossy) 14.816s
Basis 7.035s
Size on disc: (game.arcd) (LZ4 compressed):
WebP (lossy) 313930
WebP (non lossy) 315906
Basis 395526
the uncompressed basis textures were 645846 bytes
Runtime decompress/transcode
WebP (lossy) 5 textures / 327680 texels in 7.487000 ms
WebP (non lossy) 5 textures / 327680 texels in 7.310000 ms
Basis 5 textures / 436905 texels in 4.886000 ms
I calculated the texel count is more accurate on basis. They should be the same
Update The average LZ4 compression of the basis textures are ~42% of the original size.
Also note that we anticipate even more compression ratio improvements from Basis Universal, as they continue to develop it as we speak.
Some engine size numbers (since I know @AGulev wants to know 
)
Release builds, stripped
1.2.179 2635564
1.2.180 2553284
-80kb (~3%)
1.2.179 2024820
1.2.180 2092295
+64kb (~3%)
1.2.179 2160378
1.2.180 2187290
+~26 kb (~1%)
32 kb was added for the WebGL 1 fallback
In all honesty, I would have thought that the engine would have decreased even more since WebP was quite big. But I guess they were more or less the same size then. 
Piggybacking on this topic, but as I’m trying to compress my resources for iOS and Android. How do you know which FORMAT to chose?
Luminance, Luminance alpha etc don’t sound familiar, I don’t know which one to chose from. I use regular pngs and spines, which one would you pick and why? Thanks
(If this is off topic I will delete my post)
Check out this thread
awww, thx!
Then it’s time to exclude the video recorder by default! =) For me it was a surprise that webp and the recorder uses separate codecs lib. I was sure the recorder use the format it uses just to avoid using separate vpx lib.
Yes. But also note that the video recorder is excluded by default on release builds, so you won’t save anything there
2 html5 build reports.
one in 1.2.179
the other one is in 1.2.180
All the settings are the same.
web.zip (340.9 KB)
It seems like for html5 build the new compression is worse than webp
When you say worse, I know you mean size on disc.
But what about the texture quality? And the fact that we support hardware textures is also a plus.
And, as I’ve mentioned before, the devs are working on more optimizations for the compression size.
True. You right. I take into account only one aspect.
7.29 vs 5.83 mb it’s a big difference for web. what about the idea to keep current webp lossy from 1.2.179 to 1.2.180 but with other title? 
I don’t see it as very likely that we’ll add WebP back as a builtin compression format. Supporting many separate technologies is an added extra development cost.
We will however be supporting custom resource formats later this year (and we’ll keep this feature in mind when we do). In that scenario you should be able to compress the data any way you want.
Another feature I would like to see as a saving for games chasing the last megabytes, is an api to supply a font with font glyphs. That would enable a game to avoid bundling with a lot of font data.
I want to raise this topic again, my html5 build report of (Raft Wars Multiplayer game)
this is a very big difference for html5 games + ~2.45 mb,
and we see 3.76 mb vs 6.07 mb of atlases size ( > 60% bigger)
we’ve tried for a very long time to reduce the final build size by every 1 megabyte, if check again the video posted by @aglitchman the video Size matters: how loading is losing you players in his topic, such a difference may affect income.
I agree, it’s not ideal, and we’ll look into it.
Either the basis library update will improve the situation, or we’ll have to come up with a way to use webp again (e.g with an appmanifest).
UASTC is for extremely high quality (similar to BC7 quality) textures, and ETC1S is for very small files. The ETC1S system includes built-in data compression, while the UASTC system includes an optional Rate Distortion Optimization (RDO) post-process stage that conditions the encoded UASTC texture data in the .basis file so it can be more effectively LZ compressed by the end user.
Does it have features for compression amount?
Maybe reaching out to Binomial and showing them the Defold use cases would encourage them to improve compression amounts / have some advice.
@BunBunBun what is the Compression option you have set in your texture profiles when doing that test? Best?
Are you using Live Update already for minimizing initial load? Maybe worthwhile to do that in either case if you are not already.
They had very little. That’s what we’ve been waiting for.
Hopefully their new release adds the RDO optimization, which should have a parameter to tie more closely to our compression level.
Our current compression yields 8 bits per texel. With RDO, we should be able to get down to 4 bits with the optimization parameter.
Of course we can use the Live Update feature 
(and it is planned) but this topic about the texture compression.
