Addressables Feedback Survey

Sent. I really hope you be more careful designing Addressables 2.0, especially it's API. Eagerly waiting for any future developments of this package.

 

Going through it now. This questions is confusing. I'm not sure if it's asking about loading assets from their string address or being able to get a direct UnityEngine.Object reference from the string address after it has already been loaded.

 

Also not sure why WebGL is not even an option for

What platforms do you target?

 

+1

 

Took the survey.

We are struggling with Addressables for a month now. Using it for quite a big mobile project, and some things are just nasty to work with, like just knowing if a key combination does exist, or finding a way to catch the massive pile of exceptions the system throws. Knowing if something needs to be downloaded and how big stuff is. There are so many things that could be wrapped into async methods, often we are not even able to do it ourselves, because the stuff we need is internal or private.
Really hopes the system improves, Addressables is the way to go, I won't write my own asset management system!

 

My response to this is off topic, because if everyone did this Addressables would never improve, but for your own sanity, pull the package into packages/ and edit at will. Updating/merging with baseline is not too bad either.

 

I appreciate the team asking for feedback and I sent my response. I hope that you receive some good feedback to refocus Addressables on asset management and less on CDN integration. I recognize there are larger teams that want to develop live games that constantly update their data through CDNs and manage their entire games remotely. There are still many games/platforms (Steam/console) that are still shipping assets with the app. Addressables doesn’t seem to help much for these situations and the CDN stuff adds a lot of complexity for this basic use case. I feel Addressables should be the Resources replacement, but instead I still find myself using Resources again and again. For sync load API, for direct asset unloading, for loading prefabs that share assets with scene assets. Overall, I feel addressable missed the mark in its design and APIs.

 

I understand where your frustration is coming from but you shouldn't use Resource along with Addressables on one project. This will give you a lot of head-ache because assets cannot be referenced properly across resources/AssetBundle boundary and ends up duplicating assets. For stuff like textures this is not a big deal, just extra game size. But for stuff like fonts and shaders this WILL break things.

I agree they need to improve API but it is possible now to have Resources-like API on top of addressables, you just have to write it yourself. It's fine for long-term multi-person projects but may be a deal breaker for smaller devs.

 

Thanks, I'm well aware of the duplication that can occur. It creates a lot of wonderful bugs that I've had to diagnose and deal with in terms of asset duplication. So I only use addressables for leaf assets at this point (Textures/Sprites/Audio) and do not use them for any assets that have shared dependencies. I use Resources to handle the prefab or other complex objects since Unity's scene composition depends on asset references that can be shared with Resources. I don't want to put all of my scenes into Addressables since that also adds complexity I don't want to deal with.

That's my point. I don't feel Addressables should be adding this complexity. The fault may lie with AssetBundles or the Unity dependency chain, but the asset management is fundamentally complicated and difficult to work with when you start externalizing resources. This also immediately is counter to the workflows established in the editor in terms of references and workflow. So if I don't need to externalize complex resources, why bother? I'll continue to put leaf assets that can wait for async load requests into Addressables and use Resources for the complex data types. I'm not going to spend the time to rewrite an asset load wrapper for an asset load wrapper.

 

Maybe here is where your problem is. You either go full Addressables/AssetBundles or use them very sparingly (for DLCs and whatnot). If you load all your scenes from Addressables in the first place, there is no complexity. Complexity is when you're trying to mix and match old resources world with the new addressable world against best practices and how Unity works.

New adopters making projects from scratch can just forget about Resources and adding more than one built-in scene (Boot scene for initializing addressables basically) and live happily ever after. Minus steep learning curve and occasional breaking bugs of course.

There is nothing "established", Unity is a work in progress product. They are changing asset management and Addressables are here to stay. It's not like there is anything new either. People used to write their own versions of "addressables" for every game company and used the same AssetBundles with exactly the same limitations. Nothing new here and nothing "counter to workflows established".

 

I'm not trying to cancel Addressables. I'm trying to make them better by providing a perspective on how games can be built with Unity. If you have bootstrap scenes that load directly from addressables, and all of your assets are stored solely in asset bundles, that's great! None of the Unity tutorials are built that way, the Addressables getting started documentation doesn't mention this bootstrap approach as a requirement. Regardless, if a project doesn't need to externalize resources I don't know if there's much of an advantage to building your game that way.

