I tested loading models from disk in a separate thread using Delphi / windows.
I loaded the same model 200 times into an array,
It looks safe and stable, as long as I avoid calling:
procedure TCastleDownload.Update(Sender: TObject); begin Exit; … end;
Results: no crashes no exceptions no freezes The app stays responsive, even when loading many or large models.
It works well for me, but it may behave differently on other hardware or platforms
Thank you! I will test your example soon – as an inspiration. We have to enable asynchronous loading in the engine in a safe way
Though for now I have to emphasize a warning from Threads | Manual | Castle Game Engine : We do not support using the engine (and this includes loading the assets) from multiple threads .
The fact that it works in a particular case, doesn’t mean it will work always (like on other systems, under different workloads etc.) or in other cases (other models, loaded with different settings etc.).
While it may work in some cases, all kinds of things can happen in theory. This includes crashes and just undefined behavior, and it may crash differently on different systems, or under different overload of these systems (where threads’ execution will “intertwine” differently), or with different models (e.g. using more textures or different texture formats) or with different OpenGL implementations on these systems (since this is also about communicating with OpenGL API). The reason: We have some caches underneath (like for VBOs and textures) and they are not thread-safe, and if some codepath will change these caches from multiple threads → any crazy crash may happen
I know that loading in the background would be very useful. And loading stuff in parallel can make it much faster, due to multiple cores on modern systems. But it’s just more work on the engine side to really be secure and to synchronize where necessary. We plan to add stuff like TCastleScene.LoadAsync that would utilize threads under the hood.