You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I've been using bepu for a few years now. However I recently have had to diagnose an issue in my project, so I looked to reproduce it in the demos which I'm familiar with.
However, I had to change the rate from 1/60 to 1/120 to match my settings. This completely slows down the CarDemo for example. So I assume there are still some assumptions about being 60hz around the demos project, but I couldn't figure it out myself. I did see a hard-coded 60 for the framerate debugger as well, but that didn't solve the issue.
So I'm just making this issue to bring awareness that the demos can use more access to the actual tickrate somewhere, so it can be easily changed via the one constant
The text was updated successfully, but these errors were encountered:
The demos simply execute updates at the refresh rate of the monitor or as close to that as it can get. That does indeed mean that changing the timestep duration from 1/60 to 1/120 will make time progress half as fast, since by default, only one timestep is executed per graphical frame.
This was done for simplicity and for debugging; it's often helpful to have a visual representation of every single frame, and there's no hard requirement for consistency in the demos application.
That said, it was definitely less wonky back when most monitors were only 60hz. I was playing around with it on a 240hz laptop recently and... something does probably need to change :P
I might just add a simple flag for temporal accumulation based timestepping. There's already an example implementation commented out in the demo update showing how to do it.
Hello, I've been using bepu for a few years now. However I recently have had to diagnose an issue in my project, so I looked to reproduce it in the demos which I'm familiar with.
However, I had to change the rate from 1/60 to 1/120 to match my settings. This completely slows down the CarDemo for example. So I assume there are still some assumptions about being 60hz around the demos project, but I couldn't figure it out myself. I did see a hard-coded 60 for the framerate debugger as well, but that didn't solve the issue.
So I'm just making this issue to bring awareness that the demos can use more access to the actual tickrate somewhere, so it can be easily changed via the one constant
The text was updated successfully, but these errors were encountered: