Suitability of Bepu for tank game.

[preen]

I'm looking for a physics solution for a relaxed realism tank sim for XNA4, Windows. The demos look promising, but I'd like to ask you Norbo, or anyone else, if you think it's suitable for this application before I evaluate it in detail.

The physics are for armored vehicles (4-6 wheels, or tracks) driving around a heightmap terrain (with about 2.5 - 5m grid spacing) at 20-30 m/s. Up to 30 vehicles per level at good framerate on low end pc. Collision for vehicle is a box or hopefully convex hull. Also same for buildings, bridges etc, with activatable/deactivatable collision shapes for levels of damage. Wheel rims or turret will sometimes come off vehicle and be governed by new physics shape to roll or bounce around. Apply impulses to the shape for weapon recoil, and being struck by bullets, explosions. Need to measure the force of collisions (for example, driving your tank off a cliff) to apply damage to vehicles.

Dev video: http://www.youtube.com/fritzgryphon

I have tried with Jitter physics. It works ok, but the vehicle jitters too much, especially at < 50 framerate. Also, the vehicle slides slowly across the terrain, regardless of wheel friction (and increasing friction makes jittering worse). Stability of vehicle while parked, smoothness of suspension and consistency among different frame rates is my main need (You can shoot enemies from very far away, so the smallest amount of jitter will throw you off target). In your opinion, is Bepu suitable for this kind of application? Thanks for you time.

[Norbo]

Thanks for your interest in the engine! I've split up your questions into parts relating to different areas of the physics engine. In addition, responses sometimes differ between v0.14.3 and v0.15.0 due to the massive changes made.

The physics are for armored vehicles (4-6 wheels, or tracks)

The Vehicle class in BEPU is designed for wheeled vehicles, so the 4-6 wheeled vehicles will work quite well. Track-like behavior is somewhat more difficult to simulate using the Vehicle, but is still possible. An example of track-like motion using the Vehicle class can be found in the demos project; "TankInput.cs" in the Alternate Movement folder. It's not used anywhere in the demos by default, but you can switch out the regular VehicleInput for it to see how it works.

driving around a heightmap terrain (with about 2.5 - 5m grid spacing)

That size is right in the middle of the per-entity dimensions recommendation, so it should work very well. v0.15.0 improves the behavior and speed of both meshes and general collision detection, too.

at 20-30 m/s.

This should work fine. v0.14.3 has CCD if it is found to be necessary (it would most likely only be necessary if you are diving off tall cliffs or using it for projectiles), while the current beta 17 of v0.15.0 still does not have it available. It will be re-added to v0.15.0 over the next few weeks.

Up to 30 vehicles per level at good framerate on low end pc.

It depends on what a 'low end pc' is. My Q6600 @ 2.4ghz can do 400 4-wheeled vehicles on a box at around ~10-12 milliseconds simulation time. For a bunch of vehicles on a terrain/mesh, it would be a little more expensive. v0.15.0 is a lot faster when it comes to meshes than v0.14.3.

Collision for vehicle is a box or hopefully convex hull.

The vehicle shape can be any entity, including ConvexHull or CompoundBody.

Also same for buildings, bridges etc, with activatable/deactivatable collision shapes for levels of damage.

There may be a bit of a performance cost in v0.14.3 associated with creating a new mesh, since it needs to create a hierarchy. If you pre-create all the meshes and then simply add/remove the needed ones from the Space, it would probably be fine. v0.15.0 has InstancedMeshes too which allow one collision hierarchy to be shared amongst multiple affinely transformed instances.

The only other issue would be changing geometry such that the new 'destroyed' stuff would intersect with objects that the 'normal' mesh did not, producing new penetrations. This wouldn't crash or anything, but it might look a little weird while it resolves the pentration. It can be avoided by using well-designed destroyed mesh versions or simply not having objects subject to that danger.

Wheel rims or turret will sometimes come off vehicle and be governed by new physics shape to roll or bounce around.

Creating a new entity would be no issue. It would be a good idea to position it such that it doesn't intersect with the body of the vehicle or whatever it came from.

Apply impulses to the shape for weapon recoil, and being struck by bullets, explosions.

All doable (Entities have an ApplyImpulse method, amongst other things). Somewhat related; if you desire the tank turret to be physical, I'd recommend using a constraint to bind the turret and vehicle together. Collisions will work better this way than teleporting the turret to follow the tank body, and impacts on the turret would affect the tank body. If the turret doesn't really interact with anything, it could just be a purely graphical effect with a bump built into the chassis to simulate the turret body.

Need to measure the force of collisions (for example, driving your tank off a cliff) to apply damage to vehicles.

Every entity has a list of collision pairs on it. These collision pairs contain contacts and their associated constraint data, like total impulse applied at a contact.

v0.15.0 has a conceptually similar setup, although there are more abstractions that have to be worked through since the collision system now deals with more than just entities. In beta 17, it's somewhat difficult to extract the constraint data without determining the type of a collision pair. Future beta versions aim to increase the usability of this and other parts of the collision detection pipeline.

but the vehicle jitters too much, especially at < 50 framerate

The physics engine likes a fixed timestep. The time that passes in a single timestep is defined in the Space.SimulationSettings.TimeStep settings. By default it is set to 1/60f, which is a pretty good standard rate. Since games can't always keep a steady 60hz update rate, the engine also offers internal timestepping (another setting that can be enabled in the TimeStep settings). The time you pass into the Space.Update method is the amount of time you want the simulation to progress by using the necessary number of simulation steps. Sometimes, a frame may go by where the physics doesn't need to update. In others, it may need to update two or more times. The remainder in each frame is used in interpolated the entity's buffered states for graphics.

The same concept exists in v0.15.0, but some things have been moved around. It no longer requires turning on internal time stepping; calling Space.Update with a time automatically uses internal timestepping. Calling Space.Update without a time will simply move the simulation forward by a single timestep. The Space.TimeStepSettings replace the old settings system.

v0.15.0 also moves the buffered properties into a safer area on the Entities. Before, using the buffered/interpolated properties (like CenterPosition as opposed to InternalCenterPosition)when they weren't necessarywas a common error. Now, Entity.Position is what InternalCenterPosition is in v0.14.3; direct get/set access to the position of the entity. The buffered states are tucked away into a BufferedStates property.

In both v0.14.3 and v0.15.0, you can get a snapshot of all the entity states by using the buffered states manager in the Space. This is helpful if the engine is running asynchronously, or if it just fits better with your design.

Also, the vehicle slides slowly across the terrain, regardless of wheel friction (and increasing friction makes jittering worse). Stability of vehicle while parked, smoothness of suspension and consistency among different frame rates is my main need

The vehicle's motion control is implemented using the solver. This provides very stable behavior, even when things get close to rigid. Using the solver in this manner is a little more expensive than the direct, unsolved approach, but you can trade accuracy for speed by decreasing the individual wheel constraint iteration limits. In the VehicleInput:

Code: Select all

                wheel.Suspension.SolverSettings.MaximumIterations = 1;
                wheel.Brake.SolverSettings.MaximumIterations = 1;
                wheel.SlidingFriction.SolverSettings.MaximumIterations = 1;
                wheel.DrivingMotor.SolverSettings.MaximumIterations = 1;

While the rest of the solver may run 10 iterations by default, the vehicle is acceptably stable at only a single iteration. Since the car warmstarts its current attempt at solving using the data calculated previously, it behaves very stably even with such a low number of iterations.


If you do choose to go with BEPU, you'll also need to choose between v0.14.3 (the latest stable release) and the betas of v0.15.0. I mentioned a few of the differences above, but there are more. Most pressingly, vehicles are not yet functioning in beta 17 They should be up and running in beta 18 tonight or tomorrow, though. Beyond that, v0.15.0 is still rapidly evolving and you will hit more than a couple of bugs. They should be fixed pretty rapidly thanks to the near-daily release schedule for betas, but you may still have to wait on me every once in a while.

If you choose to go with the v0.15.0 betas, I appreciate your patience and the extra testing

[preen]

Thanks for your reply. It's amazing the speed and consistency you've achieved, and the car and tank should do exactly what I need. I was dreading picking up a physics engine (it's my first 'real' game, so I wanted to keep it simple) but this should work well.

[preen]

The vehicle class works very well in my project. The car is stable and locked to the terrain. I use a compound shape for the body and turret.

I am having a difficulty with positioning a convex hull in relation to the visual model of the car.

The origin of the vehicle model is set at the ground, in the center of the vehicle. The convex hull mesh also has it's origin at the ground, and it's transform is zeroed out (all it's points have positions above the origin).
I use the vertices from the convex hull mesh to make a convex hull body in-program (132 vertices supplied, resulting in 22 points in the convex hull). All the points I supply are above the origin, with Y > 0. I use this body to make a Vehicle.

I figure that, because the convex hull and the model had the same origin, I should set the visual car model's WorldTransform to be the same as the Vehicle's convex hull body, and the two will overlap just like before.
But, when the convex hull was made, it moved it's origin to it's geometric center. Now when I look at the points in the convex hull, some are Y < 0. Which means the visible car and the convex hull no longer line up.

Then I figured, just center the convex hull's origin in the Model to it's geometric center, and use it's transformation as an offset for the visual model in the game. This kind of works, but the way XSI computed the center and the convex hull generator computes it are slightly different, and the two objects are still slightly out of sync.



So I'm wondering if there is a standard way of getting convex hulls and visible meshes to line up in-game. Or, is there a way to force the convex hull not to mess with the point coordinates you give it?

[Norbo]

Convex objects recenter themselves to their local origin for the sake of other systems, so that can't be stopped. However, when a ConvexHull is created from a pointset without specifying a replacement position, the CenterPosition of the entity will be the center of the hull.

If the hull is constructed from mesh-local points, that center can be used to offset the graphic to a matching location.

In v0.15.0, convex collision shapes still try to recenter themselves on their local origin. However, the applicable shape constructors output the center, so it's a bit easier to get the offset.

[preen]

Great, I look forward to that. Modeling applications seem to get the center by averaging out vertex positions (so it gets weighted towards more dense mesh). I guess the ConvexHull gets it from center of the volume.

[Norbo]

I guess the ConvexHull gets it from center of the volume.

That's correct.