Popular Content

Showing content with the highest reputation on 12/21/19 in all areas

  1. 1 point
    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.