Hello. We are currently structuring our levels using World Partition, and I have a question regarding this.
The approach we intend to adopt is a “Nested Level Instances” structure, where we add another level instance beneath an existing one and place yet another level instance within that. (e.g., Room Level Instance -> Floor Level Instance -> Building Level Instance -> Main World Placement)
Before fully implementing this structure, we would like to seek Epic Games’ advice on several technical considerations and precautions.
1. Structural Suitability and Engine Recommendations
We would like to know if a structure involving multiple levels of nested Level Instances is an officially recommended workflow by Epic Games for creating large-scale World partition maps. Please confirm if there are any internal engine limitations that arise as the nesting depth increases, or if there is a recommended maximum depth.
2. Rendering Performance and Optimization (Lumen / VSM / Nanite)
I am curious about the impact of simply nesting Level Instances on runtime rendering performance (draw calls, culling, etc.). In particular, our project actively utilizes Lumen, Virtual Shadow Maps (VSM), and Nanite, so I would appreciate your advice on whether the nested structure is likely to cause overhead in the performance or caching efficiency of these rendering features.
3. Known Editor and Cooking/Packaging Issues
If there are any known bugs or points of caution in the workflow pipeline that we should be aware of when implementing this structure using the latest engine version, please share them with us.
Nesting LevelInstance is supported by the engine. We recommend to try to limit the number of levels as this can quickly become challenging to manage.
Structural Suitability and Engine Recommendations
You should prefer the Embedded Level Behavior mode to avoid streaming hitches at runtime. This mode merges the level instances content into the main level cells at cell generation time (PIE & Cook). This result is less levels to stream. The Standalone mode keep the LIs as extra levels that need to be loaded separately.
Rendering Performance and Optimization (Lumen / VSM / Nanite)
Using the Embedded mode also allows for the Runtime Cell Transformers (ISM & FastGeo) to transform the instances of the same mesh into constructs that are lighter when rendering
Known Editor and Cooking/Packaging Issues
There are a few known issues related to hierarchy of Actors and LevelInstance. Avoiding hierarchies as the Outliner level is the best way to avoid problem. We are working on resolving those issues as this should be properly supported
The following EPS case contains a report and the explanation for a potential fix for one of the knows issues: [Content removed]
If you are planning to use the Runtime Cell Transformers, I recommend integrating CL44081791 (FastGeo) and CL48817083\CL49332332 (ISM).
It can sometimes be tempting to create hierarchies of actors in the level Outliner to organize the content of a level. The problem is related to the way the actor hierarchy is maintained at different stages of the pipeline (load, cook…). We have seen a few cases where Actors “lose” their parent and end up at the origin in the cooked game. Actor folders are safe as root (parents) but BPs should be avoided until version 5.8.
One thing I forgot regarding nesting is that we found out that too many nesting can quickly become confusing from a management standpoint as the ripple effects of changes get harder to predict as the complexity grows.
Hello. Thank you for taking the time to address my question.
Regarding your response,
“There are a few known issues related to the hierarchy of Actors and LevelInstances. Avoiding hierarchies at the Outliner level is the best way to prevent problems. We are working on resolving these issues, as this functionality should be properly supported”
I’m having trouble understanding this part. Could you please provide some specific examples? Also, is this issue directly related to nested LevelInstances?