-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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.
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
Artifacts in post-processing depth shader on 4.3-RC1 #94777
Comments
It looks like this is the same issue mentioned in godotengine/godot-docs#9591 (see also #86316) Applying this function to each of the normal samples fixes the issue:
I don't think the change mentioned above for |
Interesting! I opened the docs issue for CompositorEffects, and I was only able to discover the problem because the Spatial shader on my quadmesh WAS receiving the correct (converted) normals values, and my Compute shader wasn't. I just confirmed the Spatial shader seems to still be getting the correct normals values in 4.3-rc1. However, when I open your MRP, I am able to reproduce the same artifacts. Here's my Spatial shader. Results were the same with linear sampling. shader_type spatial;
uniform sampler2D normal_roughness_texture : hint_normal_roughness_texture, repeat_disable, filter_nearest;
void vertex() {
POSITION = vec4(VERTEX.xy, 1.0, 1.0);
}
void fragment() {
vec3 screen_normal = texture(normal_roughness_texture, SCREEN_UV).xyz;
screen_normal = screen_normal * 2.0 - 1.0;
ALBEDO = screen_normal;
} |
Very interesting catch! We have code that automatically detects when the normal_roughness buffer is used and it automatically wraps the Here is the generated code:
And
You can see the compatibility code is only added in the first case. Looking into a fix now |
I have a patch that fixes this issue, but it introduces another issue that we have run into before. If we add the compatibility code to ensure that the normal is read correctly, it makes it so that function will always have the compatibility code. Therefore if you call the function with both the normal_roughness buffer and some other texture, it will fail for that other texture. We ran into this issue for XR and ended up just banning passing the screen textures as arguments in custom functions when using XR. I think i can fix both cases by just banning using a screen texture as an argument in one place while using a different texture in another place Edit: That was unexpectedly easy. PR incoming |
Tested versions
Reproduceable in:
Godot v4.3.rc1.mono
Not reproduceable in:
Godot v4.2.2.stable.mono
System information
macOS 14.5.0 - Vulkan (Forward+) - integrated Apple M1 - Apple M1 (8 Threads)
Issue description
I'm using this shader: https://godotshaders.com/shader/high-quality-post-process-outline/
Here it is for Godot 4.2 with all of the irrelevant mobile-related code stripped out:
Behavior in 4.2
Nice outlines, no artifacts 👍
Screen.Recording.2024-07-25.at.10.58.37.PM.mov
Behavior in 4.3
After reading through the Introducing Reverse Z (AKA I'm sorry I broke your shader) article, I made the following changes:
However, running this in Godot 4.3 there are artifacts on sloped surfaces.
Screen.Recording.2024-07-25.at.11.01.34.PM.mov
Steps to reproduce
MeshInstance3D
in the sceneQuadMesh
ShaderMaterial
using the shaderMinimal reproduction project (MRP)
Here is a repo with a reproduction:
https://github.com/TranquilMarmot/godot_4.3_shader_artifacts
There are two folders:
4.2
: Open with Godot 4.2 to see intended behavior4.3
: Open with Godot 4.3 to see broken behaviorThe text was updated successfully, but these errors were encountered: