3D Platformer Jump Lag

Can you show me a picture of the inspector for your FreeLook?

 

Looks to me like you just need to add Y damping to the Orbital Transposer in the Body section. A little Z damping might be nice too. Start with the dame damping values in all 3 rigs, then tweak the top/bottom if you want them to be a little different.

Cinemachine uses separate damping values for position (Body) and orientation (Aim). This is in order to give you complete control over camera behaviour.

 

Add a vertical dead zone in the Composer to stop the rotation when he's jumping. The dead zone allows the character to move freely within that zone without the camera rotating until the character goes outside the dead zone.

One way to do it only when he's jumping is to have 2 FreeLooks with slightly different settings that you blend between when the character changes state. You can do this with a StateDrivenCamera if the character's states are contained in an Animation state machine, or you can just do this with a script.

 

This should get you going:

Code (CSharp):

1. using UnityEngine;
2. using Cinemachine;
3.  
4. public class FreeLookDeadZoneUpdater : MonoBehaviour
5. {
6.     [Range(0, 1)]
7.     public float deadZoneH = 0;
8.     [Range(0, 1)]
9.     public float deadZoneV = 0;
10.  
11.     CinemachineComposer[] composers = new CinemachineComposer[3];
12.  
13.     void Start()
14.     {
15.         var freeLook = GetComponent<CinemachineFreeLook>();
16.         if (freeLook != null)
17.         {
18.             for (int i = 0; i < 3; ++i)
19.                 composers[i] = freeLook.GetRig(i).GetCinemachineComponent<CinemachineComposer>();
20.         }
21.     }
22.    
23.     void Update()
24.     {
25.         for (int i = 0; i < 3; ++i)
26.         {
27.             if (composers[i] != null)
28.             {
29.                 composers[i].m_DeadZoneWidth = deadZoneH;
30.                 composers[i].m_DeadZoneHeight = deadZoneV;
31.             }
32.         }
33.     }
34. }
35.  

 

Do you really want the deadzone width to be 1 when he's running? Then the camera will never recenter on him. I thought you just wanted a vertical deadzone, to stop the camera rotating when he jumps. Leave the H deadzone at 0, and put the V deadzone to nonzero.

The code sample shows you how to set the deadzones from script. Instead of doing it on OnUpdate the way the sample does, do it in your enterstate() methods.

 

No, the sample code needs to be attached to the FreeLook game object. If you want to put it somewhere else you have a few options:

1. Add a public field for the FreeLook game object, set it up appropriately, and get your components from there. You'll have to do that once per FreeLook.
2. Query the CinemachineBrain dynamically for the current camera and, if it's a FreeLook and if it's looking at the player, fetch its composers and set the dead zone there. If you use this method, you'll need to take care to guard against unnecessary Garbage Collection, as GetComponent() generates garbage. Usually the solution is to cache the components and re-fetch them only if the camera changes.
3. Use the Brain's OnCameraActivated event to invoke a piece of code to register the current camera with the state handler. That code would fetch and cache the composers. The code would not be called every frame, just when the camera changes.

 

Time.deltaTime is the delta time between frames - it will always be in the neighbourhood of 1/60 second, so you're not really lerping. What you need to do is to cache the time of the state change, say with Time.time, and then feed to your lerp the time since then divided by the time over which you want the lerp to happen.

But really you're doing this the hard way. Why not just make 2 FreeLook cameras, one with a dead zone and the other without, and activate the second one when he's running. Let the brain handle the transitions. That's what it's for.

 

Virtual cameras are not cameras. They are camera controllers. The paradigm is that you have a plurality (read Lots and Lots) of camera controllers, each customized for a specific game state. You enable the appropriate one based on game state, and the brain handles the transitions to keep it all smooth. The camera controllers consume little or no resources, especially when they are inactive.

It's not at all uncommon to have different camera logic for running, walking, and idle, and subtle differences in camera work between these states can really enhance the emotional impact of the game.

Yes you can setup a custom blend asset to customize the transitions between specific vcams, but it might be simpler to start with just setting the brain's default blend to EaseInOut with a duration of 1 second. Right now you have it set to Linear/0, which is equivalent to a cut.

For enabling cameras based on player state, the most efficient (i.e. code-free) way to do that is to use the State-Driven-Camera, driven by the player's animation controller. Set up a default cam for it, then an override cam for when he's running.

 

Well in that case you can't use StateDrivenCamera for this. You'll have to manually activate the cameras on state changes. When the vcam needs to change, you can deactivate the current vcam's gameObject, then activate the new one right away. CinemachineBrain will take care of blending, even if the outgoing vcam is deactivated.

 

Yes, use SetActive.