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
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 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]( WebGL Roadmap page-10#post-6497713)).
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
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
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.
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.