Hierarchical Instanced Static Mesh (HISM) not rendering in 5.5.1 until Editor UI is clicked

General Issues and Bug Reporting
1

Summary

Hierarchical Instanced Static Mesh (HISM) issue in 5.5.1 HISM models not rendering until the UE editor viewport border is resized, clicked, or an editor UI element is clicked.

Please select what you are reporting on:

Creative

What Type of Bug are you experiencing?

Assets

Steps to Reproduce

Presumably, developers have access to my Marketplace asset (Floxy v1.05).
If so,
(1) open the ‘Floxy Stress Testing’ map
(2) Press PLAY and enable the ‘Show UI’ check box
(3) With the default [Native Agents] option selected, click [50] to spawn 50 HISM agents.

Expected Result

50 HISM agents (white arrows) should be spawned immediately as they always have prior to UE 5.5.1.

Observed Result

Even though the agents are spawned ‘programmatically’, they are not rendered for some reason …UNTIL you click anywhere outside of the UE 5.5.1 viewport,
e.g.,

  • click the viewport resizing border
  • click the UE editor’s Outliner tab
  • click a blank area of the UE editor
  • click an item in the Content Browser.

It’s as if the spawned HISM data is not updated until the editor has received some event.
I have no idea why that would suddenly be the case, but it only started with UE 5.5.1.
(Note: the bug only inhibits ‘dynamically spawned’ HISMs during PLAY).

See the linked video for the recorded repro.

Platform(s)

Windows 10 Home
Version: 22H2
OS Build: 19045.5247
Windows Feature Experience Pack 1000.19060.1000.0

System Information

Operating System: Windows 10 Home 64-bit (10.0, Build 19045) (19041.vb_release.191206-1406)
Processor: Intel(R) Core™ i5-9400F CPU @ 2.90GHz (6 CPUs), ~2.9GHz
Memory: 16384MB RAM
Available OS Memory: 16326MB RAM
DirectX Version: DirectX 12

Display Devices

Card name: NVIDIA GeForce GTX 1660 SUPER
Display Memory: 14128 MB
Dedicated Memory: 5966 MB
Shared Memory: 8162 MB
Driver Name: \System32\DriverStore\FileRepository\nv_dispig.inf_amd64_0afec3f2050014a0\nvldumdx.dll,

Driver Version: 32.0.15.6094
Feature Levels: 12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1

Video

Repro video:
https://1drv.ms/v/c/518700558eb31581/EUFPoyMZzM1Kvdu2a6DoiIMBpeyskCj6MfPZmJfkOzHhVQ?e=BHwTJR

Additional Notes

Repro video clearly shows the issue, comparing UE 5.4.3 (working) and UE 5.5.1 (not working)

2

Hi, I haven’t seen this behavior in 5.5 (I haven’t got Floxy but have been testing HISMs)

I just made a test scene, a simple BP with a HISMC and a function to spawn 50 cube instances, then another BP with a “CallInEditor” function that gets all the first BPs in the level and calls the Spawn function (so that the construction only gets called on the 2nd BP in the level) - it seems to work correctly.

How are you spawning the instances? Does a simple test like this work ok on your hardware?

image
image1456×769 161 KB

image
image1477×370 69.3 KB

1 Like
3

Yes, I use the same method as you to initialise my HISM component.
I then call [Update Instance Transform] in the [Event Tick] path to update the rendered HISM objects.

It’s weird.
My asset is working, but for some reason in 5.5.1 the ‘spawned’ HISMs only appear after clicking a UE editor UI element ‘outside of the viewport’ as shown in the video link.

Why would that make the HISMs suddenly appear? No idea, but UE 5.4.3 and before never had this issue.

Note: this isn’t a [x]‘Mark Render State Dirty’ issue.
Just as a sanity check, I checked/unchecked the option on all my [Update Instance Transform] calls, but it made no difference.

I don’t think the issue is with my blueprint (I can’t see how), nonetheless, I will strip down my blueprint to it bare minimum functionality to replicate the issue in a very basic project.
Hopefully, UE dev/support will investigate and have some thoughts about what is going on.

1 Like
4

I can confirm I’m also having this. This doesn’t happen in 5.1 through 5.4.

Thanks for reporting and hopefully Epic fixes this shortly.

1 Like
5

Thanks for confirming the bug. :+1:

Are you using my asset (Floxy) or your own asset/implementation?

It would be supportive confirmation to Epic if the issue is also ‘independently’ affecting your project.

