When setting a Follow target our Body is set to Transposer by default. This allows for many different options through our previously looked at Binding modes — read more here.
But Cinemachine also contains other algorithms for moving our Virtual Camera.
Our default Transposer work’s by defining a fixed offset relationship to the follow target, then basing movement on our Binding modes and Damping.
Additionally, we have two other types of Transposer — Framing, and Orbital.
Framing Transposer works on a 2D plane, and mimics many features of the Aim component, but in the form of following the object as opposed to looking.
The first element of the Framing Transposer is set by the Camera Distance which moves the camera along the Z axis.
We then have our standard Offset and Damping settings, but also the composition rules of our Aim component — allowing for Lookahead time and smoothing, Dead Zones, and Soft Zones. These all work together similarly to the Aim features — read more here — to keep the target object within the frame by moving the camera instead of rotating it.
It’s important to note that for the framing to work properly, the Look At target must be empty.
The Framing Transposer is set up with 2D and orthographic camera views in mind, but can also be manipulated to work as perspective or 3D environment views.
The Orbital Transposer at it’s core, functions similarly to the standard Transposer in that it will follow the target based upon the Binding modes, but with the added difference in that it allows for dynamic positioning in a relative circle around the target. This can be defined by game logic, or by player input. No matter where the target moves, this relative orbit will follow (with the particulars defined by our Binding of course!).
On top of our usual parameters, we also have Heading, which allows us to set the camera’s orbital position depending on either how the target is moving or facing (in either local or world space). By default this position is directly behind the target, but we can manipulate the position using the Heading Bias property.
We can also add player input to allow for control of the heading.
Defining the Axis Name to an axis set up in the Input Manager, we can define how fast movement occurs, as well as either wrapping, or locking movement to an angle range.
Lastly, we can set the Transposer to automatically re-center the camera to the target heading, the rate of which can be defined.
Combining the Orbital Transposer with a Look At target, can allow for excellent circular navigation, either by player input as a way to pan around a player target, or an animated/game logic defined rotation around an object of importance.
The Third Person Follow algorithm is unique, in that we set the offset position in relation to the ‘shoulder’ of the object. From the offset position we then have a Vertical Arm Length which allows us to set an additional offset for vertical rotation of the target, so as to keep the object nicely in frame as it looks up and down.
Altering the Camera Distance simply sets the camera in place at the specified length behind the point at which the Vertical Arm ends up, and once again, we can use Damping to adjust the speed at which the camera follows on all axes.
Camera Side is set to the maximum 1 by default, with the intention of setting a right shoulder position. As we adjust this value down to 0, we reach a mirrored position on the left. This can then be used by game logic to either hard toggle between sides, or move between the two points with player input.
This is perfect for a 3rd Person Character Camera, but we can also take advantage of this algorithm by nullifying the offset and Arm Length to achieve a First Person View.
At the bottom of this algorithm, we can also see an Obstacle tab, which allows us to define gameobjects at a radius, in which the camera will not clip through.
Another unique follow algorithm is the Tracked Dolly. This algorithm requires a path to be constructed, to then allow for camera movement along it. To do this, we can add a CinemachinePath component to a gameobject, and begin plotting.
The top of the component allows customization on how we view the path within our scene view, as well as Resolution which defines how many positions are sampled per waypoint — something that becomes essential when we dive into Tangents. We can also set the path to loop.
We can then add and remove as many waypoints as we like and define their Vector position.
I’ve created a simple side movement, then a diagonal backstep, but we can take this a step further. The Tangent vector, allows for a symmetrical curved offset between the points, meaning we can create smooth circular motions without placing millions of waypoints!
Of course we could also make use of vertical movement with both position and tangent, but we can lastly add Roll. This allows for vertical rotation of the path itself, and therefore the camera.
With a path created, we can specify this back on our Virtual Camera.
I’ve created my path along the ground, which doesn’t quite work! Luckily, we can mess around further in the Virtual Camera itself. Manipulating the Path Offset vector, allows us to set the camera’s position in relation to the path, but it’s worth noting the X and Z axes aren’t in world space and can be misleading, especially if we have added roll! The X axis acts perpendicular to the path, with Z being parallel.
Yet again, we can take advantage of Damping control, as well as allowing for defining the Camera up position for the optional Aim settings. These operate similarly to the Binding modes of the default Transposer algorithm, allowing for different camera rotation rules on the target’s various axes rotations.
Now in terms of follow movement, we only actually use the follow target if we enable Auto Dolly — this positions the camera anywhere along the path at the closest point to the target. We can add a position offset based on the total length of the path, if needed, as well as limiting the search for the closest position to a select amount of nearby waypoints — beneficial if we have an elaborate path that may vary in distance to the target at times.
It’s also worth noting an Auto Dolly can be very problematic if we have perfect arcs around the target, as each positions distance will be equal.
Instead, we can return back to the Path Position property, to manually specify where (and perhaps when, with game logic) to position the camera. Each whole value is representative of each waypoint — therefore the path below contains a min-max range of 0–2. We can also change the units to be based upon Distance, or normalized to have a range between 0 and 1.
This won’t account for our Follow target, but a custom Auto Dolly script could be written in C#. Another way to dictate position could be with certain game logic triggers, transitioning the position from one waypoint to the next. The possibilities are endless as this is perhaps the most advanced of the Cinemachine algorithms!
Lastly, we have Hard Lock to Target which puts the camera at the center of the follow target. The only control we have over this is Damping. This algorithm may seem sightly pointless at times, but it could actually be used in a similar vein to the Tracked Dolly if we were to already have a moving object through our scene that could mimic a camera person or mounting point — eliminating the need for paths, but making the camera function on a purely linear.
In conclusion, we have many variations of Body types to allow for all sorts of use cases when it comes to Follow targets. Using what we now know of Aim and Body features, allows for even more combinations, suitable for whatever our game or project may need!