BEPUphysics

Our game is having alot of performance problems on the xbox, and so we used performance tools to determine where the time was being spent, and nearly all of it is spent doing the line:
space.Update();
for the physics.

I was just wondering what things there were we can do to improve the speed of doing this. We are already going to be replacing the models that we create the ConvexHulls from to make that faster.
Is there any settings or anything we can set for the space that will speed it up?

Also, I want to cache the ConvexHull when I first create it and then create the other ConvexHulls from this one. I know that I need:
ConvexHull.CollisionInformation.Shape, ConvexHull.Mass, ConvexHull.LocalInertiaTensor, and ConvexHull.Volume.
However, I do not know how to create a ConvexHull using these values. How would I do this?

Is there any settings or anything we can set for the space that will speed it up?

Yes; check out the BEPUphysicsDemos ConfigurationHelper. There's a variety of quality-performance tradeoffs you can make.

Is multithreading being used optimally? Is the work distributed well? Is there any 'empty space' in core usage over time that could be used by a better threading model?

Make sure all the stuff in the physics simulation is using the simplest reasonable representation. Simplified geometry to generate convex hulls is good. If you have a convex hull that's almost a box, go ahead and make it a box shape instead. Use a simplified collision mesh for the environment if the regular mesh is too complex.

Other than that, there are a variety of simulation-specific optimizations that are possible. However, I'd need to know more details of the simulation to provide them.

Also, I want to cache the ConvexHull when I first create it and then create the other ConvexHulls from this one. I know that I need:
ConvexHull.CollisionInformation.Shape, ConvexHull.Mass, ConvexHull.LocalInertiaTensor, and ConvexHull.Volume.
However, I do not know how to create a ConvexHull using these values. How would I do this?

ConvexHull is a prefab entity type which is designed for convenience and legacy support, so it doesn't support that level of specialization. However, it is possible to create an Entity directly without prefab entity types. It has constructors for taking the extra data. Check out the BEPUphysicsDemos EntityConstructionDemo for examples of constructing entities.

How do you setup multi-threading of the physics engine? I am trying to get some speed improvements, and though that might do the job.

I tried: but XNA gives error saying that System.Threading.Thread does not contain a definition for SetProcessorAffinity...

That works on the Xbox360. Windows uses a thread scheduler to automatically assign workloads to cores, so you just need to call Space.ThreadManager.AddThread() the appropriate number of times.

The "appropriate number of times" varies, but in the simplest case where BEPUphysics is being called and nothing else is going on asynchronously, you can safely give it Environment.ProcessorCount threads. On some platforms, you may find that using only the number of physical cores (as opposed to logical cores) is more efficient, though I don't have any numbers for hyperthreaded PCs to suggest one way or the other right now.

If heavy asynchronous tasks are running all the time, you may need to avoid adding the busy cores to BEPUphysics. It will tax the load balancer and introduce overhead most likely. As always, test and measure

We are now having performance problems on xbox and on some PCs trying to run the game as well.

I think the physics might be to blame, we have around 25 static objects, 1 dynamic player object and around 25ish dynamic enemy objects at once. If we take nearly all of it out the game runs smoothly at 55ish FPS, however, with all of it in, it drops to around 12-20FPS.

What can be done to try and speed this up? I thought about combining the StaticMeshes, however, I do RayCasts from the enemies to detect obstacles so that they can move around them. If all the static objects are one StaticMesh, won't the RayCast simply ever return the one StaticMesh, in which case, meaning I can't detect the closest obstacle so I can avoid it?

Is there any other improvements I could make? I have tried multithreading the Physics space, but it didn't even change the FPS count at all.

I thought about combining the StaticMeshes, however, I do RayCasts from the enemies to detect obstacles so that they can move around them. If all the static objects are one StaticMesh, won't the RayCast simply ever return the one StaticMesh, in which case, meaning I can't detect the closest obstacle so I can avoid it?

I would not expect significant cost due to only 25 static meshes, and so this probably isn't the source of the problem. However, obstacle avoidance is possible and commonly done without detecting atomic 'objects,' but rather using a series of queries to detect the immediate surroundings. For example, the hit location/hit normal/T parameter from a ray cast would be sufficient to steer away from an obstacle given good query patterns and steering behaviors.

Is there any other improvements I could make? I have tried multithreading the Physics space, but it didn't even change the FPS count at all.

Multithreading tends not to help much when the simulation is very tiny. That's because very tiny simulations are very cheap, and the tiny overhead of multithreading eats away any gains. A simulation only ~25 dynamic objects definitely fits in the 'tiny' simulation category, especially on the PC (my old PC can handle several hundreds of characters climbing around and on top of each other on a static mesh smoothly).

Another thing multithreading cannot automatically help is external queries. If the majority of the cost isn't within the simulation itself, multithreading won't do much.

I would recommend doing some profiling to narrow down exactly where the cost is.

Ah ok thanks, I will do. It just seems with the objects in the world it is slow, but without them it is fast, so I just made assumptions. Will look into it more with profiling.

On the Xbox our game runs at about 2FPS.
It has around 40ish objects in the Space at any one time.

Multithreading didn't provide any speed up at all.

