Download

Question about setting up Level Streaming

I’ve read the doc info and watched a few youtube tutorials but still have a hard time understanding the concept of layer streaming. I’m hoping that someone can answer the questions below so I feel confident enough to implement layer streaming to help with resource use while we are in production.

What I’ve done.

On a test map I created two new levels by going to Window > Levels and added streaming level volumes (which I sized to fit the areas I needed) that were adjacent to each other and not overlapping. I can now see two .umap files (A & B) in addition to my initial project file.

My questions:

Are the new .umap files reflections of the persistent (master) file or short-cuts to areas within the persistent file?

Are the changes made to the .umap sub-level reflected in the persistent level?

If I delete the .umap sub-level(s) will that the area content of the persistent level be deleted as well?

Are the sub-levels part of the overall project when it comes time to package? Of does some procedure need to be followed to ensure all the sub-levels are included with the persistent level when packaging?

I understand that Streaming Layers can be made into blueprints. Is this something that is better/more efficient to use Streaming Layers? If so, what advantage does creating a blueprint for Streaming Layers offer?

Thanks in advance

Wrangler

I’m not sure if you have an accurate picture of streaming levels.

The volumes themselves don’t create the streaming levels or separate out the models that are in the Persistent level to various levels. The volumes are used to trigger them on and off. So let’s say you are moving through a landscape and over a hill is this house with furniture etc… you hit the trigger (the volume that encapsulates the hill before the house) before going over the hill and it tells UE4 to load stream in the level.

Streaming in the level means it’s loading it or unloading it into the current level.

When you create the new level (Create New with Existing Actors). It will then create a new level that you can call houseInWoods let’s say. Now I don’t usually use the volume to bring in my levels, I use triggers to bring them in mostly so i have to make a blueprint call that triggers it on. I don’t remember if the volume does that automatically, but I somehow doubt it, as the volumes are just that, generic volumes.

In the Persistent level you need to make a call to the volume (Which therefore needs to be in the Persistent level) and that will stream in the houseInWoods.

the node you’re looking for in BluePrints is LoadStreamLevel and to get rid of a level, you UnloadStreamLevel.


Once you create new levels that are listed in your Levels Detail, you can add those to your levels (RMB move actor to level).

If you double click on that level it will be highlighted, thus active. So any new objects you make will be created within that level, not the Persistent level. That’s important to remember. You want actors to go in the various levels, but you can always move them later.


You can also edit the sub level independently. You can do a File Open Level, and open houseInWoods. This may be in a sub folder that you have to look for in your maps though, i find this part of level mapping inconsistent but it’s not too confusing.

Any changes you make in this level when working on it independently will be seen when you next open your Game from the top (Persistent) level again of course.

Keep in mind if you are working like this though, independently that any new directional lights you add while working, will mean you start doubling up your shadows and lighting info. I generally keep my lighting in my Persistent Level.

I know this is pretty confusing stuff, but start small. Make a simple scene, put a few objects in a new level and make a blueprint in the Persistent level that triggers it on.

So a streaming volume is nothing more than a teleport shortcut embedded in the level to minimize the need to travel? I thought it was more to do with resource conservation when working with larger levels, allowing each team member to directly open a specific portion of the level without pulling the entire world down to their system.

I agree this is very confusing. I wish UE would more fully address this since, if I’m right, it could be very useful.

thanks

No, it’s not teleporting at all.

Think of it like modeling software like Maya or even Sketchup. If you have a scene open that you are working on, but want to bring in a model of a couch or a tree, you import another model. You can build an entirely different scene and import it into Maya or other modeling programs.

This is about creating a scene, that is built to fit into your current scene, (maybe you have a landscape that it works with, but the landscape is in the Persistent level).

This is more about turning groups of objects on and off as you approach them. So if you are in a maze, and you have a maze red room, and a maze blue room separated by a hallway, as you go down the hallway the door to the blue room you left closes, you trigger an Unload Streaming Level (because you put the actors of blue room in their own streaming level) and that level turns off.

At the same time or just after, the red room streams in. This keeps the engine from having to carry too much information, and that doesn’t necessarily mean you should use it willy-nilly, building games is complex.

Another use might be that your persistent level might just show a demo and a start game interface, then when you begin it loads up the first Maze level, and as you progress it unloads the maze level, and loads the maze2 level. Leveling up.

So there are different reasons to use streaming, but there are complexities too.

It helps to try it out too in a practical example. The content examples in the Launcher Learn tab have some simple streaming examples iirc…

As a primer this might help to understand level streaming a bit more.

Leave streaming could be a bit confusing as it is called level streaming so by default it has a connotation of use

So

Yes you could use level streaming for this purpose directly and is probably the intent of the design with the more practical reason to use blueprint controlled streaming is to decrease the memory foot print requirements of say a 32 gig environment down to a much more client friendly 4 gig per block during the iteration process.

Very helpful video…thanks! This is not a very well documented concept it seems, it could have been worded better.

So essentially you’re placing things in the level, or assigning parts (region) of an existing level to a level stream so you can isolate it by removing from the persistent level. Once you add or make your adjustments you then transfer your assets (paraphrasing) to the persistent level. In this way a player with a weak system can work on an area/objects without the weight of the rest of the level impacting his system resources.

To answer my own questions:

Are the new .umap files reflections of the persistent (master) file or short-cuts to areas within the persistent file? Reflections that are used as temporary workspace who content is transferred to the persistent level permanently.

Are the changes made to the .umap sub-level reflected in the persistent level? Yes, but only when you move them there.

If I delete the .umap sub-level(s) will that the area content of the persistent level be deleted as well? Not if the items were saved/transferred to the persistent level prior to deletion.

