5 ms·

I don't understand how not writing your own physics engine automatically negates what I said. If a developer has implemented a third-party physics engine, they

I don't understand how not writing your own physics engine automatically negates what I said. If a developer has implemented a third-party physics engine, they should refer to that engine's documentation.

giornogiovanna 8y ago
Typically physics engines can't be "modulated by the delta" (which I assume means varying the dt when integrating), you just have to tick the physics world multiple times and keep the roundoff for next time. [0] gives a good example of implementing this kind of thing. If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framerate is too low. [0]: https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/
- kakarot 8y ago
  Well first it depends on what you mean by typically. Number of total engines in the wild? Or current market share? But besides, if you are using a fixed physics engine you should not be using rAF. It's not meant for that. Your comment is just a bit tangential.
  - giornogiovanna 8y ago
    Bullet, Box2D and PhysX all highly recommend using a fixed timestep, and no, you should definitely be using requestAnimationFrame with a fixed timestep, just like in the fix-your-timestep article. The number of frames to advance the simulation by is still determined by the screen's refresh rate, after all.
    - kakarot 8y ago
      That really depends. Pegging your fixed timestep engine to rAF could have the consequence of dropping frames when you have a large gap between two frames and enough physics frames get called at once that the next rAF window gets missed. If your performance is bounded by the physics simulation, you could potentially trigger a spiral of death and never catch up. Of course there are ways to mitigate this, but that just further complicates things. You have the right idea, adding each frame delta to an accumulator and triggering a physics step when reaches the appropriate value, however rAF is not the answer because it can create a potentially infinite frame delta. It's usually best to not peg your fixed-timestep physics to rAF or at the very least, pause the game entirely when the window isn't focused.
      - giornogiovanna 8y ago
        Damn, you're right, it's more complicated than I thought. But what else would you use? setInterval suffers from the same problem, doesn't it?
        kakarot 8y ago
        That's a good question. setInterval definitely also has its strengths and weaknesses, but it does beat rAF() here in that you can guarantee at least one frame will be ran every X milliseconds. With regards to Javascript physics engines, I'm only versed with Matter.js. Matter.js's Engine.update() takes a frame delta as an argument and uses Verlet integration [0] to make things work under the hood. You can optionally calculate a correction factor to be applied each frame in order to smooth out calculations with janky framerates, but if you can maintain constant FPS then it's not an issue. Unfortunately, rAF() once again becomes a pain because of the lack of proper control over FPS capping, so monitors with higher refresh rates have a larger window for variable frame deltas. I'm hopeful that these shortcomings will eventually be addressed in the spec. [0] https://lonesock.net/article/verlet.html https://lonesock.net/article/verlet.html

giornogiovanna 8y ago

Typically physics engines can't be "modulated by the delta" (which I assume means varying the dt when integrating), you just have to tick the physics world multiple times and keep the roundoff for next time. [0] gives a good example of implementing this kind of thing. If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framerate is too low. [0]: https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/

kakarot 8y ago
Well first it depends on what you mean by typically. Number of total engines in the wild? Or current market share? But besides, if you are using a fixed physics engine you should not be using rAF. It's not meant for that. Your comment is just a bit tangential.
- giornogiovanna 8y ago
  Bullet, Box2D and PhysX all highly recommend using a fixed timestep, and no, you should definitely be using requestAnimationFrame with a fixed timestep, just like in the fix-your-timestep article. The number of frames to advance the simulation by is still determined by the screen's refresh rate, after all.
  - kakarot 8y ago
    That really depends. Pegging your fixed timestep engine to rAF could have the consequence of dropping frames when you have a large gap between two frames and enough physics frames get called at once that the next rAF window gets missed. If your performance is bounded by the physics simulation, you could potentially trigger a spiral of death and never catch up. Of course there are ways to mitigate this, but that just further complicates things. You have the right idea, adding each frame delta to an accumulator and triggering a physics step when reaches the appropriate value, however rAF is not the answer because it can create a potentially infinite frame delta. It's usually best to not peg your fixed-timestep physics to rAF or at the very least, pause the game entirely when the window isn't focused.
    - giornogiovanna 8y ago
      Damn, you're right, it's more complicated than I thought. But what else would you use? setInterval suffers from the same problem, doesn't it?
      - kakarot 8y ago
        That's a good question. setInterval definitely also has its strengths and weaknesses, but it does beat rAF() here in that you can guarantee at least one frame will be ran every X milliseconds. With regards to Javascript physics engines, I'm only versed with Matter.js. Matter.js's Engine.update() takes a frame delta as an argument and uses Verlet integration [0] to make things work under the hood. You can optionally calculate a correction factor to be applied each frame in order to smooth out calculations with janky framerates, but if you can maintain constant FPS then it's not an issue. Unfortunately, rAF() once again becomes a pain because of the lack of proper control over FPS capping, so monitors with higher refresh rates have a larger window for variable frame deltas. I'm hopeful that these shortcomings will eventually be addressed in the spec. [0] https://lonesock.net/article/verlet.html https://lonesock.net/article/verlet.html