Realtime lights get baked into lightmaps?

- I create a new scene which by default contains a realtime directional light

- I add a cube and mark it static

- I set the scene to use Baked GI and press bake

Why does this light get baked into my lightmap? Worse yet it is also applied at runtime so everything ends up getting lit twice. What is the point of setting a lights make mode to realtime? I expected that realtime would mean the light is applied only at runtime and not during baking.

 

Is this in 5.3? I mentioned this issue before, and was told it would be fixed in 5.3.

 

Leave precompute on.

 

and then turn it off after? Is that the solution? I don't want to pay the runtime cost of Realtime GI.

 

If you don't move any lights, there isn't much of a cost.

 

I really don't want to waste any CPU cycles on something that I am not using at all. It also means I have to make sure all my dynamic lights that DO move would need to be removed from the GI computations, which I think can be done by forcing bounce to 0?, but that is a lot of hoops to jump through just to have baked lighting behave in a sane fashion. I am hoping they actually address this major issue with the baked path. It is almost completely ignored it seems.

 

You can switch the lights that do move from GI: Realtime to None, which you should be doing anyway.

What was described in the first post is intended behaviour, it's not a bug.

 

So it is intended behavior that a realtime light has its direct light contribution baked into the lightmaps when only using baked GI? In other threads people from Unity have said that this was a bug to be fixed. It is really hard to imagine how having a light apply it's light twice is intended behavior.

Also, out of curiosity, where does the GI:Realtime to None option live? I couldn't find that property on the light anywhere.

 

You are correct, I was confused (or it was like that in an earlier beta?, or I confused it with the options in Emissions in materials, where the options are "Baked, Realtime and none").

When using Baked GI, it should have it's direct contribution in the lightmap.

Setting the light to Realtime, implies you want to use realtime GI (and realtime light). Then disabling precompute in the lighting panel makes the whole thing weird. (what you are telling Unity is : You want the light to be realtime but you want all lighting to be baked, since you are disabling the precompute, so it's very confusing for Unity to say the least).

What you want is setting the light to Mixed mode. Which doesn't really work right now.

In the meantime, You should set the lights to realtime, if you want shadows from them, and the others to baked. If you don't move a light that is set on realtime, the cost will be very similar to what mixed mode would be.

 

Actually, when I say realtime in a baked scene, what I mean is, I want NO baked contribution from this light, it should only be applied in realtime, which is what the docs imply should happen. Turning off precompute just means I don't want realtime GI, not "no realtime lights at all".

What I really want in a baked path, is the behavior similar to Unity 4, where the light will bake its indirect (GI) contribution, but the direct contribution (and shadowing) is still applied at runtime. Obviously that would need to be an option, since you don't want all realtime lights baking their indirect if they move. I know I am probably hoping in vain for that. At this point I would just be happy if the lights didn't apply twice. Mixed mode would come close, but since that is now pushed til March (I think that is 5.4?), it is not a real option.

The docs indicate that simply having Realtime GI and Baked GI on has large overhead, since the shaders now have to unpack two sets of lighting data and apply them both, not to mention the extra memory.

 

Realtime in light -> Precompute
Baked in light -> Baked GI, (direct contribution is baked as well)

Having realtime in light and then turning precompute off is.... ????????

What you want is Mixed, but it doesn't work properly yet.

Until then, you need to stick to the Realtime, precompute path.

 

No, I don't think it is that complicated, a realtime light with precompute off should just apply the light at runtime rendering. GI is not a requirement for all lights, precompute is only for GI. I feel like we have a fundamental difference in understanding of a realtime light.

Only having baked GI with precompute off should not prevent the use of real time lights in your scenes, I don't think. Nowhere in the docs does it indicate that this should be the case.

 

What does Mixed refer to then, going by the way you define things?

 

(from the manual : Realtime works both for Precomputed Realtime GI and when not using GI.)

Using ticking precompute off and having Baked only does not mean "not using GI".

 

Sorry,
mixed , based on the description, that lightmap data is baked into static lightmapped objects, and applied dynamically to dynamic objects.
Realtime, applied dynamically to both static lightmapped and non-lightmapped objects,
baked, applied to static objects via lightmap and dynamic objects via light probes.

From the lighting and rendering page:
The default baking mode for each light is ‘Realtime’. This means that the selected light(s) will still contribute direct light to your scene, with indirect light handled by Unity’s Precomputed Realtime GI system.

However, if the baking mode is set to ‘Baked’ then that light will contribute lighting solely to Unity’s Baked GI system. Both direct and indirect light from those lights selected will be ‘baked’ into lightmaps and cannot be changed during gameplay.

Selecting the ‘Mixed’ baking mode, GameObjects marked as static will still include this light in their Baked GI lightmaps. However, unlike lights marked as ‘Baked’, Mixed lights will still contribute realtime, direct light to non-static GameObjects within your scene.

Nowhere does it say that realtime lights should bake their direct contribution into the lightmaps. But at this point I can see this discussion is not advancing. I will hope that the Unity team will address this issue, since they have admitted it is not intended behavior in other threads.

 

Thank you!