Hello mates
Could somebody please explain - does ETC Crunched actually reduce ram/vram usage if comparing it to original ETC/ETC2? Or does it only affect size on disk?
On disk size only.
VRAM is usage is identical, and RAM usage may be momentarily greater when using Crunched textures when loading them from disk if compared to “uncompressed” assets. By default Unity builds use some kind of general compression like ZL4 or LZMA on the asset data files to reduce disk size. So comparing Crunched to “uncompressed” isn’t really a fair comparison since it’s unusual, as both Crunched and LZMA or LZ4 compressed ETC textures use some additional RAM when being loaded compared to an “uncompressed” ETC texture.
GPU image compression formats are all fixed compression ratios, meaning it doesn’t matter what the content of the image is or how it was compressed, a texture of a specific resolution using a specific compression format will always be exactly the same size in VRAM. It has to be because GPUs have to be able to pick any random position on a texture and be able to get the pixel color without having to decompress the whole image to get it. The only way to make GPU texture formats use less memory is to reduce their resolution or use a different format with a better compression ratio (of which depending on the device there may not be any better than ETC).
Most web focused compression formats are variable compression ratios, which means you can’t just pick a random position on the texture to get the color value without decoding the entire image first. You don’t know where in the image’s compressed data the information for any specific pixel is located. They’re also relatively slow to decode, at least compared to GPU image compression formats.
There’s a handful of goals with Crunch texture compression formats, but the main idea is to have a compression format that can decompress directly and quickly into the matching GPU image compression format that has a better compression ratio than just using a general purpose compression algorithm on a GPU image data. It does this with two main steps, reconfigure some of data into a form that is more easily compressed by general purpose compression, and use variable ratio & lossy compression on the image data. It also aims to be fast to decode, so loading a crunched texture from disk should take no longer, or hopefully less time than loading an “uncompressed” GPU image format texture or using general purpose compression.
At this point, it really only fulfills the goal of being smaller on disk than general purpose compression alone. Modern general purpose compression techniques have focused more on decompression speed than earlier techniques and modern system storage is a lot faster than the slow spinning discs that were around when Crunch was originally created.
3 Likes
Thank you very much for your responce!
The reason I was asking this question is that for some reason bundle browser I’m using shows that runtime memory consumption of both ASTC and ETC textures that are packed into an asset bundle is a bit higher than its ETC Crunched equivalent. Even though ASTC format I’m using has much better bitrate.
I guess that browsers memory usage evaluation is invalid.
You potentially have to go to fairly large ASTC tiles to match Crunched ETC’s “on disk” size. Asset bundles downloaded from the internet are also a little weird because they don’t really exist “on disk” for the user. The browser memory stats are probably showing the size of the assets after being decompressed from the LZ4 into memory. The Crunched ETC sits in memory in it’s extra compressed form and only exists in it’s “uncompressed” form on the GPU.
It’s a little confusing to talk about this since a Crunched ETC asset is basically 3 layers of compression. The LZMA or LZ4 compression applied to the asset bundle (which I think is still applied to the Crunched assets if they’re in a bundle that’s been compressed), the Crunched compression itself, and then the ETC image format. Asset bundles need to be uncompressed from their LZMA/LZ4 version for them to be “seen” by Unity. It helps reduce the on disk or download size, but not the runtime memory usage. For downloaded asset bundles it’s probably sitting in browser memory in an uncompressed form as a resource for the engine to grab? Not really sure of the specifics.
1 Like