Description

When regular texture streaming is used (not virtual textures), the largest mips are always loaded for ISM mesh textures whenever the camera is inside the bounds of the ISM even if the instances are very far away. For example, inside an ISM for a forest where the trees are spawned procedurally.

The workarounds for this are to

  1. use virtual textures (may not be feasible on low end platforms)
  2. break up large, sparse ISMs and manually adjust ISM bounds to minimize the likelihood that the camera will be inside them.
  3. if the ISM only contains a few instances, use regular static meshes and rely on automatic instancing.
Steps to Reproduce

Open the ISM_bug level in the attached project and run “stat streaming”.

Alternately:

  1. In an empty level, create an ISM Actor with one ISM instance at (VERY_FAR,0,0) and one at (-VERY_FAR,0,0)
  2. Assign a material to the instances that sample a high res texture to the component.
  3. Put the camera in the middle of the ISM bounds 0,0,0
  4. Run "stat streaming" or “InvestigateTexture <name of texture used>”

Expected:

VisibleMips memory is low because only the smallest mip is needed for the instances.

Actual

VisibleMips memory is high because the largest mip has been streamed in because the mip streaming is based on the bounds of the ISM component and the camera is inside the ISM component bounds.

Have Comments or More Details?

There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-361876 in the post.

0
Login to Vote

Unresolved
ComponentUE - Rendering Architecture
Affects Versions5.45.65.7
CreatedJan 22, 2026
UpdatedJan 22, 2026
View Jira Issue