noob question: steady fps, slow physics (xna)

[re5et]

I only started playing around with XNA and bepu a couple of days ago, so please forgive me if my question sounds very simple.

What I'm trying to achieve is that when physics calculations start to take longer, I'd like time to "slow down" so that a high framerate can be maintained.
The setup I have consists of around 4000 boxes falling on a static (kinematic) ground box with relatively simple graphics (about 50 FPS without physics updates).

Now, I've read about the concept of fixed vs. variable timestep, but to be honest, I can't quite wrap my head around it and even though I've tried different settings and methods, I always get the same result: as soon as the boxes start colliding with each other, the framerate drops to about 12-13 FPS.

What I'm thinking is that maybe I need some kind of variable physics timestep duration which dynamically decreases so that there's less calculations performed per timestep, but maybe that's completely wrong?

Is this possible at all with bepu out-of-the-box or am I missing something?

[Norbo]

Setting the Space.TimeStepSettings.TimeStepDuration to a smaller value will cause a Space.Update() call to simulate less time since the parameterless method only runs one time step. Note that the Space.Update(dt) version of the method performs as many time steps as needed to catch up with the accumulated time which isn't helpful in this situation. (Using Space.Update(dt) with a simulation which is too expensive to simulate in real time leads to a death spiral capped by the Space.TimeStepSettings.MaximumTimeStepsPerFrame.)

Decreasing the time step duration will decrease the number of events that can occur within a time step, which does decrease the computation per time step some. The Solver's job is made a bit easier too by smaller time steps, but it will still be quite expensive with 4000 objects in a pile.

Be careful though: modifying the time step duration every frame is bad for stability. Try to limit how often it changes and how large the changes are. Of course, in a pile of 4000 objects, you may not care much about a little weird behavior here and there

To get 4000 objects in a big pile running at high speed, some extra tweaking is probably necessary. Check out the BEPUphysicsDemos ConfigurationHelper's ApplySuperSpeedySettings. They reduce the quality of the solver significantly, but will save some time. Try fiddling with the configuration helper's values to see what kinda of quality-speed balance can be achieved.

[re5et]

Thanks for the response!

So I guess my assumption was correct that a decreased timestep duration is the way to go for my situation.

My main concern is accuracy and not so much performance (hence the idea of "slowing down time"), so I'd rather not decrease solver quality.
Currently I'm adjusting the timestep duration before every Space.Update() according to the deltatime (higher deltatime = lower timestep duration) which is probably not a good idea, since that is also affected by other game logic not related to physics. Currently there's no other game logic and the 4000 boxes are just for testing/playing around, but at some point I'll have to refactor that - is there any way to measure the physics "load" so I can adjust the timestep duration according to that?

Also, can you give a rough estimate as to how many / how large the timestep duration changes should be at a maximum before noticable stability issues can occur? Is there anything else I could do to minimize that effect? Other than a minimum value of maybe 1/30 (well, perhaps a max of 1/300 or something) I don't really want to limit it too much, since performance is not an issue.

Finally, just to clarify: using a global variable timestep with the parameterless Space.Update() should cause the physics and graphics to be decoupled, am I correct? So, if there's a decrease in graphics framerate due to many collisions at once, it's probably because the GPU is affected by the high load on the CPU in terms of "hardware", not because the draw() method is still in some way affected by how long an update() takes? (I'm not an expert on computer stuff so that probably sounded a bit stupid, sorry for that )

[Norbo]

is there any way to measure the physics "load" so I can adjust the timestep duration according to that?

Using the Stopwatch to grab a timestamp immediately before and after the Space.Update will give a pretty accurate measure of time passed.

Also, can you give a rough estimate as to how many / how large the timestep duration changes should be at a maximum before noticable stability issues can occur? Is there anything else I could do to minimize that effect? Other than a minimum value of maybe 1/30 (well, perhaps a max of 1/300 or something) I don't really want to limit it too much, since performance is not an issue.

If the time step is changing every frame from 1/30 to 1/300 and everywhere in between, it will have a very hard time. Jumping from 1/60 to 1/120 and then a minute later going from 1/120 to 1/240 probably won't cause any noticeable problems. I can't really predict for a specific simulation just how bad it would be, but testing it is relatively easy

Finally, just to clarify: using a global variable timestep with the parameterless Space.Update() should cause the physics and graphics to be decoupled, am I correct? So, if there's a decrease in graphics framerate due to many collisions at once, it's probably because the GPU is affected by the high load on the CPU in terms of "hardware", not because the draw() method is still in some way affected by how long an update() takes? (I'm not an expert on computer stuff so that probably sounded a bit stupid, sorry for that )

Using a variable time step in XNA, if I recall correctly, will make the game perform one Update followed by one Draw followed by one Update followed by one Draw and so on. In that sense, a variable timestep combined with a parameterless Space.Update couples the physics update rate to the graphics rate. Generally, 'decoupled' means the physics is framerate independent or free running asynchronously. Framerate independence is accomplished by the Space.Update(dt) method, but if the simulation can't run in real time, it's not really useful.

If the framerate drops during significant collisions and no changes have been made to the graphics system (no particle effects, no new geometry, etc.), it is very likely the CPU bottlenecking the system. The Update and Draw method do not run in parallel, so unless there is some code which explicitly changes the Draw behavior based on the Update behavior, there will be no difference.


Here's a few other things:
-Using internal multithreading (giving the space.ThreadManager threads to work with), if not already used, will significantly improve the simulation performance on a platform with multiple hardware threads.
-Using asynchronous updates (which is distinct from, and can be used with, internal multithreading) can be used to ensure that the graphics can run at full blast while the physics chugs along in the background. Going asynchronous does not magically make the simulation smooth, though. If it cannot compute enough timesteps to look smooth graphically, a type of interpolation will be needed to fake it. Unfortunately, the type of interpolation built into the BEPUphysics interpolation buffers won't work for this- basically, predict the finishing time of the next time step and use it to pick an intermediate state between the current state and previous state of each object to draw. The rate of advancement won't always be equal and depends a lot on the algorithm chosen, but it could work.
-There may simply not exist a time step duration at which the simulation can execute one time step per real time game update. Before implementing any complicated logic to dynamically change it, try some really tiny durations to see if they actually do what is needed. If it doesn't work, focus on some other type of trick (like the interpolation above).

Incidentally, I'm working on some changes which may improve the performance and multithreaded scalability of lots of objects in chaotic collisions with a single large kinematic entity. I can't yet predict how much of an effect this will have, but keep on eye on the development branch over the next few days

[coimbra79]

hi man!
ive a similar problem too... mmm not very similar in reality...
im tryng to set up a game in lasts (as credits, tutorial, options etc..) hoping to produce in last wheek of july...
in these final action probabily did some error in code, and now appen that the fps (50~60 before) falled down at 30~45, at the first approach I thought was some aobout the graphic engine (the engine use normalMaps, Parallax, Hdr, Shadows), but then realized that in some shene where the subject entity collide whit some particolar objs the app have a further decline (until down to 5 FPS for 5 actives objs only!!)
Im working hardly to detect the problem cause this... but nothing at moment...
Can U suggest me some?
N.B.
I use
-FTS as 60 updates per second
-IterationLimita at 5
and in every shene change delete all entities an components (similar to demo), dispose the space and create a new...
tnk in advance

[Norbo]

My first suggestion is always to grab a profiler or to insert some timing code to see where the time is actually being spent. Measuring is always better than blind guessing

If the bottleneck is in the Space.Update() but the simulation is simple, look for:
-Invalid geometry,
-Propagating NaNs or infinities (compile the engine with v1.2.0 CHECKMATH symbol defined for a helper),
-Invalid configuration leading to too many time steps or long time steps,
-Space.Update(dt) being called with ElapsedMilliseconds rather than ElapsedSeconds or otherwise excessively large values,
-Extremely dense/complex geometry requiring thousands of tests,
-Bad threading configuration (Are other big asynchronous tasks stopping the engine from running? If it's on the Xbox, are the threads put on the proper cores? etc.)
-If the slowdown gets progressively worse over time, check for objects being kept around or perhaps garbage piling up and triggering more and more collections. The CLR profiler might be useful here.

Other than that, measure, measure, measure. If first attempts at measuring don't give any useful information, measure some more or start isolating components to measure them one by one. Attempting to replicate the problem in an isolated project- for example, in the BEPUphysicsDemos- is a great way to search for issues.

[coimbra79]

Well Norbo and thanks! ill do all u suggested (less all try i did allready )
-
sure the simulation is very simple
A ball is falling and player must build the right track to let the ball arrives to target.
to building track can spown some entities (like the red footboard in picture).
Player have a fixed number of spawnables objs for a maximum of 30.
wath an invalid geometry? The spawnables have simples geometries (std entities), the ambient where interact the ball is a staticmesh.
wath hell a NaNs?
wath the way for "compile the engine with v1.2.0 CHECKMATH symbol defined for a helper"

sorry for (as in subject) noob questions...

[Norbo]

wath an invalid geometry? The spawnables have simples geometries (std entities), the ambient where interact the ball is a staticmesh.

Examples of invalid geometry include:
-An infinitely large box,
-Mesh with lots of degenerate (zero area) triangles,
-Any shapes involving NaNs or infinities

wath hell a NaNs?

NaN values, or Not a Number values, are the result of some operations whose result cannot be represented by a regular number. For example, normalizing a zero-length vector will result in a vector whose components are all NaNs because it divides by zero.

NaNs and infinities have a nasty tendency to propagate through whatever systems they touch because any operation involving a NaN or infinity generally outputs another NaN or infinity. In the best case, things slow down a whole lot. Often, things will start disappearing and other wonky stuff happens. In the very common worst case, the program just crashes.

wath the way for "compile the engine with v1.2.0 CHECKMATH symbol defined for a helper"

Compiling the BEPUphysics library with a compilation symbol of CHECKMATH defined in the project properties will make the engine check the common access points and other areas for NaNs and infinities. This helps catch the bad values before they propagate too far, isolating the source.

However, given that NaNs and infinities more commonly just crash the application rather than slow it down, they are not the prime suspect at the beginning of a performance investigation. The first step is always to gather evidence (i.e. get a profiler or implement your own timing and measure, measure, measure ).

[coimbra79]

RESOLVED!
I measured, measured, measured!
my & my team new motto...
i put into xna.update() a 'return;' after each rows, starting by first, and at first, naturally, was all ok
measuring, measuring, measuring... i arrived to THE GUILTY BUG CODE... no one could ever imagine...
I control if Player is in Pause with a kind of:

if (Pause) {soudtrackVolume.X} else {soudtrackVolume.Y}

Naturally i know how remediate... only i dnt understead WHY?
tnk again!