BEPUphysics

Hi,

I'm at ease with most game development aspects such as rendering, networking and the like but it's the first time I'm considering using a 3d physics engine for a game. Therefore, I apologize if I'm asking some noob questions but after searching through the documentation and the forums I didn't get a clear answer to my questions.

So to make it simple, here is my current situation:

I'm developping a space game mixing some strategy with arcade 3d space combat. I really mean it: the game is designed to be Arcade therefore I thought 3d physics would be no use for such a game.

However, I need some heavy collision checks for my space ships, asteroids, space stations and of course "bullets".

I made a small prototype that is using my own collision system that first makes collision tests against BoundingSphere, the BoundingBox and finally I do some per triangle collision using the Xna Triangle Picking sample.

Stress testing the application, I realize that my bullets (I can have hundreds in a scene) are putting my CPU down. And then here I am inquiring for the use of a 3d physics system to handle my Collision tests.

So, my questions would be:
A. Is a 3d physics library such as BEPUPhysics a good choice for Collision tests or would I have a better result making optimisations on my own code specific to my game as BEPUPhysics will necessarly be designed for multiple usages?
B. Can I use BEPUPhysics without using other features than Collision testing making sure the world transforms are set for each entities as my game is targeting an Arcade style movement?

Thanks for your greatly appreciated help

Philippe

A. Is a 3d physics library such as BEPUPhysics a good choice for Collision tests or would I have a better result making optimisations on my own code specific to my game as BEPUPhysics will necessarly be designed for multiple usages?

It is true that the more assumptions you can make, the more you can optimize something. That said, BEPUphysics could very well be fast enough despite its greater generality. The best way to find out is to try and see. If you encounter some performance problems, I can help you tune it or work around it.

B. Can I use BEPUPhysics without using other features than Collision testing making sure the world transforms are set for each entities as my game is targeting an Arcade style movement?

Yes, I know of at least one game which has used BEPUphysics as a collision/events system.

Basically, instead of using dynamic entities, you will likely use kinematic entities which do not react to collisions or other interactions. They can be thought of as having infinite inertia- their velocity will not change unless you directly change it. Setting their world transform will work as well if you have no need for the velocity, though be careful if you're looking to use continuous collision detection. CCD uses velocity to determine the time of impact.

