RetekEger

Members
  • Content Count

    3
  • Joined

  • Last visited

  1. I just went and confirmed, that the issue only exists with the physics engines' time-step, not with programmatic or loaded skeletal animations. Playground tutorial where the issue can be seen, also can change to Oimo on line 11 with same output: https://www.babylonjs-playground.com/#DU4FPJ#3 Confirmation control animation that I checked: https://www.babylonjs-playground.com/#IQN716#9 If I can help with anything to move the solution further just ping me! Thx!
  2. Hi @RaananW, Thanks for the fast answer! Actually in the before mentioned example, the timestep is explicitly set to 1/60, and for my scenario I find 120 FPS a bit of overkill for this edge case, although I'd need to be sure, that animation speed is independent of the user's FPS. Is there a best practice, to limit the physics engines' FPS to 60, even if running on a 120Hz monitor? I'd expect all animations to play the same speed if I use deterministicLockstep, regardless the environment (except for lockstepMaxSteps), but might be, that I'm misunderstanding the whole concept - that is why I asked for confirmation. Thanks in advance!
  3. Hi, I'm pretty new to Babylon.js, only started using it a few days ago, but really enjoy it, great work! I encountered some odd behavior with using deterministic lockstep on my setup, when running the example from the Animation page (https://www.babylonjs-playground.com/index.html#DU4FPJ#3) on my laptop's display (120Hz) the animation is twice as fast as on my connected monitor (60Hz) - tried with both Latest and Stable version, with both Cannon and Oimo plugins. My first guess would be that the algorithm is only prepared to handle low FPS, and does not take into account possible higher values. Also tried to dig in to the project on GitHub, but since I'm not that familiar with the structure, sadly I did not find the sources responsible for the behavior. Could some expert please verify my finding? Thank you, keep up the good work, cheers!