BEPUphysics

I have an 'Entity' that falls from one point to another in a simulation under the force of gravity (0, -10, 0).

If the window in which the simulation runs loses focus then the object will move much faster than if the window has focus.

If the object is reset to its original position and orientation once reaching its destination, and its linear velocity and angular velocity also are reset to (0, 0, 0), then the object will slow down once it has undergone a variable number of iterations.

Why is the speed of the physics simulation fluctuating in these scenarios and how can I prevent it from happening?

My current settings for the simulation are:

If Space.Update(dt) is being called (as opposed to Space.Update()), the engine will take as many steps as required to reach the accumulated time. Apparent variable simulation speed implies that the dt does not match elapsed real time. Make sure the time measurement is working properly.

If Space.Update() is being called instead, variable speed is expected if the frequency of calls to Space.Update() varies. This would usually manifest as an out-of-focus window running slower, not faster. Higher update frequency for the out of focus window explain the behavior.

I'm using:
Using:
makes the problem worse.

How can I ensure that the dt (gameTime.ElapsedGameTime.TotalSeconds) matches the elapsed real time so the fluctuations do not occur? The FPS is constant at 60.

What does BEPU use to calculate the elapsed real time?

How can I ensure that the dt (gameTime.ElapsedGameTime.TotalSeconds) matches the elapsed real time so the fluctuations do not occur?

In my experience, the XNA gameTime.ElapsedGameTime.TotalSeconds does the job well enough. I wouldn't expect it to be the sole cause of big slowdowns or speedups without some other interference.

The FPS is constant at 60.

If the update rate is constant at 60 in all of these tests, then calling Space.Update() without a dt should result in a constant speed. Your Space.Update() test would imply that the update rate isn't constant.

That doesn't explain the issues while using Space.Update(dt), but it could lead somewhere.

What does BEPU use to calculate the elapsed real time?

It doesn't. It is completely dependent on external input. The user specifies the time to simulate per time step and also specifies how many time steps to take.

The dt never fluctuates either so something else is causing the issue.

I have the value for 'dt' printed to the screen each frame and it reads "dt = 0.016667" at all times. It remains the same even when the physics simulation slows down slightly.

It is odd because the simulation slows down after a few iterations (around 3 seconds) then stays settled at a slower rate.

If the dt is perfectly constant, the Game is probably has IsFixedTimeStep = true. That means the Game will try to dispatch equal-length Game.Update calls to keep up with real time, similar to how Space.Update(dt) works. In fact, if IsFixedTimeStep is set to true, there's no reason to use Space.Update(dt) over Space.Update(). Space.Update() is recommended in that case.

Note that even if the Game's dt appears perfectly constant, calls to Game.Update may not be occurring once every dt, and there may not be exactly 1/dt updates per second. This is most commonly seen when the Game.Update takes the CPU more time than the time step length, causing the game to fall behind. In this situation, it's impossible to actually keep up, so things slow down.

I would recommend isolating the issue. For example, rather than updating the physics engine and worrying about all of that complexity, just move a position a fixed amount each Game.Update and visualize it with a sprite. Based on what you've described, I would expect the sprite to 'slow down' in the same way. Confirming that it's something unrelated to the physics would be helpful.

I'll take that on board and delve further.

I can't download the demo I created to highlight problems as the attachment is no longer available: viewtopic.php?f=4&t=1839

Is it stored anywhere on the server? It would save a great deal of time to be able to get a hold of it again.

Is it stored anywhere on the server? It would save a great deal of time to be able to get a hold of it again.

It appears all attachments were purged during the recent forum-oopsing, and I don't have backups of any of the attachments between October 21, 2011, and November 25, 2013. (oops)