Unstable framerates and cars?

[RedToasty]

Hi,

Most likely an easy one Just wondering if there is any solution to unstable frame rates in games, dropping the odd frame is causing big stutters in movement at the moment. This is the sort of issue I'm having on slower PCs:

http://www.youtube.com/watch?feature=pl ... MVtiE#t=8s

I've dropped a silly amount more objects in and disabled threading to highlight it a bit more:

http://www.youtube.com/watch?v=1QksjcaCiKE

I'm using the default FixedTimeStep = false within XNA in these examples, and I'm passing the delta to the update. The only solution has been to clamp the framerate to lower than I can guaranteeing it ever going and altering the TimeStepDuration manually. I've played about with letting it use internal timestepping and MaximumTimestepPerFrame has been tested on 2-10, but always had similar results. Curiously my work PC is a big Xeon 8 core jobby, it gets stutters while multithreaded on all cores, but no issues running on a single thread. I assume the overhead of threading is outweighing the benefit at that point?

Note to anyone just curious about Cars and Bepu - It's been fantastic! I've literally ported this across to BulletXNA, JigLibX and Jitter. Bepu is by far the fastest and most solid I've used, I've managed to have a huge variety of bodies zooming around the mesh in ways that exploded all the others. After literally porting over, and over again, I can also say it was by far the easiest to integrate, it's about the only one that feels like the code was planned out before it was written.

http://www.youtube.com/watch?v=4OTFg0GJLpE

Slightly more realistic example of a Bepu stock car, in which I've let it have all the cores and set the bodies back to a sensible number (apologies for the raptors death effect ). Each raptor is a simplified character controlled, using a sphere instead of a capsule, even in this one there's 200. In the bad stuttering example there were 800, in a 35,000 vert triangle mesh, with 1 core.

[RedToasty]

Extra note, the above is actually stable if I use:

IsFixedTimeStep = true;
TargetElapsedTime = TimeSpan.FromSeconds(1.0f / 20.0f);

To force the frame rate to stay consistent.

Oh and if you're curious about the stress testing:

http://www.youtube.com/watch?v=6fnNG1OCOfA

The first 20 seconds or so are Bepu, the second half is JigLibX running the exact same test. The cars matching, right down to body sizes and spring lengths. I ran similar for BulletXNA, in which things just fell straight through the floor, and in Jitter I couldn't get the car stable with 1/60th timesteps at anything beyond walking speed. Even without the threading, Bepu was the fastest I've seen.

[Norbo]

Calling Space.Update() without a parameter steps forward by exactly one time step, while Space.Update(dt) takes as many time steps of length Space.TimeStepSettings.TimeStepDuration to simulate the accumulated time. When using the Space.Update(dt) version, the engine can take a varying number of time steps per Space.Update(dt) call. Sometimes it could be 0, other times it could be 2. (Under bad conditions, it could go up to 3, but beyond that the Space.TimeStepSettings.MaximumTimeStepsPerFrame limit- which defaults to 3- will kick in.)

Since a different amount of time can be simulated in each frame, things can appear to jitter around a bit.

Here are some potential fixes:
1) Use interpolated states. The time remainder at the end of each frame is used to blend between the last two computed states. More information can be found in section 2.B of the Updating Asynchronously documentation. (Interpolated states are not directly related to asynchronous updating, but it is a common use case.)

To use interpolated states, set Space.BufferedStates.Enabled to true, and then use the Space.BufferedStates.InterpolatedStates.GetState or GetStates, or the entity.BufferedStates.InterpolatedStates properties.

2) Set the game.IsFixedTimeStep to true and use Space.Update() without passing in a time. This will technically still exhibit jumps because the game itself can perform a varying number of updates between draw calls, but sometimes the jumping will be less noticeable because the entire game is doing it consistently.

3) Set game.IsFixedTimeStep to false and use Space.Update() without a parameter (and without modifying the Space.TimeStepSettings.TimeStepDuration on the fly, which is generally bad for stability). This guarantees a fixed number of time steps per draw call at the cost of simulation framerate coupling. For some games, this can be a viable option. When the game drops below 60 fps, the simulation slows down but there's still no jumpiness. Clients simulating at different speeds could introduce significant problems for a networked game, of course.

Curiously my work PC is a big Xeon 8 core jobby, it gets stutters while multithreaded on all cores, but no issues running on a single thread. I assume the overhead of threading is outweighing the benefit at that point?

Threading tends to scale quite well. While I don't have an 8 physical core computer to test on, the 6-core 3930K scaled decently. There was a fluctuation past 9 threads on the simulation tests that I have yet to explain (it may have simply been some environmental quirk), but I expect that going all the way up to 16 threads would not be substantially worse than the 12 thread case. I doubt that the extra 4 threads would take it from 4x+ faster to slower than single threaded, especially considering that the tested simulation with the most contention actually scaled the best.

I suspect that the difference in performance causes the time to accumulate in such a way that it becomes more/less noticeable.

Bepu is by far the fastest and most solid I've used, I've managed to have a huge variety of bodies zooming around the mesh in ways that exploded all the others. After literally porting over, and over again, I can also say it was by far the easiest to integrate, it's about the only one that feels like the code was planned out before it was written.
... Even without the threading, Bepu was the fastest I've seen.

Glad to hear it's working well for you!

(apologies for the raptors death effect )

No need to apologize- as an expert in raptor related simulation, that is a perfectly realistic portrayal.

[RedToasty]

Huge thanks for the info, I'll have a tinker! Interpolated states sound interesting, I'd not spotted those.

Threading definitely works well here, my home PC is an i5 3570k at 4.5ghz, letting it have 4 threads scales pretty much as per the front page post. It's possible there was a bit too much going on on my work PC, to let it steal all of them, hence what looked like locking.

No need to apologize- as an expert in raptor related simulation, that is a perfectly realistic portrayal.

I'd planned on raptor ragdoll, they're skinned anyway so it would have been fairly trivial Sadly I got a little sidelined testing all the physics engines and getting shadowing working, then ran out of time (for the "Prehistoric" game challenge at work, I kid you not). I did try the simple character raptors as just spheres, which halved their update time, probably something I'll swap back to using in the long run.

I get to hack it to bits now and try to make a proper game, I think something like Carmageddon is the target. I've got an Xbox and Vita for playing with, if Vita goes well I might have a look at Mono for Android/iOS

Thanks very much for your swift feedback! It's amazing the array of solutions you have for each and every query that gets thrown up on here.

[RedToasty]

Interestingly I got worse results with interpolated states, I'm not too sure why, I'm going to set up a simple car + ground plane + sleep() and see if I can replicate it on all systems. The stuttering is in a straight line which should be and ideal case for them.

I simply turned on the flag, then swapped the car drawing code to use:

entity.BufferedStates.InterpolatedStates.WorldTransform

as it's world transform. I was passing dt to the update, and left fixed timesteps off.

Instead of interpolating into the future, I might see if I can set up the opposite, timestamping old data and trying to keep the car about ~1/30th behind where it's body really is, interpolating between the two relevant data sets. Given it's a car game it shouldn't be too noticable.

[Norbo]

Instead of interpolating into the future, I might see if I can set up the opposite, timestamping old data and trying to keep the car about ~1/30th behind where it's body really is, interpolating between the two relevant data sets. Given it's a car game it shouldn't be too noticable.

Extrapolation, which attempts to guess at a not-yet simulated state, is not used by the engine. Interpolation uses the last two known states to compute an intermediate state between those two last known states.

I simply turned on the flag, then swapped the car drawing code to use:

entity.BufferedStates.InterpolatedStates.WorldTransform

as it's world transform. I was passing dt to the update, and left fixed timesteps off.

Is the camera following the correct state? That is, are both the entity graphic and camera following entity.BufferedStates.InterpolatedStates.WorldTransform? If the camera is still using entity.WorldTransform, they'll be out of sync.

Other subtle camera related issues could be confounding the tests too. For example, in the BEPUphysicsDemos, the positioning of the Camera.Update before the Space.Update leads to jittering if internal time stepping and interpolation is used. To eliminate them all as possibilities, set up a camera at a fixed position and then drive the camera in front of it to check for stutters.

[RedToasty]

Extrapolation, which attempts to guess at a not-yet simulated state, is not used by the engine. Interpolation uses the last two known states to compute an intermediate state between those two last known states.

Ah thanks I did end up with very similar looking results to what happened with interpolation turned on. Yeah, I did ponder it might just be the camera, it's so heavily damped* it goes smooth regardless though. I'll get it to output positions which should make it a bit more obvious.

One thing I was considering trying was locking the internal TimeStepDuration to 1/30, and relying on the interpolation to smooth out the extra frames when the game is running at 60.

*actually, that said, I wonder if it's exactly that, pulling in and out as does more lerps per draw. I'll go sort that properly!

Thanks!

[RedToasty]

I shifted all the camera code to the cars Render, just before I draw and removed the linear interpolation on the translation, it's now just a fixed distance for the moment. It's all smooth! Big apologies for my "I know that's rubbish, but I'll fix it later" camera code being at fault. On the plus side it's dragged me around a lot of the code I've never seen before, and now I know what extrapolation means

It ended up with:

IsFixedTimestep = false;
Update(dt);

and Interpolation states turned on and being used. It's playable jumping between 10-15fps with 3000 character controllers wandering around, crazy.

Thanks for helping me sort it out!