You can still use this thread if it’s related to the scene loading system. We also have these threads related to scenes:
Allow multiple entry/exit points in Locations
“Editor window to quickly open scenes” task
Feel free to use these ones if it’s related to what you want to discuss and we can also open new threads if it’s something specific so it really depends on what you want to talk about 
Hey @Amel-Unity , I just watched your Event and Loading Systems segment of Episode 2, thank you for the presentation.
I would like to ask if you could integrate Unity’s Addressables system for loading?
The reason why I would like to see Addressables being used in this project is: I ran into various issues when I integrated Addressables in an existing project (missing features, weird API, bugs). I would hope that you run in such issues too, which then hopefully creates a need inside Unity Technologies to add missing functionality, iron out more bugs, etc.
1 Like
Hey @Peter77 , yes sure we can use them Maybe somebody can create a PR for it and we will evaluate it. The reason why we didn’t introduce it yet is because that introduces complexity for everyone when working on the project. Keep in mind though that we currently have addressable in the system because they are used for Localization.
@cirocontinisio @Amel-Unity
Now It’s not clear the state and plans regarding development Scene Loading System:
- current code include possibilities to multiscene loading, but work not finish
- didn’t explain clear the Scene Loading System concept - It will be continuous space (It divided into separate scene with constant loading the most closest scenes) or “fully separated scenes” with teleportation between them
As a Variant can be use the mixed “Loading scheme”:
- the simple scene (beach, forest) load full at ones
- the big scene as the Town - divided on squares and it loads at once only the most closest (which directly connect to current square of protagonist), but it will have sense only if: the scene will divided more than 9 subscenes (more than 3 x 3, because the center will demands to load all 9 subscenes) or the town will have the road around the center town and the town can’t be cross directly through center.
May be good idea to create a short design doc where are shortly will described main concepts for all system and links between them.
Because now information is thrown to different places and sometime it doesn’t correlate with each other, by example “SceneLoading” - 3 threads on forums, 2 (minimum) open PR.
Work is still in progress on the scene loading system but for now we decided to keep supporting multiscene loading. I am currently working on the the game scenes re-architecture, I will make sure to include it on the wiki once it’s done and come back here to post it with the diagram. I will talk about it on the next episode next Tuesday, so stay tuned
Every location in the game will be a fully separated scene. The loading process has an option to show or not a loading screen. The loading screen could have an “indicator”, like a spinning icon in a corner so we will not need to track the progress of the scenes loading process for the loading screen.
We currently have the game wiki on the repo and we usually include a screenshot of the diagram we use to explain the different systems. I will make sure to include the new updates after the next episode.
Yes we do have 2 threads other than this one that are related to scenes (Those that I mentioned in another post above: the scene selection tool and the multiple entry/exit points ) and we are currently reviewing and merging PRs related to scenes.
3 Likes
Hey Everyone!
Hope you enjoyed the last episode
As promised, I am posting in this thread updates after the stream. Here is a screenshot of the scenes re-architecture diagram and you can find it on Miro to explore it more (Along with the rest of the diagrams we previously introduced for the different systems).
You can also watch again (or if you missed it) the scenes re-architecture presentation from episode 6.
We also updated the wiki page for Game Architecture overview to reflect the new scene organization.
2 Likes
I have made a demo of what I had in mind with having 2 location scenes loaded at the same time. I think it can be integrated quite seemlessly with what we have so far. Just instead of unloading the old location scene automatically after the new scene is loaded, we would have to unload it when the player passes the trigger.
The player would live in the persistant scene or gameplay scene, no need to do any spawning except when the game is started.
To the demo:
- it consists of 4 scenes, colored blue, green, yellow and red to make them easily distinguishable (which of course in the real game we will not make that obvious). I also gave the directional light in each scene a different color but it isn’t as obvious in the demo as I thought it had to be (possibly our brain is trained to filter out changing light conditions).
- each scene is inside a trigger collider which is somewhat bigger than the scene. Before the player can get to the scene the player has to walk into the trigger which causes the scene to load. In the demo I load the scene in full view to show the loading. In the real game I would suggest to trigger the loading when the scene can’t be seen yet.
- around the loading trigger collider is the unload trigger which is somewhat bigger than the loading collider. Theoretically I could use the loading trigger as well but I want avoid that the scene is loaded and unloaded multiple times in case the player moves back and forth on the edge off the collider.
This is how the scenes and the coliders are arranged in the demo:
- In the bottom right corner of the demo I have placed a top down camera so that you can see which scenes are currently loaded
- You might remember the discussion about giving a far away view of the town in the whiteboxing thread. For this reason I placed a 2D image of the red scene to be seen from the blue scene. Again I am unloading the 2D in full view for the demo but of cause we want avoid that in the real game.
Here is the demo:
Let me know if you would like to try it, then I will make a PR.
2 Likes
Hi @Smurjo , thanks for the suggestion. We also considered loading 2 location scenes at the same time and as you said the current system supports it. Using the method above, we can use the same method to load and we only need to trigger the unloading with an event instead of unloading the currently loaded locations. So in terms of scene loading it shouldn’t be hard to make the changes.
The only concerns that I would like to mention for such an approach is how to handle the lighting bakes and the Navmesh which will be used for the NPCs and the critters navigation on the map. We can tackle these difficulties if we want to use this approach and I suggest this link to get started with Loading Multiple NavMeshes using Additive Loading from the documentation.
This obviously adds complexity so that’s why for now, with the team we would like to test the game feel once we have the whiteboxing for the different locations and then decide if we are satisfied with the way the loading is currently done or if we prefer to adjust it using an approach like the one you mentioned above.
If we are considering the 2 location scenes approach, we would need to consider this in the whiteboxing in the sense that the scenes’ shapes fit together. I would recommend we do this just in case, so don’t need to redo the whiteboxing.
Unless you want to provide some different guidance on the shapes, @itsLevi0sa 's map and the colliders I made could help with that.
This is not problem for spot light or point lights, but only for directional lights in the case we want different directional lights in different scenes (else we can place one directional light in the permanent scene, which we previously used to create the lightmaps).
With different directional lights it isn’t an unsolvable problem, but it needs indeed attention. I would suggest a script that turnes the directional light and changes it’s color/intensity based on the player position near the scene border. When the player approaches the scene border the old scene’s light will be gradually turned to a medium rotation between the old and new scenes’ lights when the player is on the scene border and further to new scene’s light direction as the player walks away from the border into the new scene. If you like I can make a trigger prefab to be put on the scene border with a script attached that does it (I guess it takes 2 directional lights as input to be set when the scene is loaded and you would have to be careful not to place it 180 degrees rotated…).
I don’t see a problem with the nav meshs.
-
For one, even with 2 scenes loaded the ground doesn’t need to overlap much to allow walking from one scene to next (actually not at all, but a visible gap due to small inaccuracies would feel weird),
-
I wouldn’t expect the critters to follow the character out of their “home scene”.
-
We can also have one Bard Hare living on the beach and one Bard Hare being in town without the player noticing it’s not the same Bare Hard.
I want ask something about a script that is related to SceneLoading System. It’s about the EditorInitialisationLoader script where i cannot seem to understand what’s happening.
what is in that i and j for loop, when it is returning and when it is loading the scene.
Also on what basis is the _isEditorIninitializerMode is set to true or left as false.
And a silly C# question, but the return statement is returning from the loop or the Start method.
Any explanation will be highly appreciated.
With “return” you leave the method. This is indeed somewhat questionable here, as this means if one of the scenes that had to be loaded was found, we leave the method - whether we still had other scenes to load or not. It would make no difference if the array of scenes to load only contains one scene - but why do we use an array then?
This is a breaking kind of thing. This would not spawn the player too if it returns from the method.
Isn’t there a continue keyword in C# like in python to continue the loop.
1 Like
It still works with only one scene - but definitely we would have laid a trap for us if want to load more than one scene at a time later.
The keyword would be “break” I guess, but that would not be the solution either - on the next “i” in the “for” loop the scene path would be different and we end up loading a scene we had already loaded.
I would have had another suggestion, improving readability at the same time with some “isSceneLoaded”-variable and thought I would actually update the code - but looking at the EditorInitialisationLoader in my version it is only loading one scene (no array). And the LocationLoader doesn’t have the problem either, it actually has an “IsSceneLoaded” method. I wonder where you found that code that you show above.
This one: https://github.com/UnityTechnologies/open-project-1/blob/main/UOP1_Project/Assets/Scripts/SceneManagement/EditorInitialisationLoader.cs
This prefab has the script: https://github.com/UnityTechnologies/open-project-1/blob/main/UOP1_Project/Assets/Prefabs/GameplayEssentials/LocationEditorInitializer.prefab
The scene ready broadcaster:
https://github.com/UnityTechnologies/open-project-1/blob/main/UOP1_Project/Assets/Scripts/SceneManagement/SceneReadyBroadcaster.cs
No it has two scene to load, persistence and gameplay.
I still don’t think we should load multiple scenes. Yes, the downsides are all addressable, but it’s extra work that I don’t think we can support. You are basically talking about making it an “open world” game.
We can definitely give the impression that there is something beyond the currently loaded scene, by using a skybox for far details, or mega-Prefabs of compositions of natural objects (rocks, ground pieces, vegetation) for close scenery.
In my head, these mega-Prefabs would also appear in the other scene, and they would act as a “wall” to surround the currently loaded scene and force the player to exit from some specific entry/exit points.
But yes, definitely I don’t think we have the capacity to load multiple scenes if we want to finish this game by March
1 Like
Another little argument against loading multiple scenes at a time: in the current whiteboxed map, there are 800 objects. I set the Static flag on all of them, and it took something like 10 seconds on my machine, which is pretty good.
Now, 800 objects are nothing compared to the amount we might have if we decorate the island the way it should be. We could get to 100.000. Technically that’s not an issue, one might say, since we load and unload scenes, but there will be instances when we want to have them loaded at the same time. For instance, when baking skyboxes or baking lightmaps.
This might easily get out of hand and make it impossible for some members of the community to work on the project in that sense.
There is no doubt that the high number of objects sucks on performance more than polygons (Take it from someone who tried to build cathedrals stone by stone). Therefore I have made myself a script that joins meshes, but it is quite easy in to join objects in Blender as well (at least if they share a texture). We should try to merge the static geometry whereever we can.
So if you want to load all scenes at a time how does this speak against loading 2 at a time?
BTW, don’t we possibly already have loaded 2 scenes at a time sometimes anyway, if we unload the old scene async? At least if we load and unload scenes at different times, those two processes will not compete with each other for CPU/IO/memory bandwidth.
It’s not that simple. Joining meshes means they have to use the same shader, or that the tool needs to assign the correct materials to each submesh. Even then, some shaders rely on object position for… reasons (did you ever watch this episode, with the position-based random colour shader?)
In fact to solve that, we decided not to batch as static vegetation, but to use Instancing on the shaders.
Are you talking about Location scenes? We do load async and additively, but only a new location and unload the old location. It was never the plan to load more than one location at once*.
- the function still takes an array to support the loading of the persistent scenes needed, but again, never intended to load multiple Location scenes.
In any case my comment was referring to “have them loaded at the same time” in the editor, not during gameplay.