Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix proximity fade's world_pos is calculated incorrectly when in gl_compatibility #89966

Closed
wants to merge 1 commit into from
Closed

Fix proximity fade's world_pos is calculated incorrectly when in gl_compatibility #89966

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions scene/resources/material.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1619,6 +1619,11 @@ void fragment() {)";
code += R"(
// Proximity Fade: Enabled
float depth_tex = textureLod(depth_texture, SCREEN_UV, 0.0).r;
)";
if (OS::get_singleton()->get_current_rendering_method() == "gl_compatibility") {
code += " depth_tex = depth_tex * 2.0 - 1.0;";
}
Comment on lines +1623 to +1625
Copy link
Member

@Calinou Calinou Mar 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make this part be introduced by the shader preprocessor, instead of a C++ condition? This way, if you convert the BaseMaterial3D to a ShaderMaterial (making its shader code fixed), it'll keep working if you switch rendering methods afterwards. This is also important to handle situations where a project can fall back to Compatibility if Vulkan isn't supported.

(Also, I thought we already had automatic depth correction when using the Compatibility rendering method, so we wouldn't have to do this.)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed it would be great if the depth_texture was driver agnostic, so the same shader code would work regardless of renderer. Or a preprocessor macro that converts it into 0-1 (and does nothing if Vulkan).

Copy link
Contributor Author

@jsjtxietian jsjtxietian Apr 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry for my previous explaination of this problem, let me put it more clearly: depth is 0-1 but the ndc is different in opengl and vulkan. It's introduced in #54285, it changed to vulkan way of ndc so it caused this issue.

Visual shader also use an if here, see #74910. But we'd better not use this approach as Calinou mentioned.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 4.4+ we now have a way to do this with preprocessor defines. I made a PR: #100220.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 4.4+ we now have a way to do this with preprocessor defines. I made a PR: #100220.

Seems pretty reasonable. Closing this pr now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your approach may still end up being the right one, actually. It looks like preprocessor macros don't quite work right now in the generated shaders in materials. We'll see if that ends up being considered a bug or not.

Copy link
Contributor Author

@jsjtxietian jsjtxietian Dec 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like preprocessor macros don't quite work right now in the generated shaders in materials.

I suppose this can be tweaked a little? Not sure it's a bug or not, but worth investigating.

code += R"(
vec4 world_pos = INV_PROJECTION_MATRIX * vec4(SCREEN_UV * 2.0 - 1.0, depth_tex, 1.0);
world_pos.xyz /= world_pos.w;
ALPHA *= clamp(1.0 - smoothstep(world_pos.z + proximity_fade_distance, world_pos.z, VERTEX.z), 0.0, 1.0);
Expand Down
Loading