Non async version

Is there a non async version?
This code from samples :

Code (CSharp):

1.     public List<AssetReference> shapes;
2.  
3.     bool m_IsReady = false;
4.     int m_ToLoadCount;
5.  
6.     int currentIndex = 0;
7.     // Use this for initialization
8.     void Start ()
9.     {
10.         m_ToLoadCount = shapes.Count;
11.         foreach (var shape in shapes)
12.         {
13.             shape.LoadAsset<GameObject>().Completed += OnShapeLoaded;
14.         }
15.     }
16.  
17.     void OnShapeLoaded(IAsyncOperation<GameObject> obj)
18.     {
19.         m_ToLoadCount--;
20.         if (m_ToLoadCount <= 0)
21.             m_IsReady = true;
22.     }
23.  

What if i don't plan to use cdn, is there a way to load the resources synchronously?


Ok from what i gathered , sync was not implemented, but its planned, meaning it's at least half year away. Also system lacks commonly used methods of query.
So what i'd do for now is mock adressable system myself with labels and such to use resources, and then swap when it's ready.

 

Shouldn't really matter whether the asset is local or remote - why would you want to freeze your game while loading assets?

 

Maybe you can try...

Code (CSharp):

1. public List<AssetReference> shapes;
2. bool m_IsReady = false;
3.  
4. IEnumerator Start ()
5. {
6.     foreach (var shape in shapes)
7.     {
8.         yield return shape.LoadAsset<GameObject>();
9.     }
10.     m_IsReady = true;
11. }

 

I need all dependencies to be preloaded. Im not doing coroutine mumbo jumbo for something so simple.

 

If you need everything preloaded, why do you want to use addressables?

 

It speeds up editor play times, it acts as a database, etc etc there are many benefits to it apart from downloading assets. The system solves many problems with bundles and management, but it seems the main selling point is aimed at mobile/browser developers so im met with confusion when i want to do things the standalone/desktop way.

 

I just integrated it into my pooling system. So the pooling system creates the instances to be made readily available for getting instances non-async. And because addressables give it to you async, you can create more instances of a certain asset when you are running low, and you can do so without affecting performance. So the rest of you application can just get instances as though they were being instantiated.

 

So asset loading and instantiation are async? I was under impression that instantiation would behave in the same way it did before, with async part being initial asset load into memory.

 

If you plan on everything to be loaded at once, then you can load all of your assets from addressables during a loading scene using LoadAsset, then instantiate them at runtime by using the standard, synchronous instantiation code to clone the loaded assets.

 

Ill just wait til sync is officially supported.

 

Oh boy, have I got news for you...! :-/

 

I'm talking about "Addressables.Instantiate"

 

If the asset is loaded already, this will instantiate and call its callback synchronously.

 

but the function returns an IAsyncOperation

 

A completed one, if I remember rightly. Do check.

 

Why would I want to waste cpu and gpu running my game, when what I want to happen is load the thing I asked as fast as possible?

 

I personally find "why would you want X anyways" kind of comments very unhelpful and annoying, to say the least. We are all developers here and we have our reasons. Not everybody has to build in your preferred style, not every project gives us a choice. Async operations add an extra layer of complexity that in some cases is completely unnecessary.

Do you stand to benefit from async operations? Fantastic, you're already covered. Now please stop trying to invalidate people asking to get their needs covered too.

 

Agreed, this sort of thing is what makes StackOverflow rather an unpleasant place to be. In this particular case you need to understand why the decision was made to make the API what it is. The idea is that making a game load off a remote location should not require different code by default, hence why loading is async.

Anyhow, in the mean time, there are ways around it if you absolutely need instantiation to be synchronous, you can LoadAsset in advance and then instantiate manually using the regular instantiation APIs, although that'll lose you the reference counting.

I'm under the impression that if a resource is already available the load operation returns synchronously but I'm not currently on a machine with our Unity project to verify that.

 

If I should load it in advance (meaning before I know If I need it), I might as well have it in the scene, or as an inspector reference.

 

No. As soon as your data dictates that an item is required, load it asynchronously and then have it available for synchronous instantiation.

If you do not know at all whether you need it or not or whether it’s loaded or whether it’s available, how could you have it available to you synchronously? With or without addressables it will need the asset bundle to be loaded and even if that is available offline it can potentially take time to decompress etc. In other words, if you need something available synchronously without a stutter, you have to preload it at some point, with or without addressables.

 

That beats the point of Addressables having any memory management benefit at all. Say I have fifty abilities the player can use at any time, defined as ScriptableObjects, each of them with a reference to a prefab that would be instantiated when the player chooses to use that ability. You're saying because my data references 50 different prefabs, I should load them all async and have them ready for instantiation? Why, I might as well just LoadAll when the scene loads and be done with it, no Addressable system necessary!

To me the main benefit of Addressables is being able to load references to resources without actually loading up the object itself into memory, thus having a handle to my data to use when and only when I actually need it. Having this system async only for local resources complicates issues in cases where there is a certain initialization order that you have to maintain. If you're using a dependency injection framework with inter-dependency resolution at start-up, introducing async loading to that increases code complexity an order of magnitude, for absolutely zero functional gain.

 

Yeah I disagree with that idea. A game loading resources from a remote location is very obviously doing something more complicated than a game using local resources only. Why should my local project workflow bear that complexity cost for other people's remote loading projects? It's like saying scuba diving should not require different gear than swimming, and then mandating all swimmers wear scuba gear whether they plan to dive or not.

 

There's a whole lot in this thread, apologies if I'm missing something when I comment...

agreed.

Not sure where you got that, as that is not planned.

However, I will point out that the AssetReference class does keep up with it's loaded asset. So once the loading is done, you can call the sync Instantiate(shape.Asset); You do still need to make sure you wait for the loading to happen, but at least once it's done, you can be sync.

As to how you wait, honestly the snippet you showed to start is probably best. I would definitely not do

Code (CSharp):

1. foreach(){ yield return...}

. The problem with that is that it'll only load one thing per frame. Which goes against the main idea of async being capable of starting a bunch of things at once.

 

I am not really disagreeing with you, you are right. However, based on the very description of the addressables system, it does note seem to be a good match for your use case.

The premise of it is to unify local and remote loading and "asynchronous" is literally on the description of the package.

OTOH, even if it is not a direct match, I wonder if you could write a version of AssetBundleProvider that loads synchronously and then wrap the public API in a synchronous set of methods.

 

It is baffling to me that remote loading is accommodated to such extent, as I can't imagine there being more Unity users dealing with remote servers than local. Then again I don't work at Unity, so maybe I'm wrong.

In the meantime I already have my home-brew addressable system, with the limitation that it only works for assets in Resources folder. I was excited about Addressables when it was first announced as an out of the box, comprehensive system, and have been a bit disappointed so far to see I won't be switching anytime soon.

 

@unity_bill thanks for the reply.

So here is my perspective. After being told to move away from the Resources folder, we’ve been looking for ways to do so. (Even though, to date, I haven’t seen any actual compelling evidence of why the Resources folder is bad)

Asset Bundles seem like something that is intended for remote loading, that incidentally happens to also work locally, and also adds a lot more complication to our workflow. So we’ve given up on them.

So I took an interest in Addressables, and I’m sad to hear that simplicity is compromised once more because of things having to work remotely.

If this is a system that is supposed to make people move away from the Resources folder, it seems like it missed the mark. I don’t think we’ll ever move to it unless we have no other choice.

But maybe replacing the Resources folder was never the intent, which of course is more than fine, I’m sure there are plenty of people that are ecstatic about the whole local/remote thing.

I’m just offering my perspective.

 

Sufficiently small games developed and distributed in open platforms, on powerful machines, probably can get away with using Resources folders. However, you become boxed in quickly when you rely on them exclusively, and if you start a project relying on them then decide later to migrate away, you are in a world of pain. Having been there before, a system that scales from day one and involves minimal hassle, is a blessing.

The reasons to not use Resources honestly may not apply to you right now. But they may some day, if your ambitions grow.

• Are you going to release a game on a console, and need to have small patch sizes?
• Are you working with massive quantities of assets that you don't want to re-build into the application every time you need to test the game?
• Do you have to keep your game's file size small enough that you can avoid the abomination known as "Multiple APKs" for an Android game?
• Do you want to avoid long startup times? Large numbers of files in Resources mean that the game takes extra time indexing every file on startup, meaning that many small files actually slow down startup longer than a few large ones. That's in addition to the size of the first scene to load on startup.
• Do you need your base game to have a small memory footprint so that you can load and unload expensive assets at will? Or worse, must your game's base engine be so small that there's no room in memory for a bloated binary that you'll get with large numbers of resources?

Some of these might be doable with a synchronous API across all platforms. Some of them can only be synchronous in some platforms but not others. Any unified API will have to be able to work with every supported platform, and there are some popular platforms out there that require Async for a game of even moderate scale. You can take that up with the platform owners, but there's really nothing Unity can do about that other than play by their rules.

 

I develop for mobile.

