[BUG]UHierarchicalInstancedStaticMesh->RemoveInstances breaks PhysX

Included is a small repro project using blueprint, though I first encountered the issue in C++ Dropbox - BugRepro.zip - Simplify your life

Build Type: Binary

Build version: 4.12.5-3039270+++UE4+Release-4.12
Mac OSX 10.11.1

Description: Using UHierarchicalInstancedStaticMesh->RemoveInstances (and likely UInstancedStaticMesh->RemoveInstance) causes collisions and NavMesh calculation to be incorrect, and for log spam to appear as follows:

LogPhysics:Warning: PHYSX: (./../../LowLevel/software/src/PxsAABBManager.cpp 540) eINTERNAL_ERROR : A PxAggregate has exceeded the limit of 128 PxShapes. Not all shapes of the aggregate will be added to the broapdhase
LogPhysics:Warning: PHYSX: (./../../SimulationController/src/framework/ScElement.cpp 107) eINTERNAL_ERROR : Unable to create broadphase entity because only 32768 shapes are supported

Repro: Criteria to reproduce bug is that active instance count is >= 128.

If you delete 1 instance, you’ll hit the bug. Delete another 1, no bug. Delete 2, bug. Delete another 2, no bug. Delete 3, bug. Delete 4, bug. Delete 3, no bug.

Bug can also manifest with random sampling when deleting one at a time, but I have no consistent repro steps.

Adding a new instance after hitting the bug corrects collision/nav issues which is an ok workaround for now.

When run, included repro project will delete increasingly large blocks of instances every 1 second, from a starting pool of 512. Open the output tab to see the log spam. See “Meshes” blueprint for logic.

Hi steveorsomethin,

Thus far I have not been able to reproduce this on my end.

  • Does this occur in a clean, blank project with no additional content or is it limited to one project?
  • What steps can I take to reproduce this error on my end?
  • Does this only occur with Hierarchical instance meshes or have you been able to reproduce this with Instance Meshes

Keep in mind that Instanced meshes and Hierarchical meshes were not designed to be updated dynamically. Each time an instance is added or removed, the blueprint is destroyed and recreated.

Hi , thanks for the reply.

Even the included project in the linked dropbox folder doesn’t exhibit the behavior? I actually started an entirely fresh project for the repro just to make sure it wasn’t something weird about my setup. Just running the project should be adequate to repro since it adheres to the requirements that there be >= 128 instances and an increasing number of instances are deleted with every iteration.

I saw the behavior in my original project with InstancedStaticMesh, which makes sense given they follow a very similar path. I was just sorting instances and removing in a loop, which it looks like HierarchicalInstancedStaticMesh does as well.

FWIW I’m using C++ in my real project, and the source of (Hierarchical)InstancedStaticMesh looks pretty sane for the Add/Remove instance cases. I’m comfortable with the performance, more worried about the fact that removal from a relatively small set of instances breaks navigation and physics. I could just ClearInstances() and re-add everything with every change, but that seems a little funky vs a raw dynamic vertex buffer.

Does this sound similar to what you are experiencing?

These look similar, and if so there is a bug report already in for this, located here. This is currently backlogged, but if this is what you are experiencing, I’ll make an internal note that it is still occurring in 4.12.5. As stated in the other thread, however, this may be intended functionality and a limitation of the instanced mesh system.

I think they’re similar with respect to the 128 instance requirement, but that one seems to occur when adding rather than removing. Worst case I’ll probably dig into this and submit a PR if my workaround ends up becoming too expensive.

I’d want to verify dynamic updates are truly not supported however, since RemoveInstance(s) are begging to be used, and if not dynamically then when? If they’re truly not supposed to be used I’d argue they should be deprecated or assert and error past a certain lifecycle, but then that would drastically limit the use of Instanced Meshes.

Instance mesh behaviors, including adding and removing, are intended to be used in the construction script. They are meant to be placed, much like foliage, and then remain during PIE.The construction script and functionality within the construction script are inherently designed for modular/procedural placement in editor. While these instances can be updated at runtime, it is not the recommended workflow and highly prone to these types of limitations. For now, I am going to mention this in an internal note and mark this as answered for tracking purposes.

This bug still persits in construction script, not only in PIE. I remember trying this in a clean project and reproducing it a while ago.

I have built my entire game around using this as HLODS are very desirable vs normal instacing, and the normal instancing works perfectly.
This is something I have been tracking for literally years now! I need it for my game to work, simple peformance numbers. A ticket alone has 10 votes: Unreal Engine Issues and Bug Tracker (UE-40693).

My system just stops functioning if i simply switch from normal to Hierarchical instanced meshes. I was planning on a fix being found and building my system anyway, as it looks like a bug and you are able to implement HLODS in blueprints.

This has been going on for so long, and im trying to get to the point where I can profile peformance and frame rate, where this difference in an entriely procedural game really matters.
Can you finally get someone to look at it please? I feel this is something you can fix with work. Saying HLODs have limitations in removal feels like a poor excuse to just not have someone look at it, and a bug flag has already been made…