I submitted a bug report back in December (Case # 16208557) but haven’t heard anything yet.
if you haven’t done so already, it would be helpful if you also reported your own bug to Epic so there is more attention on the issue.

6

My own implementation and I can confirm I’m having it with different assets, including the default sphere and box, but also some vertex animated models.

1 Like
7

Hi. I had a similar issue and dug into the code to figure out what’s happening.
It seems like the HISM tree doesn’t really finish building if you add an instance and immediately try and update its transform, because it’s building Async by default.

What I did was to force the tree to update synchronously the first time an instance is added using:

if (HISMComponent->GetInstanceCount() == 1) {
    HISMComponent->BuildTreeIfOutdated(/* Async = */ false, /* ForceUpdate = */ true);
}

(Although ForceUpdate=true doesn’t matter because the tree is already out of date after you add an instance and will force an update anyway)

You don’t need to do this on Tick - just once after you add the first instance (or multiple instances using the AddInstances function) and let it async build for all future instances.

I’m not sure, but I believe the instance suddenly pops in when you click outside PIE is because the Async build finally updates the tree when your tick gets suspended for a bit.

Unfortunately, this function is not Blueprint callable, so won’t be available to call in Blueprints - only C++.

Cheers.

1 Like
8

Thanks xenlock, that’s an insightful investigation.

Yes, I’m using strictly blueprints, so I’m basically stuck, until the devs get to my bug report (if ever).

I did try several hacks, everything from trying to force a HISM update in [Event Begin Play] to [DoOnce] in the [Event Tick]. As you’ve identified, the problem is at code-level so probably nothing I do in a blueprint will overcome it. :frowning:

Did you post a bug report or just stuck with your code workaround?

9

I didn’t realize it was a bug and thought it was an optimization initially. If it’s a regression and you’ve reported it somewhere, please PM me a link and I can add details for a dev to look at. I tried looking through the git history of the HISM component but I didn’t find anything there that’s changed since 5.4 that would cause this, so the regression was introduced somewhere else. Cheers.

1 Like
10

I submitted the issue on 30dec2024:

Case # 16208557: Hierarchical Instanced Static Mesh (HISM) not rendering in 5.5.1 until Editor UI is clicked has been received

“Thank you for your bug submission. We will review your case and will follow up if more information is needed or a ticket is created. In the event the issue you reported is scheduled for a future release or has known workarounds, you may not receive a follow-up message from our team.”

However, I haven’t yet received any other feedback or a tracking reference.

The only place I know about for reporting issues is in this “Issues and Bug Reporting” category, where we already are.

11

I narrowed it down to this commit, which makes it a regression:
https://github.com/EpicGames/UnrealEngine/commit/dffdccfd8f867ee54833e135ea08ca7ae1c61210

Backing it out on my local build fixes the issue. From the code commit, it would seem that the intent was to move the logic to apply the result of an Async tree build to the game thread, but ExecuteOnGameThread() seems to want to work when there’s some time between Ticks which isn’t the case here, because we’re constantly updating Transforms in the tick. So the BuildTreeAsyncResult never gets applied until whatever is consuming the Tick pauses for a moment (which is why when you click outside the PIE window, the Tick suspends for a bit and lets the game thread pick up enqueued functors and you see your instances pop in).

I think another fix is required to either make sure the Tree is force-built first or that rendering a Tree which is being actively async-built accounts for this.

Hopefully an Epic dev can pick this up - unfortunately I have no way of running a proper regression test to be able to submit a PR for this.

2 Likes
12

Thanks xenlock.

The question now is how to get devs eyes on the issue, even if just to enter it into the bug tracker.
You’ve provided some important already, so hopefully someone at epic will look into it.

I will email support again to try and at least put the issue on the radar. :+1:

1 Like
13

Maybe we could open a pull request on Git?

14

Maybe we could open a pull request on Git?

I’ve never done one before.

What would be the objective, and would it have any effect on bringing the issue to the attention of the devs w.r.t. a resolution?

15

If you guys are stuck using Blueprints, you could also possibly use another workaround where you delay by a frame or two before you start updating the transforms. I think a Delay with value 0 after you’ve added all your HISM instances ought to do it. Small 1-2 frame delay should go unnoticed for the most part.

16

I think a Delay with value 0 after you’ve added all your HISM instances ought to do it. Small 1-2 frame delay should go unnoticed for the most part.

Interesting suggestion.

I previously inserted a [Delay] node (testing from 0.01ms up to 1000ms as a [ DoOnce] call on the [Event Tick] and also on the Event [Begin Play]. Unfortunately, it didn’t make a difference.

However, I didn’t think about adding the delay ‘just after’ the [Add HISM] call itself.
It’s worth a try. I’ll give it a go and report back.

17

Report: No joy.

I added a [Delay] immediately after my [Add Instances] node and tested 0.0, 0.001, 0.01, 0.1, and 1. Unfortunately, it didn’t solve the issue.

Perhaps Blueprints have a different level of indirection that don’t execute exactly like the C++ equivalent functions.

Nonetheless, (as you alluded to in an earlier post) it definitely has something to do with the HISM tree not updating unless some other event tells it to refresh, in this case, the arbitrary clicking of the UE Editor borders, content browser list, tabs, menu items, etc.

18

By investigation/chance, I managed to find a workaround.

Given that UE5.5 HISMs were broken with no feedback on when it would ever be addressed, I wondered if either ISMs, ISM batching, or HISM batching were equally broken.

With very low expectations, I swapped all my HISM components with equivalent ISM components, and to my surprise - the HISM rendering issue went away?!

I didn’t even bother to test the batching alternatives; I was happy that my 15 minute investigation actually solved my problem so easily. I don’t know why I didn’t try ISMs months ago, but probably because I was waiting for feedback/resolution from the devs.

As far as I know, the difference between ISMs and HISMs is the latter uses LODs.
HISMs are good for mesh instances (e.g. building, tracks, etc) that span large distances and you want the distant meshes to render with a lower LOD for better performance.

Luckily, my asset doesn’t need LODs at all so ISMs saved the day.

19

Oh god it seems to be even worse in 5.6!!!

So in my case, this is for a plugin I’ll release on Fab shortly. I’m not using Blueprint but this is a MassEntity plugin so I cannot play with the delay. Instances get added at any time depending on initialization and spawning of tons of entities.

This really needs to be fixed. I’ll see if I can find time to open up a pull request.

20

(post deleted by author)