In my opinion the addressable assets should work similarly to how an audio clip can be referenced directly in a scene, but not have its databuffers loaded at all times. https://docs.unity3d.com/ScriptReference/AudioDataLoadState.html. That way you can still drag/drop assets on SpriteRenderers, Materials, etc. and have the references by auto-counted decremented based on the uses. It's kind of what AssetReferences do, but they need to be integrated at the foundational asset type level so that you don't need to staple additional workflows/components on top of the more direct way that Unity can work.

Sorry for derailing this thread, @phobos2077 you can send me a DM if you really want to discuss this further.

 

Besides the common usage, I'm using(want to use) Addressable to fight ever getting slower Editor as project size grows.

The common recommendation by everyone is to break the project into smaller pieces.
At this point, it is incredibly difficult to work with the current project, so... I'm forced to break them.

This is really important and please let me describe what I'm trying to do.

I break the project into two projects, a Static Scene Project and the main project.
Static scenes take the largest portion of the whole project so it makes sense to have Static Scene its own project.
And then I build each static scene as addressable.
So far so good.

Now, I need to load the static scene into the main project so that I can overlay dynamic entities on top of the static scene.
But the problem is that Addressable cannot be loaded into the Editor Scene!!!

What!! really? !!! I was very disappointed and it felt like a slap on my face.

To me, Addressable is just read-only asset, or it's like a read-only prefab. As long as they cannot be modified once built, why can't we load them into the scene? Since it's a read-only asset, it won't have any side-effects.
Prefab is treated as a special entity, why can't we treat Addressable like read-only prefab?

Please support this feature and I'm really desperate to have this feature to save my project. If you can support, I believe it will be a game-changer when it comes to working with large-scale projects.

Thanks.

ps. If you have better ways to work with a large-scale project, please let me know. I bet there isn't other than switching to Unreal Engine.

 

I'm in the same boat as @Ferazel. Everyone needs a general purpose resource loading system, and a subset of the users needs a CDN system. Mixing those two concerns has made Addressables much more clunky than it really needed to be.

If you ship for consoles, you cannot elect to not use AssetBundles, due to patch sizes. Consoles add limits to how large your patches can be, and if you don't break assets into asset bundles, your patch will always break that limit.

The ideal thing would be if Unity packed the sharedAssets in a way that tried to keep patch sizes down (ie. allow us to decide which files goes where). Instead we have to use an API that's made in order to solve a completely different problem.

Which, as I've said before, fine, but it's still disappointing that Unity's not got a asset management system that's supported that doesn't carry the gigantic baggage of "maybe your stuff's on a server!"

 

Speaking of the Shared Asset system, this is what I said before.

Shared Asset system is a must when you are working on multiple projects. Reimporting the same asset everytime when you create a new project is not only waste of space but it takes too much time.

Well, there is CacheServer(Unity Accelerator) but it only solves parts of the problem. Why not take advantage of the CacheServer like system where you keep the common Addressable in one place. It will be much easier to manage assets from the single repository rather than fragmented sources.

This can give us very powerul Shared Asset system combined with better conflict management.

Cheers!

 

You can read
this: https://forum.unity.com/threads/addresables-2-0.912047/
and this: https://forum.unity.com/threads/universal-assets-management.912044/

They can resolve your and many more issues with asset management if Unity decide to create something like that

 

I still fail to see the problem here. Just go full addressables/assetbundles. Is anything harder/impossible to do with Addressables that you would normally do without Addressables? I don't get it.

 

The problem is that it feels for me like it's a strictly worse workflow than not using asset bundles at all, and addressable hasn't done enough to alleviate that, while adding it's own issues (no sync loads) into the mix.

 

The problem is, the main issues with the workflow are core engine deficiencies. Addressables can abstract some of them but it can't really fix them. I am a bit disappointed that the AssetDatabase has been entirely rewritten from scratch in 19.x without addressing some of the issues. Things that really ought to have been addressed and have not:
* Storing the asset type so that GetMainType() etc doesn't require loading the entire asset at least for native assets.
* Multiple/shared AssetDatabases across projects with a shared asset GUID space, allowing a more sane multi project workflow for asset bundles, where the asset database can be used both for testing without building editor-side asset bundles and for actually directly assigning asset references. This one would almost definitely take deep engine changes, but, frankly, they are needed.

 

It seems super obvious people want sync loads, they care much more about that then loading bundles from a CDN.

Besides that, addressables for me are much more confusing then the old system. I dont understand why i need all these configuration files:


I dont care about assetgrouptemplates, databuilders and whatever. Its so abstract and overly complex.

If you ask me, groups would just be called Bundles. In the current Addressables Groups window i can make new bundles and assign assets to them. I can load assets from these bundles, either async or sync. When i load something sync and it takes longer than 1ms it spits out a warning that i'm doing it wrong.

It would be convenient if i can select either to use the bundles in editor, or use a wrapper that loads the assets dynamically in the editor. I dont need 4 different buildscripts and databuilders.

Eventually, after all this is stable and nice, it would be convenient if i can configure that either a bundle is located in 'Data/weapons.bundle' or 'http://www.mygame.com/weapons.bundle'.

Currently stuck on random and unreadable internal errors.

 

I just filled out the survey nevertheless as I was curious what kind of questions you are asking

 

How would you disambiguate that from an AssetBundle? A group is not usually built into a single bundle.

 

I wouldnt, i would build it to a single bundle.

 

Group just can have option to build into few bundles using some rule. eg. split by label of just one bundle for each root prefab in folder etc.

 

Well you don't, we do. I use almost all of these features for my current project and can't imagine not having these. I agree that they could make some way to have a more "light-weight" configuration for very basic projects. But consider this. Unity's main platforms are Android & iOS. Android has a limit of 150mb per APK. And 3D games tend to be much larger than that. You HAVE to use CDN to download bundles. This needs to be easy to set up, work robustly. Which is exactly what Addressables and Unity is doing right now. This is a very common requirement for most mobile projects. So makes sense for them to provide solution for most common problems.

Having a few "extra" config files in your project that you don't care about - is a minor inconvenience compared to having to re-invent the wheel of Bundle management for every project.

Not a problem, just a write a sync layer based on example already provided by Unity. One day of work.

Looks like you're trying to load an asset with an invalid key, which InvalidKeyException is hinting at.

 

I'm aware, we have about 8000 bundles on our project using it, I'm referring to TJ wanting to call a group a Bundle.

 

That would make it useless for quite a lot of the rest of us though.

 

Agree but think that addressable group is bad naming.
Better would be BundleGroup or BundlesDefinition which describe rules for creating one or more bundles.

We in our project have scene groups and common items groups that produce single bundles and groups that describe e.g. all weapons, wear ect that now divided by labels but labels itself is useless better would be just bundle foreach root prefab.

And actually use Addressables just because Unity somewhat support it but our old solution for building bundles was way more simple and way more useful and because of simplicity it just work. Now we absolutely every release build have problems building addressables and 1 day before each release spend just fixing addressables.

So we very unhappy that we moved to use it And yes we have CDN, we use dynamic update bundles without updating clients and all this very overcomplicated in addressables and most of the times crash on build (on better days) or in runtime on specific bundles.

 

üntil now its really messy,include messy doc, messy api,and messy framework.

 

Thanks for the thorough response, clearly Unity shouldnt only listen to my opinion, but to everybody. Eventhough i have been using Addressables for about a year i havent needed much of these, and i cannot find a lot of documentation on it either. I understand its important for you to download bundles from a CDN, but when that is not important Addressables feels incredibly difficult to use. The focus, in my opinion, is too much on CDN and not enough on loading data from a disc.

Its more that i feel like its a result from an overly complex system.

If it was that easy it wouldnt be such a big issue that comes up time and time again. But its not, the example is faulty. The initialization for example is still async, you cannot use sync addressables to setup your singletons, and that is exactly what i want to use them fore.

I hope we can agree that the error message is extremely vague, why doesnt it just throw a clearer exception that explains what is going on, what file or key i tried to load. I was loading it a with an AssetReference, i dont understand why thats a key nor how that can go wrong.

 

I have singletons with fully sync API that use Addressables. In my case I just added a load step to initialization process of the game. Basically there is a boot scene (the only scene in build) that loads everything that I need in that sync singleton "resource provider", awaits until it's loaded (with visible loading progress bar) and then loads the real scene where resources can be accessed synchronously. That's one way.

Another way based on Unity's solution (although I haven't tried it) is to call DownloadDependenciesAsync with labels of everything you might need during similar Boot phase or any other time depending on your game (as an example, if you use SO to describe your scenes/levels, you can add a list of dependencies/labels to load before loading that scene). Once bundles are loaded (means they are unpacked, placed into a cache folder and ready to be used), you can use AddressablesSync.LoadAsset() to load assets synchronously using AssetBundles.LoadAsset API. This will block your main thread obviously.

So in my understanding, you should build your own resource loading layer on top of addressables that ties it to your specific game needs (games can be VERY different in how they need to load resources). Why bother using addressables then you ask? IMO, there are still benefits:

- Robust and extensible AssetBundle building mechanism based on Scriptable Build Pipeline (no need to write one yourself).
- Content catalogs and automatic bundle dependencies management (which you will have to write yourself, even if you don't need CDN - bundles will have dependencies between each other).
- In case at some point you realize you need async loading, CDN or anything more complex - Addressables got you covered.

Agree, their API and error handling definitely needs work.

 

We use a custom packing mode for a similar use case, if it helps.

• Thousands of loadable assets, representing characters, clothing items, background scenes, etc.
• Many thousands of dependencies, shared between loadable assets, some of them local some of them remote.
• For example, we may have a yellow T-shirt and a red T-shirt, they share the same mesh but not the same material, so they both reference some common assets and some unique assets.
• Common dependencies are extracted automatically with a custom version of the duplicate dependency rule that splits deps into local and remote dependency groups.
• These groups are packed with a custom packing mode that packs assets together in bundles based on their source asset path. That was really easy to achieve, the code in the build scripts is simple.

It all transparently loads local and remote dependencies.

 

Everything can be done it is super OK
But you mostly reinvent all addressables. Without them it can be done faster because of lack of docks.

In My Opinion Addressables must be tool for artist not for programmers, so artists can just by few simple clicks put assets to understandable bundles with understandable dependencies without deep customizing and without hell of deduplication rules at all.

 

Not at all. The changes are a custom build script that is 99% the same as the packed mode builder, with the handling for PackedTogether duplicated and slightly modified, and a custom version of the dupe dependencies rule that just has some extra logic for target group selection.

It all fits into the addressables system perfectly and it would be a *lot* of work to get the same result without it. It would most definitely not be easier to do without Addressables, dependency handling has never been easy with AssetBundles, especially when you want it to be entirely automatic all the way from authoring to loading.

That is precisely who uses it, pretty much exclusively our artists. The deduplicating rules are automatically run a build time and the artists do not need to care about any of it at all. We have even added rules for particular folders and asset structures to become addressables with specific naming in specific groups using Favo's importer.

 

Exactly.

It is useful only if programmers take time to customize system and make it usable for project needs.

So without touching system it is not useful

 

I am potentially not typical on this but I can't think of many cases where I could customise a system to suit our projects where I have not done so.

Improving the system so that people do not need to alter it as much is more or less the point of the feedback threads though, so keep the ideas coming!

 

I'm happy you brought this up, because this is a big issue that I noticed with addressables: names that look like they were chosen almost arbitrarily or in a nearly hipster-like manner (different for the sake of being different). 'Groups' I'll give a pass because it could get confusing as Unity already has bundles and, to my understanding, 1 group is not necessarily 1 bundle as that is only the default build processing/data builder or whatever it is called. (however it did take me several months of using Addressables before I realized I could create multiple groups and each group would turn into an asset bundle. Really funny how that wasn't made crystal-clear within the first 1 or 2 page of the docs)

Where I really start to get pissed is when I realize after several months of reading "schema" in the docs that what they actually mean is "settings" or "setup". I mean yes, if you google the definition of "schema" it roughly makes applies... Good naming is not about using the most accurate words, it's much more about using the most accurate symbols and intuitive those symbols are. The symbolism represented by the word "schema" for me is that of a several boxes connected together with various arrows and lines, which is not at all relevant to a list of little modular settings blocks.

edit: I still really like Addressables, I think it has a lot to offer even outside of remote content and whatnot. it just seems like it's one of those things that is much simpler than it actually appears because the details and presentation are needlessly complex. I'm happy to say that the docs seem to have improved in the newest version! The first page gives a better overview of the system before diving into the details.

 

Addressables + ECS Subscenes is super confusing to me...