Video summary
UE5 Instancing: When to Use It and How to Maximize Performance - ISM/HISMs Deep Dive
Main summary
Key takeaways
Subtitles Summary (UE5 Instancing: Stack Meshes vs ISM/HISM)
What the video is about
- Explains when to use Static Mesh Actors/Components versus Instanced Static Meshes (ISM) versus Hierarchical Instanced Static Meshes (HISM) in Unreal Engine 5 to improve performance.
- Goal: reduce frame-time bottlenecks (mostly CPU-side) and especially improve level load times.
- Context: The speaker updated a Fab spline mesh tool (a free blueprint + demo map in paid tiers). The mesh-type guidance applies both inside the spline tool and generally in UE.
Definitions: mesh types
Static Mesh (UE5)
- Imported 3D geometry that can be moved/rotated/scaled, but not fundamentally changed.
- Exists as:
- Static Mesh Component: attached to a larger object (e.g., inside a blueprint), not typically placed directly in the level.
- Static Mesh Actor: placed directly in the level.
ISM / HISM
- Used to group many copies of the same mesh and share rendering computation, which is beneficial when there are many repeated meshes.
Key tradeoff: functionality vs instancing efficiency
- Instancing improves efficiency when many objects share settings.
- There isn’t a fixed “magic number”:
- The speaker mentions 2 instances as sometimes a starting point, but it’s usually not worth it due to setup complexity and reduced per-instance functionality.
The important caveat: per-instance functionality is lost
Anything that was previously configured per mesh/actor becomes shared across the instances, including:
- Animation: all instances move together.
- Collision: enabled for all or none (no independent per-instance collision behavior).
- Materials: share the same material(s).
Additional limitation mentioned:
- Physics operations cannot affect instances individually (even as a group).
Performance measurement: what instancing actually helps
-
FPS isn’t the main story. In Unreal, performance is limited by CPU or GPU, whichever is slower. The “fastest” path doesn’t matter if you’re still blocked by the slowest side.
-
Instancing primarily helps CPU time (and load times).
- If your project is GPU-bound, FPS may not increase dramatically.
- Instancing can reduce some GPU/memory overhead, but the clearest wins are often loading.
Metrics used in the tutorial
The speaker uses Unreal console commands/diagnostics to show differences:
stat unit: general CPU/GPU/frame timing breakdown.- Primitives (prims):
- Marker for how much the editor is tracking (not perfectly accurate because the editor itself impacts results).
- No strict “recommended” threshold, but extremely high counts are warned against (billions = problem).
- Draw calls:
- CPU instructions sent to the GPU.
- Influenced by material/geometry/project settings (lighting, transparency, post-processing, multiple materials, etc.).
- Example:
- 10 separate static meshes sharing one material = 10 draw calls
- 10 ISM instances sharing one material = 1 draw call
stat scene memory:- Demonstrates large memory reductions from instancing.
Demonstrated results (editor timing)
Test setup
- Begins with a blank scene with a blueprint + light.
- Then uses a stress test: high-poly walls repeated ~5000 times.
Load-time comparison (editor)
- Nearly ~2.5× faster loading with ISMs versus non-instanced static meshes.
- Note: these are editor timings, not guaranteed player-facing results.
Memory comparison
- Non-instanced: about ~19 MB for the blueprint.
- Instanced: memory drops to <0.1 MB.
- The speaker emphasizes that reduced memory usage from instancing can drive faster load times.
Important note on validity
- Editor timings are not the real player experience.
- For actual results, use trace logs and packaged builds.
ISM vs HISM: the functional difference
Main difference: LOD behavior
- ISMs:
- Typically use a single/shared LOD choice across all instances (based on distance evaluation rules).
- HISMs:
- Support per-instance LOD.
- Mainly exist so nearby instances can get higher detail while distant ones get lower detail.
UE4 vs UE5 note
- UE4 historical behavior: if one instance was in view, evaluation could extend to others—making HISMs more necessary.
- UE5 update: in UE5.4+, the speaker claims ISMs are more reliable, and changes reduce the need for HISMs.
Nanite interaction (LOD systems)
Comparison
- The speaker compares HISM LODs to Nanite:
- Nanite: automates LOD generation and adapts detail in a way aligned with what the player sees.
- Traditional HISM LODs: don’t care what part of the mesh is being looked at; they don’t dynamically generate detail the same way.
Potential concern
- Nanite LODs are generated dynamically (“in real time”), which can cost processing.
- Still, the speaker generally prefers Nanite.
Compatibility guidance
- Nanite + ISMs: yes, recommended to simplify geometry and recover performance.
- Nanite + HISMs: framed as less sensible because HISMs already implement an LOD system; Nanite may not clearly help.
Practical guidance: decision rule / flow
- Do you need per-instance logic?
- If yes (gravity, physics, player interactions, collisions, separate materials, etc.): use Static Mesh Actors/Components.
- If settings can be shared:
- 1 instance: use Static Mesh Actor.
- 2–100 instances: instancing is recommended if placement is easy (tool-assisted/spline placement helps).
- >100 instances: instancing is “pretty much always worth it” because it scales well; the setup effort is considered manageable with their tool (about ~15 minutes).
- Platform/version recommendations
- UE4: prefer HISMs
- UE5 (especially 5.4+): prefer ISMs, and consider Nanite rather than HISM
- When HISM might still be relevant in UE5
- Thousands of instances far apart (e.g., foliage actors that mostly only have material animation).
- Targeting lower-end hardware.
Tool mention
- The speaker’s Fab spline mesh tool supports ISM and HISM fully.
- The video demonstration is tied to placing mesh types along a spline using the tool.
Main speakers / sources
- Main speaker/source: the YouTube creator (single speaker) presenting “ISMs/HISMs Deep Dive”, and the author of the referenced Fab spline mesh tool.