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

Vulkan: LightmapGI's Directional property only works correctly when lights' bake mode is Dynamic, not Static #49936

Closed
Tracked by #56033
Calinou opened this issue Jun 27, 2021 · 6 comments · Fixed by #61910

Comments

@Calinou
Copy link
Member

Calinou commented Jun 27, 2021

Godot version

4.0.dev (659178e)

System information

Fedora 34, GeForce GTX 1080 (NVIDIA 465.31)

Issue description

Vulkan: LightmapGI's Directional property only works correctly when lights' bake mode is Dynamic, not Static. When Directional is enabled and a light has its bake mode set to Static, it will generate lighting as if only indirect lighting was requested. This makes the scene much darker than it should be, since real-time lighting is disabled on baked objects when the bake mode is set to Static.

Having directional lighting in LightmapGI would be useful when the light's bake mode is set to Static, since this is how you can get the best possible performance while preserving normal map appearance. Otherwise, normal maps become useless for static lights if the lightmap doesn't store directional information.

See also #49935.

LightmapGI Directional disabled, DirectionalLight bake mode set to Static (correct)

LightmapGI Directional disabled, DirectionalLight bake mode set to Static

LightmapGI Directional enabled, DirectionalLight bake mode set to Static (broken)

LightmapGI Directional enabled, DirectionalLight bake mode set to Static

Steps to reproduce

  • Make sure you have meshes with UV2 and bake mode set to Static.
  • Add a DirectionalLight3D node and set its bake mode to Static.
  • Add a LightmapGI node and enable Directional on it.

Minimal reproduction project

test_lightmap_normalmap_1.zip

@Calinou
Copy link
Member Author

Calinou commented Aug 30, 2021

This was confirmed by Saracen on the Godot contributors chat.

@williamd67
Copy link
Contributor

williamd67 commented Nov 14, 2021

The option Direction does not exist in Godot 3.4. The implementation of Godot 4.0 connects Direction to spherical harmonics, which seems to be in an alpha state.

My questions are: should the option Direction exist? In case, the answer is yes, what should the option Direction do?

In case Direction is a valid option, my interpretation would be that directional lights would only be taken into account when Direction is enabled. Correct?

@Calinou
Copy link
Member Author

Calinou commented Nov 14, 2021

The option Direction does not exist in Godot 3.4. The implementation of Godot 4.0 connects Direction to spherical harmonics, which seems to be in an alpha state.

My questions are: should the option Direction exist? In case, the answer is yes, what should the option Direction do?

In case Direction is a valid option, my interpretation would be that directional lights would only be taken into account when Direction is enabled. Correct?

The Directional property toggles support for spherical harmonics, which provides light direction information for normal mapping plus rough reflections. This is expected behavior, as you usually want to disable spherical harmonics when targeting low-end mobile hardware (or to save disk space for mobile/web games in general). Whether it should be enabled by default should be discussed in a different proposal.

The Directional property shouldn't change anything else – all light types should be baked as usual, regardless of the property's value.

@williamd67
Copy link
Contributor

Thanks @Calinou, clear now. I will investigate the `Spherical harmonics' implementation.

@techiepriyansh
Copy link
Contributor

I investigated this issue a bit and found that the culprit might be the disparity between the scaling factors of 1.0 / 3.0 here and 8.0 here.

Actually, the lightmap does store the direct lighting information when the lights' bake mode is set to static. It's just that the scaling factor for indirect lighting is much larger than that for direct lighting; it appears as if only indirect lighting was requested.

Bumping up the scaling factor of 1.0 / 3.0 improves the lighting (with LightmapGI Directional enabled and DirectionalLight bake mode set to Static):

  • Original, without any bumping
    original_without_any_bumping

  • 1.0 / 3.0 bumped up to 6.0 / 3.0
    1_bumped_up_contribution_of_direct_light

  • 1.0 / 3.0 bumped up to 9.0 / 3.0
    bumped_up_contribution_of_direct_light

  • 1.0 / 3.0 bumped up to 15.0 / 3.0
    3_bumped_up_contribution_of_direct_light

  • 1.0 / 3.0 bumped up to 18.0 / 3.0
    bumped_up_contribution_of_direct_light2

On the other hand, scaling down the factor of 8.0 makes the scene even darker:

  • 8.0 scaled down to 1.0 (and 1.0 / 3.0 kept the same)
    scaled_down_contribution_of_indirect_light

With these observations, I suspect that the scaling factor of 1.0 / 3.0 might be wrong and we just need to replace it with the correct one.

@DarioSamo
Copy link
Contributor

Will attempt to reproduce and investigate.

@akien-mga akien-mga modified the milestones: 4.x, 4.2 Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants