I am having an issue with Cinemachine’s free look camera.
The issue:
When my scene starts, when I use my joystick or mouse to move the camera, the x axis rotation is very slow.
Once I move the object that the free look camera is targeting for the follow and look at, the x axis rotation then speeds up. I can adjust the speed value and the speed will proportionally increase/decrease, but there is always a massive difference in the camera’s x axis rotation speed before and after the player moves.
I attached a gif of the issue in action.
Setup:
-I am using Unity 2022.3.5f1
-I am using Cinemachine package 2.9.7
-I am using the new user input system package 1.6.1
-I have a cinemachine free look camera object which has my player object as the follow and look at target.
-Here are the settings for y/x axis and orbits:
-Since I am using the new user input system, I also have the Cinemachine Input Provider component attached to my free look camera:
-You can see I have a player action called look set for the XY axis field.
-In my input asset, Look is set to action type pass through and control type vec2. (I have also tested action type value with same results)
-I have no interactions or processors on the action or bindings themselves.
-Here is how my cinemachine brain is setup on my main camera:
-I am using a rigidbody on my player controller (I have also tested just manually moving the transform of the player via the inspector and got the same result)
-I have no code/scripts that effect sensitivity, camera speeds, or touch the bindings of the look action.
If someone could point me in the right direction or to say this is an issue with cinemachine/new input system, I’d appreciate it.
The only thing I haven’t done at this point is starting a fresh project and testing it, but honestly that solution would be quite terrible due to the size of my current project.
I found a work around. I was using Smart Update on the cinemachine brain component on my main camera, and for some reason this was causing the odd behavior.
I switched the update method to Late Update and the problem resolved itself.
I don’t see this as the correct solution. There seems to be a bug with the smart update. I was able to reproduce the problem on a brand new project but this time the speed was fast when the scene start and once I manually updated the follow/look at target’s position, the x-axis rotation became slower.
I would but I already nuked that project file from my machine. And really don’t feel like setting it back up lol Like I mentioned in the post above, the work around I am using is just switching from smart update to late update
Too bad. Fixing the problem by switching to LateUpdate from SmartUpdate suggests to me that there is some confusion relating to your use of FixedUpdate vs Update when moving your camera targets. If you restore SmartUpdate and look at the vcam inspector while the game is playing, you will see whether the vcam is updating on FixedUpdate or LateUpdate:
Smart Update will choose to update the vcam on FixedUpdate if and only if the target’s transform only changes during FixedUpdate - which will be the case if your target is a RigidBody without interpolation. Switching to LateUpdate will force the vcam to update during LateUpdate and will likely produce jitter if the vcam is following a FixedUpdate target such as a RigidBody. If this is the case, try enabling Interpolation on the RigidBody (that’s a good practice in any case as it will give smoother results in general). Interpolation eliminates aliasing by writing the transform on the Update clock.
The issue is the x axis rotation on the cinemachine free look camera is inconsistent during runtime unless switched to late update on the cinemachine brain.
The follow/lookat target is set to my player which is a rigidbody.
I already have the rigidbody set to interpolate.
I am only doing player movement inside of FixedUpdate
I switched the cinemachine brain back to Smart update:
Here is a screenshot of when I first start the scene showing that the cinemachine camera is using late update:
Once I move my player X amount enough to cause the cinemachine camera to update, it switches to fixed update
During this transition, the x axis rotation speed is drastically different. However the Y axis rotation stays consistent.
If the camera switches to FixedUpdate when the player moves, it means that you are not moving the character in a way that is compatible with Interpolation. IMO that is a problem that you need to address, and you are hiding it by forcing the camera up update in LateUpdate (you are silencing the canary that is indicating a problem).
The axis rotation being different is another matter, though. It shouldn’t be different, and I find it puzzling that the X axis behaviour is not consistent with the Y axis behaviour.
Based off all documentation from Unity that I have seen, my code should be pretty basic for movement. rigidbody.addForce. Pretty basic stuff for player movement. I have even tried turning of interpolation on the rigidbody, and the problem persists.
Inside FixedUpdate:
As for the “Transition”, like the gif on the OG post or the before and after images on my last response, once I move the player a certain amount, the camera system updates from lateUpdate to FixedUpdate. The speed of the x axis rotation is drastically different once this update method switches.
For further clarification. if you watch the gif on the OG post, I am holding my joystick fully to showcase the x-axis rotation speed. I then move the player a little bit which for whatever reason causes the camera update method to switch (transition). The x-axis rotation then becomes either much faster/slower.
The “whatever reason” is that you’re breaking interpolation. You might want to look into that. If Interpolation is enabled and properly working on the camera target, then the camera update will stay in LateUpdate. I’m not an expert on PhysX, but I do know that with interpolation enabled, you have to be very careful about what you do in ApplyTorqueToPlayer(). You may want to ask on the physics forum. The documentation is unfortunately not clear on this detail.
