Updating versus Drawing Meshes/Objects

[amorgan]

I have a generic question, does Babylone separate out updating Meshes versus drawing/rendering them?

 

Let me elaborate, for example, say I have an animation that is supposed to run at 60fps and has 3 keys that are manipulating position.x with a linear transformation at frames 0, 30, and 60. So

keys = [{frame: 0, value: 0},{frame: 30, value: 10},{frame: 60, value: 0}];

What is actually happening if my computer can only do 30 fps? Does the animation interpolate and skip half of the frames, or does the animation slow down to half the speed?

 

I'm working on creating a logic loop for a game and trying to understand how to separate it out so that a slower fps doesn't slow down the gameplay, but just the refresh rate of the render. I am thinking I need to have a logicLoop, updateMeshesLoop and then the renderLoop (which comes from Babylon). Therefore I am trying to understand what Babylon does and how I can work with it to achieve this, using Babylon Animations, moveWithCollisions, etc.

 

This might be a naive question, since if the fps is slow, then I would imagine other calculations are also behing held up. I'm brainstorming on how to achieve consistency.

[GameMonetize]

Animation are scaled to run at required speed (60fps per default). So if you are running at 30fps, animation will still run at 60fps

[amorgan]

So it is essentially skipping frames then in that scenario, in regards to that animation? Since the movement is happening at 60fps, but the scene is only being rendered at 30fps.

 

I'm also trying to understand what happens in general when a computer is running at 30fps. I understand that it is because that is as fast as the GPU can handle the scene, but more in context of babylon. For example if I am calling moveWithCollisions in the registerBeforeRender loop, but am running at 30fps, then the moveWithCollisions then would also? That is more of what I'm also trying to understand. For consistency I feel like I will need my own loop to control that, but if the renderLoop is actually taking more time to execute, for example at 30 fps or every 33.3333 milliseconds, then I would not be able to update any faster because it would be blocking? Unless I'm not understanding what is being handled by the GPU vs CPU...

 

Edit: On another note, it would be nice to be able to force the renderLoop down to specific fps for debugging purposes, and simulate a slower computer.

[GameMonetize]

The main problem actually is that you only have one thread in JS. but in you case you can keep working with the registerBeforeRender function but you have to scale the distance with scene.getAnimationRatio (will return 1 is rendering is running at 60fps, 2 is rendering is at 30fps and so on and so on)

[amorgan]

I did not know scene.getAnimationRatio existed. That will help alot then!

 

I'm trying to create a pattern that is similar to this: http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml which is a fixed time step for the game logic loop. Not following this example directly, but making my own flavor. So I'm trying to wrap my head around how do this and integrating it into the BJS framework. I recently created a loop that I called timedLoop that recursively calls setTimeout and calculates the actual wait to get the desired wait time. I'm in the process of expanding off of that and would like to create a library for use.

 

So I'm thinking my logic loop will do everything except manipulate meshes and draw. And then have the registerBeforeRender function manipulate meshes and then scene.render let it render, of course. And use the scene.getAnimationRatio to account for a slower framerate (inside of registerBeforeRender). I will try this scheme and see what problems I run into.

 

Edit: I have noticed that on a slower device, if my game logic loops gets slowed and can't process in the desired time, there is nothing guarding that and it increases to how fast it can be ran. So I might need to have a priority list and discard actions if they can't be handled within that time and stop the logic loop before it reaches the desired time. Or some other way to degrade gracefully, which might be more of an architectural problem than a limitation. Sorry typing out loud.