The headline is the question:
SM, ISM, HISM, Lightweight Instances and UE5 Auto-Instancing - a lot of possibilities but what are the differences? Is there a comparison? Is there a recommendation for use?
3 Likes
forwarding
Hi vicbrother and Omarito,
Hereās a quick overview:
SM - 1 drawcall per material in the mesh, per mesh.
ISM - 1 drawcall per material, that drawcall renders all ISMs. ISMs have LOD issues for non-nanite. When you remove a ISM from the ISMC, you have to reorder all indexes if youāre referencing them.
HISM - same drawcalls as ISM. LODs are better, when you remove an HISM, the last index in the list is put where the removed index was so all other indexes remain true.
Lightweight Instances are an experimental thing - they work in the same way as foliage. Iām not sure how they act with World Partition. I havenāt actually been able to get them to work properly.
Auto-Instancing - this is a Mobile thing and again, Iām still to see it actually working.
Thereās also Foliage Instancing - that is a layer on top of HISMs and they have cluster culling which has potential.
All but the Foliage Instancing ignores WorldParition. To get around it, the common practice seems to be create a ISMC or HISMC in every blueprint used for instances - this is not efficient by any means.
To get the best speeds, you need to create your own (or use an existing) ISM or HISM manager that takes care of all instances in your level.
To see the differences, check out this benchmarkL
9 Likes
Nice reply and website recourse!
One note, AutoInstancing or Automatic Dynamic Instancing at Runtime, was added to mobile but has been enabled/athing since 4.22 UE.
It will, for rendering, convert all static meshes to ISMs just to render each frame. it doesnt touch the actors, you can mainly see it working via draw call totals and the CVAR being enabledā¦ Which it is, by default, since 4.22ā¦ but can be disabledā¦
You are correct, however, that scraping to your own ISM each frame is faster. But, dyanmic instancing make āstatic meshā rendering basically impossible, since if enable, they will be batched dyanmically to an ISM (with overhead to do so) each frame by the engine!
r.MeshDrawCommands.DynamicInstancing 1/0 to enable/disable it.
2 Likes
Thank you for your response, so for nanite meshes there is no difference on using ISM over HISM ? or there is things to be taken into accounts ?
1 Like
Itās pretty hard to find definitive documents on this, but as Nanite isnāt using the LOD system that ISMs used to - itās pretty safe to assume that the locked LODs isnāt an issue any more.
HISMs still have the āreplace index on removalā so their indexes donāt have to be updated. Iād say use HISMs still.
1 Like
HISM still have the underlying weight of LOD (the meshes and textures or mips to display them.) So even if nanite disabled the additional LOD work, ISMS (HISM is a collection of ISMs), you would still have the impact on memory. Using ISMs, if you are always enforcing nanite, is better than HISM. HISM used to have a culling advantage in UE4, but in UE5 ISM got that same culling, so if using nanite, ISM is king.
1 Like
I have to check into that replace-remove piece!
1 Like
I read somewhere recently that HISMs will be phased out. PCG seems to switch to ISM for Nanite meshes if youāve selected HISM - seems like ISM is the way to go - just donāt remove instances, move them to way below the level and reuse them if need be later.
Edit: In UE5.3 the UInstancedStaticMeshComponent has a bool ābSupportRemoveAtSwapā which you can set to true to swap the index with the last in the same way as HISMS.
2 Likes
Thank yoU!!!
I am also looking into using per-instance custom data on the ISM instance, to make that instance masked on the nanite material. This should allow me to pool instances to 0.0.0 and not have nanite overlap issues if all the pooled instances are fully makedā¦
1 Like