Are the sub-levels part of the overall project when it comes time to package? Or does some procedure need to be followed to ensure all the sub-levels are included with the persistent level when packaging?
The sub-levels are workspace used to develop content for the persistent level. They should be vacant when you package since all content should have been transferred to the persistent level already.

Am I now understanding this correctly?

Wrangler, you don’t transfer anything to the Persistent level. Think of it as temporarily Adding and then subtracting.

Once you put actors in the other streaming levels, they stay there and only are added (loaded) or subtracted (unloaded) from you Persistent scene.

Maybe I should watch that video again, thats not the impression I received.

If thats the case then deleting a streaming level would remove all the actors created on that streaming level from the persistent level, correct? If I marked off a large section of a map and created a streaming level with it, deleting that streaming level would remove everything assigned to and everything created within the streaming level?

My hope was to make a grid from my existing level so those on my team could work on specific areas with less impact to their systems. If I must keep all the streaming levels (.umap files) that’s fine as long as they act as one entity when the project is packaged.

thanks for you patience

Wrangler.

Remember that once you move actors to a new level, or create a new level from selected actors, they are no longer in the persistent level.

So yes, if you delete a streaming level form your Levels Details list will remove all those objects from your game. You can simulate this, but clicking the eyeball and watching them turn off. You can do it by “delete” the level:

RMB -> REMOVE SELECTED (see it’s not delete because the level doesn’t get deleted from your disk. If you want to then bring it back in go to Levels above dropdown (in the Levels Detail) and :

LMB -> ADD EXISTING

Yes you can have your team work on levels separately, but I would tend to do want to be careful about this. It’s really easy to accidentally work on the wrong Level, I do it constantly. You can Lock the level that someone else is working on. I think though I would take the tack of “publishing” levels to an area that they get copied to when the person working on it feels they have made significant progress.

So if you set up your Levels, and there are additional streaming levels like, Blue_Hallway, Red_Hallway, Cathedral_Main etc, I’d lock those in your game level that brings all that together.

Have your people work on checked out versions of those levels, so Blue_Hallway_v2 (version 2). At the end of week or whenever they “publish” they copy the Blue_Hallway_v2 into the folder that has Blue_Hallway and overwrite it. It must exist already having been made in UE4 for this to work. UE4 doesn’t just see things copied into folders willy-nilly.

Then the person working on Blue_Hallway_v2 should save as Blue_Hallway_v3 and work on that not v2 any longer. Keep version backups to keep yourselves from having a major accident. If someone overwrites Blue_Hallway_v2 by accident and you do daily updates, then you have only lost a days work.

There are other techniques for multiple developers to work together, but I haven’t investigated the UE4 techniques for this, because I’m a solo developer. However, I do work with many levels in my game, and often I work in not the Persistent level to get at a particular level, like Blue_Hallway, but I just load up Blue_Hallway remembering that if i add lights or stream in my global lights then i have to remove them when I save out.

I take any lighting that should be global to my game, like sky, the main directional light, and fog, and put those in a GLOBAL_LIGHTING level. That way if i am working on Blue_Hallway, all I have to do is stream in that GLOBAL_LIGHTING while I work.

Be mindful of lighting though. If people are sharing lighting things can get quite tricky. It may be better to have separate lighting, but an individual can do the main lighting, save it as a GLOBAL_LIGHTING file, and get that to the team, so they can copy those lights and use them as a starting point for their scene. In vfx we called this pre-lighting, or Look Dev, which is a much cooler title.

Look Dev/Pre-lighters decide the look and how things may work, and get that out to the team so people have a place to start by their lead, and don’t waste time doing the same look development.

Also you will want to experiment with lighting and be aware of issues when streaming levels. Here is an article to help.

https://answers.unrealengine.com/questions/210479/separate-lighting-between-streamed-levels.html

Tim Hobson in the above link has this to say about this important topic:

In the instance above it doesn’t affect lighting at run time because the error message generated from a workaround and no lighting actually needs to be rebuilt.

It’s also not a bug, since it’s a hacky way of getting the above method to work. If there were legitimately objects that didn’t have shadows build in the scene these would use dynamic lighting and cause performance issues.

This is a break down of how I did it above, which may or may not work in your case. It can be an involved setup.

All Lighting is Static/Stationary

4 levels/maps: - Persistent: nothing is placed in this level - Level 1: Couple of meshes and Red Light. - Level 2: Couple of meshes and Blue Light - Level 3: Couple of meshes and Green Light.

Since I knew these levels would be loaded/streamed in via my Persistent level I couldn’t just hide a level and build lighting for each with the light bleed from other levels. To get around this you can open each level individually by double-clicking on them in the Content Browser and then build lighting for each, save and close.

After this, going back to the original Persistent Level and loading in will produce the clean light builds as seen above, but the persistent level will assume lighting has not been built for these levels. It’s not going to default back to dynamic preview lighting, but the warning will be there thus the need to remove the warning with “DisableAllScreenMessages”.

This is excellent information thank you!

We are a small team and, as of now, only half of us can access/open the project (large level). This is one reason why level streaming is appealing, I’m hoping that it would allow those with older and more resource deficient systems to access components of the project to make improvements and additions. In this way, by directly opening the .umap created as a stream, perhaps I can get more of my people adding to specific areas of the level which they can either move to persistent level or as a stream be a component of the persistent level when its time to package/compile. Until those with weaker systems can upgrade its essentially a slow moving 3 man show.

Agan, thank you for your insight, its been very helpful.

hi every body
actually I want to built light my project and it is a very huge project and very large scale, so I want to use Level Streaming to use less RAM so I can built light them Separate, but I don’t know how can I do this? :confused: