So if you add a mesh to the picker list when the onNewMesh obs is fired, it will fail because the _forcedInstanceCount and _LODLevels is not ready yet.
The work around is it wait a frame, but I’m not sure if this should be considered a bug, or just a situation you have to do a timing work around.
Seems at the moment waiting for a frame is the best option.
I think it should be considered a bug as there is no explicit documentation around this and I dont think it is expected behaviour. Waiting a frame works but feels a bit hacky IMO
Here is another solution with extra observer - https://playground.babylonjs.com/#YU2IJ5#15
This is an interesting chicken and egg problem. To detect if the mesh has thinInstances we need a first round of rendering to get all the late bound variables in place.
We can either document that limitation or try to adapt. I’ll think about it and report here
The main problem with OnNewMesh is that it is called before ANY other initialization. It is literally the first thing to happen in mesh constructor. So no other attributes are ready to be used. This is because the code to call that observable is in the AbstractMesh class that is called by all super() in the child classes.
Thus I would not qualify this behavior as a bug. It is a de facto product of how the engine works.
That being said I’m not comfortable with the current implementation so I think I will automatically delay to the next frame the call to these kind of observables.
Here is the PR:
Goal of this PR is to make sure we raise the onNewXXX when the entity… by deltakosh · Pull Request #15848 · BabylonJS/Babylon.js
I just noticed this last night that anything dealing with the mesh buffers would fail at that point, so yeah I agree not a bug and not specific to the GPU picker even.
And simultaneously I think the correct expectation is to get the mesh when fully ready inside the onNewMesh so I think the PR fixes that
I think so too, that solves the expectation of the mesh being actually ready (at least for the case of GPUP). Thank you!