Canon Man Tutorial: Hierarchical Instanced Static Meshes - July 26th - Live from Epic HQ


In this learning livestream has prepared a mini-game, Canon Man, to demonstrate how to use hierarchical instanced static meshes. We’ll be covering adding and removing instances, the behavior of the meshes when they are removed, and how to manage parallel data using blueprints. Join us for a brick-breaking good time!

Tuesday, July 26th @ 2:00PM Countdown]



Feel free to ask any questions on the topic in the thread below, and remember, while we try to give attention to all inquiries, it’s not always possible to answer’s questions as they come up. This is especially true for off-topic requests, as it’s rather likely that we don’t have the appropriate person around to answer. Thanks for understanding!



Ohh, sweet!!!

Funnily enough I’ve been playing with these today. Hopefully the stream content will be made available online elsewhere soon after the stream so that I may review it! :slight_smile:

I’d like to see how (if possible at all) to turn off dithered LOD transitions, and hopefully HISMCs work with static lighting already.

That’s actually really good timing! :slight_smile:

Hierarchical Instanced Static Meshes save ~30 FPS in my game :cool:

this kind of canon ->

or this kind of cannon ->

… Man :slight_smile:

This kind of Canon:

It’s named after our legal counsel, , who as advised against naming the project after any games it may have any vague similarities to.

It was a good stream!!

Hey All,

So on the stream, we were trying to mess around with static shadows. Turns out the Grid Actor and all of it’s components were movable :\ Setting them to static fixed them so they’d generate and receive static shadows. With them being static, lighting built fine, and even if the components were static, it still allowed me to remove instances from the Hierarchical Instance Static Mesh Component.

While testing their removal, it appears as if the static shadows don’t move around with the instance as things get deleted unlike the changing Per-Instance Random values. Of course, cast shadows stayed put creating a number of artifacts.

If I use direct light (static) and my HISMC actor is static also, and I am in ES2 preview, HISMC is pitch black. Plus dithering kills performance.

A couple of questions:

a) did this session cover navmesh generation over HISMs? Because this seems to be somewhat problematic in 4.11, especially for C++ users; I seem to need to do ReregisterAllComponents() to get Navmesh generation to happen on newly spawned instances - UpdateComponentTransforms() didn’t work for me (as per this old thread concerning 4.6)

b) will the video be put up somewhere aftewards? I was asleep when this was on so I missed it.

Many thanks.

Heya dmo9001,

We did not cover navmesh generation. Also, the method we used to manage collision (creating and removing blocking volumes) would have caused a dynamic navmesh to update regardless.

VOD is available at Twitch

Not sure when the youtube video will be up, as there was some cross streaming hickups.

@Shaddenfreude PM’ed you

It would be awesome ! ))

Regarding that “Pre-shadow” warning message:

Hey , I watched the video and you mention that there are tutorials to make the camera zoom in and out depending of the distance between players, do you have a link?

That’s sweet…

I have a project that uses regular ISMs and they move around just fine. So how is being able to change the transform the difference between HISMs and ISMs?
The only complication I can think of is that I’m changing the ISM loc/rot in C++.

Why are you using HISM instead of ISM? The only difference between them is that HISM allows per-instance LOD, but this adds an additional overhead. In situations where per-instance LOD isn’t required like in this example, it is better to use ISM.