Cinemachine Collider Third Person FreeLook with Jitter

Hello,

I try to use the Cinemachine Collider with my FreeLook camera, but I still did not get good results.
If the camera collides with a wall and I move the mouse in order to rotate on the rig, the collision will be avoid rather smoothly. But things get tricky when my player is encycled with constantly moving enemies, then the camera repositions all the time, it’s like warping to new position around the player, which is totally annoying with the fighting system. I tried all avoidance strategies with different parameters, but still no luck. So is there a way I can have no camera clipping but still smooth camera transitions? And there is totally enough free room around the player and the enemy mob, I have a rather big open arena, with no ceiling and other obstacles.

Hi,
Did you try changing the Collide Against parameter on your CM Collider? If you don’t want your camera to collide with surrounding enemies, then you can ignore them.

Also, you may have a look at the Clearshot example scene (Cinemachine Example Scenes/Scenes/ClearShot/ClearShot.unity).
It could work for your game. For example, you could setup several cameras around the player (even above, because you have no ceiling), and then set a priority order between your clear shot cameras. The system will put the main camera from where it can see the player and has the highest priority. You can also set up custom blends for transitions.

Actually, I want the camera to collide against my enemies, so I select the “Enemy” layer for the parameter “Collide against”. The problem is just the avoidance is not smooth and smoothing values seems to really have no huge impact. Even the different strategies seems to be bugged, for example if I choose “Preserve camera height” then the camera sometimes choose a lower spot inside my player character.

The multiple camera setup does not really help me since I have a Free Look camera with three rigs, so the player has to be in control everytime. I would rather have one camera that avoide walls and enemies more smoothly. Is there any example of such a setup?

Do you ignore every part of your player? (First select Nothing, then your enemy layer, so it’s not mixed).

I checked CM collider with the Pull Camera Forward strategy (see the attached image) in a simple scene with a lot of objects, and it worked ok for me.
Collide Against (red): Enemy layer.
Minimum Distance from Target (yellow): Setting this to a number bigger than your target’s radius will ensure it does not go inside the body.
Camera Radius (green): This will make the camera feel more responsive, because we are checking for a bigger ball for collision.
Damping when Occluded (blue): This will smooth the collision avoidance strategy.

One thing that may be causing problems for you is when there is no space between the occluding object (enemy) and your follow target. In this case the camera will just go back to its max. distance.
If this is the case, then currently we don’t have a complex collision system for that, but you could script something like:
For example:

  • Have a FreeLook vcam
  • Have a Basic vcam has no follow target, only look at target.
  • Via script, position your Basic vcam to be always at the same place as your FreeLook but higher up.
  • When our basic collision system cannot handle your situation properly, then transition to the Basic vcam, which is higher up. Do the transition by changing the priority instead of enabling and disabling vcams.
  • Note, the controls will work nicely with the Basic vcam, because it follows the FreeLook vcam.

Let me know if this works.

5545624--570808--collidersettings.png

I’m not really sure about your first solution. When I set the max distance for the collider to a higher value, then the radius of the bottom rig will be ignored despite when there is no collision. I would rather expect that it only goes to the higher avoidance distance if there is some occlusion. So there is no befenit if the camera ignore the lower bottom rig radius if there is no collision. I don’t understand the design implementation here.

For me, the camera goes all the time to the max distance, even if there is no occlusion.
For example, if I set the avoidance max distance to 10, then the camera will always have a distance of 10 to the player, whether if there is a collision or not, ignoring also the freelook camera’s rig heights and radius. Very odd.

Also, I do not understand the shot evaluation value. It seems to have no impact on the collider behaviour. Are there other settings that influencing the collider script in a bad way?

