However, I have a project where I have hundreds of meshes in my scene and I only enable a small portion of them. Therefore, I don’t want the disabled meshes to use up computation resources every frame to check their readiness when they are not rendered anyway.
I can fix this by overriding the method but I’m afraid that then I will reintroduce the bug that was fixed by this PR. This makes me wonder: how can I reproduce the bug that this PR is supposed to fix?
most of the time if you load something, you are willing to present it. It could be disable at first but the app will make it available. So to prevent issues and stuttering during the runtime phase, we had to check meshes independently of their state.
It makes me wonder why in your case you are even using process to parse/load/create assets in your scene if they are never used ? This is also detrimental to the overall perf of your application.
As discussed on the PR we can introduce a mode to reach back the previous behavior but this is still not the most efficient way ?
In my case, what I forgot to say is that the set of enabled meshes can change quickly from one frame to the next, depending on multiple factors including, for example, a custom frustum culling.
So I need all meshes to be ready, but I don’t need to check their readiness on every frame.
What I got wrong is that I was calling isReady on every frame, which caused all meshes to be checked. Actually, from what I understand, isReady is not really supposed to be called outside of the executeWhenReady function, right ?
Anyway, I fixed the problem in my project by only checking readiness when new meshes are added to the scene.