Scene Management in Unity

Scene Management in Unity | Code Review

Рет қаралды 12,618

Күн бұрын

Пікірлер: 38

@MaxIzrin 8 ай бұрын

Since the main issue with the scenes is the large textures, I would've handled it the way maps are rendered. Split the massive textures into small tiles, and load them based on player position, same concept as Minecraft's "Chunks". This way only a small part of every scene's background needs to be loaded at any given time. It will also allow for seamless traversal of the world if you wish, doing away with scene management altogether.

@WeslomPo 8 ай бұрын

There also a some info of how Disco Elisium working. There are similiar concept.

@alex2416 8 ай бұрын

your videos are so interesting ! seeing how sub-systems like this one are used in real game production is really cool :D

@TobyJWalter 8 ай бұрын

To this day I don't understand why this channel is so underrated. I Love your videos and keep up the great work!

@SharpAccent 8 ай бұрын

If you are going to add the addressable scene then your add in build settings function won't really be used. You can just use the AssetReference for the scene instead of the scene. HOWEVER, if you are going to use a scriptable to keep the scene data like this then you won't be able to do online content delivery if you want to add a new scene without making a new build for the game, since you'll have to be making the container for each new scene. Technically, a clean approach for ocd would be to get a container with all the addressable paths you may need for a scene from an online backend somewhere, then recreate these containers at runtime. But that's only if your game actually requires that.

@_zarka 8 ай бұрын

Doesn't having a big root object for each scenes affect performances? Smaller hierarchies beneficiate from multithreading to update their Transforms, whereas larger and more complex hierarchies have a bigger impact on garbage collection. Unless you scenes are not complex enough for that to actually affect your frame budget?

@uselessgamedev 8 ай бұрын

Wait a minute is that true? I've been certain everything Unity.Object related is updated on the main thread always for years. I thought this was both the strength of Unity (ease of use/learn) and its weakness (performance). When you do stuff to a transform from a a thread it even tells you you can only do it on the main thread. Do you have a source for this?

@noisecrime 8 ай бұрын

Possibly, how bad is often dependent upon project. Unity recommends to use flat hierachies where possible and to keep the depth of the hierarchy to a minimum, ideally less than about 50 gameObjects ( I believe thats due to optimal memory usage/performance when updating transforms as batches). As a general rule, you should prefer multiple small hierarchies at the root to one big hierarchy.

@uselessgamedev 8 ай бұрын

All right I did my rounds and it seems the confusion is that unity multi-threads *transform change checks* per hierarchies. They do indeed recommend flattening hierarchies and using multiple small ones rather than one big one. Not a huge issue in my case (except for the dungeon this is most likely going to have a noticeable effect on performance). I'll see if I can think of a different architecture

@noisecrime 8 ай бұрын

@@uselessgamedev If you do change this, it would be interesting to profile before/after and see if it had any effect. For example if your scenes are only a thousand GO or less, I could see the overhead from this being dwarfed by some other unoptimised practise and thus not gain or really lose performance due to hierarchy layout.

@_zarka 8 ай бұрын

@@uselessgamedev that's an interesting nuance! I second what @noisecrime said, if you do make the change it would be interesting to see if there's any actual difference in term of performances

@psuvideographer 8 ай бұрын

Thanks for the video! I always enjoy them. I thought maybe if you needed to upload a big texture but didn't want to decrease the quality, you could slice it in pieces and upload one piece per frame. That way you still have your overall resolution.

@uselessgamedev 8 ай бұрын

Yep, that's the plan. One of the plans anyways. Splitting would also allow me to get po2 textures which is nice

@Spy653 8 ай бұрын

I personally would give the choice to the player between longer loading screens, preloading with potential lag spikes, or just full ram usage (I paid for 16gb I'm going to use them god damn it!)

@uselessgamedev 8 ай бұрын

True, it could be a parameter for PC users

@WeslomPo 8 ай бұрын

I have 64gb xD

@Spy653 8 ай бұрын

@@uselessgamedev it would also mean your pipeline would be more flexible for future projects that may have more or less intense scenes

@WeslomPo 8 ай бұрын

So hard theme you tackle. It have so much pits and bumbps. For example. With loading/unloading you at risk to have severe a memory segmentation with time that lives your game. Also, I think, if you can, you should stop using OnEnable, Start, Awake etc events if they for logic. Better to have some object on scene, that have all objects that can have logic, and call their method directly. Unity events can be unpredictable. Anyway good luck. You have a nice project :)

@kaasronald3623 2 ай бұрын

i thought LoadSceneAsync was fine in build mode (not in editor). But maybe my scenes are not complex enough to cause stutter in build.

@skloutown852 2 ай бұрын

I actually prefer using Addressables to load scenes. I ended up creating my own scene manager with Addressables, which gives me much more flexibility when I need to load scenes or groups of scenes.

@uselessgamedev 2 ай бұрын

That's a good point, I guess AA already takes care of some of the things I mention

@explodingmonkey44 7 ай бұрын

I'm brand new to Unity. How do I install a Scene Reference script into the editor? I can't find a video on it.

@uselessgamedev 7 ай бұрын

You could just download the script and put it in your project, I think this one is a single script. There is also a more complicated way to install it as a package