However, when I change the material for a mesh (and set isChangesInScene=true), or add it to a HighlightLayer, the changes are not applied immediately, and the rendering that is called right after the changes does not reflect them. And since no more renderings are called (until the next changes occur in the scene), the scene remains rendered incorrectly.
To solve the problem when changing the material, I called material.forceCompilation(mesh), but this didn’t help.
Is there perhaps some mechanism that allows tracking whether more frames need to be rendered to correctly display the scene with all the changes?
This doesn’t sound like the most elegant solution. Are there perhaps some events that allow us to understand whether the internal processing of the mesh has been completed?
EDIT3:
I have two PGs open with tha same code. In one of them it works in the second one it doesn’t… WTF! I’ve just created a screen recording but I’d rather investigate a bit more on the issue, don’t want to look like an idiot if I screwed up something obvious
EDIT4: One of them didn’t stop the default render loop.
If the change takes longer than the timeout, then there will be an incorrect result on the screen, and if we make a very large timeout, then there is too much unnecessary rendering, which negatively affects the battery life of mobile devices.
When I worked directly with WebGL, after each change (loading textures, compiling shaders, and so on), I called a special callback that initiated a frame redraw. Is there something similar in Babylon?
You could use a numberOfRendersNeeded variable instead of isChangesInScene. Or even better create a function called function rerender(changeType) and call this to queue some render cycles. Queue number of cycles according to changeType.
More generally, is it really that we need actual renders? Or is it not rather some async stuff going on which takes a bit. So the problem would be to figure out how to measure precisely when the async stuff has finished.
No timeout but render cycles. You might associate number of rendering cycles needed to the actions you perform. If you add a mesh to the HL it’s 2. If you move the mesh, it’s 1. So you render 2 times or once. If you perfrom these actions together call render (2 > 1) 2 times.
I have created a component for react-babylonjs that listens to movements and animations.
in my own app (not react-babylonjs) i had a similar issue as yours. I made a global variable that I could change to force a rerender. something like:
Currently, I’m using isReady and running forceCompilation if !isReady. The callback of this function tells me when the compilation is finished, and I perform a redraw.
However, I wish Babylon.js had a mechanism that would allow intercepting all changes in the scene (shader compilation, texture loading, and other things). It’s a pity that it doesn’t exist. Without it, you constantly need to figure out which callbacks to attach to which events that might change the scene when rendering is complete.
For now, I’ve figured out the issue. It’s a pity that Babylon.js doesn’t have exactly what I was looking for, but your answers have given me an understanding of what to do next. Thank you all very much!
I believe this functionality will be very welcomed by the community. Nowadays a lot of products are designed for mobile platform at the first place, desktop comes as second. Saving the battery by rendering only the necessary amount of frames could be a very useful stuff.
@Deltakosh what do you think about it? Can we somehow notify the client code that everything has been rendered? If so and we get enough votes and you give me some pointers where to start I’m willing to do the PR.
