In short: How are you approaching addressables in your project?
Are you using addressables and bundles for all assets and scenes? (Or only replacing what used resources and such)
How did you split your asset groups, did you found issues in your groups depending on how you splitted them?
How are you configurating your assetgroups, have you find issues while using packed together or issues when using pack separately?
Have you found any strange settings that have lead to issues in your project and you had to setup it differently?
Please, if possible just share any knowledge you think might be important and is not written anywhere in the documentation… Would be very grateful even if it does not help us!
(Skip this if you think the post was already to long, but below I’m just gonna share a little of our issues)
We are having quite some trouble with addressables for some weeks now, things that are not making sense and are looking like a nightmare. There seems to be a lot of issues with dependencies not being managed properly after releasing an asset and then trying to reload it, some of them only occur when using packing together, some of them only occured in a previous version of unity with LoadSceneMode.Single (I believe there was a bug Unity fixed about unloading/loading assetbundles in the same frame, which probably was the cause for the LoadSceneMode.Single as the scenes shared assets) We perform a release in all loaded assets which are just used in the scene when unloading it, and we load them and use manual instantiate insted of using instantiateasync (which had lead to some problems earlier).
If @unity_bill or @davidla_unity could maybe discuss a little more in depth some issues would be great, even via email or anything you preffer. We already posted some issues here with some sample projects, but should we use another approach to share this bugs and ask for support?
I can share a bit of insight on how we used addressables thus far.
We use them for both assets and scenes yes. All of the menu scenes are still built with the player and all of our playable scenes are packed in addressables.
We mostly use ‘leaf’ assets, so hardly any dependencies exist between them. I guess we’re lucky on that side that we don’t have to deal with dependencies much. We did split our assets according to the ‘type’ of asset. Scenes versus assets being one of them, and among assets themselves we have separate groups for music files, cosmetics, items players can place in the world etc.
I initially set up every group in the same way: uncompressed + pack together. This results in extremely long loading times for scenes and setting up custom player levels also took up a bunch of time. So I set some groups to LZ4 + pack separately. This helped a ton to actually reduce loading times compared to before using addressables.
Not settings per se, but I did encounter (on Mac at least) an error that running the editor and the build on the same machine made initializing the addressables package in build impossible. Another member had the same issue and fixed it by changing one line that would no longer use Playerprefs and always generate the location to load from instead.
Overall, I got addressables integrated in a project that’s been released since 2015 and we’re still regularly pushing out updates but we ran into a file size limit of resources which made us switch to addressables. I must say it was a pain to figure things out when dealing with it from a code perspective, especially when integrating it with our custom build tools or running some maintenance scripts. But, as with any new framework, once it clicks in your workflow, it works decently enough. Though I’d wish the API would be a little less cluttered on the editor side, and a bit more flexible on the player side.
I eventually designed a few custom asset references to deal with fetching Monobehaviours (which ain’t assets) instead of GameObjects (which is are assets) and put in some extra information about that asset in the reference. So even though it can run out of the box, for more serious work, it still requires some tinkering imo.
I don’t know if you’ve checked out the MemoryMangement page of the manual yet but that might be a place to start. That may or may not offer some guidance.
As far as general advice I’d say try and ensure that you separate “pack together” groups into subsets of your assets that are likely to be loaded at the same time. Don’t separate all prefabs into one group and all materials into another. That’s going to cause some serious memory allocation that you probably don’t need. You can do this by packing stuff together for a certain level some other constraint.
“Packing separately” groups can help alleviate some issues with having too much data loaded at once but you might incur more overhead cost for loading N number of bundles for a given asset. Though if there’s a lot of shared assets you may only incur that overhead cost infrequently.
Also you should be able to run some of the Analyze tools to get a feel for your dependency graph. There’s also some changes to how the dependency tree for an asset gets loaded in the most recent versions. You may be seeing some issues that we’re actively working on if you’re on latest (1.12.0 at the time of writing).
Hopefully that, or LuGus’s comment, can help you out.
Could you elaborate a bit for us please, @davidla_unity ? I am currently chasing a number of dependency issues, since our project makes extreme use of dependency loads and it would be very interesting to know what known issues there are.
As I wrote in this post also, we attempted to fix the problem we were having with materials losing reference to textures by creating a custom AssetBundleProvider that would change the parameter of AssetBundle.Unload() call to false, but it didn’t seem correct to apply such workaround, and finally we started having problems in Console platforms…
We are just really confused if we are doing something wrong or if it is a problem with the system itself (if you look at this post , seems to be a problem with the way Addressables is managing the unloading of dependencies…)…
We were using this page in special as reference, but it doesn’t seem to cover the issues we are having…
Sure, we are not keeping all prefabs in the same group. We divided each asset type into several subsets. We also tried the “pack separately” option, but no success. The problems actually became worse after we divided the groups further.
@LuGus-Jan , thanks for your insights, too! Probably you didn’t have the same issues we are having because you use mostly “leaf” assets as you said. In our case, we were loading mostly Prefabs with Resources.Load(), so when changing it to Addressables loading, we started having these issues with lost references to textures in the materials they were using…
Our project is extremely large, and if our bundles weren’t basically one asset per addressable, we’d need many gigabytes of mobile cache space, which is a non-starter. Mobile apps should only download exactly what they need, not a byte more. We think that the whole large-bundle idea is broken. Downloading and updating has to be as granular as possible, or you’re wasting too much of the user’s space and bandwidth (and your own).