Skylight cubemap unnecessarily loaded at runtime for baked lighting

Development Rendering
, ,
1

Hello!

When profiling memory usage (`memreport -full`) on our Quest 3 title, I notice that some of our largest textures have no usage counts:

Cooked/OnDisk: Width x Height (Size in KB, Authored Bias), Current/InMem: Width x Height (Size in KB), Format, LODGroup, Name, Streaming, UnknownRef, VT, Usage Count, NumMips, Uncompressed
4096x4096 (65536 KB, ?), 4096x4096 (65536 KB), PF_B8G8R8A8, TEXTUREGROUP_Skybox, /Game/_Assets/Vista/Sky/Sky_NGM_dramatic_night.Sky_NGM_dramatic_night, NO, NO, NO, 0, 1, YES
1024x1024 (49152 KB, ?), 1024x1024 (49152 KB), PF_FloatRGBA, TEXTUREGROUP_World, /Game/_Assets/SceneCaptures/SkylightCaptureB.SkylightCaptureB, NO, NO, NO, 0, 1, YES

We are using baked lighting, so the skylight’s contribution is pre-computed into lightmaps at build time. The cubemap should not be sampled at runtime but the cubemap is loaded because the SkyLight actor references it, but the mobile renderer doesn’t actively use it.

To confirm the skylight has static mobility, real time capture disabled, and source type SLS Specified Cubemap

The cubemap is hard-referenced in the SkylightComponent:

/** Cubemap to use for sky lighting if SourceType is set to SLS_SpecifiedCubemap. */
	UPROPERTY(EditAnywhere, BlueprintReadOnly, Category=Light)
	TObjectPtr<class UTextureCube> Cubemap;

Likewise, these textures are likely getting cooked and packaged unnecessarily increasing the size of our builds.

Is this intended, or is there an optimization to be made here. Hopefully we can free up >100MB of memory for our title!

2

Hi there,

As you suspected the hard reference from the Skylight is causing this texture to be always loaded. Since it is technically a hard reference, you also can’t force the texture not to cook (the cooker will throw an error). Texture Cubes also can’t stream, so unfortunately you can’t stream in only the required mips either. The simplest solution is probably to add these textures to a custom texture group, and set that texture group to have a Max LOD Size of 1 in your Android device profile. This will cause the texture to get cooked with a maximum texture size of 1x1 on Android platforms, which will take up a miniscule amount of space both on disk and in memory. You could also set this on your Quest device profiles, however, this doesn’t apply at cook time (only base profiles for a device type apply at cook time). Setting this on the Android device profile ensure that you also don’t waste the space on disk either.

[Image Removed]Extra bonus tip for saving memory:

You might also want to check how much memory your collisions are taking up. On a previous VR project I worked on, we found that complex collisions (which we didn’t even use most of the time) were taking up considerable amounts of memory (something like 500MB). This will probably show up under the BodySetup section of your memreport if I remember correctly. I’d suggest setting your Default Shape Complexity to “Use Simple Collision As Complex”, and overriding it on the meshes that actually need complex collision if you see that memory usage from collisions is high.

[Image Removed]

Let me know if you have any further questions,

Regards,

Lance Chaney