Use circular fade instead of linear fade for distance fade

[Calinou]

master version of #69959.

This makes distance fade look the same regardless of the camera angle, for all distance fade modes (Pixel Alpha, Pixel Dither, Object Dither). Distance fade now behaves like fog in this regard.

This has a minimal performance cost, but the quality increase is worth it. When viewing a plane that fully covers the screen, I get 215 FPS instead of 218 FPS with Pixel Dither in 4K, but this does not reflect the typical use case of distance fade (which is for LOD purposes). Besides, there are likely other ways to improve dithering efficiency (such as reducing branching or using interleaved gradient noise).

Thanks to @mrjustaguy for providing the formula here: godotengine/godot-proposals#2963 (comment)

This can be cherry-picked without conflicts to the 3.x branch. I tested this PR on the 3.x branch on both GLES3 and GLES2, and it works as expected there too. This PR can be merged independently of #50297 as both can work together.

This closes #53853 and partially addresses godotengine/godot-proposals#2963.

Testing project: test_distance_fade_circular.zip

Preview

Note: These images should be viewed on a desktop device at 1:1 resolution by clicking them. Otherwise, they will not look as expected due to the nature of dithering.

Pixel Alpha

Pixel Dither

[PolyVector]

Orthographic projections should still use a linear fade, or it will cause artifacts while panning.

[Calinou]

Orthographic projections should still use a linear fade, or it will cause artifacts while panning.

I guess I have to apply the same if statement as done here:

godot/scene/resources/material.cpp

Lines 678 to 680 in a71169c

	code += "\tif (PROJECTION_MATRIX[3][3] != 0.0) {\n";
	//orthogonal matrix, try to do about the same
	//with viewport size

[clayjohn]

My suggested changes are functionally equivalent to your code except shorter and much faster.

[Calinou]

Rebased and tested again, it works as expected for Pixel Alpha and Pixel Dither. However, Object Dither no longer seems to be faded irrespective of camera angle. Rotating the camera without changing its position will change the entire object's opacity, which is unexpected.

Edit (2022-08-31): Fixed thanks to clayjohn's review suggestion.

I added a testing project to OP.

@clayjohn Do your suggestions handle orthogonal camera projections automatically?

Edit (2022-08-31): It seems distance fade makes objects invisible in orthogonal camera, even before this PR. I'm confused at how the distance is supposed to be calculated when using an orthogonal camera anyway.

[elvisish]

Could this be reviewed again for 3.6?

[clayjohn]

The code changes are fine. My only concern is with the comment which will quickly become out of date.

I am fine with substituting Akien's suggested comment above.

[Calinou]

The code changes are fine. My only concern is with the comment which will quickly become out of date.

I am fine with substituting Akien's suggested comment above.

Done 🙂

[akien-mga]

Thanks!

[akien-mga]

This can be cherry-picked without conflicts to the 3.x branch. I tested this PR on the 3.x branch on both GLES3 and GLES2, and it works as expected there too.

This has significant conflicts now, so would be worth a dedicated backport.

[elvisish]

This can be cherry-picked without conflicts to the 3.x branch. I tested this PR on the 3.x branch on both GLES3 and GLES2, and it works as expected there too.

This has significant conflicts now, so would be worth a dedicated backport.

I thought this was for 3.x? This was started before 4.0 was even released.

[Calinou]

I thought this was for 3.x? This was started before 4.0 was even released.

The code in this PR changed quite a bit compared to its first revision, and master started diverging more and more over time. The more time goes on, the fewer PRs can be cleanly cherry-picked from master to 3.x.

[elvisish]

I thought this was for 3.x? This was started before 4.0 was even released.

The code in this PR changed quite a bit compared to its first revision, and master started diverging more and more over time. The more time goes on, the fewer PRs can be cleanly cherry-picked from master to 3.x.

There were some original pushes last year that never made it, surely those would have been relevant for 3.x then as they would be now? @clayjohn did a revision at some point, what caused it to be shelved until 3.x became non-priority?

[Zireael07]

@elvisish Many PRs take a looong time to get merged, for whatever reason (personally I think it's the sheer number of PRs open vs small number of contributors who can merge)