Compressed textures using more memory than uncompressed textures?

I have few 2k textures in my scene, so I was thinking about using Basis or KTX2 textures formats. So initially I tried replacing only small number of textures(6 textures). But when I tried to convert the basis UASTC texture, the converted textures are 5x larger in size than original, is it weird or normal? Ik size does not really makes any difference while using compressed formats its about resolution and KTX2 format textures are of same size as original. But now as I was trying to replace the original textures with basis UASTC and KTX2 formal textures it seems like compressed textures are using little more memory than uncompressed(JPG & PNG) textures.

Stats for JPG format


Screenshot (114)

Stats for Basis UASTC


Screenshot (113)

Stats for KTX2


Screenshot (115)

idk if I am understanding this stats correctly or not, but seems like compressed textures and using more memory than uncompressed textures.

Demo for jpg textures app : https://condescending-beaver-c43950.netlify.app/
demo for Basis textures : https://serene-hopper-fb0640.netlify.app/
demo for KTX2 textures : https://angry-leakey-9776b3.netlify.app/

1 Like

I’m having a bit of a hard time isolating what’s going on in these demos, and notably they seem to be loading the Basis WASM transcoder repeatedly (~12 times)… would it be possible to narrow this down to a particular GLB or texture that you believe is using memory differently than expected?

Also note that there’s no difference at all in the compressed texture contents of a .basis or .ktx2 file, they’re identical, just some modest differences in the attached metadata. Both formats support the Basis Universal ETC1S (moderate quality) and UASTC (high quality) codecs. With glTF/GLB files it is always better to use .ktx2, using .basis is nonstandard.

4 Likes

I would have tried to isolate if I knew whats going on or had a doubt where it is going wrong, but I have no idea, should I just isolate some random model out if my scene for you? will that work?

When I was using ETC1S it was showing good results in terms of memory usage but textures were losing quality, so after searching about it I found out about UASTC and now quality is really good but having issues with memory.

I am isolating one of the model with ktx texture, maybe this might help you to see if there is any problem or what is the problem.

Demo for model with ktx texture
Demo for model with jpg texture

I’m trying to find a glTF file containing a KTX2 texture in these demos, in the list below…

…only one GLB is large enough to have a big texture, the 600KB one, and it doesn’t seem to use KTX2. I did see one loose .ktx2 texture loaded in the demo, as the lightmap – is that the texture you’re asking about, or should there be others?

When I was using ETC1S it was showing good results in terms of memory usage but textures were losing quality, so after searching about it I found out about UASTC and now quality is really good but having issues with memory.

If you have the full-resolution source textures available, sometimes using ETC1S at a larger resolution can still be a size and memory savings compared to JPEG or UASTC. ETC1S tends to be good best for color textures (e.g. base color) but not for normal maps. For normal maps you generally do need UASTC, or even PNG.

ETC1S will use less memory than UASTC as you mention, but I’m surprised that the UASTC version of your demo is using higher memory than JPEG… I think something else may be going on here and would like to look into that more.

1 Like

Yeah, there is only one ktx texture in that scene. (That big glb model(600kb) isn’t using ktx). My point is that both demo are identical but only difference is that one of them is using one ktx texture and other is using no ktx texture. So the demo with ktx texture should be using little less memory than the other or the same, right? But it is using more memory than the demo without ktx texture which is weird. And difference is kinda noticeable and only grows when I try to use more than one ktx texture.

This page is taking about 6 minutes to load on my computer and using about 300MB of memory (at least according to SpectorJS), including many copies of the Draco decoder. There is too much going on in this application for me to help with a benchmark, … you may need to strip it down to a simpler case, or use the R3F Discord for help from users more familiar with R3F I think.

I can say that for this particular lightmap texture in isolation, the JPEG copy will use about 21MB of memory and the Basis Universal UASTC version (whether .basis or .ktx2) should use about 5MB on modern devices if I understand correctly.

One weird thing, though, is that if you try dropping each of these textures into https://sandbox.babylonjs.com/ and then doing a Spector.js profile on the texture by itself, I’m seeing:

  • 18MB for the UASTC texture (which seems higher than expected, but OK…)
  • no texture memory at all for the JPEG texture (which seems obviously wrong)

I’m wondering if Spector.js isn’t getting the correct stats here for some reason. :confused:

1 Like

Opened:

2 Likes

but we can see that memory difference with stat js too, so is that really an issue with spector js?
or I am not understanding stat js properly.

There is a bug in spector.js here, it’s computing the size of compressed textures incorrectly. It sounds like they’re working on a fix for that now. Stats.js measures memory in RAM i think, not on the GPU. JPEG does not necessarily get decompressed until GPU upload. For mobile devices RAM and GPU memory may be shared but on desktop I think you’d want to consider them separately.

1 Like

Oh, got it. Thanks :blush: