Question about Update

[Telanor]

I've just added BEPU physics to my game and I've been having a bit of an issue with the update speed. According to the documentation, calling Update() will advance the simulation by 1 timestep as specified by Space.TimeStepSettings.TimeStepDuration. The alternative is to call Update and pass it a delta time, which will cause BEPU to update several times if needed. What happens if my timestep is 1/60 but I pass a dt of 1/120? I currently update BEPU with the following call:

Code: Select all

Space.Update((float)gameTime.ElapsedGameTime.TotalMilliseconds);

And yet, the physics still seems to be framerate dependent. My game currently runs at around 400 fps with shadows off. Toggling them on lowers the FPS to around 120. When I do this, I can watch an object falling suddenly speed up or slow down based off the FPS. If I don't want to run XNA with vsync/fixed timestep on, how can I have BEPU update based on the time that has passed rather than the number of frames that have been rendered?

[Norbo]

What happens if my timestep is 1/60 but I pass a dt of 1/120?

It will accumulate 1/120f worth of time. If the accumulated time is greater than 1/60f, it will perform a time step. The remainder at the end of any frame is used to compute interpolated states for smooth movement if the interpolated states buffer is enabled.

Space.Update((float)gameTime.ElapsedGameTime.TotalMilliseconds);

That is passing in milliseconds instead of seconds. That means the physics are being told to advance at 1000x real time. The Space.TimeStepSettings.MaximumTimeStepsPerFrame defaults to 3, though, so it only takes 3 time steps instead of hundreds. Since the clamp is so low compared to the target number, the physics appear to be framerate dependent.

The Space.TimeStepSettings.MaximumTimeStepsPerFrame can be changed, but hundreds of time steps per frame will be a little expensive Switching that line to TotalSeconds instead of TotalMilliseconds should result in expected behavior.

[Telanor]

Ahh, my mistake. Changing to TotalSeconds fixed it, thanks.

[coimbra79]

wow!!
i based a mine entire project and the relative physics on this line

Code: Select all

Spazio.Update(gameTime.ElapsedGameTime.Milliseconds);

it works properly becouse i've

Code: Select all

TargetElapsedTime = new TimeSpan(TimeSpan.TicksPerSecond / 60); 

and my pc is ever inside the 60fps...
But now im going to fix the relative parts of engine that requires to be modified in the cases the game 'isRunningSlowly'.
So i suppose i must to modifi all the forces and inertias... Would you mind to suggest me the right way to fix this apocalipticist situation, without implement some others 'BigDummyBug'

Thanks!

[Norbo]

So i suppose i must to modifi all the forces and inertias... Would you mind to suggest me the right way to fix this apocalipticist situation, without implement some others 'BigDummyBug'

Mass and inertia can be left unchanged, but all time dependent values do indeed require scaling. For example, if the game was effectively running at 3x speed before, gravity and other forces will have to be scaled up by 3 to keep the same apparent behavior.

There's also the option of setting TimeStepDuration to 3/60 and passing in 3 * gameTime.ElapsedGameTime.TotalSeconds to Space.Update(dt), assuming that the Space.TimeStepSettings.MaximumTimeStepsPerFrame was set to 3 and TimeStepDuration was set to 1/60f before. This is definitely a hack, but it ends up simulating at the same rate as the former Space.Update(milliseconds) approach since the Space was only simulating 3 steps of TimeStepDuration = 1/60f thanks to the MaximumTimeStepsPerFrame. Unlike the old approach, it will actually be framerate independent since it can actually keep up with the accumulating time.

I lean towards actually fixing the simulation to run at the normal rate rather than doing the hack, though. It's difficult to tune a simulation properly if you have to remember to apply an arbitrary scaling factor.

[coimbra79]

yes, your plane seem exact (naturally!)

I added the command

Code: Select all

Spazio.TimeStepSettings.TimeStepDuration =1f/60

with

Code: Select all

Spazio.TimeStepSettings.TimeStepDuration =1f/Main1.mApplicazione.TIME.FpS;

where Main1.mApplicazione.TIME.FpS get the current framerate.
It work fine (as seem)!

Do you think is a acceptable solution?

[Norbo]

If Main1.mApplicazione.TIME.FpS varies, it will cause instability proportional to the variability in the FPS. While it might be okay in most conditions, if the computer hitches for a half second, everything will probably explode. TimeStepDuration should be a constant value over the course of the simulation for best behavior.

Passing an accurate value into Space.Update(dt) with a fixed TimeStepDuration is the preferred method of getting framerate independence.

[coimbra79]

Ok, i'll work and try to set update following your suggestions!

Very Thanks!

Norbo for President!!