Vousk-prod.

Better understanding of registerBeforeRender() function

Recommended Posts

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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 !!

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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;

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.