+1 vote
asked in General Help by (130 points)


When I teleport my VR CameraRig to a new spot in the scene, my player body which is wired up with VRIK leans forward and flies/glides to the new destination, presumably because it's trying to catch up with the new positions of the CameraRig head and hands.

What are best practices for avoiding this, so that when the teleport happens, the IK body will appear gracefully in the same orientation at the teleport destination?

I was able to get decent results by setting weights to 0, doing the teleport, calling solver.Reset(), and setting the weights back to 1, but there was still significant stutter when appearing at the destination.  I also don't want to rely on this only happening for known Teleport events.

Ideally, any time the tracked solver positions in the CameraRig become wildly out of reach for IK, the IK body would snap to that position seamlessly.

Let me know what ideas you have.

Thanks all!

1 Answer

+1 vote
answered by (22.8k points)

When you teleport, also move the root of the avatar by the same amount as you move the CameraRig, then call ik.solver.Reset() immediately after, no need to set weights to 0.


commented by (130 points)
Thanks Pärtel.  This gave us the same behavior as when we were setting the weights, but it may be a networking sync issue that's causing the remaining stutter on the models during teleport.  Tough to say.  We can hide it for now, but it may be something interesting for us to pair on in the future, if you're interested.

The only remaining issue on our side is the inability to teleport above the origin ground level with `Plant Feet` enabled.  We have a spectator area above the map for when you are dead.  We teleport both the camera rig as well as the player transform to above the map, (0f,4f,0f) in this case, but the player transform is forced back down to 0f on the y axis.  Confirmed if I manually set y to 4f in the Editor, it'll still immediately force back down to 0f.  What can we do to avoid this?

Thanks again!
commented by (22.8k points)


I tried to reproduce it here with a simple script like this:

public VRIK ik;

    public Transform trackingSpace;

    private void Update()


        if (Input.GetKeyDown(KeyCode.T))


            trackingSpace.position = transform.position;

            trackingSpace.rotation = transform.rotation;

            ik.transform.position = transform.position;

            ik.transform.rotation = transform.rotation;




But I could not see any problems, with Plant Feet enabled or not.

Are you sure the player transform you were moving was the transform assigned as "Root" in VRIK's References?

If it only happens with remote characters, could be that you are sending the teleport command over via RPC, while the IK targets are synced via OnPhotonSerializeView (if using Photon), so the teleport is executed when the RPC arrives, but the IK targets are moved back to where they were before teleporting until their new positions are serialized and deserialized. Or maybe there is some custom interpolation of the IK targets going on that doesn't account for the teleporting and causes the interpolation to move the IK targets half way back to their old positions or something like that.

commented by (130 points)
The Photon behavior you're describing is my guess as well for why we still see some stutter on remote client teleports.  We are moving off of PUN soon, so I'm not spending too much more time on it right now.  If you'd like to work through it so you know for future reference, we can definitely do that.

I'll check the root reference tonight.  I'm moving the transform that has the VRIK component, but I didn't verify the reference.  The grounding behavior happens for me locally.  It's likely something quirky with our setup.  Do you have a Discord you like to use?  We can talk through easier there and report the results back here after we've landed on something.
commented by (130 points)
Figured out the grounding issue.  We had two separate issues.

One is that when the root object also has a NavMeshAgent, it will try to restrict position to within the NavMesh.  We had just generated new NavMeshes while working through the first issue, so it wasn't immediately obvious.

Next was again with networking.  We were relying on messages to tell us when to teleport the root to catch up with the camera rig.  If a client connected after the message had been sent, we weren't replaying the messages to catch up the root object.  We solved this by adding networked tracking the position of the root object (as we were already tracking the head and hands of the camera rig) instead of relying on the teleport message.

Welcome to RootMotion Q&A, where you can ask questions and receive answers from the developer of Final IK and PuppetMaster and other members of the community.

Post as a guest, create an account or login via Facebook.

Please use the correct category when you post your questions.