This question relates to Unreal Engine’s dynamic level streaming system. Here’s some context:
Our application uses a persistent level that contains a number of predefined sub‑levels. These sub‑levels include shared assets such as the vehicle, drive‑mode effects, the avatar, and other common content. They are configured directly within the persistent level and are shown or hidden at runtime using UGameplayStatics::LoadStreamLevel, which loads instances of ULevelStreaming. This setup works reliably.
Our theme system introduces additional requirements. Based on the active theme, we need to load extra additive levels alongside the persistent level. These theme‑specific levels cannot be known at build time, so they are not sub‑levels of the persistent level. To load them, we use ULevelStreamingDynamic::LoadLevelInstance, which creates ULevelStreamingDynamic instances. Because these levels are not part of the persistent level’s streaming hierarchy at build time, the persistent-level streaming rules do not apply. The benefit is that each theme can dynamically load and unload its own geometry as needed.
This approach mostly works—but we’ve encountered a significant limitation: levels loaded dynamically via ULevelStreamingDynamic do not load their own sub‑levels, even when those sub‑levels are set to “Always Loaded.” This includes sub‑levels that contain static lighting data (e.g., lighting scenario sub‑levels). Consequently, lighting scenarios embedded within those dynamically streamed levels never load.
I attempted to manually load these sub‑levels via C++. They did appear to load, but the resulting lighting was completely black, and I did not investigate further.
So the core question is:
Does Unreal Engine support dynamic level instances that contain their own sub‑levels—including lighting scenario sub‑levels—and, if so, what is the correct workflow to ensure they are loaded and lit properly? I really do not want to switch persistent levels since we are one world with geo being streamed out. We are not a game buy an HMI app so world partition does not apply to us.
Thank you.
[Attachment Removed]
Hello!
"This approach mostly works—but we’ve encountered a significant limitation: levels loaded dynamically via do not load their own sub‑levels, even when those sub‑levels are set to “Always Loaded.”
I can confirm this is an engine limitation: Load Level Instance does no attempt to detect sub-levels to spawn those as well. Sub levels work only when the map owning those sub levels is the persistent map.
“I attempted to manually load these sub‑levels via C++. They did appear to load, but the resulting lighting was completely black, and I did not investigate further.”
Was the resulting lighting black only in the build, or also in PIE?
I attached a zip project where I experimented with creating a custom WorldSubsystem that auto-detects sub-levels of a level loaded via Load Level Instance. Then, with a custom function I can spawn that sub-level manually via more Load Level Instance calls. I’ve gotten that working with baked lighting, that lights the spawned level’s static geo correctly via Lighting Scenario sub levels, and attached that as a ZIP project:
- In the initial map MAP_Base, check the level blueprint for test keys
- Package the project and launch the game, or start PIE
- Press P first to spawn MAP_Spawned, which has lighting scenario sublevels
- Press N, M to toggle those lighting scenario sublevels via a custom function
Important: Lumen has to be disabled in that map area, or for the project, for the baked lighting to be visible. More info here.
The example world subsystem implementation might be of use! However, know that since this way of using sub-levels is beyond what’s intended to work, we can’t provide much more support beyond this. The static light sources in your sublevel will still dynamically light static geo in your persistent level (the outermost level from which you spawned the Level Instance with sublevels) and will warn about unbuilt lighting. You’ll have to make sure that the custom world subsystem logic doesn’t fire on levels unintentionally.
Looking forward to hear whether the custom solution suits your needs. I’m also curious what your expectations are with respect to static lights in the sub-level interacting with geometry that it couldn’t prebake, i.e. from the outermost persistent level?
[Attachment Removed]