ragdoll disappearing when off screen

I have a weird problem where whenever a ragdoll goes off screen, it vanishes… kind of. What I have discovered is that it actually teleports around 1000 units away into empty space.

This happens every time I pan the camera so the ragdoll is off screen. I have tried setting the skinned renderer to update while offscreen, but that did not fix it.

The strange thing is - it only happens in real time. If I step through then it remains in place even when off screen. The moment I return to real-time, off-screen ragdolls shoot off to another location.

It has to be some weird physics glitch, but playing with the physics settings (increasing solver iterations, etc) has not fixed it.

Does anyone have an idea what might be causing this?

Update: I’ve noticed that if I move the camera so the ragdoll is off screen, but immediately move it back on-screen, so it’s only off screen for a split second, then the ragdoll is bouncing upwards. So it looks like what’s happening is that the ragdoll physics are deciding, when off screen, that some kind of intersection is occurring causing the character to deflect upwards…maybe.

This is odd though as the only thing it’s interacting with is the floor, which is a static flat surface. Also, the ragdoll is asleep by this point, so there shouldn’t be any updating going on until something hits it. Very weird.

The same problem here. Seems to be related to the Mecanim Animator component.

I used the legacy animation system with culling mode set to “based on renderers”. My ragdolls instantiated and stayed at the correct places despite of being on screen or not.

Yesterday I migrated to Mecanim and these problems appeared with animator culling mode set to “based on renderers”:

  • if a ragdoll is instantiated for a character off-screen, it will instantiate at (0,0,0)
  • if a ragdoll goes off-screen, it will move to (0,0,0) and take a pose in the animation

When using animator culling mode “always animate”, everything works. But it creates a lot of processing overhead as we have ~100 active characters in the level.

Our solution was to use Always Animate and disable animator component with code when AI character goes off screen and re-enable when they become visible again. There’s unity callbacks for these. We had some small issues as the animation state is not correct at re-entry but we were able to resolve this with some minor coding…

Solution found: just set proper hips position like : animator.GetBoneTransform(HumanBodyBones.Hips).transform.position = animator.transform.position; Right after turn on animator will fix this bug.

Go to your skinned mesh renderer, and check “Update When Offscreen”,Go to the main skinned mesh renderer, and check “Update When Offscreen”

I have the exact same problem, I also have an animator and a ragdoll and I disable the animator when the ragdoll kicks in, but still the ragdoll glitches and gets shot upwards when it goes offscreen.

It seems to have been fixed when I connected the ragdoll to the main GameObject (containing the animator and a separate collider that is switched off when ragdoll is enabled) it belongs to by a joint.

So my GameObject looked something like:

> Dude (contains animator and collider)
> - ragdoll root (with own colliders)

and now it looks like this:

> Dude (contains animator and collider AND a rigidbody connected to ragdoll root by a joint)
> - ragdoll_root (with own colliders)

it SEEMS to have fixed it but I am not sure.

EDIT: Nevermind, it didn’t help.

Same problem.

It’s probably considered bad form to “necro” a five year old question, but I just ran into this very problem, and I wondered if there was a fix.

The position of the hip bone from animator.GetBoneTransform(HumanBodyBones.Hips).position seems to be completely unreliable if animator culling is turned on (“Cull Update Transforms”). If “Always Animate” is the chosen option, then it works perfectly fine, but I assume there’s a large performance overhead involved with that unless you’re careful to turn AI characters on/off at some distance (probably good practice anyway).

Or, is there another way I can get the hip bone position that might actually be accurate?