Startup times seem unaffected by the Resources folder. (Although admittedly maybe our Resources folder usage is sensible?)

And the difference in memory usage was negligible.

Also IMO, having an Android game instantly start downloading stuff after I have already downloaded it is the worst thing ever. As a user it means I immediately close and uninstall, so I can’t imagine why I would do it as a developer.

 

That's interesting. I have had rather the opposite experience, where resources folder use increased our launch times quite a bit. It does very much depend how much data is in there though.

Using asset bundles doesn't necessarily mean that the game needs to not have any of its assets bundled with it. For example, we bundle everything needed to get at least through the tutorial with the app in local bundles. Those local bundles can still be updated/replaced with remote bundles if needed. Huge monolithic downloads post-install is a massive turn-off for me too.

Also, while this is not currently supported by the addressables system and I have never actually done it, asset bundles are also used for app thinning on iOS, where the App Store only bundles the resources appropriate to the device the app is being installed on.

 

Yes, I also would rather simply download the game and just have it. I miss the days where you just buy a game and play it.

What I mean about Android is the concept of APK splitting which is required by Google Play for apps over 50MB.

While Google tries to hide what’s happening from the user, you still have to implement a content downloader of your own in case Google Play fails to deliver all the APKs. And of course the hassle involved in testing an app like this, where you have to upload your secondary APKs to Google Play seems needless.

 

I have tried this and there are a lot of problems than I thought. You could read if you want to challenge it. (Hint : not as simple as replacing with AssetBundle.LoadFromFile and return completed IAsync and pretend that you could .Result right away)

https://forum.unity.com/threads/why-are-there-no-synchronously-loadasset-apis.539946/#post-4273024

Along the way I understand more why UT choose async only. It's more than asset, and it is not just dependency chaining. It is async all the way from the catalog system. Async is a superset of sync and that's good that the API was made to cover. What Unity really need is something like UniRx.Async (or better) where you avoid callback hell with a bunch of yield points in a custom player loop. You just wait then continue from the same point thanks to async context capture. If that's possible then there is no problem with async only. You only feel the friction because you need that invisible hand iterating the coroutine and that is not given by default. (Or default if you do it from IEnumerator Start, but still not fluent enough) And when you need one, you need some game object to "host" it.

It seems to have opposite effect than you described to my multiple friends who plays gacha-game/troop management game. I observe that they are very willing to wait for the 500MB-1GB voice acting and graphic resource to load while seeing the game's title graphic and maybe some music. (Some game let you play tutorials first, so you don't want to quit)

But when I said to try this good game with download size 1.5GB they say maybe later and not coming back to it again. They must have tested that this onboarding is psychologically better, at least the game's icon is already on the home screen. If the space is insufficient (happen a lot more than I thought) for stores it is gated by OS's popup and is difficult to come back this deep in the store after you do bother to clear up the phone. For game icon on your home screen, retrying is easier and more inviting.

 

Yeah, what I am suggesting would only work properly if you could guarantee that everything is available synchronously already, that the catalogues have already been loaded etc. which is why I was arguing that I cannot think of a nice API to expose both sync and async loading for this system that would be properly orthogonal and not confusing.

I might take you up on the challenge and try it myself too if I get the time, just to familiarise myself with the internals better, I don't doubt for a second that you are right.

 

The fact that you can't instantiate a local (or already loaded) asset synchronously is a blocker for using the addressable assets system. I can't imagine why that isn't supported.

So, what are the best alternatives to the addressable assets system?

 

Let Addressables handle the hard part of preloading all of the assets you want synchronously available, and then instantiate them them manually using traditional Instantiate() calls when you're ready to use them. A very simple wrapper class with an async function to pre-load an asset and a synchronous function to instantiate an already pre-loaded asset is all you would need to make this happen.

 

Added sync loading to the dead Addressables asset? Or is it just as useless?

 

I'd really like some comment from Unity on this. So far Unity has failed to provide a robust solution for resource management, addressables is so very close to what we want but the whole Async operation kills it for myself and others here.

Sure, it's been brought up that if you need something loaded synchronously then just preload it. Then why even bother using the addressable system, now I just have to write my own system on top of it to manage what is loaded and unloaded. Then we go back to having everything preloaded at runtime which is what we were trying to avoid in the first place by using the addressables system.

I don't see why these things can't exist together quite easily. Just provide some method that synchronously loads something but only if it's local, or loaded previously. If people care about network loading then they setup themselves appropriately.

 

The async stuff is very good, but sync is absolutely necessary as well.

If an asset is already downloaded on the end user's computer, it should be able to be loaded & instantiated synchronously, exactly how Resources.Load() works currently. This will allow projects that rely on Resources.Load() to transition seamlessly to Addressables.

