CinemachineDeoccluder behaviour

[Artur_Filipe_Sousa]

I’m experimenting with Cinemachine (v3) and I found out about the Deoccluder extension.
I’m struggling to understand how to work with it, though. From what I understood, the PullCameraForward strategy moves the virtual camera closer to the Tracking Target until there are no colliders being raycast between the camera and the target.

The other two strategies seem more interesting, as they move and rotate the camera to try and never let a collider between camera and target, either maintaining distance or camera height.

However, both these strategies permanently move and rotate the camera in relation to the target, never returning to it’s original position. Is there a way to have the CinemachineDeocculder have this behavior? If I use both CinemachineDeoccluder and set up Cinemachine's rotation and movement controls, then, whenever the deoccluder detects an occlusion, the camera goes totally haywire.

[Nina]

Hi,

Welcome to our community!

In which course and lecture are you?

[Artur_Filipe_Sousa]

I’ve completed Complete Unity 3D Developer: Design & Develop Games in Unity 6 using C#, and now am attending the Unity RPG Core Combat module.

I was at the lecture 2.8. Although Rick used a camera with the position manually set through code, I was trying to use the cinemachine I was taught at the former course, as well as some stuff I read on the Unity docs.

[Brian_Trotter]

Hi Artur,
Unfortunately, the version of Cinemachine used in the RPG course (lots of courses, actually) was supplanted a few months ago by Cinemachine version 3. This change to Cinemachine is what we call a “Breaking Change”, as it fundamentally alters not only how you add a Cinemachine Camera, but the entire setup and workflow for the camera. While I’ve been in the process of working through the changes needed to apply the same camera setups as are used in the courses, my recommendation for now is to revert the Cinemachine version used in your RPG project to version 2.0. I’ve recorded some generic instructions for this here:
Reverting Cinemachine To V2 - YouTube

[Artur_Filipe_Sousa]

Oh, I’m using the RPG course more as a learning guide, rather than following it by letter. I learned about Cinemachine on the Unity 6 course, which used Cinemachine 3 already, and was just interested in following the old course mixed with my knowledge from the Unity 6 course. After 6 years as a commercial developer, this kinda goes like a second nature to me. This was more of an “anyone got an Eureka moment to share?” thing.

[Brian_Trotter]

I haven’t directly worked with the de-occluder, but interesting that it’s not snapping back. The old CinemachineCollider (which we didn’t actually cover in this course) offered the option to pull in (zoom in until no collider is occulding the camera) or pull up (my personal preference). Again, it always snaps back where it was before the occlusion occurred.
I like the name change from CinemachineCollider (vague) to CinemachineDeOccluder. The new name says what it does and does what it says. The old name is, as I said, vague.

Looking over the documentation, it looks like the fix here to get it back to where it should be is by adjusting the Damping, lower is faster, higher is slower.

https://docs.unity3d.com/Packages/com.unity.cinemachine@3.0/manual/CinemachineDeoccluder.html

One caveat, however, is that it appears that the DeOccluder doesn’t memorize where it was when you encountered the occlusion… this means that for something like a freelook camera, the return position may not be where it was when you started. It should return to a calculated position based on the positioning component’s calculations. (This was actually true of CM2’s CinemachineCollider as well)