That's understood,. The concern is if the Kraken-type compression on SSD allow PRT to be read. If not compressed beyond DXTC, we could store and read texture tiles. If we crunch a whole texture down to its smallest size for fast loading, can we then load individual tiles within that archive? One would assume not. One can't dive into a .zip of a text document and pull out letters indexed at position 15 and 27 without unzipping the whole thing.
For SVT, textures are tiled at a fixed size during development. When using PRT only high resolution tiles that are visible are transferred to VRAM so you can’t compress entire mips (outside those that’s smaller than the fixed size of the tile). You compress the individual tiles so each mip level is represented by a composite of compressed tiles.
The ZLIB or Kraken compression doesnt inhibit the ability to request individual tiles needed by SVT. The unreal engine already accommodates the use of zlib for virtual texturing to minimize I/O costs. Unreal also allows the use of crunch which employs both lossy and lossless compression on disk and transcodes to a supported block compression format to VRAM.
Last edited: