BC7 is on average 2x the size of the file on HDD. Question is, if it is also 2x the size when actually loaded in the VRAM/RAM?
To me it appears its not, but its not so easy to test it properly, doing the same type of long gameplay twice etc.
I just tested it with terrain texture in both variants and the VRAM/RAM usage was exactly the same.
So this leads me to the conclusion, that once its loaded in the VRAM or RAM, these formats take up the same space.
Am I right about it? Or am I missing something?
I think you're mostly right about that. From my limited understanding, the main purpose of compressing textures has more to do with keeping the bandwidth between the RAM and the GPU down to a reasonable level. The GPU will then decompress the texture once it has been transferred to the graphics card.
Decompression on the GPU is FAAAAAAAST, but moving the data over to the GPU is a bit slower, especially when you consider the massive amount of data that is getting transferred (textures aren't the only data being transferred, but they are the largest portion). You want to keep that bottleneck as clear and open as you can and that means simply sending less data to the GPU.
Take a look at the tables in the Unity Documentation here:
Texture Compression Formats
I think the key difference between DXT5 and BC7 is the
compression quality, so I would expect that there would be fewer compression artifacts when using BC7 at the cost of longer compression time, but this would happen in the editor and have no effect on the player's experience. I'd speculate that decompression time for BC7 may be just slightly slower, but I can't say that for sure; it isn't mentioned anywhere that I've read, so I'd assume the difference is trivial.
Aside from that, they appear to be very very similar. They both work with both RGB or RGBA images, so either format can be used with sprites with transparency.
-------------------------------------------------------------------
Now, as for a recommendation, I would suggest just letting Unity pick the compression method; just leave it set to 'automatic'. I believe it already picks the most optimal choice for desktops, but if it doesn't, then follow this quote from the above link:
For devices with DirectX 11 or better class GPUs, where support for BC7 and BC6H formats is guaranteed to be available, the recommended choice of compression formats is: RGB textures - DXT1 at four bits/pixel. RGBA textures - BC7 (higher quality, slower to compress) or DXT5 (faster to compress), both at eight bits/pixel. *HDR textures - BC6H at eight bits/pixel.
*HDR textures probably aren't relevant to anything you're doing, so you can ignore that bit.
So to summarize:
-------------------------------------------------------------------
If you're interested in saving disc space, RAM, and VRAM, then I'd suggest lowering the resolution of some of your PBR textures (other than the albedo texture). I don't know, but maybe you're already doing this, but with my PVE mod, I found that I could get good results on certain textures with a lower resolution normal map for the macro details, then supplement it with a small (like 64x64) generic tiled secondary normal map with its UV scaled to like 4 or 8 to show some fine detail up close. a small set of like 3 or 4 secondary normal maps can be used for lots of different textures, this way it doesn't add anything else to the memory footprint.
This technique worked really well for rough textures like stone and also textile textures like the flags and banners.
The unfortunate side effect of using lower resolution PBR maps is that they get pixelated if you drop the resolution down too low and they player doesn't enable bilinear or trilinear filtering in their DFU options... that's why I suggest that people play PVE with those filtering options on. I'd wager that most people who play with DREAM will also have these filters enabled.
-------------------------------------------------------------------
Anyhow, I hope this information helps. I'm
pretty sure what I've said is accurate, but maybe someone else can confirm or correct if there are any errors.