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.

 

Hi Gregoryl, I've taken the time to look a little more into the cinemachine, and from what I understand the input values define a rotational offset relative to whatever is defined as the heading. I figured there might just be an event for telling Cinemachine that my heading has changed OnTargetObjectWarped() can tell it my position has changed, but that doesn't seem to be the case.

I tried just setting the values of m_AxisX.value, but that was a really bad idea because it confused Cinemachine about the constraints and also didn't properly reorient the camera on the way out of the portal.

Long story short I'm tired of guessing how cinemachine works, and I'd like to take you up on your offer of helping me set the values.

I have attached my inspectors as requested all 3 rigs are just using an orbital transposer and a composer so I just posted the top rig.

 

1)Bind mode is World
2)it was 1.3.3, but I just updated it to the latest 1.6.x and problem persists.
3)Here is the basic principle of doing a portal

-We have a second camera that renders an area where we want to warp the player.
-This camera renders into a render texture at the resolution of the screen or higher.
-We have a portal plane with a shader that samples this texture using the screen space coordinates, the result of which is that the plane geometry basically acts as a mask for the rendertexture, which shows the world exactly as we want it when the player is teleported.

In order to teleport the player seamlessly
1)The main camera and portal destination camera must have matching field of view and possibly other aspects.
2)When we warp the player, the Camera and player must have the same relative position to each other but the system must be reoriented so that the actual camera matches the position and orientation of the portal camera.

NB That's not quite right you have to compensate for weird orientation of the player and camera because you'll be spat out at a strange orientation not aligned with the floor if you do that. But I couldn't even get to the step where my camera is in a reasonable starting point so I haven't investigated that yet.

Getting the position right is not so difficult, but we can't just manually reposition the free cam because it snaps right back into place.

Things I've tried

Solution: Have a fixed Virtual Camera and at the destination, and hope the interpolation just works.
Problem: The camera tries to snap into a weird relative position as soon as I go from fixed back to freelook

Solution: Parent the player in the camera brain, move and orient the camera brain to match the portal camera, and then unparent the player
Problem:The camera assumes the same relative position to the player as soon as the frame ends, even though the player is facing a different way, so you would think that the target heading would be updated, and the axis values would move to compensate, but that doesn't seem to be the case.

If this has something to do with the coordinate system binding, because I'm using world coordinates and not fixing to the target I can see why maybe it behaves that way.

Solution:Try playing with different coordinate bindings
Problem:TThis might be the right thing to do, but if I use this the camera relative control in the example project (3D platformer lite) break.

4)Example project
https://github.com/awiebe/PortalCinemachine

Pertinent scripts are PortalTrigger.cs
Open the Portal "Demo Scene", play and walk towards the plane which is projecting an image
(try not to do this too quickly I haven't worked out the kinks of zeroing the player's velocity on teleport)
When you contact the plane the player will be warped to the location of the camera which was producing the image for the portal, t with an identical offset to the destination camera as their local offset from the main camera on entering the portal.

The player will also have been rotated so that they are facing as if they had just exited the other side of the portal, that is facing the same direction as the camera that produced the portal image. The editor will then Debug.Break()

The trouble is as shown that the player has moved, and the camera has moved but my attempts to get the cinemachine camera to match the portal's camera, so the match cut is seamless have failed.

 

I gave some thought to the orientation problem and the most logical thing to do is to have a second identical freelook rig orbiting a standin for where I want the player to arrive, but it needs to somehow be also rotated by an arbitrary vector.

If we consider the simple x-z plane case.
We can have one portal facing (0,0,1) and one portal facing (-1,0,0)

The orbit and aim of both relative to the follow target of are identical, but the destination is rotated 90°, I am testing if it will just work if I drop an identical camera rig into a transform rotated 90° or whether it still tries to orient to the world instead of the target heading.


since delayed recentering is an option I assume this means that the camera's freelook orientation is set arbitrarily, and is not relative th=oe the racked object's facing direction when I have the binding set to world mode, and I have to very specifically twiddle the coordinate system biding to get the behaviour I want.

 

Did anyone get this to work successfully, I have tried the most applicable suggestions and it's clear that there is some chase "velocity" on the camera when it's teleported that is causing it to look like it's popping. I am guessing this must be "by design" as you get the same effect when you initially press play e.g. the camera will attempt to "rubber band" to match the speed of the character (in my case an aircraft.) I might just go back to writing my own camera script as it offers better control.

 

Okay, so the issue is with the dampening, if I set x, y, z and yaw to zero it seems to work as expected. Is there a way of dealing with this?