How do I teleport a Cinemachine Freelook Camera without it lerping

I have a section of my game where I teleport the character across the map without warning.

It uses a freelook camera and cinemachine brain. On teleport, I move the player to a new position and try to move the camera to the right position, but it insists on overriding my set transform.position call and lerps over to where it should be very quickly, effectively turning what I want to be a hard cut into an unwanted instant lerp. Do you have any idea how I can fix this? I dont think swapping between two freelook cameras is a good idea, and it seems like it is always going to try to lerp if it is displaced.

Thanks,

Pablo

 

Alright, I tried that in an earlier version and it did not work, it seemed to cache some positions. But I will update and try again.

Thank you.

 

Unfortunately, what happens is that when you re-enable the vcam, it does at first snap to the position but then immediately after interpolates from the old position to the where it should be - in my case flying through a bunch of a level objects along the way.

It seems that if I could empty the cache of where it thinks it was last that would do the trick. Any ideas?

Thanks,

Pablo

 

What about changing Default Blend in the CM brain to Cut?

 

Re-enabling the brain

I am not switching cameras - I am turning a FreeLook and a Brain on and off. Switching to Cut has no effect. Thanks for the suggestion though.

 

I've just tried re-enabling my FreeLook, Brain and there is no lerping, just cut.

Which Cinemachine version are you using?

(Also could you file a repo project?)

 

Version 2.1.10

Did you translate your target as well as your freelook by the same amount in between your enable/disable?

(Also could you file a repo project?) what do you mean by this? I unfortunately cannot share this project.

 

Yeah I've changed my transform position after disabling CM Brain and enabling it again.
Repo project is just an empty project which shows the bug.

 

Ok I am at work for the day but when I get home I will try to file a repo project.

 

Are there any other notable settings that you are using on your camera to have a clean cut across world space?

 

I've been trying to get this working today and have had some success. Rather than disabling/enabling the vcam component, you need to set its GameObject Inactive/Active. It's not longer lerping all the way across the scene, but there is a little judder when I set the new position. It also goes totally wild if I try and do this in the middle of a camera blend so it's not really a proper solution.

 

ah thanks. Yeah, I realized that my prob may be associated with the fact that I am on 2017 2.0b8 but once I upgrade I will check again.

 

Here's a quick bump for any one in the future that lands here (like I did and ended up spending half a day debugging issues).
The easy way to do teleporting is to use the new "OnTargetObjectWarped()" on the vcam

https://docs.unity3d.com/Packages/c...amera_OnTargetObjectWarped_Transform_Vector3_

 

That one does teleport following of the camera, but doesn't warp the aim component, e.g. Group Composer.

Does anyone know how to adjust the Group Composer, so it would look towards the look at transform after teleportation? Calling OnTargetObjectWarped manually on the Group Composer doesn't seem to work.

 

Yeah, this is a problem that aim stays the same instead of looking to the look at object.
I guess altering rotation of the vcam directly should work. Need to try that.

 

Nope, just the virtual camera.

Setting rotation directly didn't worked either.

 

Okay, so I've figured out this works perfectly (resets both position and rotation correctly for me):

Code (CSharp):

1.         private void TeleportCamera() {
2.             _virtualCamera.Follow = null;
3.             _virtualCamera.LookAt = null;
4.        
5.             StartCoroutine(UpdateCameraFrameLater());
6.         }
7.  
8.         private IEnumerator UpdateCameraFrameLater() {
9.             yield return null;
10.        
11.             _virtualCamera.Follow = *yourTargetToFollow*;
12.             _virtualCamera.LookAt = *yourLookAtTarget*;
13.         }

Shame it requires a small coroutine alloc, but its better than non-working teleportation.

 

Well, that something's position is the thing that has changed.
And the camera is being teleported to that position no problems via OnTargetObjectWarped.

Its the rotation that is kept the same which cannot be "warped" because that method doesn't exist.

It would be nice to have some kind of API to force update position and rotation in a "cut" manner instead of relying upon workarounds that might stop working in a future versions.


Because to be honest - OnTargetObjectWarped is terrible from the user / other programmer's perspective.
Calculating delta direction / distance vector just to snap camera to its new position, really?

Something is happening upon = null / = newTarget. That something could be put into that sweet "teleport" or "snap" method.

If there's a certain technical limitation why it doesn't exist, or why its done that way, it would be nice to know it.
Probably worth putting into docs.

Just my 2 cents.

 