I would like to see an Install method, this will download and install an asset (including it's dependencies). Once the installation is complete, then an asset can be loaded synchronously. Like so:

Code (CSharp):

1. var operation = Addressables.Install("MyPrefab");
2. yield return operation;
3.  
4. Instantiate(Addressables.Load("MyPrefab"));

 

I've spent the last week deep-diving into Addressables to decide whether to integrate it into our project. I'm impressed by what it can manage and automate. It looks like it could help tremendously with organization, builds and update patches.

Unfortunately the lack of synchronous behavior is a deal-breaker.

The offhand ideas mentioned in this thread for ways to code around the problem do not work for our situation.

I'd be entirely satisfied with a simple LoadFromLocal() method that simply returns null, or perhaps throws an exception, if the Asset is not present. Let me worry about the Asset being there or not, because I know it will be. I do not care that I'll lose the ability to someday obtain data from remote servers without code changes.

I want to second what BirdiePeep said above, that Addressables is so close to what we need. It could be great. But without synchronous behavior it's useless for us. Would adding LoadFromLocal() to the API be so difficult?

I'd love to hear something official from Unity. Absent that, it looks like we have to fall back to the old Asset Bundle system which seems like such a waste.

 

If you've already loaded the resource from memory (say, during a loading screen), then any calls to instantiate it should complete synchronously. It would be trivial to write a helper method that wraps the "async" Addressables call and returns the loaded asset if the call is already completed. You could throw an exception if the async call hasn't actually completed to enforce that your assets are all pre-loaded.

 

Aha, more people complaining about Addressables enforcing async where it doesn't really have to. All of us seem to be saying the same thing.

Here is my latest long rant about this.

I don't know if Addressables devs will listen to us developers who are the actual (potential) users of their library. As I've complained, they seem to care about 'sticking to their design' more as we've been asking for this since 2018.

So if anyone wants to use Addressables in a sane way, they should follow the advice that some here have said that you need to create a wrapper layer that has the ability to do async preloading/caching of assets and then provide a sync api for instantiating those assets. It is still a pain though because you have to preload/precache at the 'asset' level so you have to precache everything you will need. You need to know before hand all assets that will be needed.

If Addressables provided a sync API, it could allow preloading on an 'assetbundle' level. So maybe just one call to preload an assetbundle, and then you could sync instantiate all assets in that assetbundle.

 

Some will say, just use async/await. And yes, I do use async/await ... but async/await can't be used everywhere. For example property getters/setters.

And you can't have Start() or Awake() be async (and whatever calls Start() or Awake() doesn't await it).

Not being able to have everything set up for a GameObject after Start() completes is a pretty big thing. It goes against one of the fundamentals of Unity coding that has been taught since forever.

Now instead in Start() you might have just started an async operation to begin loading an asset used for the GameObject. Then you might have to do further setup that is needed AFTER that asset has finished loading. And Start() or Awake() doesn't run until a GameObject is set "active". So you have to show this GameObject in an unready state to the player just to get it to start loading. I couldn't believe the Addressable devs didn't think this was a problem when I first used Addressables.

What I do is, in my game, almost everything is a prefab, including whole game levels. I have an IPreStart interface that defines an async PreStart() method. Any game components can implement this interface to do any async loading they need. Then when my Addressable wrapper instantiates a game level prefab, it will call PreStart on all IPreStart implementors it finds in the whole game level. If any PreStart loads another prefab that has a component that implements IPreStart the system will call and await PreStart on those too. It will await all those PreStarts to complete before actually "starting" the game level (setting the root game level GameObject active). This way when every GameObject's component's Start() runs, they have all assets already loaded.

I'm not sure if I got the details right in this description cause it is a pretty complex solution. Also I actually have IPreStart1 and IPreStart2 because there are issues where some GameObjects depend on children to have finished their PreStarts first or vice versa. So there are 2 PreStarts.

Thinking about it, it is pretty crazy, but it works and I can't imagine using Addressables without it. If I didn't use IPreStart I would probably have to have PostStart instead as the method for actual initialization after assets are loaded, and maybe have a system that moves assets that aren't actually ready outside of the camera bounds and move them in when they actually are. But then you will have to keep track of the position of where the game object should be so you move it back to the correct position and maybe that would cause problems and there would still be the problem of having to manage dependency of initialization order and having GameObjects 'pop in' at different times.

The way I have it everything in the game level will finish their async loading before appearing all at the same time. Having things 'pop in' at different times or after the level first appears would break immersion. And for this specific 2D game in this genre/theme, having things 'pop in' would make the game feel 'cheap'.

