Unsure how baked lighting, point light mode Mixed, dynamic and static objects work

[AgusTriesToDev]

As a disclaimer i’ve barely worked with lighting or any other thing apart from the coding side of things and all the documentation and videos I’ve been following are not clearing things out for me. Everything that follows is on unity 2022.3.5f Built-in render pipeline.

So, after failing to work with lighting in my main project I started a fresh new one with everything by default.

A point light in “Mixed” mode and two 3D objects, one as static and one as dynamic, all on a static plane:

After baking:

Here, from what I’ve understood (clearly I havent) when baking, the static objects will have a “fixed” shadow. A shadow that is baked into the lightmap. Well, this must be wrong since the shadow is changing when I move the box and not staying in the same position on the plane:

So whats the point on setting it static?

Also, a whole different thing happens in my main project with the same configuration both for the point light and the lighting settings:

Before and after baking:

The shadow disappears completely for some reason.

So yea, im quite lost at this point and dont really know what I should be looking at.

Any help is appreciated it

[wwWwwwW1]

explanation

Real-time Lights:
The light is real-time and is ignored by the Progressive Lightmapper.

Mixed Lights:
The light is real-time, but the PLM bakes indirect lighting for it.

Baked Lights:
The light is baked, which means it is only visible to the PLM.

Dynamic Objects (Contribute GI unchecked):
The object is invisible during lightmap baking. For example, an emissive object has Contribute GI unchecked, so the PLM won’t bake its emission.

Static Objects (Contribute GI checked):
The object is visible to the PLM, but if you change any static object (transform, material properties, …), the lightmaps need a re-bake to be visually correct.

@agusmazoalarza

Here, from what I’ve understood (clearly I havent) when baking, the static objects will have a “fixed” shadow. A shadow that is baked into the lightmap. Well, this must be wrong since the shadow is changing when I move the box and not staying in the same position on the plane:

I see you switched to “shadowmask” baked lighting mode, the Progressive Lightmapper will bake shadows to “shadow lightmaps”. Under the default “distance shadowmask” mode, the baked shadow is only visible when exceeding real-time shadow distance. You can change to “shadowmask” mode to see baked shadows of static objects.

The square-shaped shadow can be considered as “environment lighting shadows” (from skybox), so it’s not shadows from the point light.

@agusmazoalarza

Also, a whole different thing happens in my main project with the same configuration both for the point light and the lighting settings:

I think you can switch to lightmap debug view and check what is baked into the lightmap and if the objects’ lightmap UVs are suitable.

[AgusTriesToDev]

Thanks for taking the time to clarify it!

About the issue in my main project…

@wwWwwwW1

I think you can switch to lightmap debug view and check what is baked into the lightmap and if the objects’ lightmap UVs are suitable.

…this led me to the shadowmask overlay:

Where I noticed that if I set as active the lights in that room to the right, those colors (which im guessing is representing light intensity?) appear. But if I set active every light I have then the colors move towards other light sources:

Leaving me with no realtime shadows from the dynamic objects on the dark zones.

Apparently im not alone in this .

Is this still a thing? I have around 20 lights. I cant wrap my head around the fact that 20 is too much. How do people do it? Is there any workaround?

I’ll keep investigating and I’ll post whatever I can find here in the meantime.

Thanks

[Pema-Malling]

Shadowmask mode comes with an inherent limitation: There may only be 4 overlapping Mixed mode lights at any given point in space. This is because the shadows are being baked into a texture - the shadowmask - which can only have 4 color channels. The check that determines whether lights are overlapping is not perfect and is a bit conservative, but if all lights on your screenshot are set to mixed mode with shadows enabled, it definitely seems like you have some overlap.

What you are seeing in the shadowmask debug view are the shadows from the shadowmask. Each color represents a different light. When you enable all the lights, you presumably introduce some overlap, which will cause the shadowmask to change in a rather unpredictable way. To illustrate, see this example where 5 Mixed mode lights are casting shadows onto a plane. In this screenshot, the scene has already been baked:

Notice how one of the 5 shadows looks noticeably worse quality than the others. This is because these 5 lights are overlapping, but we are only allowed 4 overlapping lights. The last light thus falls back to being a fully baked light. This can be verified by looking at the shadowmask debug view:

Since the 5th light fell back to being fully baked, it will no longer cast realtime shadows. If I add another object to the scene post-bake, this can be observed:

See how the added sphere only casts 4 shadows, instead of 5.

In the future, we plan to improve shadowmask index selection by letting users control the shadowmask indices for lights directly if desired, rather than automatically assigning them based on calculated light overlaps, as this can be a bit limiting for some scenes. There isn’t currently a supported way to do this, though.

On top of the limitations of shadowmasks, realtime lighting alone has some limitations as well. See this second example, in which all 5 of the lights are marked as Realtime instead of Mixed:

As you can see, shadows are missing for one of the lights. This is due to maximum “Pixel Light Count” project setting, which by default is set to 4. You can find it in “Edit > Project Settings > Quality > Pixel Light Count”. If I set this to 5, the missing shadow appears:

This is intentionally set rather low by default, as realtime lights with shadows are quite expensive to calculate, especially when using forward rendering, which is the default rendering path.