Convert extremely large scene to addressables without too much pain

Hi guys, I have a ridiculously large scene which holds my entire game in it all at the same time. I turn on and off parts as they are needed, yes it uses a ton of ram lol. Im trying to move away from using ordinary Resources, for speed/performance and to get around the 4 gig texture limit, as well as allow my game files to be downloaded from a server somewhere.

Is there a way to just make this entire scene addressable and build out asset bundles from it? I have read and watched a lot about asset bundles and addressables but I find it somehow confusing. What would be the best approach to convert this huge scene (>200meg) into using the asset bundles/addressables system to achieve the objectives mentioned above? Thanks.

 

Sure, you can make the whole scene addressable, and load with Addressables.LoadSceneAsync. But you won't get much benefits. The whole scene turns into a bundle file, whenever you make an update, you need to redistribute the huge file.

The common usage of addressable is on the actual asset level, you mark your images, animations, models as addressables, and load / update on demand.

However, if you split the huge scene into some smaller sub scenes, then mark those scenes as addressables, and load them on demand, you can still get benefit from the system on some levels.

Legacy Resource.Load can be migrated automatically, see more in migration guide.

 

I am in the same boat. A couple massive scene files that I'd like to not get baked into massive bundle files. I think my ideal end result would a bunch of ~50mb bundles instead of a couple ~1gb bundles.

It sounds like if the assets have addresses, they wouldn't get baked into the scene bundle, so it'd just be a matter of assigning addresses in a way that groups them into appropriate chunks? Has anyone written any scripts yet to go through levels and automatically assign addresses to the used assets semi-intelligently?

(I haven't dug into the API yet, but hopefully there's an editor API function to set address, and some other general purposes Unity editor function to get an array of assets in use by a scene)

 

Just some notes to point you in the right direction...

When a scene is built, some things are flattened into the scene, and some are not. Prefabs, for example, are. So if you have a scene, with a prefab instantiated in it, and you mark both the prefab and the scene as addressable, then your build winds up with two copies of the prefab. One flattened into the scene, and one it its own bundle.
Textures and meshes, on the other hand, do not get flattened into the scene. So if you marked a texture from a scene as addressable, the scene will point to the texture that got pulled into its own bundle.

In our own prototyping the best model we've come up with is a script that takes all the game objects on a scene, makes them prefabs, then replaces them with a proxy. That proxy can then have a script on it that instantiates the addressable prefab based on the camera's location. We don't yet have a clean and shareable version of this script, but are working on a demo to put in our Samples github.

 

Thanks @unity_bill, that gives some great starting points. Can you confirm if AnimationClips and AudioClips will be flattened into the scene or to bundle (or more generally, is there a list of types of each category somewhere?) Already just getting the textures and meshes into their own bundle should help our filesize massively.

 

Prefabs (GameObjects) are the only things I'm sure get flattened. As far as I know, everything else doesn't. Which probably means there are a couple less-known things that get flattened unbeknownst to me. Or maybe it's just prefabs.

 

So, when we have an instance of a prefab, addressable or not, it gets saved into the scene? I thought the scene only referenced the GUID of the prefab.

 

AssetReference only stores GUID, so not get flatten.

 

Correct, and apologies if I was not clear. The only scenario I was talking about that flattens prefabs is if the prefab is instantiated into the scene being built.

 

I want to write some scripts to do my whole scene for me automatically, where's the best place to start?

 

The mentioned script doesn't sound artist friendly. It almost seems like that process would need to be done as part of a build automation setup where the repo is pulled down to a separate location temporarily so scenes that have their gameObjects swapped out won't be saved as part of the main repo.

I'm guessing BuildPlayerWindow.RegisterBuildPlayerHandler would play a part in getting this to run?

Or have it in a testing branch where it can be easily reset maybe, since using the build automation approach would make testing in the editor with Packed Play Mode selected difficult.

Or both?

I'd prefer to have all the scene gameObjects set up as prefabs in advance to avoid creating duplicate prefabs when they're bundled.

I'm trying to figure this out as well, though I hadn't realized prefabs get flattened inside scenes. I think I get why, but it's still disappointing. At first I thought "can't prefabs be another dependency of addressable scenes?" but I guess prefab overrides couldn't be easily applied.

I have dozens of smaller scenes with hundreds to thousands of gameObjects in each. Figuring this out is a high priority for me. I already have an editor script that swaps out gameObjects for prefabs.

This is one of the scenes I'm dealing with, which has over 1200 gameObjects by itself:


I'm also concerned about the overhead of having so many proxy objects running scripts at the same time. I'm guessing it'd be done using something like this?
https://docs.unity3d.com/ScriptReference/GeometryUtility.TestPlanesAABB.html

Thanks!

 

Damn that looks great! Reminds me of Slime World on the Atari Lynx

As for asset bundles/addressables etc I still can't get my head around any other way than the default way unity does it. It is far too confusing and not automated. I am ready to fix that by writing an asset which can automate everything perfectly, but I don't know how yet LOL..

 

Thanks @radiantboy

I'd really like to get feedback from @unity_bill about whether the approach mentioned above would be viable and about my concerns for such a large number of proxy objects running scripts.

 

I can see a lot of issues with this, how do you determine what's changed into a prefab or not? how would we make sure we don't break an important hierarchy or referecences between objects?
Flattening prefabs into the bundle is really an issue, this means that if we have multiple scenes using a prefab and we want to push an update to the users on this prefab only thee'll end up having to redownload the full scenes causing a big download for almost nothing. Is this something you're trying to change @unity_bill ? If not can you share why it is not possible to fix?

 

I have a question about nested addressable prefabs, then.

Since prefabs inside a scene are flattened, what about nested addressable prefabs that aren’t in a scene? Are the nested prefabs flattened out?

Is the problem as simple as just having a single root prefab that gets loaded into an empty scene? It does it come down to really proxy loading each and every addressable nested prefab even if it’s not in a scene?

 

Hi there. I hope you don't mind me trying to resurrect this topic. In our project we're trying something very similar: turn existing scenes into prefabs, then have them instantiated by a tiny bootstrapping scene. This seems to work- except that it can't really handle baked light data. The bootstrapping scenes are completely empty, apart from the single gameObject that contains the prefab loader script. So we have to use the lighting data baked with the original scene. But in doing so, it seems that through LightingData.asset, the original scene gets referenced. So we're back to square one: the tiny bootstrapping scene references the original scene, so the bundle that contains the scene as a prefab will now contain duplicate assets. Am I doing this wrong? Is there a way to preserve baked lighting information, but also make sure that there won't be scene-to-bundle redundancies? How did your solution handle it?

 

We did that by using an additive scene instead of prefabs. That way you keep all the scene goodies like baked light, navmesh, etc...

 

Lol this seems like ridiculously important info. I don't think this is anywhere in the documentation.

Also what happens if you remove the prefab link and just leave the mesh with scripts etc in the scene?
Then it loads correctly from the bundle size?

Edit: This only happens when the prefab you put in the scene is marked with static batching, then it gets built in the scene and the bundle increases in size, otherwise it doesn't.