Vulkan: Separate near/far dof_blur_amount no longer available (unlike 3.x)

[TokisanGames]

Godot version

4.0.alpha10

System information

Win 10/64 NVIDIA GeForce GTX 1060/PCIe/SSE2

Issue description

Godot 4 has one setting for dof_blur_amount.
Godot 3 has two, one for near and one for far.
Since Godot isn't calculating real DOF, the near and far planes may need to be different values, so both should be provided.

Example 1:

I've written a physical camera for Out of the Ashes that calculates the real depth of field ranges based upon aperture and focal length of my lens. Then I position the DOF blur plane distances according to the math, set the transition value to the same as the distance, and simulate the amount of blur based upon math, a lot of experimentation, and my photographic experience.

Here you can see that the near plane has a strength of 0.12 and the far plane 0.062. Near distance 3.561, Far distance 4.619.

This is not possible in Godot 4, but should be.

Example 2:
At https://dofsimulator.net/en/ you can play with camera lenses and position of objects and see how the focus ranges are positioned. This demonstrates why having only one blur setting is physically incorrect.

Here is a 90mm lens at f/4, with the subject 20m away. You can see the background is nearly in focus in the sample image. This is because, as you see on the bottom, the far focus plane is very close to the infinity focus mark, where anything after that distance is in focus. You can see the hyperfocal distance is 34.91m, meaning if the subject is there or farther, the background will be perfectly in focus. However, that does NOT mean everything in front of the subject is also in focus! Imagine if someone's head or hand steps in front of the camera within 5m. Is it also going to be as nearly in focus as the background? No, it's going to be a very blurry mess.

Steps to reproduce

Built into the engine.

Minimal reproduction project

No response

[clayjohn]

Sounds good to me. I will be implementing more physical attributes for the camera later this week and will keep this in mind.

If you are happy sharing your code for calculating blur amounts from aperture and focal length, it would be a big help.

[Calinou]

Separate amounts for near/far DOF blur was removed in the 4.0 DOF implementation for performance reasons, as it allows performing both DOFs in a single pass. This is also why #50723 in 3.x was reverted.

Tweaking the transition distances can help make it look like you're using different DOF amounts for both, although it's not the same thing.

If you can find a way to have separate amounts for near/far DOF blur without incurring a performance penalty, it would be very welcome 🙂

[TokisanGames]

@Calinou It may be faster, but it's wrong. Transition amounts are not going to cut it. There's no way to do what I described above accurately, and have it work in all cases using only transition amounts. You could have a faster, mirrored option for those who do not care about being physically correct, and two for others.

Also a better blur would be good. The current 3.x implementation gets ugly and unusable very fast.

@clayjohn What do you have in mind to do?

[clayjohn]

We can just pass in a two values, one for blur near and one for blur far:

godot/servers/rendering/renderer_rd/shaders/effects/bokeh_dof.glsl

Lines 42 to 52 in f6072c9

	float get_blur_size(float depth) {
	if (params.blur_near_active && depth < params.blur_near_begin) {
	return -(1.0 - smoothstep(params.blur_near_end, params.blur_near_begin, depth)) * params.blur_size - DEPTH_GAP; //near blur is negative
	}
	if (params.blur_far_active && depth > params.blur_far_begin) {
	return smoothstep(params.blur_far_begin, params.blur_far_end, depth) * params.blur_size + DEPTH_GAP;
	}
	return 0.0;
	}

[Calinou]

@clayjohn I'm looking into it, and I see a bunch of other references to params.blur_size throughout the shader, which don't use get_blur_size(). Can these also be made to use near/blur size as needed?

Also, can raster DOF (used in the mobile renderer) be modified to support separate near/blur DOF sizes?

[clayjohn]

@clayjohn I'm looking into it, and I see a bunch of other references to params.blur_size throughout the shader, which don't use get_blur_size(). Can these also be made to use near/blur size as needed?

Yes. DoF first generates a radius and stores it in a texture, then during the main pass the radius used is limited by the one that was stored in the texture. That way you can do far and near in a single pass and have different amounts of blur for each. In the second pass blur_size takes on a new meaning, it is more like maximum blur radius (which is why circle mode just outright replaces it). We can just do max(near_blur, far_blur).

Also, can raster DOF (used in the mobile renderer) be modified to support separate near/blur DOF sizes?

Yes, it's the same as the compute version.