Resources.Load - massive filesize?! [Resolved]

Hello, I have a question about the 'Resources' system. My project is an old one that existed before AssetBundles and Addressables ... I will be upgrading to Addressables in the future, but I want to make sure the performance of Resources.Load is maximized for now ...

Long ago, I used to instantiate objects by:
1) having a reference to their prefab in the inspector
2) calling Instantiate() on that prefab

I learned that when your game gets bigger, and you have a ton of references in the inspector, scenes will take forever to load.

So I moved all my prefabs to the Resources folder, and changed my instantiation code to:
1) Resources.Load to access the prefab
2) calling Instantiate() on the loaded prefab
3) Deload the prefab reference later when not needed

This made the scenes load much faster, but it had me wondering ... should I also be moving the 3D models and textures into the Resources folder along with the prefabs, or is it perfectly fine to leave the models/textures in the 'Assets' folder? Am I missing out on performance gains?

Thank you.

 

Definitely leave the textures and models out of the Resources folder. The same goes for asset bundles too. Just put the assets you want to directly load from there, everything else referenced by that asset will be included by the engine. This way, if you change texture or model you don't need to go to the Resources folder and delete the old ones.

Also, the number of files inside the Resources folder has a direct effect on startup times, so you want to minimize that.

This a really nice write up about Resources and AssetBundles:
https://learn.unity.com/tutorial/assets-resources-and-assetbundles

 

Ah that explains why the "startup time" metric for my app has been rising. Very useful info, thanks!

 

Every time I run a game and it freezes on startup, I'm almost certain that this is the reason for it

 

Also, don't forget that any folder named Resources in Assets folder counts. So make sure you're not putting anything in them if you don't need it. Some plugins leave shaders in them and use Shader.Find to get them. It's better to just have a reference to that shader on the object.

 

Haha, well I guess it's time for me to switch to AssetBundles. Thanks again!

 

Consider Addressables if you are on applicable Unity version

 

In your opinion, what's the benefit of Addressables over AssetBundles (or Resources for that matter)? I'm looking to determine what to use for a game that is very dynamic and loads and pools lots of prefabs at runtime, but is pretty much just going to be deployed to PC/Mac/Linux so I'm not super concerned with micromanaging memory and size as much.

 

Addressables ARE AssetBundles except they come with built-in framework that offers you a way to manage your assetbundle madness, instead of developing a wheel (i.e. your own system). They have one downside - as everything with Unity they are overwengineered so it is a bit hard to get in. But once you chug through it and understand how it works you can really exploit its potential.

 

That's one reason I still use AssetBundles. Once you write your own code to manage the pipeline, it's really easy and gives you a lot of freedom. I'm don't think it's even possible to do half of that with Adressable as far I read the documents.

 

Tell me more, I'm curious. How does your workflow looks like? How do you manage AB runtime? How do you separate concerns? Just like with Addressables, when you use pure Ab approach you bound to have some overhead and complexity, like, what do you decide to load with scene load, what do you decide to unload? You now need to be concerned with the resources packaging overhead because if you split into too bug bindles you end up using more memory and loading more stuff than needed for Scene2, for example. if you split ABs granularly you now increase complexity and overhead tenfold.

I'm really curious how different people solve these issues.

 

We're more concerned about 2 things: load times and patching. Everything else is secondary when it comes to build pipeline.

- For load times we found out that loading a whole scene/bundle into memory at once is 2x faster than loading it using normal unity methods, and because we load one scene at a time, memory overhead is just the permanent buffer that we create at startup. We load some of the regularly used asset bundles (Localization, fonts, etc.) at startup and load/unload other bundles are we need them.

- Patching is complicated, especially on consoles. Each one has its own requirements and quirks, so we would need control over which files are gonna change in the new build. Right now in Adressables the system creates the patch for you which is big black box which could create a lot of problems for us, and if it doesn't work as we need it, it'll be too late to replace it with anything else as it will be post launch.

 

That wasnt really my concern. With default resource packaging Unity provides on build - everything is coupled VERY tightly together, during runtime, Unity loads ONLY what is required by loaded scene with surgeon's precision (what's referenced). With AB. you now have to manage it yourself. Which results in 2 approaches:
- either have big bundles and load them less offten, thus less hassle, but since they are big they will take a lot of memory
- separate bundles on more precise level, for example, have some permanent data, some long-term data (i.e. player in a Zone that contains several scenes which share some common resources) and have short-lived bundles, which contain only scene-specific data. This allows address the memory issues and loading mess to some degree but then you now have massive overhead with managing all this bundle mess ()potentially hundred+) and you basically have to develop your own tools to do that without wanting to die.

There are also concerns with some cases where you have to make compromises and limit player's agency and freedom. For example, very quick scene changes between scenes in one zone (noticeable memory spikes and loading) or especially between zones i.e. in cases where you have to re-load long-term data as well, besides scene-specific. This all hurts loading times.

There are also some issues with AB, like, you cant populate shader data even if you load AB with shaders - Shader.Find() wont work for them, etc.

You already said that pros outweighted cons, still, I'm curious what was the line of thinking and decision making here?

Can you elaborate what exactly patching makes easier? You still need to replace old bundle with new and there bound to be big ones

 

Actually if you use no compression or chunk-based compression, unity will only use the needed amount of memory and load only needed parts.

Creating a open-world game is gonna need a lot of flexibility in streaming assets in and out, so you probably gonna have to write a whole custom system for it, that's probably on top of ABs anyway because in Unity you won't get that much flexibility anywhere else.

You can put all shaders in one separate AB and they won't be duplicated in other ones (I think it's a little bit more complicated but doable). Using Shader.Find() is a very bad practice: it basically searches the Resources folder or shaders that are already loaded.

I have to be somewhat vague so that I won't break our NDA: when we build our ABs, we can do a diff and see exactly which files are changed and decide what to put in the patch and what to ignore if the changes aren't important (minor artistic changes and such) so that we won't go over the allowed patch size.
As some of these platforms only support file-level patch granularity we have to decide this at file level. One thing I learned is to make our ABs a little bit more granular, but that's also a balancing act, because too many files could change our disk access pattern which could result in certification failure. That's another thing that I'm worried about with Addressables. It creates way too many small files with random GUID file names that I can't handle manually.

At the end of the day, we have this system we developed for more than 5 years that works well for us and has passed certification. So I'm really reluctant to replace it with an untested black box that is using AB anyway.

For newcomers I definitely recommend it over using Resources, but I hope unity keeps their promise and replace the Resources with something simple that uses Addressables/AB behind the scenes, so it would have the simplicity of Resources and none of the horrible side effects.

 

Alright, thanks, good insight.