I have tried finding a profiling tool to determine where in physics engine all the time is going. However, finding a tool that works with our approach has been difficult, the best I could find just let you time sections of code, however, due to BEPU being in a dll means I can't time sections of the physics engine. All I know is that all the time in our game that is slowing the game down is spent running the line:
All the objects are made in the same way as the Entity Construction demo. The ConvexHull data is cached and so the ConvexHulls are only created once for each type of object. InstancedMeshes are also used for the Static objects.
The models the objects are made from are all simple primitive models, like cylinders and boxes made in maya and exported as FBX files, which are put into XNA and then are used to create the ConvexHulls and InstancedMeshes.

It runs at about 30-63FPS depending on how powerful a computer we run it on. However, it is the drawing that slows the PC versions down. However, on the xbox it is definitely the space.update() method that is slowing it down.


*EDIT - ADDED*

I was wondering, the problem seems to get worse the more objects that are added to the game, as in with about 5-10 objects the game runs on xbox at a perfect 63FPS. However, the more that are added it gets exponentially worse.
Does the collision handling system do any kind of region detection to speed it up, or does it just compare every pair of objects to test for collisions? The wikipedia article mentions things like Octrees or BSP to speed up collision detection. Does BEPU do this kind of stuff, as in do I have to tell it to use it or whatever?
I just cannot see why it is so slow, as you say that BEPU can handle much much large simulations than this game.

I have tried finding a profiling tool to determine where in physics engine all the time is going. However, finding a tool that works with our approach has been difficult, the best I could find just let you time sections of code, however, due to BEPU being in a dll means I can't time sections of the physics engine. All I know is that all the time in our game that is slowing the game down is spent running the line:

Some profilers, like ANTS, will let you pick the source code or debug data to reference. An alternative would be to include the BEPUphysics project in your solution so that you can debug/profile it normally.

It runs at about 30-63FPS depending on how powerful a computer we run it on. However, it is the drawing that slows the PC versions down. However, on the xbox it is definitely the space.update() method that is slowing it down.

To isolate the problem more, you could try replicating parts of the geometry and simulation in the BEPUphysicsDemos. If you can reproduce the issue there such that I can run/debug it, I would probably be able to point out the issue.

Does the collision handling system do any kind of region detection to speed it up, or does it just compare every pair of objects to test for collisions? The wikipedia article mentions things like Octrees or BSP to speed up collision detection. Does BEPU do this kind of stuff, as in do I have to tell it to use it or whatever?

BEPUphysics has a fast broad phase acceleration structure, and it is used automatically. Otherwise, most nontrivial simulations would be fairly impossible

Ah ok thanks very much.

Would there be any tests you think we could run on the game to try and pinpoint the issue? As the game has grown to quite a size and so producing a demo version of it would be quite hard.

Would there be any tests you think we could run on the game to try and pinpoint the issue?

Use a profiler capable of referencing the source code or put the source code in your solution so it can be profiled. If the time is within Space.Update this will let you narrow it down more.

Another option would be to cut pieces of the simulation out until the problem goes away. This is basically a much slower, manual version of profiling.

As the game has grown to quite a size and so producing a demo version of it would be quite hard.

The whole game need not be reproduced; if you can test individual pieces of content and similar situations, it will at least narrow down the problem space (if not reproduce the problem directly).

I don't know if this is relevant, but it may help.

I use the character controller. In my static mesh level I have a fence, a farm style fence.



Whenever the character went near the fence the frame rate would drop from 60fps down to 2fps. I think the character was trying to step up onto the bottom part of the fence but then being blocked from passing through. I fixed this problem by adjusting the character step up height.

So if you have anything similar in your level, that may be the problem. If not please ignore me.

A massive drop in performance upon a step-up being blocked is not expected unless the geometry blocking the step-up is extremely complex (multiple hundreds of triangles, for example). There is some cost, but it should not be 30x.

I have heard that a way to improve performance would be to put the physics running on one of the cores or threads. And then not run anything else on that core or thread.
I was just wondering how you do this for BEPU?

The Updating Asynchronously documentation goes into that and has an associated demo.

Using asynchronous updating complicates the usage patterns, though. All accesses from other threads must be buffered in some way, so you lose easy direct reading and fiddling. If you can use a simpler approach, I would recommend doing so.

The simplest approach that still makes use of multiple threads is internal multithreading. With internal multithreading, you can use the engine mostly without caring about the fact that it uses multiple threads inside. There are still a few things to watch out for, though- doing invalid operations from within immediate context collision events, for example. Picking the right number of threads for your project is important to good performance with internal multithreading. On the Xbox360, using 3 threads (one assigned to each of the physical cores) is usually the sweet spot as long as the cores are fully available for the duration of the space update. It would be bad to have other asynchronous tasks running on the same core as a space update since that would stress the load balancer unnecessarily.

You can also combine asynchronous updating with internal multithreading.

A less common intermediate option is to have a separate physics thread, but run it in lock step with the game update rather than allowing it to free run. This allows you to have controlled synchronization points where you can read or write data to the physics simulation without worries about it running a space update in the middle of it.

The best option just depends on the required jobs and on how much juice you can squeeze out of the CPU. The less wasted core-time, the better. Creating a diagram showing the computational durations of the work on all the cores would help inform the design of a good system.