2D Physics

[Falagard]

I'm curious if it'd be possible to use Bepu Physics for a 2D game. I realize that's not what it was intended for, but if I have intentions to move onto a fully 3D game later, and would prefer integrating only a single physics engine for both games.

For example, I'm thinking of zeroing out one of the coordinates each frame.

Thoughts?

[Norbo]

One way to do it is to set two rows of an entity's local space inverse inertia tensor to zeroes. This corresponds to two axes of the local space inertia. The effect will be that the object will be unable to rotate around those two axes. In a 2D game, you generally only want rotation to occur around the axis pointing in/out of the screen, so this works well.

You'd also need to keep your object on a certain plane. You might try a simple spring force that pushes all center of masses towards the plane; a custom Updateable type and its updateDuringForces method would work well for this. Another option is to create a solver-based updateable that corrects the velocity of the object during the velocity solver (as well as to correct any minor positional drift). It'll be a bit more robust, but is a significant chunk more difficult.

[Falagard]

Thanks for the response. I will look into your suggestions and probably post questions when I hit problems

[Falagard]

Also, as a request, it would be excellent to have a 2D physics example in with the rest of your examples. Not sure how much work is involved, but it may sway some people over to using Bepu Physics instead of one of the 2D physics engines that have been made for C# / XNA, especially since it's valuable to have a physics engine integrated with your code if it can be used for both 2D and 3D physics.

[Norbo]

I've thought about it in the past; I'll probably make a simple demo of it at some point when I have time.

[Falagard]

Awesome

[Eizon]

I used some time to figure out how to do this. It's kinda dirty way to do it, but it works in most cases. It will cause some hiccups on non-planar ground though. I selected BEPUphysics for my project because I archived the 2D in 3D physics.

Code: Select all

foreach (Entity entity in physics2DArray)
 {
    entity.moveTo(new Vector3(entity.centerPosition.X, entity.centerPosition.Y, 0));
    entity.orientationQuaternion = new Quaternion(new Vector3(0, 0, entity.orientationQuaternion.Z), entity.orientationQuaternion.W);
}

[JusTiCe8]

As a post-digger expert , this is a 2D demo I've made:





To use it, htere is just need to add this line:

Code: Select all

typeof (TwoDdemo),

to the

Code: Select all

demoTypes

array in DemoGame.cs .

It's not 100% perfect as boxes can move on Z a bit but I believe it's fair enough this way, also due to some randomness, sometimes structures fall on their own, at least you can enjoy watching them collapse.
I have used a PointOnPlaneJoint contraint to keep the ball Z component to 0, easier (and maybe cheaper) than an custom Updateable, then only not so good thing is the joint anchor is at origin, using a "ghost/shadow" ball (kinematic perhaps, stuck on Z=0) may or may not be better for bigger game world.

For other kind of 2D games like puzzle or platform game, it could be easier to keep a zero Z component, depending on how collisions occurred and are managed in the game.

(Feel free to do whatever you like with the code.)

IMPORTANT note: I've made a (not so) little mistake in my PointOnPlaneJoint setting, the right code is:

Code: Select all

PointOnPlaneJoint ballKeeper = new PointOnPlaneJoint(null, ball, new Vector3(1, 1, 0), Vector3.UnitZ, ball.Position);

as in documentation:

An infinite plane is attached to entity A and a point is attached to entity B. The constraint attempts to keep the point on the plane.

Order matters here ! In another code, I didn't paid as much care as I should have done and didn't understand why the constraint failed to do its job .