Collision extremely slow on instances

[Hyperloop]

Win 7 64 bit, UE 4.8.1

I’m sorry, there’s a lot to parse through here, I’ve updated this as I continue to explore the issue which uncovered some additional potential bugs which I’ve also made note of here for now.

Problem:

I am spawning a number of instanced static meshes via blueprint. Performance is quite good while the player character is stationary but whenever the player moves, the framerate drops from 90+ to 2-3 FPS. If I turn collision off on the instances I do not see the same drop in performance and the game runs at a consistently high rate. I think I have narrowed down the culprit via the profiler:

Additional Info:

-I’ve tested with several collision types, a simple collision cube as well as using complex as simple.

-The meshes I am instancing are extremely simple and consist of few polygons.

-Visually rendering the instances takes almost no time at all where collision is not concerned.

I’ve attempted to test with both movable and static instances but [due to different bug][2], static instanced static meshes cannot be spawned without crashing the editor.

Edit 1: I’ve discovered that ANY movable actor with collision moving in the scene causes this slowdown. If nothing in the scene is moving the framerate is great. If anything with collision moves, the framerate tanks. I double checked the usual suspects with stuff happening on tick in my logic, etc and those things are not causing any issues, I can run the game at 90fps without collision or when the player is not moving.

##Troubleshooting:

Tested using HISMC’s instead:

Result:
Even with aggressive culling I did not see an improvement.

Uncovered possible secondary issue with HISMC’s: Culled HISMC’s seem to still create collision overhead? That seems consistent with what I am seeing here because:

1. I can trace to a completely culled HISMC
2. I see similar degradations in performance in respect to the collision regardless of HISMC culling settings.
3. If I explicitly turn collison OFF on the HISMC’s I do not see the fps degradation.

Given that the biggest overhead with instances appears to be related to collision, I strongly suspect that it is not intended behavior - there would seem to be little point to only culling HISMC’s visually but leaving the collision.

Manually Turning collision on only around the player:

Result:

Framerate improves overall however

1. There is a large lag spike every time collision is turned on in the immediate area of the player.
2. This only sidesteps the terrible collision performance, it does not solve the underlying bug with colliders lagging so heavily.

Even still, I think this could be a viable solution IF there’s a way to avoid the frame hitch when turning on colliders. Do you have any thought on how this might be avoided?

Thank to for looking at my wall of text!

[anonymous_user_b9532c9a]

Hi ,

How many instances are you spawning in before seeing the collision error occur? Are the meshes you spawn using LODs? If yes, do you have collision on all of your LODs or only on the instanced meshes with LOD 0 active?

[Hyperloop]

Hi , which error are you referring to, the general slowdown related to instances and collision, or the second error where HISMC’s don’t seem to cull collision?

To answer the first: The slowdown seems to progress in a linear fashion and becomes quite drastic once around 20-50K instances are in the scene. The same scene renders are around 90 fps if the instances in question do not have collision and at 1-4 fps when collision is on and the character is moving, or when any object with collision enabled moves in the scene.

If you were referring to the HISMC collision not culling I believe I tried it with something around 2-3k instances. Here are several configurations I tested and the results:

1. HISMC’s with no LOD and collision on. Result: could trace to invisible (fully culled) instances and observed the same collision slowdowns regardless of how many instanced were visible/culled. (I cranked the settings down to the point where only one instance was visible with no framerate improvement)

2. HISMC’s With LOD 0 collision on. LOD 1 collision off Result: same behavior as above with the exception that LOD1’s could not be traced to (which is of course expected since they do not have colliders).

3. HISMC’s with collision off Results: same as with ISMC’s, frame rate is phenomenal with no hitches or slowdowns.

[anonymous_user_b9532c9a]

These have to do with both actually. The reason I ask is because any LODs past 0 probably should not have collision, if anything, tracing by a different channel would be your best choice. Each instance of a mesh generates collision twice and adding a large quantity of instances into your level will cause an expected drop in framerate from the sheer quantity of data being generated. Your best bet would be to keep the distance at which you have LOD 0 very close to the player so that it isn’t bogging down your system. If you set your trace to another channel as opposed to visibility/collision (try something like a custom channel for foliage specifically), does the framerate still drop the way you described above?

[Hyperloop]

So to be clear, I don’t actually need to trace to them, I was simply using that as a test to see if the collision was culling. Sorry, I probably didn’t explain that very well.

I can absolutely understand why having a ton of collision meshes in the level could cause a slowdown, but what seems to be happening is that the collision isn’t culling when the HISMC culls.

Yes, I tested it with the culling setting set very aggressively so that only the instance directly under the player was visible and it made no difference to the performance in respect to collision.

I also tested without running traces just to be sure that wasn’t the issue.

Thank you for the help, I really appreciate it.

