Odd DoF blends on playable director using cinemachine cameras with different focus offsets

Hi there,

Having upgraded to 2022.3.49f1, we’ve got a depth of field issue in a sequence using cinemachine + playable director.

We have a number of shots in the sequence that animate by blending between two cameras, A and B in a linear fashion. This is great for making straightforward pans / rotations etc and adding some visual interest. So far, so good.

Post-update, depth of field has been a problem. We’re setting changes to focus offset via a Volume Settings extension component on each virtual camera (although same behaviour observed by having different volumes for each camera). On blending, rather than the clean transition we had before (matching the blend curve) it seems that we’re now getting a weird parabolic blend… eg a focus offset on camera A of 0.3, and a focus offset on camera B of 0.6, seems to be blending via an extreme positive or negative value, rather than the linear progression you’d expect of .4,.5 etc.

Any ideas on where we might have gone wrong here? In 2022.3.49f1 metal, using cinemachine 2.10.3

Thanks!

This is an issue in DoF PostProcessing, and is unrelated to Cinemachine. The problem is that the blend works by simultaneously lowering the weight of the outgoing volume as the weight of the incoming volume blends in. What happens under the hood is a blend to “default” DoF for the outgoing, and a blend from “default” DoF for the incoming. The problem is that there is no such thing as “default” DoF, so something gets chosen arbitrarily, which is unlikely to be between the two values in question.

One possible workaround is to create a global volume to implement a default DoF. Choose a value that is more-or-less an average of the DoF values you expect to be using. It won’t be perfect, but you can probably get pretty close.

Ok, will take a look at this workaround, thanks. It was working until recently, is there a plan to un-break it in a future LTS fix?

This is not something that changed recently. Perhaps your issue is something else. Please let me know one way or the other if the workaround solves the problem.

I’m afraid it doesn’t, no, because any focus offset that would be an appropriate ‘average’ value for one camera setup is inappropriate for another. Let’s say cameras A and B show a smooth focus pull on a vase on a table, and cameras C and D show a similar focus pull between two cars. They don’t pass through the same focus distance because the cameras are at very different distances to their subject, and each other.

So yes, your workaround technically works as you describe, but inappropriately for the context of a sequence of shots in a real game context.

I rolled back the project to 2022.3.14f1, our previous editor version, and the bug is not present (then hopped to the next commit after we updated and it was present again). I’m afraid this does indeed look like an issue introduced with an update, so I guess I’d ask again if this is getting a fix.

Are you using HDRP or URP or the PostProcessing package? I will forward this issue to the appropriate team.

Also, for clarity, can you please specify the precise versions of both Unity and Cinemachine for the case where the issue was present and for the case where it was not present.

Thanks :slight_smile:

URP is the package,

Version where it works:
Unity 2022.3.14f1 // Cinemachine 2.9.5

Unity upgraded to 2022.3.49f1 and it got buggy with no change to cinemachine, but my current setup is, as mentioned above:

Unity 2022.3.49f1 // Cinemachine 2.10.3

Appreciate the help

Thanks for the info. One last question: is it buggy with Unity 2022.3.14f1 // Cinemachine 2.10.3?

I can only update it to 2.9.7 in that version of unity, but no bug if I do so.

You can go all the way to 2.10.3. It would be a very helpful data point to have, and will narrow our search for the issue.

Do it like this:

ah, yeah, that also breaks it (but just to confirm, Unity 2022.3.49f1 // Cinemachine 2.9.5 has same issue)

hmmm… that’s really weird. We’ll dig into it.

Appreciated sir :slight_smile:

I can’t repro your issue with the information I have. I’ve attached a test scene that blends between two DoFs. Result looks reasonable. To test, press play then activate/deactivate one of the virtual cameras to trigger a blend.

Can you modify my scene with settings that produce the problem, then send it back to me?

doftest.unitypackage (24.5 KB)

Thanks, that was really useful, and I’ve been able to ‘break’ it in a really straightforward way… all you need to do is go into Virtual Camera Profile and change focus distance from 6.59 down to something closer to the other profile, say 1.2. You’ll see that now, the dof slingshots away and back in the transition. Looking at your example fresh, you can see that there’s a bit of an overshot in that even, but it’s far more noticeable at closer values. Hell, if you set both profiles to the same value, you’ll still see the slingshot. It’s definitely going through another value during transition for some reason… maybe some kind of rounding error or imprecision somewhere?

Thanks for the extra info. I was able to narrow it down to the cause. I was wrong earlier: Cinemachine did make a change that affected this.

The issue is that the DoF blends differently from the other PP types, and the blending logic does not give the same results for both. The change made to CM fixed a serious bug when blending the other types, but unfortunately had this side-effect on DoF blending. There is no simple way to fix it - it’s a choice between the lesser of the evils, and the way it is in 2.10.3 is the lesser evil, so we won’t be changing it again.

However, I did think of a workaround, which I’ve attached here. It’s based on the idea of a global volume with a default DoF, but the extra sauce is that the value is chosen dynamically to match whatever the current CM camera has, so it always adjusts itself according to the current needs. See the Dof Blend Correction object in the scene. Add one of those to your scene, and you should be good to go.

Let me know if that works for you.

doftest.unitypackage (25.9 KB)

Nice, feels like we’re closing in, appreciate you making that.

This works well if I enable / disable virtual cams to test, but when we transition via a playable director, there’s a pop in the last few frames before a cut. I’ve added a timeline to your example… you can see that right at the end, the checkerboard black squares do a little pop. This seems to happen both if you use focus offset or create a bunch of profiles with different focus distances.

doftesttimeline.unitypackage (29.5 KB)

Right. It’s very subtle, but I see it. Updated the script, it should be fixed now. To me it looks good in both editor and build. Unity 2022.3.53f1.

doftesttimeline2.unitypackage (27.9 KB)

hmm, ok, while that has fixed the issue in your demo, it just blends out and smooths over the same bug in my scenes, putting it back to the kind of ‘wrong’ it was before. We go from 95% right then a quick glitch at end of shot, to 90% wrong throughout.

Can I ask what the update done in that script was? I can’t find any meaningful difference between our scene setups, beyond my profiles being more complex. I’m wondering if you’re working off an assumption about my setup that I’m not matching.

The change in the script was to change weight > 0.9f to weight == 1.

I’m just going by the info you give me. Unity can be configured in so many ways… maybe it’s best if you set up and share a test project that shows the problem, then I’ll be able to get to the bottom of it.

Also you mentioned that things changed when you upgraded Unity but not CM. That spooks me a little. There could be another issue at play. Are you using the same version of Unity as I am? If not, try that.

Try simplifying your scene until the problem goes away. Do you have a global volume somewhere that’s interfering somehow? It might have something to do with global volume weights and priorities. Unity will try to blend all these things together.

Note that I’m travelling for the next 2 weeks, so my responsiveness might be a little slow.