1. vcam is following targetA, looking at targetA;
2. targetA gets warped and I'm calling vcam.OnTargetObjectWarped();
3. There's no group B.
4. As a result: position warps correctly, but the rotation is kept the same, leading to the slow vcam rotation (due to damping) from the previous rotation towards new position of the targetA.

Edit: I'll post screenshot of the setup tomorrow, if that would be helpful.

 

Already tried that, it didn't catch up if done in a single frame. The only workaround that worked out for me is the one posted above.

Here's a vcam setup:


I'm pretty sure extra damping / rotation is caused by Tracked Object Offset property.

 

I've tried these steps and it doesn't seem to have correctly updated the rotation of the virtual camera. I am using the prebuilt rig which comes with the 3d platformer kit.

I have augmented it with two scripts:

• MainVCam: A singleton that allows me to broadcast information to the actual main virtual camera.
• PortalTrigger: Causes my camera to be repositioned and rotated... or at lest it should

Code (CSharp):

1. public class MainVCam : MonoBehaviour
2. {
3.     public static MainVCam singleton;
4.     public Cinemachine.CinemachineFreeLook[] cams;
5.  
6.     public Vector3 position { get; internal set; }
7.     public Quaternion rotation { get; internal set; }
8.  
9.     // Start is called before the first frame update
10.     void Start()
11.     {
12.         singleton = this;
13.     }
14.  
15.     public void Invalidate()
16.     {
17.         foreach (Cinemachine.CinemachineFreeLook c in cams)
18.         {
19.             c.gameObject.SetActive(false);
20.             c.PreviousStateIsValid = false;
21.             c.transform.position = position;
22.             c.transform.rotation = rotation;
23.             c.gameObject.SetActive(true);
24.         }
25.         Debug.Break();
26.  
27.  
28.     }
29. }

Code (CSharp):

1. public class PortalTrigger : MonoBehaviour
2. {
3.     public Camera camera;
4.  
5.     void OnTriggerEnter(Collider other)
6.     {
7.  
8.         if (other.tag == "Player")
9.         {
10.             //MainVCam.singleton.gameObject.SetActive(false); //doesn't seem to work
11.             Transform playert = other.transform;
12.             Transform l_cam = Camera.main.transform;
13.             Transform oldParent = playert.parent;
14.  
15.             //Move the player in relation to the camera rendering the portal so the transition is seamless
16.             //Rotate the player so they are facing towards the same direction as the camera rendering the portal  
17.             //so they are correctly oriented camera relative when they arrive.
18.             Vector3 relpos = l_cam.InverseTransformPoint(playert.position);
19.             playert.position = camera.transform.TransformPoint(relpos);
20.             playert.rotation = Quaternion.LookRotation(camera.transform.forward, Vector3.up);
21.  
22.             //Update vcams
23.             MainVCam.singleton.position = camera.transform.position;
24.             //Orient the camera to face the same way as the camera that rendered the portal
25.             //This is the part that doesn't work
26.             MainVCam.singleton.rotation = camera.transform.rotation;
27.             MainVCam.singleton.Invalidate();
28.             //MainVCam.singleton.gameObject.SetActive(true);
29.         }
30.     }
31. }

Conversely if I just turn off the virtual cameras and reposition the main camera directly it pops right into the correct position. Then as soon as I turn the virtual cameras back on it is at the correct position, but the orientation screws up, as if it did not invalidate the orientation.

 

It is using the classic input system's mouse movement, which returns the delta of the mouse.(The 3DGamekit Lite calls this axis CameraX and CameraY respectively. If the mouse is stationary there is no input, therefore passing through the portal with the mouse neutral the axis are zeroed.

As I understand it this means that the inputs to cinemachine are zero.

The camera also appears to be facing the exact direction and is in the same position relative to the lookat as before I teleported the lookat position.

Symptomatically it is appears more like the new position and orientation were not considered when resuming the camera. Since the main camera simply copies the transform of the destination camera, and then the player is transformed relative to the main camera to match the same relative position, it seems to me that when the freelook cam is re-enabled cinemachine should evaluate the shot, see that it is in a valid position and get on with its day, that is unless manually relocating this camera in some way breaks the virtual camera's state.

It is as if when the target is teleported OnTargetObjectWarped happens, and the rig just looks at where it was and where the target is, and moves the brain according to its last known relative position and orientation. However for this use case it should have also evaluated that the Brain has also been warped and indeed transformed.

If that is a weird edge case behaviour you don't want to evaluate when an object is warped that's fine, but then setting the last frame invalid should also make sure the camera checks if it is in a valid relative position, and not try to snap as if only the target warped, or there needs to be a seperate call to tell the camera that it was also moved.