Only the first 128 instances of an instanced static mesh have collision when spawned in a blueprint

Running 4.4.3, Win7.

I’m spawning instanced static meshes via an actor blueprint using the “AddInstanceWorldSpace” function, and once I reach 128 of them, no subsequent instances spawned in that blueprint actor have collision. They do not collide with the player, nor do they generate trace events.

~I’ve tested this both with using simple collision as complex, and also with simple collision boxes.

~I’ve confirmed that once you hit the 128 limit, you can spawn a different set of instanced meshes within the blueprint and they will have collision for the first 128 copies.

~The issue does not exist if you set the instanced mesh to be static and not movable.

This is severely limiting the usefulness of instances, because you can’t manage or delete them unless you can get a ref to them by tracing.

Hi Hyperloop,

Does this occur on a blank project with no additional content? How are you spawning them in (dynamic, manually placed, etc.)?

Adam - I wasn’t aware that you could manually place Instanced meshes outside a blueprint? Is that possible??

Anyway, in terms of if it happens in a black project with no other content: yes, it does happen.

Here’s the error message from the console that may be related:

" LogPhysics:Warning: PHYSX: …\LowLevel\software\src\PxsAABBManager.cpp (541) 32 : 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 (112) 32 : Unable to create broadphase entity because only 32768 shapes are supported"

This error only seems to pop up after the 42’nd instance is created for me though.

Regardless, the 128 instance limit on collision for movable meshes seems to be predictable and reproducible across projects for me.

Here’s the pastebin of my node setup, in case you want to test it out yourself (you’ll have to replace a couple variables though)

The 129’th block on the end of the row won’t have collision.

Ah I missed the “instanced” in the description, my mistake! Are you calling these in the construction script?

I’ve tested calling them both in the event and construction scripts, the behavior is the same.

Here’s the quick and dirty node setup:

I just came upon this problem trying to loop thru all the instances in a InstancedStaticMeshComponent. When hitting the 129 instance in the loop (index 128), it crashes. Mine component was set to Movable, and this is fixed when setting to Static as you said, but I’m curious why that’s happening also.

Can confirm that when setting it to static it is fixed. This does make instances of limited usefulness however since it would be nice to be able to move them on many occasions.

Hi Hyperloop,

I have been able to reproduce this effect on my end and have entered a bug report, ttp#348924 to be assessed by the development staff. For now, please use static meshes instead of instanced static meshes until we can get to the root of this bug. Thank you!

Is there any public way to check the status of these bug reports? I just tried testing again in 4.5 and it still crashes.


Hi Ruffian,

Currently we do not have a public location where users can check into the status of bugs.

I have one more question about speed… I have a simple grid of these instanced static meshes, all updating positions every tick with [UpdateInstanceTransform][1], simply oscillating their Z-values. I did some profiling because you can see in the screenshot below, the frame time when the grid is 41x41 squares is pretty extreme. The profiler says the rest of the app is basically waiting for the “Phys SetBodyTransform” to finish, which takes ~50ms every frame, and is called 1681 (i.e., 41x41) times. I was wondering if it’s a bug that it’s this slow of a call, or if it really is just gonna take that long to update that many instances.

Hi Ruffian,

A lot of that lag will have to do with your hardware, but otherwise it is going to be fairly normal for it to take a bit more time with that many instances being spawned at the same.

Hi Adam, this bug is still in 4.7.6 :frowning:

If it is appearing again it may be a regression. I will try to reproduce this on my end tomorrow and see what I find. Thank you for the update.

Thank you for staying on top of this, it would limit the usefulness of instanced meshes severely if we can’t track this down.

How many instances are you spawning at one time when this occurs? I just attempted an instanced mesh blueprint with 500 actors in it and all had collision as intended. Do you have repro steps I can take to reproduce this on my end?

You tried an instanced mesh blueprints with 500 Actors in it? I don’t really get what you say, do you call Instances “Actors”?

Just create an Blueprint, add an Instanced Static Mesh Component (I use the Hierarchical Instanced Static Mesh Component) and add 500 Instances. Once you exceed 128 instances your output log will get spammed with the PhysX Warning.

Adam, I posted a screen cap of one possible node setup you can use to repro this higher up in the thread.

I apologize, I used incorrect terminology. I did mean to say instanced meshes. Here is the setup I used:

I attempted this with the Hierarchical Instanced Mesh Component as well and received the same results. Collision worked on all objects and no errors appeared in the Output log. Are you using a specific mesh that is creating this error or does this occur in a new, blank project with base assets?

I used the tree from the kite demo for my tests, did your mesh had collision set up?