Download

Need info on Hierarchical Instanced Static Mesh Components

4.7 came with the new Hierarchical Instanced Static Mesh Component node, but there is almost no information about what it does, how, and what if anything we need to do to take advantage of it. Assuming it can work with normal instancing, but all the focus has been on foliage without a hint of detail so who knows how we are supposed to handle it.

From the patch notes:

Surely you could have provided more detail than this… especially since there is a nice shiny blueprint node by that name.

I’m seconding this. I’m working on a blueprint project which uses large amounts of instanced static meshes, and I’d be very interested in knowing how hierarchical instanced meshes can be used to increase performance. Under what circumstances does it lead to increased performance? Are there drawbacks compared to regular instanced static meshes?

Heh, I don’t think I have ever heard such crickets on this forum for what should be a pretty simple answer. Hopefully the GDC hangover goes away soon!

Guys? Beuller? Beuller?

J^2

I looked at the implementation a bit. It has a tree data structure that gets async rebuilt on the fly according to LODs and MaxInstancesPerLeaf var. Rest of it is basically the same as InstancedStaticMeshComponent, as it is derived from that anyway.

Afaik, you can just use it like a normal ISMC, it does the tree building by itself, just calling the AddInstance should suffice as it is overridden.

So normal instanced meshes don’t handle LOD’s at all, or just not quite the same or as well as the new version? The MaxInstancesPerLeaf sounds like something specifically for foliage, so I wonder what that would do for a normal mesh…

When I get some time from my current work I will see if I can push it to the limits and compare that to my current setup to see if I see any difference.

Thanks for the info!

Leaf in this case is just the name used to represent the bottom node of the tree structure, so not foliage related at all, as Chariots pointed out, its derived from the existing InstancedStaticMesh classes, so anything it could do, the Hierarchical can do it better. As for LOD’s not sure if existing instancing could, but this one also has smooth transitioning between the different LOD levels (rather than a popin).

I did do a small test of it last weekend, and was able to push the hierarchical to about twice or three times as many instances as static before I started seeing a significant drop. Now this isn’t a terribly reliable test as all instances were in view at all times, and they model used was not indicative of what you would normally use instancing for, but the results seemed significant none the less.

That sounds promising.

I wonder if there are any cases where Hierarchical might be worse, or if they are just an all around upgrade from the previous instances.

ISMC does the LOD transition per cluster, whereas HISMC can do per mesh LOD (dithered) transition, because it rebuilds the tree on the fly (afaik).

It’s been a couple weeks and still no details or docs on this node. Looking at the details panel and it doesn’t look any different then an instanced static mesh component. So, how does this allow for millions of instances vs the standard ism? Basically, we just want to know how to use the ******. Surely a simple demo project showing how it differs from a standard ISM can’t be that hard to knock together is it? Cheers,

J^2

Let’s say you’ve made a race track with a single InstancedStaticMeshComponent. Due to the nature of the ISMC, it’ll draw all of it in one chunk, and all of it will be on the same LOD level. So if you have 2 LODs, and get close to the track, at all times it’ll draw the highest detailed LOD for the entire track, no matter how small the part you’re seeing.

If you were to make that with HeirarchicalStaticMeshComponent, it’ll transition the parts that are close to you to higher LOD (as per mesh LOD screensize setting*), while keeping the rest of the track in the lowest LOD possible.

Example scenario: You’ve made a race track with 100 parts, highest LOD has 1000 triangles, and lowest poly has 50 triangles. In ISMC, if you get close to the race track, it’ll draw 100x1000=100k triangles at all times. If it were HISMC instead, and you were only close enough to change 5 parts’ LODs, it would draw (5 x 1000) + (95 x 50) = 9750 triangles.

*One other benefit of HISMC is that LOD screensize setting actually works. ISMC treats all of its instances as 1 mesh, so the screensize setting evaluates the entire structure, and you end up having to make another setting for the meshes that you use with ISMC. While HISMC transitions per mesh LODs without treating the entire structure as 1 mesh.

Other than that, both functions exactly the same way. HISMC is a subclass of ISMC. You still use the AddInstance and RemoveInstance on both.

And to add to the above excellent overview. HISMC dither on LOD transition which helps to ease the transition rather than a popping effect.

HISMC vs ISMC

ISMC’s render all of their instances or none of them (if they are offscreen or occluded). HISMC’s are internally culled so that if most of the instances are off screen or beyond the cull distance, then most of them are not rendered.
ISMC’s choose one LOD for all instances; this does not work well. HISMC’s internally make LOD decisions so some of the instances can be at each LOD.
HISMC’s supported dithered temporal LOD transitions; no popping.

HISMC’s in 4.7 do NOT support occlusion culling very well…as well as ISMC’s, but the problem with 4.7 has to do with the foliage tool. In 4.6, the foliage tool would create multiple ISMC’s and these would be culled (including occlusion culling) as normal. The number of ISMC’s created was related to the cluster size. For small instance counts this could work quite well. For a million instances, clusters would be both too big and too small; you would neither get good culling, nor good CPU performance. With HISMC’s, this is fixed; there are no clusters and the foliage tool only creates one component, however, that means all million instances have only one occlusion query; so if you are in a cabin in the woods you are still going to be rendering the entire forest. This is fixed in 4.8.

HISMC’s remain a bit rough in 4.7 but they should be usable and unless you have very few instances with no LOD occupying a small part of the world, they will be superior both for CPU and GPU costs…though dithered LOD transitions are not free.

-Gil
epic

Hey Zeustiak,

Thanks for noticing we didn’t have adequate information on our new Hierarchical Instanced Static Mesh Component Node. I have requested that documentation be written up about this. If for any reason you need to reference this report in the future, please refer to: UEDOC-1423

Thank you!

Thanks! :slight_smile:

I think I missed this when you posted it, so I apologize.

The problem we are having is that we are trying to use the HISM node, but FPS drops from 55 to 6 with a mere 30K HISM trees in the world. Each is a speed tree with 3-4 LOD’s all the way down to the billboard. The LODs transition, and don’t seem to make a difference on FPS, whether the trees are in billboard or not.

It seems like we either don’t know how to use the node, or it is broken in blueprint.

We use the AddHISMComponent node, then use it to set a variable of the HISM type. We then feed that into AddInstance. It should be pretty straightforward, yet the results are pretty bad.

whenever I try to create a HISM node in a blueprint it crashes for me.
what is the proper workflow, the same as ISM? add hierarchical instance then set static mesh? do i need to press the + on the instance array inside the HISM node? that’s where it crashes for me.
any advice.

Yep, if you do not specify the StaticMesh in the StaticMesh Group in the Details panel of the HISM node in a blueprint - you get Editor crashed!
So, firstly set the StaticMesh, then add Instance and here you go.

I don’t know whether this is working the way it should.

I have a HISMC and there are some speedtree trees inside. They are moving with the wind.

But every time I add a new tree to the HISMC, the wind movement get’s reset to 0. This is how it looks with one new tree per second:

I need to add and remove trees while the game runs, not only 1 per second but more like 10 per second. Then it looks as if there would not be any wind. How can I fix this? :frowning:

I’ve uncovered the same issue - have you tested it with no collision on the HISMC? When there’s no colliders the performance is phenomenal! However, it would appear that the HISMC does not cull colliders and therefore even when it is completely culled, or LOD’ed out to a mesh with no collider you incur a massive cost because colliders still are present on each instance even the culled ones. I confirmed this because I was able to trace to an HISMC that was completely distance culled.