Efficient editor workflow for seamless level streaming in UE5? Issue with hidden sub-levels all being loaded into memory when the Persistent Level is loaded in the editor

neofuturelabs
Mon, 29 Aug 2022 15:17:21 +0000
World Creation

Hi all, I’m working on an indie project in UE5, and hoping some more experienced devs could chip in regarding workflow for level-streaming and how it should be structured in my project.

Basically, I’m working on a level-based game (not an “open-world”), where I want level transitions to occur seamlessly without loading screens. Also, I want to keep things structured as simply and efficiently as possible.
For this project, you can imagine the player character flying into a warp gate, the previous level unloading during the warp gate animation, and the warp tunnel opening up into the next level after it has been loaded in.

Logically, the current system I’m using seems to make sense. I’m using a single Persistent Level which only contains a post-process volume in order to ensure consistent bloom, exposure, and other graphics settings across the game. Each individual level is placed in this Persistent Level, and loading/unloading is handled from C++ according to the game state. When editing level environments from the editor, in the Levels window I would hide all the levels except for the individual level I am working on. This is a fairly convenient way to switch between levels for editing and previewing purposes.

However, there is one major problem with this approach. When opening the editor with the single Persistent Level as the default map, all the data from all the sub-levels is automatically loaded into memory, even if they are all hidden in the Levels window. This greatly increases editor load time and memory usage, to an extent where I think I need to find a workaround or give up on this approach.

Here are the other posts I found about this same issue, neither of which has been resolved:

Ue 4.26.2 - High Memory Usage in Editor - Level Streaming Programming & Scripting

Hi all, I am working on an open world project. My Map is divided in small square. Every square is filled up with 10-15 sublevels. Every Sublevel is driven by a Blueprint streaming method and Streaming level is enabled. Unfortunatly, I am getting those issues: In editor, I have something like 40 gb of memory usage (at this time isn t a problem but it will be as soon as it’ll hit 90 gb) Opening the project is dramatic: although all of my levels aren’t visible neither loaded (they are d…

Is level streaming free memory in editor? World Creation

Can somebody told me, when I toggle off eye button, my memory stats do not change. Should they change in editor? And will they change in builded project? (Sorry for my english) [229183-11.jpg] [229184-12.jpg]

This post mentions that enabling the “Use Background Level Streaming” Project Setting would prevent invisible levels from getting automatically loaded into memory in the editor. However, I tested both enabled and disabled, and there wasn’t any difference (all data is loaded into memory regardless):

Why are my sublevels loaded automatically? Programming & Scripting

Hi there, I have a setup with a persistent level containing game logic, and a number of sublevels containing art assets. I don’t have any streaming volumes, and I have set the “Initially loaded” flag to false on all sublevels. My intention is to load the sublevels via blueprints when I reach certain checkpoints and not before. When I remove all sublevel loading nodes from my blueprint I’m expecting the game to load up quickly and for the memory usage to be low (since I’m only loading game logi…

So I was wondering if anyone happens to know a solution to this problem, or perhaps a better workflow or way to structure level data?

The only alternative I’ve thought of so far is to create an additional Persistent Level for every level in the game (contents: 1. a “common data” level containing the post-process volume + 2. the individual level data). These Persistent Levels would only be for the purpose of previewing/editing levels in the editor, and wouldn’t be used in the final game. Since each of these would only contain the data for a single level, the above memory issue would be avoided. This seems like it would work, but not necessarily be as convenient/simple as my original approach.

4 posts - 3 participants