next »

[archgame]

I'm working on multiple Unity projects that are beginning to run into memory issues. I've been trying to craft a work around that allows me to load and unload assets based on proximity to the camera, but I've run into a few obstacles. I've been using Load Level Additive, however there is always at least a one frame stutter and it loads per scene. So if I wanted each object to be able to load and unload I would need to make a scene for each asset, which doesn't seem like the correct architecture for a project. I'm trying to replicate the gif above, where the level is constantly loading and unloading assets of a variety of sizes and locations. I found this talk below from Unit 2016 about INSIDE and their use of loading and unloading. However, I don't understand the time slice aspect (current video url).

https://youtu.be/mQ2KTRn4BMI?t=656

What are some good recommendations for structuring a project where it is unloading and loading multiple objects at a time in Unity3D? Is there a general rule of thumb on how many objects one should have per scene or how large a scene should be before it is split into smaller scenes? Along with these technical questions, how does one design a level when the objects are in multiple scenes? Furthermore, if anyone could explain the technical aspects of time-slicing and how it is done in Unity3d (or point me to an example) that would also be useful (I know in the talk they mention changing the unity source code, I have Unity Pro so this might be a possibility).

I'm open to any asset store solutions as well.

Bonus Question: Does anyone have an recommendations for unity3d controller or camera scripts that have tegotae?

[Polly]

I'm trying to replicate the gif above, where the level is constantly loading and unloading assets of a variety of sizes and locations.

That GIF demonstrates frustum culling .. Unity already does this automatically.

[JWki]

Very important distinction here. There's no resource unloading and loading happening in that gif, as polly says that's only frustum culling which means things don't get rendered but the resources are still in memory. The kotaku article that you probably read is simply wrong here which is part of why it has received so much shit from the gamedev scene.

[archgame]

@Polly sorry I should have specified I was only using that gif as an image reference, the video I linked is a better indication of the workflow I'm interested in.

@JWki Apologies again, I should have specified that the gif was only a visual example.

If the gif above where truly unloading and loading assets using Unity's Load Level Additive, it would appear each asset has it's own scene. Where in the INSIDE example they clearly use scenes to create a seamless level. As I said, I'm running into memory issues, not rendering issues, So I was wondering two things: 1) How did INSIDE get the game to not stutter when it was loading and unloading scenes? 2) is there a general rule of thumb for the size of a scene to load and unload?

[bateleur]

As an aside, if you were to have stuff loading and unloading with a granularity as fine as seen in that GIF it would cause you some really horrible problems. Unity, like many garbage collected environments, can suffer from uneven performance if you thrash the garbage collector. As such you don't want to be doing frequent allocations of any kind during gameplay.

The video you've linked is about following exactly this principle: not doing things during gameplay.

[Ordnas]

You need to use a series of octrees, dividing the game map, and if it is done right, the update is very fast.

[archgame]

@Ordnas @bateleur:

Thank you both for you thoughts. Octrees seem like the right direction for managing the granularity, but part of my question is how granular should the octree divisions be? Is there a size which allows for additive load level without the frame freeze?

The second part of my question is in regards to how one would split a scene into octrees and still work efficiently in the editor? I'm looking for more of a best practice. Are most people splitting their games into octrees before going to the editor, or are most people building their scene in the editor and then splitting into octrees?

From how I understood the presentation on INSIDE, they are only allowing a certain amount to load each frame (time slice) and I was wondering if this is possible without access to Unity's source code? In the presentation they make it seem as though scenes are loading and unloading when certain conditions are met, which I assume is during gameplay?

[JamesK]

In my unity game I implemented something similar, but did not have to create any complex partitioning due to the fact that my game is a rather simplistic 2D design. I structured my loading/unloading of the world based on the way the map flowed in my overhead game.  Basically, I use bounding boxes to know when a player is near the point in the world where we'll have to load a chunk of the map or when they leave an area and we can unload it.  In one of my blog posts I have a (rather large filesized) gif at the bottom demonstrating the loading.

http://pixelpolishgames.com/node/27

I can offer a few pointers or lessons learned that you can keep in mind while implementing your approach:

1) I broke up my specific map chunks into their own scenes and reparent the contents to my master scene once loaded. When the player is deemed far enough away, the top level game object gets unloaded (which removes all scenery) and any transient game object (like a chasing enemy) will get reparented correctly so they don't get removed because their original map chunk was cleaned up.  That's all pretty specific to my implementation, but hopefully that gives you some ideas.

2) I originally wanted to have prefabs for my map chunks so I could avoid multiple scenes, but learning as it is I didn't know at the time that prefabs inside prefabs aren't a thing and you can't really do that in unity.

3) I don't recall the specific function name I use to load my scenes, but I do know that I'm using the async version. Once it is loaded, the handler will reparent all game objects into the master scene and I dump the old scene.

4) And lastly, I found that it also suffered from a split second stutter and though I don't have the link, I found in my research that this is a common issue when running the game in the editor.  I didn't find a work around.  But I did do a test and ran the compiled game to see if I still had the stutter and was happy to find that it did not exist where it mattered most.

[Polly]

From how I understood the presentation on INSIDE, they are only allowing a certain amount to load each frame (time slice) and I was wondering if this is possible without access to Unity's source code? In the presentation they make it seem as though scenes are loading and unloading when certain conditions are met, which I assume is during gameplay?

It's explained step-by-step in the presentation. What exactly don't you understand from it? But yes, you don't need to access the Unity source code for this, and yes loading & unloading happens during gameplay.

[archgame]

@JamesK thanks! I never thought to try it compiled, that did the trick, love it when it's a simple solution, I'll just have to ignore it while I continue working in the editor. thanks for the other tips as well.

@ Polly: I had implemented INSIDE's preawake concept, but was still getting the stutter on loading and unloading and knew they had mentioned having access to Unity's Source code and didn't know if this is what I was missing out on, but @JamesK tip that the stuttering doesn't happen with a compiled build was spot on.