To get kinematic entities to generate collision events when they hit other shapes, you can use the collision rules system (http://www.bepu-games.com/BEPUphysics/d ... tation.pdf). By default, kinematic entities' collision rules will avoid creating pairs with other kinematic entities. This can be configured however you see fit.

v0.13.0 is slated to include a bunch of changes that will ease the process (http://www.bepu-games.com/forums/viewto ... ?f=5&t=849), though it is going to take a few months to complete. It may also be split into multiple versions in an effort to get parts out faster.

Thanks Norbo for these clarifications. I'll give it a try then but still have some initial design questions before going on

As I told you, I'm a noob at using 3d physics in game but here would be my current design choices on how to use BEPUPhysics...

First, I'd create for each Model in my scene a Box entity attached to some sort of GameEntity class that would take care of handling the Physics and Rendering stuff.
I would also add an additional TriangleMesh or StaticTriangleGroup to this class to handle per triangle collision.

I would then use the Box entity to check for initial collisions and if box collision happens, I'll then request for a per triangle collision.

I assume I would then have to Update the Box and StaticTriangleGroup worldtransform properties manually each frame based on my own behavior code and somehow either activate/deactivate the StaticTriangleGroup collision detection.

A. Do you think that makes sense?
B. If so, could you please give me some more details or refer me somewhere to understand better the differences between Entity and Updateable?
C. Would it be threadsafe to update worldtransform properties in my game while using BEPUPhysics Multithreading system?

Thanks

Philippe

A. Do you think that makes sense?

BEPUphysics includes a broad phase collision detection step that creates collision pairs based on each object's current axis aligned bounding box. Testing for Box (OBB) collision prior to testing a deeper collision will likely not provide much of a speed bonus, and it may actually slow it down due to its redundancy with the AABB test.

I wouldn't recommend using a StaticTriangleGroup for a moving object or for many separate objects. It is optimized for large unmoving meshes that make up an environment.

If triangle-wise tests are absolutely required, you can use a CompoundBody entity that has a bunch of Triangle entity children. The CompoundBody class basically lets you create concave shapes from other shapes and is designed for moving objects. It also has a built-in acceleration structure to speed up collision queries. That said, the less entities that it has to use, the faster it will be. If you can make your collision triangle meshes relatively simple, this could be enough.

There's also the option of separating each model into multiple pieces which each can be wrapped in a ConvexHull. You can then add these relatively few ConvexHulls to a CompoundBody and it should be substantially faster than dealing with 50x more triangles. The process of breaking up a model into different pieces is known as convex decomposition. There's algorithms for it, though there is no tool for it in BEPUphysics yet. I'd recommend setting up a simplified collision mesh and separating it into convex pieces at content creation time.

The third option is to approximate the shape using simple primitives like Boxes, Spheres, Cylinders and so on. These would again be bundled in a CompoundBody. If your ship is well suited to this approach, it may be the simplest and fastest way to do it.

B. If so, could you please give me some more details or refer me somewhere to understand better the differences between Entity and Updateable?

An Updateable is simply a class which has a series of "update" methods that a Space will call at specific times during the Space.update method. The Entity is a physical object that can be interacted with in the simulation. The StaticTriangleGroup manages Triangles, which are Entities. The things other stuff is colliding against are those Triangle entities, not the Updateable class.

C. Would it be threadsafe to update worldtransform properties in my game while using BEPUPhysics Multithreading system?

Yes, though it's important to beware the difference between internal multithreading and asynchronous updating.

Asynchronous update:
http://www.bepu-games.com/BEPUphysics/d ... tation.pdf
Internal multithreading:
http://www.bepu-games.com/BEPUphysics/d ... tation.pdf

When you're updating BEPUphysics asynchronously and you need to read or write the worldTransform from another thread, it automatically goes through a read/write buffer. These buffers prevent your access from reading half of a value or setting a value during some important calculation in the engine. If you use the internalWorldTransform property on the other hand, it will not buffer anything and you will be free to corrupt any data you want

If possible, I generally recommend that you avoid using an asynchronous update. It's a lot easier to avoid bugs when everything runs in a sequential flow. If you enable internal multithreading and not asynchronous updating, it does not change the flow of your program, which lets you act like everything is sequential from your point of view (for the most part). You wouldn't have to worry about using buffered properties; using internalWorldTransform would be perfectly safe.

The buffered properties can be tricky sometimes due to the lack of an immediate effect on setting the value. You can see an example in this thread: http://www.bepu-games.com/forums/viewto ... ?f=4&t=876. As long as you don't assume that a write will immediately change the read value, you will be okay.

Hi Norbo and thanks again for these clarifications. They are really useful and if I may give you a small advice, you should spend some time combining such content in a small web page in your main site in a FAQ for instance

Back to topic:

If I understand you correctly, you're actually telling me that I shouldn't go for TriangleMesh usage for dynamic shapes rather use Entity derived shapes to build a collision "mesh" that will be as close as possible to the real triangle based model?

I actually tried to implement my own GameEntity class which handles 3 classes:
1. SunBurn SceneObject used for Rendering purposes (nothing really important here)
2. A Dynamic and AlwaysActive Box entity instance that I create using the Model's BoundingBox which updates my SceneObject World Matrix each frame for rendering purposes.
3. And finally, a deactivated ConvexHull instance built with the vertices of my Model (using TriangleMesh static method to retrieve the Mesh's Vertices) that I was thinking to activate when the Box entity would raise a Colliding event to make some more precise collision tests.

The idea behind it is obviously for my Bullet system. When a ship fires a bullet towards another one, I want to first make collision test against the Box entity and if a collision occurs, and until the ContactPair is valid, I would test against the ConvexHull to then know exactly where it hit the ship.
This will allow me to render some sparks where the bullet hit and also manage my ship structure damages as hitting the engine will be different from hitting a turret or even the cockpit

If I'm going the wrong way (which seems to be the case as far as I understood your reply), could you please give me some advices on how I should do?
And finally, I'm not sure to understand right your first paragraph, the broadphase that performs a first test against OBB Boxes can be intercepted before it goes deeper in the Entity collision tests?

Philippe

Hi Norbo and thanks again for these clarifications. They are really useful and if I may give you a small advice, you should spend some time combining such content in a small web page in your main site in a FAQ for instance

I'll probably be adding more types of documentation after the website gets a ground-up revamp

And finally, I'm not sure to understand right your first paragraph, the broadphase that performs a first test against OBB Boxes can be intercepted before it goes deeper in the Entity collision tests?

The broadphase is just a system to find entities with overlapping AABB's. If two entities do not have overlapping AABB's, the narrow phase detailed collision test will not be run. So, the broadphase will determine which entities overlap with the ship-wrapping Box entity's AABB. Only entities with AABB's that overlap the Box's AABB will be tested against the Box itself. The Box collision test will generally be superfluous and may slow things down- though there are other reasons to have the Box entity (like how it is used in option 1 below).

Here's the main approaches I'd consider:

1) When some entity that wraps the ship has a CollisionPair with a bullet (doesn't need to do an actual narrow phase test against the box, chances are if it overlaps the AABB it's good enough), test that bullet against a more detailed representation which is only updated when collisions occur.
Advantages:
-Can support triangle-wise collision by querying a TriangleMesh object as the detailed representation. Would need to manually call some of the Toolbox's collision tests to see if Triangles from the TriangleMesh collide with the bullet.
-Avoids continually updating a large number of entities or refitting shapes except when collisions actually occur. Could avoid doing any refits by instead transforming incoming bullets to the local space of the collision mesh for testing purposes.
Disadvantages:
-Does not support continuous collision detection.
-Requires doing a good bit of manual work.
-Figuring out which part of the ship was hit can be tricky.

2) Have a CompoundBody composed of multiple ConvexHulls. Each ConvexHull wraps a reasonable part of your ship's mesh (or a simpler collision mesh). Note that this isn't a single ConvexHull, since a single ConvexHull removes any concavity from the mesh. This CompoundBody provides you the world transform for rendering as well.
Advantages:
-The multiple convex hulls allow you to attach individual collision events. Instead of intercepting a collision and then figuring out where it was, you could hook an event on the "engines" or "cockpit" shape directly.
-With a reasonable number of ConvexHulls, will be fast.
-Doesn't require manually calling collision tests; the broadphase and CompoundBody's own acceleration structure will take care of only doing narrow-phase tests on the right parts of the ship.
Disadvantages:
-The transforms of all sub-entities in the CompoundBody are necessarily being changed each frame. This is more expensive than working on a single entity, but if you stick to a reasonable number of hulls, it won't be an issue. Moving 10 sub-entities around won't be a problem.

3) Similarly to #2, have a CompoundBody composed of multiple primitives like Box, Sphere, Cylinder, etc. This has most of the same advantages/disadvantages as #2, but could be nicer depending on your preference. Some primitive tests like sphere-sphere collision detection also have faster narrow-phase tests, though this won't play a big role in overall performance since most of your collisions are extremely brief impacts.

Personally, I lean more towards option 2 or 3 than 1 mainly because of the ease of implementation and management.

Thanks again Norbo, I think I'll go for the second option or the third depending on my advancements

I've made some early tests and I get some good collisions between ships. I'll now enter into Bullet collision checks.

I wondered now what properties I should set to my Bullet entities (probably using a small Box) so that the ships do not get additional forces to their motionstate as I just want to check collisions not apply them

Philippe

You could change the bullet's personal collision rule to "noResponse": Collisions between the bullet and other shapes will still be tested and generate contacts (which are in turn used to generate collision events), but the solver will ignore the contacts and no forces will be applied.

The above assumes your ship is dynamic. Kinematic entities (which are constructed without a mass parameter or later converted by using entity.becomeKinematic) have infinite inertia and won't change velocity unless you force it directly.

If the ship is kinematic, be careful about its default collision group. Kinematics don't usually need to generate CollisionPairs with other kinematics since they can't influence each other's motion, and so their collisionRules.CollisionGroup is set to something that ignores other kinematics. If you instead set the collision group to a new group (which by default collides with everything) or the default dynamic collision group (which by default collides with everything) it will work: