Collaborating with Sublevels and Perforce

Hey there,

Coming from the manual about sublevels I thought it would be a way to have people working on a level in parallel, while using perforce as source control.


User A works only on geo.
User B works only on lighting/camera

  1. So I create Level_p as my persistent level. It only contains a postprocessvolume.
  2. I create sublevel Level_cine and move my lights and cameras there.
  3. I create a sublevel Level_geo and move my geo there.
  4. I set both sublevels to “Always loaded”.

What I assumed that would let me do then, is that
User A can check out the geo level and work on the environment, while still seeing any changes made to the cinematic stuff (light and camera).
User B can check out only the lighting/camera level and work on camera/lights, while also seeing changes in the geo level.

What I don´t get:

A) They both need to open the Level_p and then make their sublevel the current level, right?
Do they also both need to check it out?
Can User A only lock the lighting level, without needing to check out the persistent level?
So that User B could only lock the geo level at the same time on his end?

B) When I opened the level_p for the geo user AND locked the cine level, i was still able to pilot the camera, shouldn´t that be locked then and not Move?

C) Am I even getting how this is supposed to work…?

Yup you got it.

Covered under the category of scene management and has been used for years in other types of 3d applications.

In 3ds Max it’s called x-referencing where it solves the OBS problem. (One Big Scene).

The problem with working from the persistent level alone only 1 single developer can work on that scene project alone. Add Perforce to the mix and you have the check in and check out locks to deal with (more on this in a bit).

Using Level Streaming, aka x-referencing, you can have as many developers working on the project at the same time with out having to be concerned your going to mess up the persistent build.

Typical problem dev A and B are working in the persistent level. Dev A commits their “extensive” changes. Dev B commits their changes with out updating. Dev B changes will over write the changes made by Dev A.

Level Streaming solves this problem by eXternally-referencing the level,scene, and that reference is contained with in the persistent level of the master scene.

A and B no longer has to commit the persistent level as the file you are working on is referenced as being external. For that matter if an external file is updated the master is updated in real time.

To learn more just do a Youtube search for 3ds Max x-refercing. Different names but same use.

What else you can do.

1)An external scene can be loaded in and is by default the persistent level of “that” file which means you can add other levels that are part of the main level. So as you say you have a lighting level you can add it to the lvel being edit as a level stream and test for lighting on your edit using the lighting solution of the master.
2) A lighting level can be turned into a lighting scenario. If you label it as a scenario Unreal will generate light maps for that level. You can then have a level for day and one for night
3) Shader compiles are decreased big time as you only have to deal with the single edit level.
4) Since at some point the master will only contain the persistent level containing the external referenced file the same map can be used to create inherited assets necessary to run a custom game type. We have a level,load on bp, that loads in the flags and player spawn points for CTF.
5) My fav. A UE4 map is a UE4 map and the only real difference is the unique components and elements usually provided to the 3rd party mapper. Lets say you made Dust 2. You could have a version for all games using the UE4 engine.

Lot’s more tips but enough to get ya thinking?

As for Preforce. Being part of a large project, over the webs :D, the issue of locking out files became a problem with check in and out. Files tend to be locked out that did not need to be so we went with a manual process instead.


so, i kind of was the only one using the perforce setup like this for a long time, due to time constraints I couldn´t dive deeper.

We´re in a bit of a different scenario with sublevels now:

  1. We have several template scenes set up now in our template depot, that consist of a persistent level and several sublevels. The sublevels contain mostly geo/skeletal meshes, the persistent level only contaings light/postprocess/camera.
  2. When we work on a new project, the idea is that we just duplicate the persistent level, copy it to a new location and then the team member working on it works on that, but keeps all the original referenced sublevels in it.
  3. They should not be able to make any changes in these levels, as they are imported from the template depot using perforce.
    So, any changes they need to make, they make in a subsequence for their project instead (we only use Unreal for cinematics).
  4. When duplicating the file, even though the sublevels do not get altered, they need to be resaved and for that reason get checked out as well.
  5. So in the end, when they try to submit their changelist, they get an error and have to manually move the sublevels from the changelist and revert changes (which also sometimes doesn´t work).

Is there a way around this?

I was thinking we´d maybe change that workflow and instead of copying the persistent level with all the referenced sublevels in it, we just make a template level without these sublevels and then spawn them using the sequencer, but I haven´t tried if that would even work and I don´t know what consequences that might have for any changes they´d make in that spawned sublevel then.

Yet another approach would be to package these sublevels into blueprint levels instead.
I haven´t used these yet though, so I´m not sure what the advantages/drawbacks of this would be, in terms of reusability/consistency of future updates to them vs source control advantages/disadvantages.

Ok, never mind.
I figured it out.
I simply had to change the perforce permission table to only grant read access to all the template files and then only grant write access to the specific folder they work in.

So now, if they try to check out any sublevels, they get an error.
Which is fine, because they SHOULDN´t make any changes to the sublevels directly and (for now, until I figure out blueprints) instead make any edits in a subsequence for that sublevel.

So, if they try to save, they are reminded that they work outside the intended workflow and hopefully don´t loose too much work until they get it…

The only time when this becomes an issue, when they try to use level visibility tracks.
Because whenever they animate a sublevel visibility in sequencer, the sublevel needs to be saved/checked out, which is rather annoying and I don´t know the reason for this.

BUT. Even if they don´t save (because they are not allowed), the visibility track still works for rendering.
And of course they can also still choose to not check it out, but instead just “make it writable” for that, without affecting the original files in the depot.

Still not ideal, but it works for now.