Cinemachine FreeLook snaps rather than blending between its three aim points

I have Cinemachine (freshly downloaded) on a project in Unity 2018.1.0f2 and am using it to control a three-mode follow camera for my player character. First and third person modes are working great, after I did some tweaking of settings (which of course is expected).

My problem mode is FreeLook. I set up the CM FreeLook with its three virtual cameras. The orbital rings are at about knee, chest, and slightly above head height, and all about 2 meters in diameter with the chest-high ring being the largest.

Everything works as intended (modulo one CM bug, which I'll mention below and for which I found a workaround), but the camera blending within the three FreeLook vcams is really abrupt.

If I move the camera in play mode but watch it from the side in Scene View, what I observe is that the motion of the camera body along its spline is quite smooth, but when it transitions from one aim point to the next the transition is practically instantaneous (it appears to be within one frame). I've tried increasing the damping on various axes, but it doesn't seem to help. I'm sure others have this working, so I assume this is my own "pilot error", but I'm not sure what else to check.

Now the bug I think I've found is this: Instead of letting CM directly observe the input axis to control the FreeLook X and Y positions, I have my own PlayerController script in C# that owns the axes and sets the positions on the FreeLook rig. That part is working fine, but it happens I renamed the "Mouse X" and "Mouse Y" axes in my project settings to something else. Even though the axis names are *empty* in the FreeLook rig -- and believe me, I double- and triple-checked that! -- the rig appears to still attempt one query of the mouse input axis during its Awake(), Start(), or OnEnable() logic (or some roughly equivalent point). Everything works thereafter, but I get an error in the log that the axis is not defined.

The workaround for the bug is simply to define a dummy axis called "Mouse X" and "Mouse Y" that are connected to a nonexistent joystick.

Thanks for any advice on the camera aim damping.

 

Good morning, and thanks for the reply!

I'm using version 2.1.12, installed via Package Manager. (As of today, it shows 2.1.13 available for download, which I'll do soon, but the release notes for that don't mention any changes to the FreeLook camera).

My overall rig uses CM state machines at the top level, to switch camera modes (FP, TP, FL), then defines state machines within each of those to allow me to switch vcams within a mode based on animation state -- the usual reason the docs recommend using state machine cams. Right now, only the top state machine level has multiple states; the one between that and the FreeLook vcam is essentially a no-op as it has only a default state.

Attached are the first five screen shots walking down the hierarchy, in order. Due to file upload limits, I have to post the others in a separate post.

Two side notes:

1. Cinemachine is amazing, and Unity's really hit a home run with this and Timeline!
2. I think it's great that the state machine rigs can nest like this, and you guys should mention that in the documentation because it allows tremendous flexibility. I was trying to cook up some complex Animator thing with one state machine CM rig, then I decided to try the nested CM approach, and it Just Worked.

 

The other three screen shots

 

I should mention, the settings I have right now are fairly smooth in movement, but this was after *much* tweaking, and deviating even slightly from here seems to bring back the snapping aim points. I would have thought the aim point transitions would be blended, basically regardless of even bad settings on my part, and that the consequence of bad settings would be a blend that is way too fast but still a blend. What I observe in the scene view is literally a snap from aim point to aim point.

One more item: You can disregard the map camera and weapon camera. One is controlled by a different CM brain, operating on different layers, and the other is just a plain old camera with a limited culling mask, existing outside CM altogether.

 

CM created those automatically. I didn't. Strangely, they disappear from the hierarchy (not just disabled...GONE) during Play mode, then reappear when I stop play.

 

I've had the same thing few months ago, deleting them does nothing. @syscrusher You can delete them.

 

Did some testing; here are my observations:

1. Deleting or disabling those child objects caused most of my settings for the three camera rigs (top, middle, bottom) such as dead zone and soft zone to be reset to defaults. My guess is that CM is using those objects to store settings.
2. @Gregoryl those screen shots I sent may not have the working settings I thought they did. The aim points are suppose to have Y offsets of 0, 0.7, and 1.2 meters for bottom, middle, and top rigs, respectively; dead zones X of zero, and dead zones Y of fairly large. The large dead zone is how I got the camera to work without snapping. I don't know how those got cleared between my editing session last night (working) and taking the screen shots today.

EDIT: Confirmed, the screen shots are missing some of my settings, for which I have no explanation because it was working last night and therefore I didn't touch it. :/

 

Sure. This project is just a sandbox for a class I'm taking, so it's not highly proprietary. At worst, the whole project is currently about 900MB, which is at least doable for Dropbox. I'll try tonight to extract a small subset for you, but if I can't I'll just upload the whole project then PM you with a link.

 

By deleting most of the art assets and turning the level into a giant box made in ProBuilder, I was able to shrink the project down from 950MB to 315MB, and it compressed in ZIP to about 180MB. I've put it on Dropbox and will PM you the link.

After doing all that, I realized there was a better way: I've got the project in Unity Collaborate (I have the Plus version), so I could just share that and let you have access to the whole thing. Doh! I'll still send you the link because I think the simple level is less distracting for replicating this issue.

Replication instructions:

• Extract the project and open in Unity 2018.1.0f2 or later.
• Open the scene "Western" and resolve any errors related to your environment vs. mine (hopefully none).
• Enter play mode with a gamepad or keyboard and mouse active.
• Left stick or WASD to walk and strafe. Right stick or mouse with LMB pressed and held to look around.
• Press left stick button, or V key, to toggle among three camera modes (FP, TP, FL, in that order).

Out of the box, the FL should work reasonably well, though I'm not completely happy with it yet. But observe in the Scene View how the camera snaps instantly between aim points.

Now go to the Cameras...PlayerCameraRig subtree in the hierarchy. For the free look rig, shrink down the Y dead zone and you'll see that nasty snap behavior.

 

I've made a short demo video (which I'll delete after we figure this all out, unless the Unity folks want me to keep it archivally) showing the problem at full speed and at 25% speed. (Unlisted link -- I know this forum is public, but please don't share it elsewhere since the link will die if I delete it later.)

You're correct about the mouse jitter; sorry about that annoyance. It is because my prototype script is updating the XY positions every frame, even when it doesn't need to, and it's picking up the input axis jitter. That's a known issue in this prototype and something I plan to correct with a dead zone for the input axes, either in the Unity settings or in my C# code (haven't decided yet where I want that).

By the way, the large black square under the character is a procedural mini-map marker that follows the character and is culled by all cameras except the mini-map. You can disregard it in this demo. Likewise the small green cube you may notice is a marker for part of the weapon aiming system, again not relevant here.

 

Wow, thanks! I had no idea the multi-brain bug was impacting this situation.

Here are my test results:

1. I tried doing the layer fix (your #2) first, as an experiment to see if the CM bug really did relate to me. The layer fix alone was not enough (which you had hypothesized -- again, I was just gathering another data point).
2. I upgraded CM to 2.1.13 without problems, using Package Manager. The upgrade reset the aim look point offsets as well as the dead zones X and Y to defaults, a problem that I had been having off and on with 2.1.12.
3. After the upgrade, I set the dead zones X and Y to zero for the three orbital rigs and retested. The problem was still there for the first test run, but on the second and subsequent test runs it was gone. I think there must have been a need to re-serialize some asset files somewhere.
4. The correct behavior persists across Unity editor restarts, and I also was able to make some desired changes to my orbit heights and maintain those changes across Unity restarts.
5. So far, the problem of spontaneously resetting aim parameters and dead zones has not recurred other than that one time immediately after the upgrade.
6. (Addendum) To further pinpoint the multi-brain problem, as step "1A" (which I forgot to mention above), I tried disabling all the other CM brains and vcams, with my layers set correctly but while still running CM 2.1.12. As you predicted, this prevented the camera snap problem.

Conclusion: I think this problem is solved, with the caveat to anyone else in the same situation that you probably want to save the project and scene, restart Unity, and recheck the virtual camera parameters one more time after upgrading CM and before retesting.

@Gregoryl, thank you very much for your problem solving assistance!