Question Can't get my State Driven Camera to behave correctly

A few things you can try:

• Replace the FreeLook with a simple vcam with FramingTransposer in the Body, and POV in the aim (simpler, better performance, and closer in feeling to the original video)
• Give some dead zone, so the character won't always get always recentered to the same spot
• Enable InheritPosition in the vcams to smooth the transitions

Something like this:

 

Nice progress!

I assume you misspoke here, and that in fact you want the camera to steadily follow player on the Z axis. Am I correct?

1) This is a known issue with FramingTransposer when the camera is at an oblique angle relative to target movement (the algorithm tries to preserve the worldspace distance camera->target, which changes with target vertical movement, when what you're wanting to to is to preserve the distance as projected onto the XZ plane). It can be prevented if you give it just enough Z dead zone to absorb this movement, but if you do that you should also do it on the normal player vcam, not just on the airborne one, to keep it consistent when it transitions. However, there are side effects to this, as you point out. I think it wouldn't be too hard to make a slightly modified FramingTransposer to add the ability to consider distance only on the XZ plane.

2) It's because you're cutting to airborne when in the middle of transitioning airborne->normal. Does it help to set the transition airborne->vcam to cut? Or give a small (equivalent) blend to both?

 

Let me play with it a bit and get back to you. Don't want to send you down any rabbit-holes.

Yes, you're right, that should work. Let me look into it. It might be a bug.

 

@ZeroThreeZero Unfortunately I was overly-optimistic in thinking that the necessary change to the FramingTransposer is a simple one. It's not. The fact is that the dead zones on the FramingTransposer were intended to be used in a 2D context, and in 3D when the view is oblique it's going to give you some undesired up-down motion when the target moves within the dead zone. Fixing that would require changing the whole algorithm. So for oblique views such as this you'll need to set your vertical dead zone to 0.

Which means we need to implement the jumping dead zone another way.

Here's an idea: create an invisible GameObject to serve as an "anchor" for your player. By that I mean that every frame it positions itself to match the player, then drops a raycast downwards, stopping at a maximum distance or a collision surface, whichever comes first. That point becomes the Follow target for your vcam - effectively implementing a vertical dead zone.

I made a little experiment to try it out, it seems to work well. I set it up like this:

Anchor is a child of Player (doesn't need to be, but that's how I set it up):



Vcam targets Anchor instead of Player:



Anchor has one script:



It looks for surfaces on the specified layers, ignoring any colliders present in Player. Anchor chain length is specified here. This is the script:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class PlayerAnchor : MonoBehaviour
4. {
5.     /// <summary>Attach anchor to this object.</summary>
6.     [Tooltip("Attach anchor to this object")]
7.     public Transform Player;
8.  
9.     /// <summary>Objects on these layers will be detected.</summary>
10.     [Tooltip("Objects on these layers will be detected")]
11.     public LayerMask CollideAgainst = 1;
12.  
13.     /// <summary>Will not get farther below the target than this</summary>
14.     [Tooltip("Will not get farther below the target than this")]
15.     public float ChainLength = 3;
16.  
17.     void LateUpdate()
18.     {
19.         if (Player == null)
20.             return;
21.  
22.         var pos = Player.position;
23.  
24.         // Raycast down
25.         var rayLength = ChainLength;
26.         var ray = new Ray(pos, Vector3.down);
27.         const float Epsilon = 0.001f;
28.         float extraDistance = 0;
29.         while (Physics.Raycast(
30.             ray, out RaycastHit hitInfo, rayLength, CollideAgainst,
31.             QueryTriggerInteraction.Ignore))
32.         {
33.             if (!hitInfo.transform.IsChildOf(Player))
34.             {
35.                 pos.y -= hitInfo.distance;
36.                 transform.position = pos;
37.                 return;
38.             }
39.  
40.             // Ignore Player hits.  Pull ray origin forward in front of obstacle
41.             Ray inverseRay = new Ray(ray.GetPoint(rayLength), -ray.direction);
42.             if (!hitInfo.collider.Raycast(inverseRay, out hitInfo, rayLength))
43.                 break;
44.             float deltaExtraDistance = rayLength - (hitInfo.distance - Epsilon);
45.             if (deltaExtraDistance < Epsilon)
46.                 break;
47.             extraDistance += deltaExtraDistance;
48.             rayLength = hitInfo.distance - Epsilon;
49.             if (rayLength < Epsilon)
50.                 break;
51.             ray.origin = inverseRay.GetPoint(rayLength);
52.         }
53.         pos.y -= ChainLength;
54.         transform.position = pos;
55.     }
56. }
57.  

So now, vcam will look at the anchor, which will always be on the floor (or chain length units below the player if jumping high enough)



You can add an offset in Framing Transposer to put the yellow dot back on the player center, to match vcams that follow the player itself with no dead zone:

 

Tracked Object Offset is a very new feature, only available in CM 2.6.2 and up (2.6.2 is available in preview only, but it's exactly the release candidate that will be the real 2.6.2, so it's safe).

Use a vcam aimed at the anchor anywhere you would want a vcam to look at the player with a vertical dead zone. If you don't want a dead zone for a vcam, then use the player as a target instead of the anchor.

I wouldn't lerp the anchor - let the vcams do their own damping (give them soft zones, but not dead zones). That way you can have different vcams with different settings.

EDIT: Just thought of something. I don't know if your project is physics-based or not. If it is, and if you don't have interpolation on your player, then you'll need to modify the anchor script to work in FixedUpdate, or you might get juddery motion.

ANOTHER EDIT: If you don't want to upgrade CM, then you can just build the vertical offset right into the anchor script (just add the offset in when setting the anchor's position).