Hello, I have a beginner’s question: I learnt that when using Lumen, all static lights and lightmaps are disabled. Does it still make a difference when using Lumen if I set my lights as static or stationary (are there any engine optimization?), or are they all treated as movable lights without any distinction?
1 Like
If you set your lights to anything other than moveable, you will get message ‘light need to be rebuilt for x object’, and you are using static ( or stationary ) lighting.
If you don’t want that, then always set them to moveable 
Not so, still totally possible.
EDIT: Just to clarify, I mean static lighting with UE5 is still possible, just not at the same time as Lumen.
1 Like
According to the documentation (Lumen Global Illumination and Reflections in Unreal Engine)), enabling Lumen should disable precomputed static lighting contributions, and subsequently, all lightmaps should be hidden.
And in fact, I’ve observed that when I bake static lights while Lumen is active, the resulting lightmaps turn black. On the other hand, stationary lights appear to bake correctly, but I suspect their lightmaps may not be utilized in practice.
This leads me to a broader question: Does altering the mobility settings of lights (from static to stationary to movable) have any impact on the performance of Lumen? I’m looking to understand whether light mobility plays a role when using Lumen for GI and so NOT using baked lighting. And if lumen treats all the lights as movable, may it still be relevant changing the mobility to stationary for example for other aspects like shadow quality or performance ?
1 Like
I think yes. Static lights only have preview shadows (they are not in the game and you can’t set everything on them that you can on dynamic ones (e.g. Distance fields are not there)), while Stationary have per object (or whatever it’s called) and can cause you performance issues…
1 Like
But there is difference for Nanite and NonNnanite meshes with Virtual Shadows and new rasterizer. Virtual shadows are faster with Nanite, because they work with cluster culling, but they did not support Stationary Shadows.
1 Like
Lumen doesn’t do anything special for static or stationary lights. If you don’t use baked lighting then you can just disable allow static lighting in project settings for a small perf boost and reduction in shader compilation. With that option disabled every light becomes basically a movable one from perspective of the engine.
2 Likes
Thanks. Is it possible to get rid of this freaking message? Floods the output log per actor for users who do not use virtual shadows. Map check cannot be used and there is no filter for this:
StaticMeshActor_ mesh 'SM_ uses Nanite but Virtual Shadow Maps are not enabled in the project settings. Nanite geometry does not support stationary light shadows, and may yield poor visual quality and reduced performance. Nanite geometry works best with virtual shadow maps enabled. See release notes.=
In my last job, I had tens of thousands of such messages in combination with the world partition and I had to shut down the engine, because its freeze when i try to check world map.
And I still have one question. If I have a stationary light in the scene, because the lumen does not matter. What happens if I have disable allow static lighting in project settings, Nanite in the scene and switch to medium settings with default scalability config?
Edit: I tested it with pointlights on 5.3… It doesn’t really seem to matter even with medium settings. Anyway, it would be nice to remove the confusing reports from the logs, when static lightning is off.
And what you wrote would be nice to write in the documentation about the lights.
and update popups
And the third question. If Lumen does not depend on light mobility settings. What happens in the case of the scene if the skylight is switched to Static? Even if Static lightning are off. Eg. test scene is quite different:
My point was that there are no performance benefits of different mobility types with Lumen. Static lights are completely removed from the renderer, as renderer assumes that they are baked and already accounted for in the lightmap. Static skylight also won’t work with Lumen.
Internally we just flip Allow Static Lighting to 0 and then every light effectively becomes a movable one.
As for the !VSM+Nanite in general we advise to use both together, as this should be the fastest path. And for the message, may be best to fill a bug.
1 Like
“And for the message, may be best to fill a bug.”
No, thanks. Its not for me anymore. But for users.
Is this only true from the perspective of Lumen or does it apply to all the rendering features as well?
Like, speculating ignorantly I could imagine if the engine knew a light wasn’t going to move, maybe shadowmaps could be cached more efficiently, might make light culling easier… I don’t know if that’s actually how any of it works though.
1 Like
Thanks for your response! Just a little follow-up question…so when using lumen you always suggest to disable “allow static lighting” for a small perf boost and you can consider all lights as movable… but does lumen still render stationary lights differently from movable ones? (For example i see slightly different shadows cast from a stationary directional light compared to a movable one)
Ok but when using stationary lights i don’t get the same error message to rebuild the scene, so i was wondering how lumen handles stationary lights and if they become exactly as a movable light or there are still some differences
Yes i’d like to know if that’s the case
Lighting mobility controls basically which lighting method should be used - baked shadows, dynamic shadows etc.
While it could be used for some optimizations, it’s not really useful. We have like maybe 100 lights tops in a scene and checking if they moved isn’t really a big deal, so no point in using mobility and hoping that users set it up correctly.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.