I’m loading five car at the scene start. I was loading this five car at the same time but sometimes one of the car was not loading successfully at build so now I’m spawning this cars step by step. After that I don’t have loading problem but loading times is really high at some phones like(Mi 5X) 7-8 second. Mi 8 have 3 second loading time. Also loading car at some phones Like Mi 5X reducing fps a lot. (4-5Fps from 40-45) I don’t know if loading problem while loading at the same time is bug or how can I decrease this loading times and why fps is decreasing a lot. Can anyone help me about it please?
Curious. Let me kick this to the team for some guidance. Which version of Addressables are you using?
Thank you for answer. I use Addressables 1.16.15
Before started to use Addressables all cars were in scene and game start time was 5.2 seconds. With Addressables and no car reference at scene, scene loading time is 5 second but Addressables load time is high (Android Mi5X). It depends on with device but at low-end devices it is worse. Also decreasing fps lot at editor and build.
Hey @Ceylan12 that’s not a bug we’re aware of. If you’re kicking off several individual loads at the same time it could be possible there is a race condition that’s messing something up.
However, if you know you always need these 5 cars at the start of your game I’d recommend giving each of them a label, something like “starting_car” or whatever you like and then doing one load call and pass in the label. This will give you all 5 cars but with one load call.
Hope that helps!
Thank you for answer @davidla_unity , I think it will solve my start problem. I’m loading car from build. What about loading times and fps drop while loading car. Should I investigate this things or are they normal?
I think there is problem at also instantiate. Is Addressables.InstantiateAsync is same with Addressables.LoadAssetAsync + Instantiate.
It sounds like something that should be handled in Addressables to me.
If you know that it’s technically impossible to support “individual loads at the same time” without “messing something up”, then the system should implement functionality to ensure that individual loads are queued up internally.
I wonder how other game engines handle individual loads at the same time. Do other engines have the same limitation, or is this an Addressables implementation specific limitation?
Is this limitation on specific platforms only?
This seems like something that’s often not really feasible from a game-code point of view. From my experience it’s often different parts of the game, eg. during initialization, that request individual assets at the same time.
For example to load characters, where the individual assets make up the appearance of a character, which isn’t known at build-time such as “load body 3, hair 7 and outfit 2”.
Another example would be an effects system might trigger/pre-load various effects during initialization, while the characters system loads those characters as mentioned above. The characters- and effects-system don’t each each other, they’re different systems.
Ensuring in game code that “individual loads at the same time” don’t occur would require some sort of additional layer on top of Addressables, wouldn’t it. The additional layer then has to manage and schedule load calls to ensure “one load per time”.
This functionality belongs in Addressables instead, in my opinion.
2 Likes
If the difference in load times of the scene with cars (5.2sec) and without cars (5.0sec) is only 0.2 secs, you could be loading the cars from RAM instead of the disk. Unfortunately, addressables will always load from the disk, even if that same asset was released just 1 second ago (I think they have a lot of opportunity to improve loading time performance here). You would need to restart the system every time you want to measure the times.
1 Like
Thank you for answer. I didn’t know this before but anyway I managed to reduce the loading time to ideal times.
@Peter77 I agree that Addressables should be able to handle several subsequent calls at the same time without messing up. I was more suggesting something I thought would be a better workflow but also had the potential to workaround that if it was a problem.
If we can get a consistent repro of consecutive async calls not working we should address it.