We need Object.InstantiateAsync

This is the last remaining feature of Unity that really kills me. You have to deal with a frame hit if you instantiate something too big. Unfortunately there is just no way around this as an end user. There needs to be an instantiate call that can spread the performance hit over multiple frames.

and the InstantiateAsync in Addressable is not a real async instantiate call, internally it comes to just rest on Object.Instantiate

 

I can't be the only one wanting this.....

 

You're not the only one - unfortunately I'm pretty sure I read somewhere it has to be done on the main thread, although I'll have to leave it to someone else to elaborate on why. I could also be mistaken.

Definitely agree we need a solution, it's currently the primary roadblock where streaming worlds and "play while loading" are concerned. At least some way to distribute the process/break Instantiate up into multiple frames even if it would be on the main thread. It would also be a good idea to support a fallback like that anyway as WebGL has issues with multithreading (and I imagine there might be other single core platforms/devices worth considering).

 

On the unity side, what they could do is stagger the model uploads, texture uploads and deserializing of big components over multiple frames. Then have it call 'Awake'. User would be responsible for staggering their Awake/Start methods over multiple cycles.

I don't even think this would be that hard for unity to do. Seems like someone could probably reverse engineer the yaml of prefabs and do it already. Just would be a hell of a lot of work.

Could maybe do the staggering of model/texture loads already if you get clever. But I don't know if that is where the biggest hit comes from.

I think more users need to start asking for it.

 

I consider it highly unlikely that UT will implement this feature. ECS is around the corner which can instantiate 100k entities in 1 ms (see MegaCity Demo). Unity core with GameObjects is single threaded. I guess it would not be as easy as you think it would.

 

Edit: hopefully they get DOTS working for WebGL (which is also single thread limited ..at least right now, based on other posts I've read.. not counting initialization).

Nobody wants to install anything / can't due to security restrictions etc. And unless there's a demo for the web it's a hard sell for many, especially with so many developers moving to Unity from flashy web app backgrounds.

That said - whatever. Luckily in my case in doesn't matter. For people that count on Unity for their livelihood it's more of a downer I'm sure. This is my first project with the engine while I learn it. Too bad I didn't know earlier this year.. such is life I'll learn dots when the the GameObject system gets deprecated, if not sooner.

 

I guess the answer to OP is that the only option really is to roll your own instantiation, or hope another developer seizes on this deficiency and does it for us. From what I understand, the only currently-stable web option available in Unity for the next few years anyway is GameObjects+WebGL+single core. Especially with WebGPU being years away from full adoption and never going to replace WebGL entirely: "WebGL (the API) is not considered a dead end, not even after WebGPU arrives, because WebGPU adoption will be restricted to Vulkan, D3D12 and Metal capable devices." (source).

I mention WebGL because it's already easy enough to get things loading asynchronously on multiple cores / rolling your own solution isn't a big deal. Single core solution.. very big deal and would be a game changer, literally.

Edit: Note we're still stuck behind this, where WebGL is concerned it's the 2nd roadblock to indefinite play within the same world: "Calling GC.Collect() has no effect on Unity WebGL. This is because we can’t garbage collect when the call stack is not empty. More details about this limitation can be found in the manual. At the moment, Unity WebGL will try to perform a little bit of garbage collection at the beginning of every frame. Then when a new scene is loaded, a full garbage collection is performed." (source)

Edit: "indefinite play within the same world" as in new content while you play.

 

I get that you wouldn't want to call GC Collect during gameplay unless you could do it asynchronously.. and I haven't seen that done in anything I've ever worked with before, I'm actually not sure it's even possible. I just mentioned it given it's technically a limitation not to be able to free memory during gameplay (during a menu.. or while time is stopped.. or when the camera has gone dark.. at good times for it kind of thing), though I don't think Unity can do anything about that (?). I ruled out streaming worlds [in WebGL] early on given concern for memory recovery along with the OP issue, BUT I can say for Desktop WebGL that in my tests I've seen it's possible to unload/reload a lot of content without unloading the scene or having memory usage grow without shrinking again after a while. I've never had to close a desktop web browser once due to memory use, and I have pushed it pretty far (in a practical sense - not deliberately stress testing). But Mobile WebGL, I have seen you must unload the scene per the information at the related link.

I was originally planning to support Mobile WebGL when I was deciding on my approach to things. Actually when first discovering it I was like, why would anyone ever create an app again when we've got WebGL now?! Anyway, I've dropped Mobile WebGL entirely, given current limitations which aren't Unity's fault.. though I may revisit that in the future, if/when hardware/software is good to go. I sort of reached the conclusion that a company with an app store isn't likely to throw their full weight into web-based apps working just as well.. so yeah, I was definitely dreaming

Now that I don't care about Mobile WebGL, the only real issue for Desktop WebGL where procedural or streamed worlds are concerned is stutter-free instantiation on a single core, which would mean less restrictive structuring and limitations being drastically pushed back. I generally have the mindset of "just do the best with what you have and don't gripe about what you don't" but felt obliged to jump in given the OP issue has actually impacted the direction I took and limited what I'd have liked to do - however, given how much time everything else I have planned will already take me, I guess that's not necessarily a bad thing

 

It may be coming. It took a while, but this may be it. Sadly would require using the Unity with the runtime fee.
https://docs.unity3d.com/2023.3/Documentation/ScriptReference/Object.InstantiateAsync.html

 

Pretty much off-topic, but that sentiment is completely irrelevant until you're selling a game that's more successful than 90% of them out there. I have your publisher's first steam game on a wishlist, ship it and then see if you think the runtime fee minimums are so scary.

 

It's not off-topic, this feature requires Unity 2023 which has a different pricing than previous versions. The ones interested in using this new feature will be the ones deciding if it's irrelevant, not you. Not everybody has a business model that consist on selling a game on Steam with a publisher.

 

haha yeah.. I'd completely forgotten about this. Addressables has had InstantiateAsync for ages, great to see it for normal GameObjects now, it's actually great timing for something I'm working on, so thanks for the heads up.

I'm wondering though.. at the link you shared, it shows some older versions in green under the dropdown, but those all have broken link / go to index instead of the corresponding pages - I'm already using 2023.3, but for anyone interested, according to docs it should also be in 2021 LTS and 2022 LTS. Either the links are just broken, or having them green there (which means supported) is a mistake/error.

Edit: Actually never mind, I'm a dumba** (see below). Also while I'm correcting this post anyway, I said GameObjects above, when it should say Objects

 

I think you've missed reading some text:

 

You're right, it says without - and I wondered about that, but it also says "supported" for the green ones

Edit: I guess "supported" means Unity supports that version. Lesson learned lol

 

For future reference, the green indicates it’s a currently supported version of Unity that’s still receiving updates. Also, if you’re unsure about that kind of thing, it’s never a bad idea to check the page for the class on the other version. You would’ve seen that InstantiateAsync is nowhere to be found.

 

Yeah, I did see it was nowhere to be found, but had always thought green ones meant it existed in those versions (like, since I started using Unity). Obviously I was mistaken.

 

This API is now available on Unity 2022.3.20 LTS
https://unity.com/releases/editor/whats-new/2022.3.20
Being an LTS I wasn't expecting that. This is awesome!

 

Out of curiosity I looked up Addressables.InstantiateAsync (available for many years) to look at the differences. How asynchronous is it relative to the new Object.InstantiateAsync?

Here's Object.InstantiateAsync:

In contrast, Addressables.InstantiateAsync (1.14, 2.0) only does the loading async and is fully synchronous if already loaded:

So it does not look like Addressables was intending to do the same thing and the description at least hasn't been updated in 2.0 to make me believe that its now using Object.InstantiateAsync internally unless someone has info to the contrary.

 

Related:
https://forum.unity.com/threads/asynchronous-object-instantiation.1547894/#post-9655724