So is static lightmaps just not a viable thing anymore in UE5?

[TomcaT]

I’ve been trying to find a good way to greybox and prototype levels for my game. I used to use BSP for that in UE4, replacing it later with meshes. With UE5, cubegrid is really powerful and I’d like to explore using it. Even for a simpler game I could use it for level creation without the need for meshes depending on the art style. The main problem I keep running into, is that static lightmaps don’t work with either of them in UE5.

My projects are usually set for low end machines, so no lumen, no virtual shadowmaps, no raytracing - just good old fashioned UE4 style baked lightmaps. But doing that continually produces terrible results:

• If I use cubegrid, even with ‘generate lightmap UVs’ and changing the result - unless the LIGHT actor itself is static, it doesn’t bake, just acts as though there is no shadow casting.
• If I use BSP, the same is true. Unless the light is static, it doesn’t bake.

The sun, for example, should be stationary - but this makes it so there are no shadows on the map for that light, which is terrible at expressing the idea of the final image.

I could go through and use hundreds of ‘blockout’ static meshes but that is inflexible and extremely backwards for level design.

I’ve asked a dozen times since UE5 came out but no one has ever answered, and it doesn’t seem like anyone else cares about this particular issue - but not everyone wants to use lumen, or hundreds of meshes. A level editor should come with a geometry editing toolkit that at least works.

So hopefully someone at Epic can see this and explain why it doesn’t work - because at this point, over a few years of trying over and over to make it work, I have no answer.

[Shmoopy1701]

@TomcaT

• If I use cubegrid, even with ‘generate lightmap UVs’ and changing the result - unless the LIGHT actor itself is static, it doesn’t bake, just acts as though there is no shadow casting.
• If I use BSP, the same is true. Unless the light is static, it doesn’t bake.

That is working as intended. Only “static lights” will bake onto “static geometry”. Note also that:

• any material on a static mesh that needs baked lighting must have the “used with static lighting” flag checked
• every mesh needs a sufficient Lightmap Resolution or the lighting on it will be super chunky

Static Light Mobility In Unreal Engine | Unreal Engine 5.4 Documentation | Epic Developer Community (epicgames.com)

For low end and legacy projects, you will have like 95% static lights and a few strategically placed stationary or dynamic lights for character real-time shadows.

I am involved with multiple UE5 projects that use good old fashioned static lighting with Lumen turned off. It is perfectly viable. Any questions let me know.

[Fafhrd]

@Shmoopy1701

That is working as intended. Only “static lights” will bake onto “static geometry”. Note also that:

That’s not 100% correct. Indirect lighting from a stationary light should still be getting baked. Direct shadows from a stationary light will always be real-time, even with static geometry. So TomcaT should still be seeing shadows.

I’ve seen an issue with 5.2 where stationary lights weren’t casting shadows unless I enabled Virtual Shadow Maps, or set shadow quality to high. Not sure if it was still an issue in 5.3+, or if it was just an issue with the custom 5.2 build I was using (they had some weird scalability defaults)

[TomcaT]

Thanks for the replies, I’ll clarify what the issue was in more detail, but I did find a solution actually in the strangest place.

The core of the issue was with greyboxing. I know in a final render of a level, static and stationary lights work just fine. I’ve done that process in UE4 hundreds of times, and it works just the same in UE5.

My issue with UE5 has been while developing a level or an environment, at the greybox stage, I used to use BSP and when baking lighting it would give you a ‘vibe check’ basically. Since you could bake static and stationary lighting to it after a rebuild and building geometry.

I’ll emphasize that after a lot of messing around, the sole remaining issue was working with directional stationary lights. Arguably the one light you want to be stationary if the rest of them are static.

In both of the following cases I could not get the greybox geometry to self-shadow from that specific light source. Using BSP, building geo and lighting, and giving it a good lightmap resolution - by all accounts it should have worked but doesn’t. Not to mention the absolute kneecapping of the development experience. Second was using Cubegrid, even with ‘Generate lightmap UVs’ on the plugin settings, even if I manually generated one and assigned it in the static mesh settings, and validated its lightmap resolution, it would still not cast shadows. For both, in my several years of experience as a level designer/level artist, it should have worked - and didn’t.

I did however find a magic tickbox (love unreal) that seems to have been some kind of source of the issue. On my directional light there was a tickbox for Distance Field Shadows.
With it ticked, no lightmaps showing at all.

With it unticked, bam, lightmaps showed up.

I only found this because instead of rightclicking and making a new level in the content browser, I went File > New Level and selected the one that already came with a directional light. That directional light evidently is not a stock one, its got a few settings flipped, this being one of them. Could not tell you why this was the issue, but breaking the mold this process has consistent results.

So far, using cubegrid, overriding the lightmap resolution to fit the scale of the scene, and baking with this configuration of directional light, I’ve had consistent results.

I am still disappointed in the required steps to get this working though. Namely the hidden setting in the Project Settings > Plugins > Mesh Model Tools to “Generate lightmap UVs”. I feel like UE should have profiles that support out of the box static lighting for their tools - particularly since I think Lumen still needs a lot of work for use in most games.

Anyways, thanks for the replies regardless! I did eventually discover an answer, and its great to hear there are people that still do things the old tried and true static route.