koobas.hobune.stream
Better way to see what contributes to file size?
According to the docs, and several forum answers, the way to see what contributes to file size is to check the editor log ( Unity's doc on reducing file size ). However, all this really tells you is how much memory these assets use at runtime, not the actual file size.
I.e. a 1024 16-bit texture uses 2MB of memory, but on disk it's a PNG of about 600kb. Even worse, I have an 8mb audio clip, but since it streams from disk, it's listed as 0.0kb at the bottom of asset list.
Is there any way to get a break down of actual asset sizes going into the build? I'm working on iOS/Android, though i'm sure there must be a way regardless of platform...
Another curiosity is, I changed sample rate of my large sound clip from 44kHz to 22$$anonymous$$hz, which reduced file size from 16mb to the 8mb, but it made absolutely no difference in the estimated file size of my ios build. Even compressed it should have shaved off at least 1 mb, no?
Unity recompiles resources(images, audioclips) to some unified format for release package, I guess. though the source format differs the output might be the same.
all this really tells you is how much memory these assets use at runtime, not the actual file size.
No, it's the build file size. That's the whole point.
a 1024 16-bit texture uses 2MB of memory, but on disk it's a PNG of about 600kb.
It's never a PNG on disk. Unity does not use the source files at all when making a build. A 1024 16-bit texture uses the same space on disk as it does in RAM.
I can accept that images are stored in a diff format than png, but I would think whatever format they use uses some kind of compression, thus taking less space on disk than in memory.
At any rate, i still contend the asset list is not the complete build list, since like i mentioned, the largest audio clip (an others) is reported as 0kb. That clip does go into the build, and definitely takes more than 0kb, so the asset list is definitely underreporting...
I would think whatever format they use uses some kind of compression, thus taking less space on disk than in memory.
It doesn't, though. The format on disk is the format that's used directly in VRA$$anonymous$$, so truecolor RGBA on disk uses 4 bytes/pixel, DXT5 uses 1 byte/pixel, etc. (not including mipmaps). The only real exception is web player builds, where the entire file is LZ$$anonymous$$A compressed.
the largest audio clip (an others) is reported as 0kb
I haven't seen that myself, but it sounds like a bug that should be reported.