I like to have the following behaviour: The player can use the freelook camera at every time but if there is some occlusion, the camera will smoothly find a point where no occlusion is.
So if the player is very dense encycled by enemies all around, the camera should rather pick a location far more away to the player and the enmies. So the camera should not find a spot between the player and the enemies (since there is mostly no space) but rather go behind the cycle of the player and enemies. Also, the new obstacle free spot should not switch fast every frame, there should be some time out, so it will not constantly warp to location due to enemies moving, blocking the view in one frame, not blocking the view in the next frame.

I did not mean the radius of the rig, I meant your character. (e.g. your character is cylinder with radius 1, then I would set the min distance from target to a number bigger than 1).

But the rest is odd, I agree.

It is difficult to discuss the problem like this, could you send a small project here, where I could observe the exact problem and play with it. Then I may be able to help your more.

Actually, it is really simply to observe.
Have a FreeLook camera and a Collider script.
Then set the avoidance max distance to any higher then the highest radius of all three FreeLook rigs radius.
Click play and observe the camera will always stay at the avoidance max distance whether there is an occlusion or not, destroying the FreeLook camera rig settings.

I just tested it with an empty scene, a capsule primitive as the lookat target and adding a freelook camera from the Cinemachine context menu.

So I do not get what the use case of this parameter is, when you have a FreeLook camera.
It is just a global distance to lookat target parameter, overriding the freelook camera’s rig radius, put into the collider script (where it should not be). Therefore, the tooltip for this is misleading.

Nevertheless, is there any example or tested use case by Unity, showing Cinemachine is capable of smooth occlusion avoidance with third person freelook on a map with many moving objects?
GTA V, RDR2, etc. like…?

The tooltip is definitely misleading! We’ll fix that.

We do have an example, which will be available soon, probably in the next release. It is not using Free Look though, we have a specific rig for it.

In the meantime, you can pull master branch from our public repo (https://github.com/Unity-Technologies/upm-package-cinemachine), and import the example scenes. Have a look at 3rdPerson* folders. Please note, this is not an official release, so use with caution ;). Let me know if this helps.

I checked the preview packages and the collider component is actually working more smoothly, and I’m wondering why it is not working like this with the freelook camera in the current package (2.5.0). Did you fixed a bug with the collider script or introduced other improvements? So the solution is to switch to the approach with the framing transposer and POV instead of a FreeLook?

1 Like

The 3rd Person Follow component has the collider built in. I wrote this collider specifically with 3rd Person Camera in mind, so it’s not using the CM Collider script.

The other 3rd Person example using Framing Transposer + POV + CM Collider. We have not changed the collider script, but the Framing Transposer received lots of updates.

I think both of these approaches are better than FreeLook in your case.

The intention is that this parameter be set to be just a little larger than the radius of the LookAt target, so that the target cannot be considered to be obstructing itself. This is useful in the case that your target does not have a unique tag that you can put in the Ignore Tag field. Putting a large value in here is an abuse of the parameter. Probably it would make sense to rename this parameter to something like LookAt Target Radius.

Just a feedback of disapprovement for this choice, the built in collider is very limited in respect to the Extension…

What features would you like to have that are absent?

In particular I miss the different strategies to solve the collision

6843899--796658--upload_2021-2-16_18-22-21.png
6843899--796661--upload_2021-2-16_18-23-7.png

Yes, those are indeed nice to have, but it’s not clear that they are appropriate for the 3rdPerson aiming cam. They are also quite costly due to the number of raycasts required.

I still don’t agree, you suggested in multiple places to switch from FreeLook to 3rdPerson Follow, which I would love to do because we need to offset the player from camera center without causing secondary problems, but:

  1. one has to integrate his own camera control code (I’m trying to integrate two AxisState to handle input).
  2. the collision is limited to PullCameraForward, which is bad for our game.
    So I think I’m wasting time trying to integrate the 3rd person follow.

Regarding the performance cost consideration, in my opinion that’s an evaluation game-makers should make, not tool-makers.

You have the option to use Framing Transposer (body) and POV (aim) to create a more general third person camera. See our 3rdPersonWithAimMode example scene.

Your feedback is very much appreciated :slight_smile:

1 Like