Performance of load_threaded_request for a huge stage scene with multiple resources inside

[nines]

Godot Version

4.5

Question

I’m looking at Background loading — Godot Engine (stable) documentation in English , and I would like to use load_threaded_request. I also see that I have to do polling to get the progress of the resources loading.

Suppose I have a scene of a grassland stage that has the player, enemies, trees, etc. - all of these MeshInstance3Ds along with their textures, skeletons, animations, shaders, etc. will be loaded in one go with load_threaded_request. Afterward, I could use load_threaded_get_status ( ResourceLoader — Godot Engine (stable) documentation in English ) to see the progress of the loading.

Questions:

1. is it possible to know the status of each resource in the whole scene here rather than just the number 0.0 to 1.0 for the whole scene?

2. Regarding the description of load_threaded_request:

Loads the resource using threads. If use_sub_threads is true, multiple threads will be used to load the resource, which makes loading faster, but may affect the main thread (and thus cause game slowdowns).

Assume that this is during a loading screen where the player is not playing so slowdowns do not matter.

In this case if the resource I am loading is a scene and it has many resources associated as aforementioned in the second paragraph above, will using load_threaded_request with use_sub_threads set to true be faster than just a normal load ? If so, I am thinking this should be beneficial for a very huge scene.

If not, what about we have a list of resources that we know exist in the grassland scene and load them first with load_threaded_request with use_sub_threads set to true first. Once all the threaded loads are done, we then load the grassland scene. This should be faster, right?

[normalized]

@nines

is it possible to know the status of each resource in the whole scene here rather than just the number 0.0 to 1.0 for the whole scene?

No, due to how resource dependencies are handled by the engine. There was an article on this very topic by Linietsky (iirc) but I cannot seem to find it right now.

@nines

In this case if the resource I am loading is a scene and it has many resources associated as aforementioned in the second paragraph above, will using load_threaded_request with use_sub_threads set to true be faster than just a normal load ? If so, I am thinking this should be beneficial for a very huge scene.

On multi core machines it’s always better to use sub threads if your main thread is not doing much work. This will always be the case if you’re only displaying loading screens. But have in mind that threaded loading can also be used to stream in the “future” data while the game is being played. In that case, it may be preferable to give more processing power to playing the game and load “slowly” in the background. Ultimately it will all depend on the specifics of your game.

@nines

If not, what about we have a list of resources that we know exist in the grassland scene and load them first with load_threaded_request with use_sub_threads set to true first. Once all the threaded loads are done, we then load the grassland scene. This should be faster, right?

It probably wouldn’t make much of a difference.