What makes ISM cheaper than HISM?

Development Programming & Scripting
, , , , ,
1

I made a lot of tests involving ISM, I was convinced that ISM was cheaper than HISM for a long time.
I made some tests back in the days regarding this, and I remember ISM coming out winning.
I dont recall exactly what it was now, but i think it had to do when moving them.
Recently i made another test and HISM came out winning with 10x better performance…
Maybe something changed in the engine.
Could anyone explain exactly why and how is ISM more performant than HISM, if it is?

Here’s the things i already know from my research:
ISM vs HISM:

  • Contrary to popular belief, ISM has LODs. The only difference is that ISM Lods apply to all instances and are calculated from the center of the ISM component.
  • ISM doesn’t do per instance culling.
  • HISM does Per instance Culling but it calculates all the LODS individually on each instance…

Now i think there is a difference when animating them.
Thats where i think the performance difference makes it worth it to use ISM rather than HISM.

In general it is recommended to use HISM if you are working with lots of objects spread all over the map.
But if you are working on clusters/groups of objects that are specific to one area, then ISM will do fine.

So if you have a group of cards on top a table, then a group of cookies, then a group of coins. All of these could be ISM and since they are separated but contained in their area their LODs will work for the whole group.

But if all of these were spread accross the room chaotically then their LODs would not work properly…
If that makes sense…
Anyone could give me more insight in this?
Why exactly is the ISM cheaper than the HISM, if it actually is?

2

Another difference is that HISM has distance culling for it’s clusters.

For it to work the material needs Dithered LOD Transition to be turned on.
Edit: ok so ISM seems to have it too now in older versions it was just in HISM.

1 Like
3

So at this point im quite confused whats the benefit of using one over the other. It seems like HISM is always better. Even if we use ISM for small contained groups as i explained above…is there any actual benefit to that?

4

Well hism is an evolution of ism. Its probably being kept around for legacy reasons.

1 Like
5

yup, look at this ism is not culled by frostum. though hism is.

6

ISM is a flat instance buffer. It is fine for a few thousand instances when materials are few, bounds are tight, and updates are rare. Past that, the render thread and instance buffer updates become the choke point long before the GPU runs out of shader throughput. HISM adds a spatial tree and clusters that cut draw submission and cull work.

It also plays better with GPU Scene so visible work scales with what is on screen, not with total count.

Treat 5k as a sanity marker, not a hard rule. The real break point depends on material slots, per instance custom data size, average bounds size, camera motion, and how often you mutate transforms.

Level 1

  • Use ISM for < 5000 instances
  • Control MarkRenderStateDirty()
  • Preallocate with Reserve()

Level 2

  • Use HSIM for > 5000 instances
  • Enable GPU Scene
  • Batch by spatial locality

Level 3

  • Profile MDC cache misses
  • Custom instance culling
  • ISMPool for dynamic scenarios
  • Consider your own batching/clustering sauce.

First, it does not promise a single draw no matter the count. Materials, shadows, and depth only passes still create multiple Mesh Draw Commands. Second, do not spam MarkRenderStateDirty on HISM. It defeats the spatial structure and turns edits into frame hitches. It’s original design was for foliage etc stuff that rarely changes once pushed onto the scene.