These are actual real world issues/considerations occurring from Addressable's async enforcement and is why people will have a very hard time moving from Resources.Load and why many people will just say 'forget about it' and use Resources.Load and/or managing their asset bundles manually.

I've stuck with it because I need the 'remote asset bundle downloading' features, and they do work, so it was worth it. But a better designed Addressable's API would have made my life (and other devs) a lot easier.

 

The Install method already exists as

Code (CSharp):

1. public static AsyncOperationHandle DownloadDependenciesAsync(object key, bool autoReleaseHandle = false)

https://docs.unity3d.com/Packages/c...pendenciesAsync_System_Object_System_Boolean_

What is missing is the LoadAssetSync method.

 

Actually, you can make Start() a coroutine just by making it return IEnumerator. You can then yield the load operation. Not that it is going to help you in what you probably want to do here, but just pointing that one one.

Anyhow, the SyncAddressables example in the addressables examples repo actually functions pretty well. It has some annoying limitations, such as not being able to mix and match sync and async, but depending on your needs it could well fill your niche.

 

Thank you for the suggestions.

Yeah, I never seriously looked at SyncAddressables example yet. My fear was about how well they would continue to support it.

 

Fear not, they never really started to support it! It doesnt work, at least not for the case you want to.

The initial loading of it is still async, its not possible to use it in Awake. If it would work at all.

 

The line you have highlighted is initialisation of the addressables system itself, not loading of the asset. You can very much use it in Awake or Start() provided something else has already initialised the Addressables system, which would normally be your loading scene, game manager or whatever design you have to do game initialisation. I did have a prototype that loaded all our GUIs from local asset bundles using it, while the rest of the game uses async addressables as per usual, and it worked fine. The setup is not entirely obvious, you have to use the sync providers for the groups you intend to sync load. Dumped it because the workflow to create said GUIs was horrid.

 

You're right, it is usable after some time. But not immediately, not in the first Awake to happen, you still have to wait in some cases.

Which isnt a limitation with regular assetbundles, and in my case makes Addressables unusable. I try to setup my singletons as early as possible, and that is delayed while using Addressables.

 

I can see why in some cases Sync version of loading might be preferred. But this should be a proper sync-all the way IMO. The kind that blocks the thread completely and uses Sync versions of all the underlying methods. I can see issues with this however:

• Current implementation of ResourceManager and providers deals with async processes all the way. They'll have to write entire parallel sub-architecture to support sync versions. So this might explain why this is not done yet. But for a professional developer that shouldn't be a road block either.
• What if your asset bundle needs to be downloaded? There's no proper sync function to download remote asset bundle. So they'll have to hack some way to block the main thread while everything is downloaded. Even if they manage it I think doing such thing is questionable at best.

My suggestion for developers is to not be too lazy and implement proper sync versions of all methods but throw exceptions if anything more complex than "load bundle, load asset from bundle" needs to be done.

I'm currently migrating to Addressables and I already see some places where I could use some sync code just for the ease of migration. But for my case it shouldn't be hard to achieve:

• Script that manages the process of loading scenes would have to also pre-load a list of all addressables that I'd want to use afterwards. It should delay the loading sequence until everything (scenes and addressables) is loaded.
• In the in-game code, I just use AsyncOperationHandle.Result (or AssetReference.Asset) to get the object and throw if it's null. (this can also be done in the previous step with some additional variables to store the direct asset reference).

Ideally, I don't want to load anything during gameplay ever! Everything should either use async loading or be already loaded once the game started. Player's eyes and nerves shouldn't suffer from extra stuttering because of my lazyness.

 

I think the conflict here has to do with different use cases. I absolutely see your case for video games, but Unity is sometimes used for other stuff than just games where sync actually makes perfect sense.

 

I think I just want a method like this:

Code (CSharp):

1. GetSync<T>(Object key)

which: Get a single asset synchronously in loaded assets cache (in memory(RAM)).
If the asset is loaded in assets cache, return the asset object of type `T`. If not loaded, return `null`.
It need to co-work properly together with Preload.
And as other APIs, it need to work properly with same memory management design by increasing ref-count, and need to call `Addressables.Release` when you need to unload it, which (in my opnion/understanding) usually can be placed after you instantiated the GameObject by the loaded prefab asset.

Thus, the benefit is:
We can keep those many existing game codes/structures of load assets in sync approaches, without having to modify/break all of them into async. We just need to preload the assets we need beforehand by Addressable async loading APIs.

-- edited, replaced 'load' into 'get'