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

BakedLightmap ignores environmental light energy settings #47785

Closed
kalbfled opened this issue Apr 11, 2021 · 10 comments
Closed

BakedLightmap ignores environmental light energy settings #47785

kalbfled opened this issue Apr 11, 2021 · 10 comments
Assignees
Milestone

Comments

@kalbfled
Copy link

kalbfled commented Apr 11, 2021

Godot 3.2.3 and 3.3rc8
Nvidia GTX 980 with driver version 450 on Ubuntu 18.04
GLES2 renderer (not tested with GLES3)

Issue #23948 might be related.

Issue description:
Baking environmental light does not work as expected. I created a scene with only environmental light using the default environment, set the background and ambient light energies to 0, and baked using BakedLightmap. In Godot 3.3rc8, the resulting images are not black with BakedLightmap.environment_mode set to "Scene". Godot 3.2.3 does not have the environment_mode property, and it behaves like "Scene" in the newer version. In 3.3rc8, setting environment_mode to "disable" gives me a black image, as expected.

In 3.3rc8, seting the sky, sun, and ground energies of the default ProceduralSky to 0 gets me a black image, but this is counterintuitive. The documentation does not discuss this either.

I have also noted that the viewport display doesn't always update after baking light. Sometimes I have to close and re-open the scene.

For additional context, see this question on StackOverflow.

Steps to reproduce:
See the attached project.

Minimal reproduction project:
baking_bug.zip

@JFonS
Copy link
Contributor

JFonS commented Apr 22, 2021

I opened #48089 which should fix the issue.

@akien-mga akien-mga added this to the 3.4 milestone Apr 22, 2021
@Calinou
Copy link
Member

Calinou commented May 4, 2021

Fixed by #48089. If you can compile the 3.x branch from source, feel free to test there to make sure 🙂

@Calinou Calinou closed this as completed May 4, 2021
@kalbfled
Copy link
Author

kalbfled commented May 21, 2021

It isn't obvious to me that this is fixed in 3.3.1 by #48089. Perhaps I misunderstand how baking light is supposed to work.

Here is my scene with only the default environment at default values and no baked light. (BakedLightmap.light_data is empty.) When I run the game, it looks exactly like what I see in the view port. If I modify the background energy and re-run, I see that change reflected.

env_no_bake

Here is my scene from a distance. I have the BakedLightmap extents surrounding everything. I'm not sure if it matters for baking, but I verified in Blender that the normals of the interior faces of the walls point inward.

BakedLightmap_extents

Now I bake the environmental light. There are no other lights affecting the scene. My expectation is that it should look the same as in the first image, but it's much darker. When I run the game, I see the same dark scene.

env_baked

@JFonS
Copy link
Contributor

JFonS commented May 21, 2021

Baking the environment still takes into account occlusion from the scene, so in your case environmental light only can get in through the windows.

We could add an option to bake the environment without occlusion, but I'm not sure if it makes a lot of sense... what is your use case here?

Some other options that come to mind are using the "Min Light" property or maybe adding an option to have light maps apply on top of the regular environment lighting. Again, it depends on the use case :)

@kalbfled
Copy link
Author

kalbfled commented May 21, 2021

My use case is this website. I want to bake to get the best performance on low end hardware. The scene is static except for the player, which does not cast shadows (although this will change later).

I tried using min light. It seems to work, but it looks bad (flat). I also encountered the unpredictable problem of the scene not updating in the view port after baking. After changing min light from black to hex 333333, only the furniture got brighter.

env_333333_min_baked

However, everything was brighter when I ran the game. I cleared the light data and re-baked. Then the view port matched the running game. That looked like this:

env_333333_min_baked2

I still don't understand why the non-baked and baked output differs for a scene with static lighting. Does the view port render not consider occlusion? Even if it doesn't, would the running game take occlusion into account?

The min light setting seems redundant to the environment's "Ambient light" settings.

@kalbfled
Copy link
Author

I've chosen to work around this for now. I added back all the lights in the scene (omni + emitter material), set BakedLightmap.environmental_mode to "Disabled", and baked. I'm baking "all" for the OmniLight. It looks good enough.

bake_all_no_env

@JFonS @Calinou @akien-mga
I continue to think that baking environmental light is broken in Godot and that this issue should not be closed. I tried two methods to lighten the dark areas in the current output, and neither worked.

  1. I set BakedLightmap.environmental_mode to "Scene", set the default environment's "Sky Contribution" to 0, adjusted the ambient light energy, and re-baked. I did not observe any effect.
  2. I brightened the OmniLight's shadow color, but I did not observe any effect.

I suppose I could have dialed up the BakedLightmap's "min light" property. I still don't see how it isn't redundant to the ambient light energy.

I searched YouTube for "Godot baking light" and watched a few of the top tutorials. They all begin with adding a WorldEnvironment node to the scene to remove the default environment's effects. (These are pre-3.3; could set the BakedLightmap's environment mode to "Disable")

@Calinou
Copy link
Member

Calinou commented May 23, 2021

I brightened the OmniLight's shadow color, but I did not observe any effect.

The Shadow Color property is likely ignored by the lightmapper, but Shadow Color has been removed from 4.0 anyway for performance reasons.

@JFonS
Copy link
Contributor

JFonS commented May 24, 2021

@kalbfled Again, the environment baking is not broken.

Environment lighting is done by all the light coming from the sky. In realtime (using the environment node) this lighting doesn't take into account the scene geometry and it affects all the surfaces equally. This is done because it would be too costly to compute in real time, so environment lighting is normally used in exterior scenes, where the sky is not occluded.

Light baking uses path tracing to simulate real lighting, so the environment light only affects surfaces it can reach. In your example only the window lets sky light come through, so you get a very dark result, and this is expected.

I mentioned the "Min Light" property because it applies a minimum amount of light to all surfaces, regardless of occlusion, and from your comments it seemed like you were trying to achieve exactly that. Notice how "Min Light" is not redundant with environment lighting: one takes occlusion into account while the other is applied on all surfaces equally.

Finally, if you only want a constant amount of light on all surfaces regardless of sky occlusion, you don't need to use a BakedLightmap. You won't get any performance benefits from it over just letting the environment light the scene. Baked lighting could even be slower in some cases, since you are reading all the lighting from a texture while the environment will simply apply a constant value to the whole scene.

@kalbfled
Copy link
Author

Thank you for spelling all this out for me. This is the answer I needed. The basis for my misunderstanding was this documentation, which says that ambient light affects all geometry equally. It does not say anything about baking or occlusion, and I couldn't find that distinction anywhere in the documentation.

@Zireael07
Copy link
Contributor

@kalbfled: "Ambient" light has nothing to do with baked light.

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

No branches or pull requests

6 participants