Godot-proposals: Make lights set to 'Bake Mode All' stop lighting baked objects

[Janders1800]

Describe the project you are working on:
Mobile game

Describe the problem or limitation you are having in your project:
With the current implementation if a light is set to Bake Mode ALL it lights two times baked objects (once the baked lightmap and once the light itself) which makes them too bright compared to dynamic objects who only get light once making it a pain and confusing to make it look consistent.

Also what's the point of baking a light on 'Bake Mode All' if is still going to dynamically illuminate (wasting resources) baked objects?

Note: Dynamic objects still need to be able to cast shadows on baked objects.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
If lights set to 'Bake Mode All 'stop lighting baked objects, dynamic and baked objects will get the correct amount of light. Making the lightmap process much more consistent and easy to use.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

• A light gets set to 'Bake Mode All'
• All baked objects stop receiving dynamic light from that light and computing shadows from baked objects.
• Dynamic objects can cast shadows on to baked objects (doesn't matter if shadows get added and look a little more dark, thats preferable to the current behaviour).

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Don't think so.

Is there a reason why this should be core and not an add-on in the asset library?:
Its much more intuitive that wen you set a light to 'Bake Mode All' all is going to be baked and it will stop receiving dynamic lighting from that light. It will also make the lighting process much more simple for users and it will give consistent results and better performance.

[Calinou]

Also what's the point of baking a light on 'Bake Mode All' if is still going to dynamically illuminate (wasting resources) baked objects?

You should hide the light after baking using the "All" bake mode. However, the light baker should still take it into account, so you should enable it again before re-baking lightmaps.

This is definitely an usability issue I struggled with in the past. We'll probably have to add another Light property that can be used to hide the light from real-time rendering without excluding from baking.

[Janders1800]

If I hide the light then dynamic objects don't get any light (only indirect light but that looks really bad).

Hidden lights still get baked, that works OK.

[Zireael07]

@Janders1800: For dynamic lighting, use a second light node?

[Janders1800]

Well, I think that actually makes it worse;

• Now you have more nodes to keep track of and a more complicated setup.
• Since there are more lights, worse performance.
• Baked objects also get that light so that makes three lights vs dynamic two, so still no consistency.

This is a "workaround solution" y put together to make a setup that "works nice" with dynamic objects.
The Gold rule here is:

• If the light is going to touch a dynamic object then set the amount of light at normal and the baked objects materials at half brightness.
• If the light is not going to touch a dynamic object but it is in a material that shares lights that they do (the material is at half brightness), then set the light at double brightness and hide light.
• If neither the light and other objects lights are going to touch a dynamic object lights and materials normal and hide lights.

Here a example:
LightMaps.zip

As you can guess this gets really crazy, really fast, in big scenes.

[TheDuriel]

extends <Type>Light
class_name Baked<Type>Light

func _init() -> void:
visible = false

or

extends <Type>Light
class_name Smart<Type>Light

func _init() -> void:
visible = light_bake_mode > 0

Same amount of light nodes. No keeping track of anything.

Or, make a Class which manages two Light nodes for you, and manage your light layers to exclude/include lights as needed. You need to write the code for this _once_, and never again.

In fact, light layers exist to solve the problem you have.

[Janders1800]

Whit the current behaviour the set up of the lights is not that simple, you have to take into account if they are going to light dynamic objects, or if they are going to light materials who are going to be light for lights who are going to light dynamic objects.

The problem is the interaction with dynamic objects. If you move dynamics to another layer then forget about casting shadows, for example, on a baked floor without double lighting the floor.

Also, light layers do not work on GLES2 on stable.

[lawnjelly]

Agreed, current behaviour was very hard to control last time I looked at it. Something for @JFonS to have a look at? There may have already been adjustments to this. His version will be replacing the old as soon as merged:

https://github.com/godotengine/godot/pull/40035

[JFonS]

@lawnjelly My lightmapper PR doesn't change much of the runtime implementation of the lightmapper, only to add atlassing.

I will look into adding automatic detection so lights set to bake mode "All" don't light meshes that use baked lighting. I agree it makes a lot more sense this way and will make setting up scenes with baked and dynamic lighting much easier.

[JFonS]

I opened https://github.com/godotengine/godot/pull/41629 which should address the issue at hand. Feel free to test/review :)

[Janders1800]

Nice! Do you know if it will make it to 3.2.3?

[Calinou]

@Janders1800 The 3.2.3 release is imminent, so I think this is more likely to land in 3.2.4.

That said, since baked lightmaps are hardly usable in 3.2.x already (at least until https://github.com/godotengine/godot/pull/40035 is merged), it probably doesn't hurt to merge it right away…

[Janders1800]

Yes please, I intensively use lightmaps for my game. And I can tell you this improvement will help a lot setting up scenes.

[JFonS]

https://github.com/godotengine/godot/pull/41629 was merged, so I'm closing the issue :)