Kind of dissapointed by Cinemachine's obstacle avoidance. Am I missing something?

Overall I find Cinemachine to be a damned impressive piece of kit, and it does some amazing things. However this weekend I was trying to work with some stuff and was really let down by the limited feature set it appears to have for obstacle avoidance and I am wondering if I am just missing something.

One of the driving features behind Cinemachine was, to my understanding, solving the more challenging engineering issues that many different games have to re-implement on their own, and obstacle avoidance is definitely one of those things. It is hard to get right and takes a good lot of work.

But all I can seem to find for doing this with Cinemachine is the Collider behaviour which does nothing more than pull the camera forward of any collider it hits. It doesn't check to maintain line of sight, and it doesn't make any attempt to smoothly nudging the camera in a way to keep the player's comfort level up. It just teleports the camera to the other side of a collider it hits.

Is there something else in this package that I am missing?

Amazingly good talk about the subject by the way:

 

How close to walls can the camera collision get? in my code, I project the frustum of the camera so it can get to basically, ground zero without clipping problems. If Cinemachine can reach that far I could consider using it instead of custom...

 

I have tried all of those settings, though blindly as I don't know what they are supposed to do But no matter what I do I still get camera "teleporting" which is very confusing to the player. I don't ever want the camera to jump from one spot to another. It should always MOVE smoothly from one spot to another.

 

Oh nice! thank you.

 

Ok I've started getting some of the behaviour I Wanted thanks. I was increasing the damping but I needed to be increasing the Damping When Occluded. Somehow I totally missed that second setting first time around.

 

So after playing with this and getting a feel for it, it is better than I originally thought, though not really advanced enough I think for most games that really was nice polish on their game cameras.

This well help you keep your camera from losing line of sight, and keep it from "sitting" inside the world geometry, but it seems at best all it will do is pull the camera forward to clear obstructions. It still allows the camera to go through geometry, just in a more controlled manner. This is fine for many games, but if you are looking for a more polished system that actively pushes the camera AROUND obstacles then this just doesn't seem up to the job.

That said, this is adequate for many games, but I'd like to suggest a few more options for control here.

I feel like you need individual control over two similar but separate conditions.
1) When the cameras path pushes it into an obstacle and the camera just needs to not penetrate the obstacle.
2) When an obstacle comes between the camera and the target

In case 2, you probably want a bit of damping so that the "pull forward" isn't disorientating to the player, but in case 1 you want no damping because you just want to the camera to stop when it hits the obstacle. If you have any dampening in case 1 then the camera will temporarily get pushed through the obstacle and then pull itself back out which looks bad. So you really need two different damping controls here.

On the surface that should be what "Damping" and "Damping when Occluded" would be, with the first covering case 1 and the second covering case 2, but this doesn't seem to hold true. In fact I seem unable to find a scenario where the plain "Damping" is used.

Complicating case 1 even farther, is there really are two values needed here. Essentially the "pull forward" and "push back" need to be tweakable separately. In this case you generally want damping at 0 to prevent the camera from moving into the obstacle temporarily, but if you have it at 0, then when the camera is clear to "push back" to its normal distance it does so instantly which can be disorientating at worst, and ugly at best.

Lastly there is some odd behaviour that I don't even know how to explain, such as this here. What is going on here?

https://i.gyazo.com/10394b3845be067cdeede9ef5d872f58.gif

 

Is this what you want? Anything else?







As far as layers go, there are really only two layers involved in this test. Default and "Puck". Puck is the short cylinder inside the character and is part of the movement system. It is only being shown as debug and is ignored from any collisions, and the camera collider is set to ignore it as well.

 

https://i.gyazo.com/a1a5fa008f3c596a2f66ea351d7d0d8c.gif

https://i.gyazo.com/c59116ee57288ce209fb84230414d6da.gif

 

There is no collider in the doorway itself as if there was the player wouldn't be able to move through.