Edit: as an aside - where could I find more info about collision generating twice on each instance, curious what the reason for that is. Also, I wasn’t aware that it was possible to trace to objects without collision, that’s pretty interesting.

[anonymous_user_b9532c9a]

Hi ,

I misspoke earlier. I meant to say that it renders polygons twice, not collision. Are you using imposter sprites for your HISMC that are far away? Additionally it is a known limitation that culling does not remove collision from components. Try utilizing the suggestions located here:

https://www…com/watch?v=-csRxRj_zcw

[Hyperloop]

Hi , thanks for the reply and the additional info. - haven’t gotten as far as testing sprites - visually, I’m able to get the performance I need even with LOD0 - the collision is the bottleneck, not drawing the frame (I get 90fps without collision). If I’m understanding correctly even LODing out to imposter sprites wouldn’t remove the collision so that won’t help the bottleneck.

Do you know if there are any plans to enable removal of collision when HISMC’s are culled?

I’ll check out the video you linked as well, again thank you for the info it is helpful to know that this is known behaviour and not a bug.

[anonymous_user_b9532c9a]

Hi ,

I entered a feature request, UE-19739, to be considered by the development staff to disable collision on HISMCs that are culled out.

[Hyperloop]

Hello , just wanted to check in and see if this either made it into 4.9 or if there are any other updates on it. Thank you.

[anonymous_user_b9532c9a]

Unfortunately this has been marked as “Won’t Fix”.

[Hyperloop]

Understood -

I suspect there may be some technical reasons involving nvidia physx that make changing this behaviour either difficult or ill-advised. -Since collision is such a huge part of the instanced mesh bottleneck it doesn’t seem to make much sense not to give us control over culling them unless there’s a good reason.

Let me ask you this: Is there any possibility we could get some insight into the rationale for leaving the behaviour as is? This would be most helpful because I’ll probably need to task a programmer to change this on my end so if there’s some larger technical issue at play here that you are aware of, it would be extremely helpful to understand.

Here’s my email in case you’d prefer to discuss offline: trevorjlee AT gmail DOT com

as always, thank you for your time!

[anonymous_user_b9532c9a]

Hi ,

There were concerns raised that deactivating collision on physics objects could potentially have negative consequences. The nature of culling is specifically designed to removing rendering and was not intended to affect object interaction. This could become especially problematic with networked titles.

[Hyperloop]

That’s helpful, - thank you for taking the time to explain.

I’d like to push back on one aspect of that at least slightly:

The static mesh LOD interface already allows us to define collision per LOD level, and HISMC’s currently break that functionality. If HISMC’s respected the LOD settings that are already in place in regards to collision, then developers would have the control they needed to make the choice that is right for their title.

Currently, the interface leads users to believe that HISMC’s should be using each LOD level’s settings for collision but that is not the case.

Since the functionality already exists in the interface for static meshes, and one of the primary advantages to HISMC’s is per-instance LOD levels it seems very odd that this particular aspect of the LOD functionality is missing/broken when used with HISMC’s

EDIT: actually, this is broken for static meshes too I just checked it and only LOD0 collision is used regardless of LOD level and irrespective of the checkbox settings.

Thank you again.

-Trevor

[anonymous_user_b9532c9a]

Hi ,

Are you referring to LOD transitions in 4.9, specifically for HISMCs? If so, this has been reported and fixed in UE-20297, though I do not have a specific timeframe of when it will be incorporated into the editor.

[Hyperloop]

I tested in 4.8, but yes at the time each LOD level would still only use the collision settings for LOD0 so if, say LOD1 was set to ‘no collision’ then it would still collide because LOD0’s collision was still active.

If this is indeed being fixed then that’s super awesome news. Being able to truly set the collision meshes and setting per LOD gives us all the flexibility we need.

[Hyperloop]

So just to confirm: the LOD system SHOULD be respecting the collision settings of each LOD level, and this bug if fixed and should make it into some future version of the engine (timeframe unspecified)?

[anonymous_user_b9532c9a]

Hi ,

That is correct. It is fixed, but the fix will be implemented at a later time.

[Hyperloop]

Hi , just checking in - is UE-20297 fixed in 4.10? I didn’t see it in the patch notes but wanted to check to be sure.

[anonymous_user_b9532c9a]

Hi ,

20297 has been marked as fixed and was implemented in 4.9.1.

[Hyperloop]

Hi , I just tested this with static meshes in 4.9.2 and it is not fixed: every LOD level uses collision regardless of the settings in the static mesh editor.

I created a new project from the FPS template and I took a cube with a simple box collider, and added a second LOD to it and unchecked the Enable collision checkbox in the Mesh editor.

Here’s a screen cap from the PIE: the rocks you see are the LOD1 mesh I added to the static mesh cube, and they are still using the collision from LOD0 in spite of having the “Enable Collision” checkbox unchecked.