Handling dynamics for bowling pins

[nickgravelyn]

I'm currently working on a little bowling demo to learn BEPU and am having some issues with the pins. I can't figure out exactly how to handle them:

1) Try to figure out a set of primitives that covers most of the necessary surface area. I figure that it could be done with a cylinder and about 8 or 9 spheres.
2) Use a convex hull designed in a 3D tool realizing we'll lose accuracy around the "neck" of the pin.

I'm currently attempting the second option because it seems easier to test given that I can model the hull visually to match the pin's model. I'm currently running into the issue of inertia.

Right now my pins seem to immediately fall over and start rolling and shaking, almost as if they had a driving force. I'm fairly certain this is due to a lack of me setting a custom inertia tensor on the entities. However I'm not entirely sure how to calculate even a rough approximation of the proper value. Anyone have any tips for figuring that out? It doesn't have to be perfect but right now I can't even get my pins to stand up properly so anything is better than nothing.

[Norbo]

The default computed inertia tensor should work for the convex hulls (which are indeed the way I'd approach a bowling pin). You could also do a CompoundBody of two ConvexHulls if you'd like to preserve the concavity.

Shaking and general collision detection inaccuracy can sometimes be caused by scale problems. The collision detection system is tuned for a certain range (around .5 to 10 units, though this is not a hard limit and it can generally handle quite a bit more). Pins in the range of 1 unit high should be fine. I suspect the issue may instead be the ground entity. If you have a very large box or triangle acting as the ground (acting like a plane), you will most likely start to see bad behavior. Shrinking this down may alleviate the problem.

[Norbo]

Also, if you'd like to test out a different inertia tensor, you could try setting the entity's localSpaceInertiaTensor to:

[ X 0 0 0 ]
[ 0 Y 0 0 ]
[ 0 0 Z 0 ]
[ 0 0 0 1 ]

Plugging in values for X Y and Z will give you behavior like that of symmetric objects. For example, a cube might have a tensor of X = 10, Y = 10, Z = 10.

[nickgravelyn]

I had no idea an inertia tensor was generated for me. That's pretty nice.

I am using a big box as my plane. Currently my lane is 21 units x 400 units (and I give the collision box a depth of 10 units). Could that scale be the issue? How would you suggest resolving this? Should I shrink my physics simulation down to a smaller size and then simply apply a scale when I go to render my scene?

[nickgravelyn]

Well I solved part of the problem. Turns out somehow my visual model was 1 unit higher on the Y axis than my collision mesh. Not sure how since I modeled both on top of each other in Maya so they shouldn't have needed to be changed. However I applied a matrix for rendering to fix that shift and they definitely look a lot better. I still get a little jitter every once in a while when they're rolling and I assume that will be part of the lane issue you mentioned.

Would be better to model a tessellated plane and use that as a triangle mesh object? Would that yield better results?

[Norbo]

That scale is probably sufficient to see the problems. If you were to scale that down by a factor of 10, chances are it will work without jitters.

Another option is to use a static triangle group (Demo #28 in the demos project) as you mentioned. You could choose an arbitrary number of triangles to represent collision mesh of the alley, each triangle being within the recommended size. You could probably get by with less triangles if you keep to a smaller scale as well.

Some other details about the collision system: It likes 'fat' objects. This means really long or thin objects have a higher chance of producing scale issues than a more 'cubelike' shape. Thin, near-degenerate triangles should be avoided when modeling a collision mesh.

I've got an annotated powerpoint that accompanied a lecture I gave at a local university game development class which covers this and some other general tips. There's also a demo game associated with it. I'm aiming to get it uploaded as documentation in the next few weeks (a few tweaks here and there need to be made still).

[Norbo]

And as a note for the future, if you find yourself wanting ever so slightly more 'realistic' rotational behavior, you can try enabling the conservation of angular momentum and RK4 angular integration:

Code: Select all

                    space.simulationSettings.motionUpdate.conserveAngularMomentum = true;
                    space.simulationSettings.motionUpdate.useRK4AngularIntegration = true;

It's disabled by default since it's a bit more expensive and leaving it off is usually fine for game physics, but you could try it out to see if you like it more.

You could also fiddle with the inertia tensor padding that the system uses when computing inertia tensors (found in the static SimulationSettings.MotionUpdateSettings). With RK4 and conservation enabled, you may find that other settings look better.

[nickgravelyn]

I tried modeling a plane that was subdivided a bunch but that didn't seem to help (and made the ball bounce as it rolled down the lane).

I also tried making everything smaller and that seemed to make a bit of difference, but the pins still acted like they were responding to collisions right off the bat and fell over. My code that generates the hull moves them up such that their lowest point is right on the plane so they should just sit there fine.

My collision shapes also still seem offset which makes no sense. If I load in the model and my collision model, they're definitely both sitting on top of each other. But when I take the collision model and make a convex hull, it doesn't seem to line up with the visual shape anymore.

Has anyone or could anyone whip up a little bowling sample? I can't for the life of me seem to get anything solid working. I'm probably going to start a clean project to try later which should make it easier for me to add some debug graphics but if anyone has done something like this, I'd love to see a little sample to help me out.

[Norbo]

I'll try to set up a little demo game later today.

pins still acted like they were responding to collisions right off the bat and fell over. My code that generates the hull moves them up such that their lowest point is right on the plane so they should just sit there fine.

There's two things that are likely contributing to this.
1: Objects have 'collision margins.' A fairly detailed description of what they are and why they are there can be found here: http://www.bepu-games.com/forums/viewto ... ?f=4&t=409
If the entity is perfectly touching the plane, it will be pushed somewhat upward to get out of the margin. This alone likely wouldn't cause the pins to fall over, the pins would usually just smoothly move around .07 units upward. However...
2: Convex hulls, and other shapes, compute their center position as the center of their volume (which happens to also be their center of mass, unless you offset the center of mass). When the entity is moved, it's teleporting the entity to be centered on that new position. To know where to accurately put the center position relative to the ground, you need to know the distance from the center position to the bottom of the shape. The easiest way to do this is probably to compare the expected 'center' position of your model to the center position of the hull after you create it.

[Norbo]

I attached a little bowling demo based on the BasicSetupDemo (http://www.bepu-games.com/BEPUphysics/documentation.htm). Left click to shoot a mess of bowling balls. By default, the ground is a big box. You can comment out the box and uncomment the StaticTriangleGroup part to test it.

There will be a little bouncing behavior for balls going across triangle boundaries with a StaticTriangleGroup, but it is fairly small in the demo. It's caused primarily by the contact location being slightly different when it transfers to the next triangle due to a few aspects of the sphere-triangle collision system.

It's possible in theory to completely eliminate this behavior by looking at the contact data between the bowling ball and the triangles and making sure that it meets some requirements (like the contact locations being flat on the surface). This is a bit more difficult to manage, but if you'd like to mess around with it, you can register an event handler that is called every time an entity's collision pair updates while colliding:

Code: Select all

entity.eventManager.addEventHook(new BEPUphysics.Events.EventHandlerCollisionPairCollidingImmediate(...));

The CollisionPair that is passed into the handler manages the interaction between two entities (like a StaticTriangleGroup's Triangle and a bowling ball). It has a list of contacts in it that you can access and change the properties of as you see fit.

Cautionary note: that event is called during the middle of execution, so be careful what is accessed from it (particularly if you have enabled multithreading). The events which do not have the "Immediate" extension are deferred until the end of the frame and evaluated in sequence, which makes them 'safer,' but they can't as directly impact the execution of the engine.

[nickgravelyn]

Wow, that's great! I'll download that and give it a try later. Hopefully this does it for me.

[nickgravelyn]

Well the test works pretty well. I'll have to keep playing with it to get the right scale (a bowling alley lane is 1.05m x roughly 20m) but this is definitely a good starting place. I tried making the box 10x200 to approximate the scale but, as expected, this caused the pins to randomly fall over from the start. I'll have to experiment and see what I can get to work. Perhaps a physics simulation that is 1.05 units x 20 units will work and then I can just scale the graphics up to work well for rendering.