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

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!

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.

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

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.

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.

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.
[/QUOTE]

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.

Hmm, I will have to check on that. And you mean collision on, or even just having a collision mesh? Don’t need any collision whatsoever for these trees either way.

I finished an extensive tutorial on Hierarchical ISMs yesterday. A lot of setup tips & troubleshooting included. So I hope it makes some things more clear

https://.com/watch?v=oMIbV2rQO4k

Very informative. Thank you!