Use Compressed Heightmap Storage setting on landscape

Hey, I’ve stumbled upon a property on landscape and corresponding CVar:

bUseCompressedHeightmapStorage

landscape.HeightmapCompressionMode

I’ve used it, recooked the build and compared memory usage before and after. Unfortunately no memory was saved, it was actually slightly increased. Which makes no sense to me. I could not find any real documentation or UDN topics on this, there is only a mention of this in the CVars reference (https://dev.epicgames.com/documentation/en\-us/unreal\-engine/unreal\-engine\-console\-variables\-reference\#landscape) and repeat of the comment in code in the landscape proxy variables (https://dev.epicgames.com/documentation/en\-us/unreal\-engine/API/Runtime/Landscape/ALandscapeProxy\#variables).

I would expect this to help reduce size coming from TEXTUREGROUP_Terrain_Weightmap. The number of entries (landscape streaming proxies in memory) is identical between runs. But this is what happens:

Compressed (bUseCompressedHeightmapStorage set to true)

Total TEXTUREGROUP_Terrain_Weightmap size: InMem= 130.02 MB OnDisk= 264.75 MB

Total TEXTUREGROUP_Terrain_Heightmap size: InMem= 64.41 MB OnDisk= 102.75 MB

Uncompressed (default, bUseCompressedHeightmapStorage set to false):

Total TEXTUREGROUP_Terrain_Weightmap size: InMem= 119.90 MB OnDisk= 264.75 MB

Total TEXTUREGROUP_Terrain_Heightmap size: InMem= 59.20 MB OnDisk= 102.75 MB

What happens is that in the uncompressed version, there are less of those textures streamed in at the full resolution of 256x256. Uncompressed has 124 heightmaps and 249 weightmaps fully streamed in (384KB per one), while compressed has 142 and 284. I have verified this with force GC every frame, the camera is still and identical between takes. Nothing besides level loading takes place before measurement.

In case it helps, it looks like we have 4 heightmaps and 8 weightmaps per landscape proxy. Please explain how this property works and if this is not how I could reduce usage in those texture areas, then how could I modify that.

Hello!

Yeah, sorry, the documentation is not complete yet.

The implementation in 5.6 should be in a much better state than 5.5, as it has been tested in an actual shipping game there, I would recommend trying 5.6 if you want to use the compression.

In 5.5, landscape.HeightmapCompressionMode overrides bUseCompressedHeightmapStorage - make sure you have those set properly in the comparison.

In 5.6, we removed the per-landscape bUseCompressedHeightmapStorage control, and that landscape.HeightmapCompressionMode works slightly differently, and is enabled by default.

The compression is on-disk compression, it does not change the size in memory (in a steady state).

When enabled, you should see smaller disk file sizes, at the expense of some CPU perf and a temporary memory cost to decompress the texture data when it is streamed in.

The smaller mips are not compressed, and you can control the mip level at which it switches to uncompressed data with landscape.HeightmapCompressionMipThreshold.

Some platforms with weaker CPUs are set by default to not compress any mips, as the CPU decompress cost was too costly.

Hope that helps!

-Chris