Download

InitRagdoll() on pawn behaving differently on map with many actors

This is a bit of a weird one, and I’ll welcome any suggestions on what may be causing this issue.

When enemies are killed in my game, I trigger InitRagdoll() on them, so they fall around all limp. This is the description of what this native function does:



/**
 * Does the following:
 *	- Assign the SkeletalMeshComponent 'Mesh' to the CollisionComponent
 *	- Call InitArticulated on the SkeletalMeshComponent.
 *	- Change the physics mode to PHYS_RigidBody
 */
native function bool InitRagdoll();


I’ve recently discovered that if there are many hundreds of actors on the map (like huge player-built bases), the collision on the pawn becomes very unreliable, to a point where they sometimes fall through the landscape.

Here is a short video, first showing the pawn collision on a map with very few static mesh actors. Then after on a map with hundreds of static mesh actors.

https://youtube.com/watch?v=sbMKVvRQQ2k

Note: Although in the video i’m unable to move the second pawn at all, usually the root bone still appears to have collision.

Sounds very similar to this limitation.

Thanks for the response @franktech.

This would be very concerning if I’ve hit a limitation like this. I’ve been very careful to keep my collision meshes as simple as possible.

There doesn’t seem to be any frame-drop etc, which leads me to think this is a hard-coded limit somewhere (which i doubt is necessary on current hardware).

Any ideas of how I can begin to tackle this problem?

Do a quick test using the more complex scene example you showed above etc.
Pick a mesh that appears multiple times and has slightly more complex collision.
Resave it in Content Browser without any collision, then rerun the test in PIE.
(By the way don’t think programmatically toggling collision worked, but try it).

If its the same issue, problems will instantly vanish, but then what do you do?
I guess its a question of auditing the level. I used trial & error unfortunately.
Brute force deleting meshes, and taking notes of what freed up vehicles etc.
Eventually I found rocks / spheres that had over-complex auto-convex collision.
I simplified those and reduced the number of meshes overall using substitution…

I didn’t find a hard coded limit for this, I didn’t even find similar UDK threads.
You’ve been more careful. But if its the same issue you’ll discover it quickly.

BTW:
If Mesh count / complexity is the cause, Frame Rate may not offer many clues…
The best solution suggested in a different thread is merge meshes in a 3D app.
(As unfortunately UDK doesn’t have a quick Merge-Actors command unlike UE4).

Thanks for your input @franktech.

I don’t believe mesh complexity is the issue. I tried replacing all the actor meshes with a very simple mesh and the issue is still present.

However deleting a couple of these static mesh actors during gameplay does seem to temporarily fix the issue. But it’s not very predictable.

It certainly seems linked to the sheer number of static meshes spawned on the map, as it only seems to occurs for players that have build ginormous bases. It only seems to affect collision of skeletal meshes (like the bear skel mesh in the video).

I feel this one is going to be tricky to solve. I definitely appreciate any/all helps. Cheers

is your map a 10k one?ive recently noticed on my new 10k map that the nearer I get to the edge,the clunkier it seems-although there is not really a noticeable framerate drop.

even in the editor,if I move an actor it is like the grid snap is on,even when its not.

I don’t have any other bots in the map yet to test their physics, but I seem to randomly fall through the landscape.

any previous 10k maps ive done you couldn’t get to close to the edge because of the maps layout but the new one is open sea and you can get right to the edge.

I have the same problem, rigid bodies and apex cloth in the map edges have an oscilation, stronger as you are far from the center of the map. For cloth is not too bad… seems like wind. But for rigid bodies (boobs)… no.