I’m having a problem when I’m trying to mix the deterministic lockstep engine setting with a 144hz monitor. It seems that despite setting the time-step to be (1/60), if the frame rate can reach 144hz each step will be (1/144). This can be seen using the example playground app on the document for using the feature…
document:
https://doc.babylonjs.com/babylon101/animations#deterministic-lockstep
playground example:
https://www.babylonjs-playground.com/#DU4FPJ#3
As you can see from the timestamps, at 60fps the engine reaches frame 551 after 8.726 seconds (0.0158 ms between frames) whereas at 144fps the engine reaches frame 551 after 4.005 seconds (0.00726 ms between frames) …
Is there a workaround for this? Something I’m not understanding?
hi
chrome by default keep frame rate on 60 fps
look about -disable-gpu-vsync
I appreciate the response but that’s not the issue I’m having.
The problem is, when using lockstep, even with the engine timestep is set to (1/60), it will run at (1/144) if the framerate reaches it. Which, shouldn’t happen I would think. The whole point of using deterministic lockstep is to ensure that things run at a set pace, not slower, not faster…
the lockstep will adapt animation to a determine value but will not control the speed of rendering
You can do it by updating your renderloop to check if current frame should be skipped (or just use setTimeout) as for now renderloop is called by the requestAnimationFrame
I get that. But the he doc says "Sometimes it is important to make sure animations, physics and game logic code are in sync and decoupled by frame-rate variance.... The principle is to quantize the state execution time, by updating the state at a fixed frequency with discrete time steps..." with the example of using physEngine.setTimeStep(1/60) saying… "With the code above, the engine will run discrete steps at 60Hz (0.01666667s)..."
As far as I can tell, that’s not happening as soon as the framerate goes above 60fps. I’m not expecting it to render at 60fps, I’d expect the physics simulation and the step count to be independent of the framerate, which is what the document implies…
yep and this is what should happen 
See here: Babylon.js/scene.ts at master · BabylonJS/Babylon.js · GitHub
the deltatime is build based on the lockstep
But I guess we are making the assumption on the framerate here: Babylon.js/scene.ts at master · BabylonJS/Babylon.js · GitHub
Maybe this hard coded 60 should be something user can define
So probably a bug then?
IMO it would be a parameter you pass in when you set the engine to use lockstep.
ie:
this.engine = new BABYLON.Engine(theCanvas, true, { deterministicLockstep: true, lockstepMaxSteps: 4, frequency: 1/60 });
It might also be important that the onBefore/AfterStepObservable are only called at the correct frequency, as well as the value from getInternalStep …
Um…I’d be happy to, and I could try when I get home later. Not sure if my TS knowledge is good enough though…
Ok I took a stab at it.
Here are my changes…
https://github.com/sacharobarts/Babylon.js/blob/lockstep/src/scene.ts#L3755
also had to make a few small changes to thinEngine.ts and engine.ts… as well as deterministicLockstep: true you can also pass in timeStep: 1/60 (or whatever value you want, 1/60 is default).
Here are the results…(top in red is the current, below in green is with changes)
I feel like I might be able to get it a little bit closer to 1:1…donno…
1 Like
This sounds like you are about to do a PR (And this is cool!)