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
- So I create Level_p as my persistent level. It only contains a postprocessvolume.
- I create sublevel Level_cine and move my lights and cameras there.
- I create a sublevel Level_geo and move my geo there.
- 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.