I want a follow cam, but the “3rd person follow” isn’t working for me because my camera is rotating with my playable “character”. I’ve found a different post that suggested “world space” binding mode, but there is no binding mode on the 3rd person follow cam - maybe that changed? There are binding modes for “Transposer” and it appears to almost work for me.
First: Can someone recommend a video or article showing the differences between world space / simple follow with world up / lock to target with world up? For my setup they all seem to behave pretty much the same.
But they also have the same “flaw”. At some point the camera makes a quick transition around my follow target, or does some other crazy move - sometimes it’s fine with the target moving towards the camera - and sometimes it decides to flip around it so it travels away from it.
I’m trying to make my controls relative to the camera direction and if I determine my input every vector I run into oscillations, where after the camera move the controls switch causing the camera to immediately flip back. My backup plan is to keep the control vector reference frame constant after the initial touch input. But then after the camera move the controls would sometimes behave differently then the player got used to.
What terms should I google to find out more about fine controlling the behaviour of the Transposer? Is it possible to delay the big camera flips? (So I could avoid them until user input ends) Or maybe it’s possible to remove it completely - effectively making “static” follow cam with a fixed offset?
It’s difficult for me to understand from your description what camera behaviour you want.
There are a number of 3rdPerson camera setups in the Cinemachine Sample scenes. See these in particular:
Free Look character
3rdPersonWithAimMode
AimingRig
Do any of those scenes implement the kind of camera you’re looking for?
You can get the sample scenes from the Package Manager.
Thanks, but they all seem to use the mouse for free look or rotating the camera. I have figured out that what I want 99% of the time is Lock to target with world up. I just need to read up on the different Aim types, and try to understand what exactly the composer is doing. Why if my character is traveling at a fixed heading (with tiny variations) the composer is deciding to either follow behind or in front of the character?
(I tried “Do Nothing” following your advice in an older thread, but then the target can fly out of frame completely)
Here’s a clip of what it looks like most of the time and roughly what I want: gfycat.com/pl/positiveaggravatingcob
But in certain orientations this happens: gfycat.com/pl/constantanycoypu
The Body component of the vcam (e.g. Transposer, FramingTransposer, etc) is responsible for setting the camera position. It won’t rotate the camera. Aim (e.g.Composer) is responsible for setting the camera’s rotation. It leaves the position alone. Think of someone telling a cameraman: stand here, and point the camera there. The two things are decoupled so that you can control them independently.
When you tell the Transposer to follow a target (the Follow target), you have to give it an offset vector, because you don’t want the camera to be in the same place as the target itself. The Binding Mode tells the Transposer how to interpret that offset: is it a world space offset (WorldSpace binding mode), which stays constant as the target rotates? Is the offset in target-local coords (the various LockToTarget flavours), so that the camera position will rotate along with the target? Or is the offset specified in camera-local coords (SimpleFollow)?
If you choose LockToTarget, then the camera will always look at the target from the same angle (ignoring damping for now), and will rotate around the target when the target rotates. Regardless of where the camera is positioned relative to the target, it can look anywhere, so if you want it to also look at the target, you will need a composer and a LookAt target (usually the same thing as the Follow target).
Why is the camera going crazy for you? Possibly because you have some kind of feedback loop in your setup. Target, vcam, and main camera should all be separate objects, not parented to each other. Use the main camera as reference frame when you interpret user input, and apply that input to the target.
Another possible reason is that your target is tilted 90 degrees when the camera goes nuts, and LockToTargetWithWorldUp doesn’t know where to position the camera - it gets noisy because of gimbal lock (this is a math problem, not a bug. There is in fact no correct place to position the camera when the target tilts up or down by 90 degrees). I suggest that you try using SimpleFollowWithWorldUp binding mode instead. That will ignore the target’s rotation and will move the camera as little as possible in order to keep the desired distance from target.
Thank you for taking the time to explain all this. While researching this, I’ve seen in other threads (mostly about golf-type games where a camera follows a ball) a suggestion to have a different object and continuously set it’s position to above the actual target and point cinemachine to use that. (I guess this is exactly what SimpleFollow would do).
If I wanted to have the camera follow the rotations around the world up, but not others I now realize I will run into the exact same problem as LockToTarget is having. But at least then I have total control over how the edge cases are resolved. I’m doing a similar thing already to get the camera relative control axis, either starting with camera right or camera forward depending on which is “less colinear” with my target’s up. (Similarly for example simply projecting the target’s forward by flattening the y component will break when the target’s forward is aligned with world up, but I could project the target’s right (or up) in that case instead) - I just had a look at com.unity.cinemachine/Runtime/Components/CinemachineTransposer.cs at 191da54402144e89361d96829d39245e87feced9 · Unity-Technologies/com.unity.cinemachine · GitHub and see it uses the previous frame orientation - I can probably come with some solution that while biased towards certain directions but avoid the oscillations.
Thanks again, I feel like I have a much better grasp on what’s going on and what my options are.