alternative to 'registerBeforeRender'?

[jellix]

Hi folks,

I want to change some values on every 'frame' (or 'tick' or 'renderLoop' ... how do you call it correctly?). And I only want to do that in specific cases.

So I could put it into the Scene.registerBeforeRender function. There I could implement an if-question to check if the values should be changed or not. In my opinion it doesn't feel very good.

Is there a kind of listener to get the event when a frame is rendered like requestAnimatioFrame (from the babylon engine and not form the window or document itself)?

 

[GameMonetize]

Hello

this is exactly what registerBeforeRender is about

[Pryme8]

You could do a secondary timeout loop but the before scene register will give you better results.  Keep it down to one register and use other functions to make it more dynamic.

[jellix]

thanks for your answers.

Sorry, I'm still a bit confused ...

Let's say I use the registerBeforeRender to rotate a cube permanently.

Now I have a special animation that I want to apply to a torus that is only 30 frames long ... If I use the registerBeforeRender for that, it will lose the previously written rotation for the cube.

(And I don't want to use the animation-framework of babylon for that.)

[GameMonetize]

Nope registerBeforeRender is cumulative  (like an event)

[jellix]

Ooooh, I see - that's new to me.

Thanks for the info, great!

[Pryme8]

But keep in mind they have to calculate fully before a draw call...  so don't just make a bunch. 

 

@Deltakosh am I mistaken but it's my impression it has to fully process each of the before render functions before the render function process on each tick?

[GameMonetize]

Correct as there is no threading support everything has to be run synchronously

[Pryme8]

Ehhhh yes and no...  you can simulate sub threading.

 

so get this you have your before register loop running in it you have a series of functions that you want to fire every frame, now if you just put the function in there it would have to calculate fully before moving to the next line.  Now we know if we do a timeout it will go ahead and go to the next line.

so we wrap all out functions in their own separate timeout and have the function itself calculate a call back when ever it's conditions are met, which you could have them recursively checking themselves to check for the go to response state.

i know this sounds wishy washy, but it's possible and is the basis for mmmPieUi (though that has no relation to bjs or the beforerender stuff but functions on the same premise of buffered function asynchronous calls)

 

the reason I call them a buffered function is because you need to have them have the ability to fail as often as they need to and just keep calling themselves till their associations or other conditions are available.  This will impact performance so that's where the buffer comes into play where you use a io rate and date calculations to check if it's time to rerun the check, hence the buffer.