Better understanding of registerBeforeRender() function

[Vousk-prod.]

Hello,

I understand the principles of registerBeforeRender function, but I'm wondering what is the difference and the benefit of doing

scene.registerBeforeRender(someStuff);

instead of

engine.runRenderLoop(function () {

someStuff();

scene.render();

}

For what kind of situation this function have been added to the framework ?

[Temechon]

Hi, 

 

Generally, in a game, you want one engine and multiple scenes. With this method, you won't have to check in your renderloop : 

if (scene1.isActive) {} ... is (scene2.isActive) {}...

 

But if you have only one scene in your project, it's exactly the same.

[GameMonetize]

There is also the case where you do not own the renderloop(like if you use the playground for instance)

[Vousk-prod.]

Ok, thanks for your answers.

So, since I already have my own game logic in place, with a very similar registering tasks system in my scenes and engines managers, I have no particular benefit (in terms of performance for instance) using registerBeforeRender in my main "render loop". Better to call my registered events directly instead of (re)registering them with registerBeforeRender.

The flexibility and the whole bunch of available options really make this bloody BJS a truely piece of art, love it !!

[Vousk-prod.]

I'm wondering whether tasks registered with registerBeforeRender() are framerate dependant or not ?

For instance if I update camera position in a function sent to registerBeforeRender, the movement speed will be constant whatever the device or be framerate dependant ?

[Dad72]

It depends on the framerate, since this function is called just before rendering that depends on the framerate.

[Vousk-prod.]

That's what I presumed, but there are often smart mechanism I don't notice deeply implemented in the rendering process, better to ask to be sure then

Thanks.

[JCPalmer]

beforeRender is mostly about code organization, with no performance effect.  There are 2 types of beforeRenders,  those registered to the scene & those registered to an individual mesh.  I am only going to talk about those registered to an individual mesh.

 

A mesh beforeRender is much more OO, especially if subclass your mesh.  You can do sophisticated things like have a variable number of "bad guy" meshes moving around.  Just instance them, then register a beforeRender.  Doing this for each instance in the render loop is extra management code that adds no value, toxic.

 

If you do not subclass your mesh, like if it is coming from a .babylon, then you will need to create a class for your before render, so that you can pass the Mesh to work with in the constructor.  The constructor can do the actual registration though.

 

You can do things in a beforeRender, like check if the state of has somehow changed, and react.  I am doing this in DIALOG.Panel.  You could put this in render loop too, but a render loop could become a total mess fast.  The only thing a before render might not be able to do is run when visibility = false;

 

beforeRender is a great way to write an extension, because you can have more than 1 per mesh.  So you can have one checking for some state change, and still use the POV extension, which is implemented as a before renderer.

 

Really, a better question is what is the benefit of having more than a token render loop? It might be good for non-programming types,  or learning an experimenting.  The bigger your game, you will start to see that introducing more and more advanced logic becomes difficult to deal with.

[Vousk-prod.]

Oooh I didn't know mesh beforeRender existence !!

Clearly this is a powerfull tool to keep code simple, well structured and without redondancy. Once again I'm astonished by the versatility of BJS !

Thanks for the piece of info JCP !

[JCPalmer]

FYI,  I had thought about the need to either subclass a mesh or make a class to hold the before-renderer in order to really use it.

 

Neither would be required, if the call to the renderer was passed the instance of the mesh it was to work with.  Good news for users of .babylon files.  Made a feature request, here: http://babylonjs.uservoice.com/forums/267546-general/suggestions/7128610-mesh-before-after-render-upgrade

 

Btw, there is also an after render feature.

[GameMonetize]

Will be in the next push

[styxxx]

How do I use beforeRenderer on meshes (not scenes)? I couldn't find it in the codes or docs.

[Convergence]

You can do sophisticated things like have a variable number of "bad guy" meshes moving around.  Just instance them, then register a beforeRender. 

So I just discovered mesh.registerBeforeRender through this thread, and this was exactly the type of implementation that I was looking for, however it looks like mesh.registerBeforeRender doesn't get called when the mesh is invisible (makes sense, the name is apt), but then the AI for those invisible creatures stops working. What would be a good solution for that?

 

 

How do I use beforeRenderer on meshes (not scenes)? I couldn't find it in the codes or docs.

Just call mesh.registerBeforeRender(function) for every mesh that you want to have this callback;

[styxxx]

Thanks! Seems like instances don't have their own registerBeforeRender. Good to know  

[GameMonetize]

For invisible meshes, Babylon.js tries to remove them as soon as possible so the best option should be to still use scene.registerBeforeRender and iterate through your list of invisibles meshes