Hi there, I have just begun using World partition and seem to have hit a bit of a wall.
Whilst i have been building my scene i have encountered an error message when i try to build lighting - “world Partition maps do not support Static Lighting”. The problem is, i cant seem to find the source at all. I have deleted and stripped my entire scene back to the bare landscape and am still getting this error message?
Now i am fairly new to UE and this solution may be obvious to someone out there.
Any help would be greatly appreciated.
Thanks
Hi, thanks for the reply. I cant seem to see an option to change the static, stationary or movable options under the details panel. Would you be able to point me in the right direction?
Hi, unfortunately not. Ive actually gone back to UE5 EA2 as i don’t seem to run into this problem there. I really hope someone can tell me the solution as i left quite a bit of work behind.
If i find a solution i will be sure to post it here
Two years later, and World Partition still doesn’t support static lighting.
I really hope it will be included in a future version, and that Unreal Engine won’t abandon static lighting entirely.
The combination of the world sizes that World Partition supports, and the distance-based per-actor streaming makes supporting static lighting for World Partition levels wildly impractical. If you need static lighting just make a regular level instead of a World Partition one.
You can also sort of hack it by disabling Lumen, making a non-World Partition level and building lighting in that, and then using an Instanced Level Actor to add that level to a World Partition level. But you won’t get the Volumetric Lightmap for that level when you do that, so you’ll have to fake any indirect lighting on skeletal meshes and moveable objects.
Why do you think it’s wildly impractical? Theoretically, the actors can be loaded at the same time as their light maps, or along with a chunk of light maps. This isn’t a technical problem, something similar is already done with HLOD.
However, I guess they would need to revisit how light maps are handled in the source code, and I don’t think it’s a priority for Epic Games at the moment. Hopefully, it will be done someday.
I need to use static lighting, so I’m already working with a regular level, of course. But my project is an open-world one, and I also need to use World Partition and Level Instances to avoid loading unnecessary things in the distance and to optimize resources.
Not the first completely off the rails laughable idea he wrote on this forum (and won’t be the last).
But hey, at least he seems to learn somewhat, unlike others on here who just troll for trolling sake.
Try world Composition instead.
Not sure if or how its still a thing in the latest.
I would go back to .27, generate what I need, and migrate it to the latest engine version via conversion to see what I get.
Based on that, I’d use the result as a “what to set things to template” and convert th acrive project levels / settings appropriately.
Be mindful that baked lightmaps and landscape shadows have been seriously neglected and still give wildly bad results inclusive of random bias (wait, thats for dynamic, i almost never bake lights because poweing up the 10 computers to make it happen in 1 hours means 10 windows updates at this point , good luck with the swarm thing )
HLODs just look up their lighting data from the already loaded BuiltData of their level, they’re not loading an entirely different BuiltData package.
For a large World Partition open world you’d have to actually break up the BuiltData, because a unified BuiltData package for the whole world would be absolutely immense. So do you break up the BuiltData by Actor? By World Partition Tile and HLOD Tile? Either way you do it you’re adding a significant amount of extra data that you’re loading and unloading as stuff streams in and out. And what about Static Skylights and the Volumetric Lightmap? You can only have one of each of those active at any given time, and you’ve only got so much range from the Skylight before its accuracy starts going bad, and the Volumetric LIghtmap can only be so big (sure, you can tweak the settings to get one large enough to cover your whole world, but you lose basically all the fine detail in it if you do) so that means swapping those out as you traverse the world, and you’re going to get awful light flickering as you do.
No.
It’s would be based on the landscape components on screen which are already handled by the system and can load/unload as needed based on occlusion.
And who said anything about these being even a thing in a STATIC lighting environment?
Why are you making stuff up?
I don’t think you understand the concept behind BAKED lighting. Let me … illuminate (cheap pun? I guess):
You COOK everything exactly like you want it to look.
Then that data is LOADED, instead of being COMPUTED.
Now tell us:
Which version do you think would costs LESS performance wise? (never-mind it’s apparently not a thing anymore in the latest engine).
(and won’t be the last).
, good luck with the swarm thing 
)