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.

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 voxel GI issues (2) #76550

Merged
merged 1 commit into from
May 3, 2023
Merged

Conversation

RandomShaper
Copy link
Member

Follow up of #76437, in the spirit of what I suggested here: #76437 (comment).

Fixes additional manifestations of #76243 when other effects are toggled (I've experienced, and confirmed no longer an issue with this PR, with SSAO). It may also fix other still not caught bugs.

Copy link
Member

@clayjohn clayjohn left a comment

Choose a reason for hiding this comment

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

Looks good!

@Calinou
Copy link
Member

Calinou commented Apr 29, 2023

It may also fix other still not caught bugs.

It might be worth checking whether this resolves #55334. (The issue can be reproduced in https://github.com/Calinou/godot-reflection/tree/voxelgi if you want to check there.)

@jcostello
Copy link
Contributor

It may also fix other still not caught bugs.

It might be worth checking whether this resolves #55334. (The issue can be reproduced in https://github.com/Calinou/godot-reflection/tree/voxelgi if you want to check there.)

Does it make sense to combine both?

@Calinou
Copy link
Member

Calinou commented Apr 29, 2023

Does it make sense to combine both?

In some situations, yes. For instance, if you want fully real-time GI in a specific area of the world, but want to use SDFGI for general open world GI. (SDFGI isn't fully real-time as it lacks support for dynamic occluders and emissive objects.)

@RandomShaper
Copy link
Member Author

I've included another fix in the commit; namely, initializers added to some fields of LightInstance.

Without this extra change, I was being able to reproduce #76243.* And, considering the kind of fix, @Calinou's hypothesis about optimization levels playing a role makes full sense. Without initializers, garbage data was reaching the renderer and, if certain values happened to be Inf or Nan, related computations delivered wrong values. Specifically, the computation of pssm_coord here was affected:

for (uint i = 0; i < params.directional_light_count; i++) {
if (directional_lights.data[i].volumetric_fog_energy > 0.001) {
vec3 shadow_attenuation = vec3(1.0);
if (directional_lights.data[i].shadow_opacity > 0.001) {
float depth_z = -view_pos.z;
vec4 pssm_coord;
vec3 light_dir = directional_lights.data[i].direction;
vec4 v = vec4(view_pos, 1.0);
float z_range;
if (depth_z < directional_lights.data[i].shadow_split_offsets.x) {
pssm_coord = (directional_lights.data[i].shadow_matrix1 * v);
pssm_coord /= pssm_coord.w;
z_range = directional_lights.data[i].shadow_z_range.x;
} else if (depth_z < directional_lights.data[i].shadow_split_offsets.y) {
pssm_coord = (directional_lights.data[i].shadow_matrix2 * v);
pssm_coord /= pssm_coord.w;
z_range = directional_lights.data[i].shadow_z_range.y;
} else if (depth_z < directional_lights.data[i].shadow_split_offsets.z) {
pssm_coord = (directional_lights.data[i].shadow_matrix3 * v);
pssm_coord /= pssm_coord.w;
z_range = directional_lights.data[i].shadow_z_range.z;
} else {
pssm_coord = (directional_lights.data[i].shadow_matrix4 * v);
pssm_coord /= pssm_coord.w;
z_range = directional_lights.data[i].shadow_z_range.w;
}
float depth = texture(sampler2D(directional_shadow_atlas, linear_sampler), pssm_coord.xy).r;
float shadow = exp(min(0.0, (depth - pssm_coord.z)) * z_range * INV_FOG_FADE);
shadow = mix(shadow, 1.0, smoothstep(directional_lights.data[i].fade_from, directional_lights.data[i].fade_to, view_pos.z)); //done with negative values for performance
shadow_attenuation = mix(vec3(1.0 - directional_lights.data[i].shadow_opacity), vec3(1.0), shadow);
}
total_light += shadow_attenuation * directional_lights.data[i].color * directional_lights.data[i].energy * henyey_greenstein(dot(normalize(view_pos), normalize(directional_lights.data[i].direction)), params.phase_g) * directional_lights.data[i].volumetric_fog_energy;
}
}

*: Interestingly enough, I could only see this specific issue in the D3D12 renderer. That made me think it was a D3D12-specific issue, but "happily" it turned out to be a menace for the whole rendering infrastructure.

@Calinou
Copy link
Member

Calinou commented May 3, 2023

Specifically, the computation of pssm_coord here was affected:

I think this is a bug I introduced when adding either Volumetric Fog Energy or Shadow Opacity properties to Light3D. Sorry for the inconvenience 🙁

@mhilbrunner mhilbrunner merged commit ba32279 into godotengine:master May 3, 2023
@mhilbrunner
Copy link
Member

Thanks! 🎉 Merged.

@RandomShaper RandomShaper deleted the vk_gi_take_2 branch May 3, 2023 18:30
@akien-mga
Copy link
Member

Cherry-picked for 4.0.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants