I am trying to load a large size (10MB+) 3D model stored on the server in a WebGL build into a Scene using Addreassable dynamically.
I am running into a problem where the game pauses during loading, probably due to lack of multi-threading support.
I think the workaround is to preload the files, but there are so many types of files to load that preloading all of them will easily reach the mobile Safari memory limit of about 500MB and cause the game to crash, so I need to load the minimum amount.
Can you please tell us how to solve this problem?
Yes, there is no multithreading. Whether you preload or load when entering a level you will have a delay and rising memory consumption. The major benefit of using addressables is that you can unload them, thus freeing memory after each scene. However this only makes sense when some assets are only used in some area and you have a transition between them such as a „level complete“ screen. If that‘s not what your game allows (ie seamless open world) then addressables will not help you solve memory issues.
Determining which assets go into which addressable and when to load/unload each addressable is something only you can solve.
Note that loading an addressable asset may initially (in the loading frame) allocate more memory than if it were included in the build.
@CodeSmile
Thank you for your response.
My question was not about memory consumption, but how to control the temporary game stiffness that occurs when loading addressables assets. That was the intent of my question.
Also, if the game is preloaded, the stiffness is not an issue, because the user will not notice the game stiffness because the screen has not yet been loaded.
In the application I want to do, when a new player joins during a multiplayer game, the player’s model needs to be loaded.
I want to make sure that the game does not become rigid during that loading.
This is not a particular problem if I preload and treat it like an object pool, but it can be a problem if I load it dynamically.
All of those models need to be preloaded, otherwise you’d force all connected clients into a loading screen. Unless you make it so that only the local player sees its custom model, while for everyone else that player looks like the default player.
If the design calls for players to choose a large number of models, or even provide their own, then I’m afraid you’ll have to change that design, or the target platform so you can make use of multithreading.
1 Like
It still seems difficult to read custom-like avatars along the way.
If anyone knows of another way to do this, please let me know.