BEPUphysics

Hello Norbo (and everyone else)

It's been a while since I've had the opportunity to work with XNA and BEPU. I recently upgraded some projects to VS2010 and XNA 4, so I am slowly catching up. Anyway, as the title states, my goal is to create a Content Processor that works with Maya generated FBX files, and blends both the Custom Animation Pipeline / Runtime with BEPU Ragdoll physics. Any help is appreciated.

I'm using the Ragdoll demo that has 8 ragdolls (not sure if they are instanced though) as a test bed, and loading in a biped skinned character for testing purposes. Ideally, I'd like key words and values set in Maya to drive the construction of the ragdoll. The "bones", which are the geometric entities representing the bounding volumes of the mesh, are easy enough. The CollisionRules though could be problematic. For the joints I hope to use a one-to-one mapping of keywords and values for joint type (ballsocket, revolute, hinge, etc.) and limits. But it might be hard to do so in Maya with all the options, and an XML file might be better suited for this. Well, maybe initially anyway. Maya and MotionBuilder must have these same values and constraints too, I just don't know how to get them through the processor.

Any thoughts?

While I don't have much to offer when it comes to the details of implementation, here's a few things:
-Basing the ragdoll off of animation bones on a 1-to-1 basis may lead to excessive numbers of physics entities (consider the density of animation bones in a hand, versus what is necessary for physics).
-Creating a separate conceptual 'physics' rig with pieces which represent physics entities may be a good idea. One entity could own multiple animation bones (e.g. a hand). There are some difficulties to overcome in the transition phase since there's not a single correct way to handle individual bone transforms in a group that's owned by a single entity. One option would be to keep the old relative transformations.
-The physics rig could define the shapes of entities rather than relying on bounding volumes alone.
-Collision rules could be defined directly using whatever tool/script is used to create a physics rig. If going the procedural route, then assigning collision rules to constrained entity pairs would be a good start. You may also want to go through every entity and detect other entities that are intersecting with it in the initial configuration and assign appropriate collision rules.

Thank you for the thoughtful response Norbo.

We are using a separate rig for the physics engine, and as you noted below, it is simplified to meet the model's needs. I'm looking at exporting the skeletal information from Maya now using a script, and it appears that the Maya constraints should be accessible. Hopefully I'll have this done by today / tomorrow and can provide an update.

Well, I am now able to write the information I want from Maya using MEL. With that said though, I do have a couple of dumb questions - Norbo would you please expand on the below items, perhaps provide an example of what you mean?

-The physics rig could define the shapes of entities rather than relying on bounding volumes alone.

-Collision rules could be defined directly using whatever tool/script is used to create a physics rig

Thank you for your time.

First, when I refer to a physics rig, I'm referring to a collection of metadata which may or may not be associated with a traditional animation rig.

The physics rig could define the shapes of entities rather than relying on bounding volumes alone.

By this I mean there could be metadata that actually defines the shapes separately from animation bones. E.g. a sphere of X radius for the head, capsules for the arm components, a couple of boxes for the torso. These shapes wouldn't be actual meshes or animation bones, but information that tells the system how to set up the ragdoll shapes. Since there isn't necessarily a 1:1 relationship between animation bones and physical entities, additional metadata would be required to describe how entities control the animation bones (which bones belong to which entities).

-Collision rules could be defined directly using whatever tool/script is used to create a physics rig

The collision rules, like the shapes, could be included as additional metadata. The shapes could be given names and the rules would relate two names with some collision rule. The same would go for constraints. A tool could be created to ease the creation of all this metadata.

By this I mean there could be metadata that actually defines the shapes separately from animation bones. E.g. a sphere of X radius for the head, capsules for the arm components, a couple of boxes for the torso.

This is exactly what I've been setting up.

The collision rules, like the shapes, could be included as additional metadata. The shapes could be given names and the rules would relate two names with some collision rule. The same would go for constraints. A tool could be created to ease the creation of all this metadata.

What are the collision rules that I need to account for? What about when a part of the body interacts with many different parts?

What are the collision rules that I need to account for? What about when a part of the body interacts with many different parts?

The metadata would need to include an arbitrary number of collision rule relationships. The core idea of it is just two entities and a collision rule (most likely always NoBroadPhase) between them. A single entity can have collision rule relationships with any number of other entities. If the simulation shows undesired pairwise interactions, toss another collision rule pair in there to stop it.

Thanks Norbo. That makes sense.

I'm hoping to work on this later tonight, but if not then I'll work on it this Saturday. This has been a thorn in my side for some time. I'm really hoping to get realistic collision detection working again, with the ability to switch to ragdoll physics on demand. The most important aspect of this is to make it reproducible in a pipeline manner. And hopefully others can benefit from it too.

Norbo, would you be willing to take a look at a modified Ragdoll demo?

In Maya we created a three joint, two bone model. It's really quite simple but I don't understand what's going on with my setup. I read the Entity data from a text file, and the CollisionRules from another text file. Heck, I even have most transformations set to the identity trying to debug my problem. Actually, it's kind of wierd. The model in Maya is layed out along the X-axis, then the Y-axis but the capsules don't start that way. I have to add an initial transformation along the Z-axis to get the capsules to line up. A BallSocketJoint sort of works, while a SwivelHingeJoint crashes BEPU.

Can I email you this project?

Sure; norbo at bepu PleaseIgnoreThisBots entertainment . com would work, or the forum/private message if it fits.

I have two guesses to start with as well:
First, if the entities are transformed after the joints are created, the joints will fight to return to the initial relative configuration. Second, there was a bug in v0.15.2 in the SwivelHingeJoint and its handling of certain degenerate configurations. That bug should be resolved in the latest development version: http://bepuphysics.codeplex.com/SourceC ... evelopment

I sent it. Thanks.

Looks like I'm missing the ragdoll.txt and ragdollCollisionRules.txt. Do you have specific sample files that you'd like me to look at?

Edit: Ah, got the e-mail

At a glance, here's a few things I found:
-BallSocketJoint anchor location is not placed at a logical joint location, so everything turns out goofy.
-Limits with completely locked allowed ranges are not as robust as using a constraint designed to fully limit those degrees of freedom. (BallSocket twist and swing limits both have 0's for ranges)
-Limit bases don't match configuration (presumably due to testing attempts).
-Loaded individual orientations from text files are unused and zeroed out.

Another danger zone is related to the issue I guessed earlier. Right now, the character is transformed by the ragdoll world transform before adding constraints. If the constraint definitions include world space data, this is correct. If, however, the constraints are configured for local construction, then they'll all be incorrect relative to the entities post non-identity world transform.

-BallSocketJoint anchor location is not placed at a logical joint location, so everything turns out goofy.

Shouldn't the joints be at the same location as they are specified in Maya? I've shortened both the length and the radius of the capsules but the results were rather wild.

The first bone should be aligned along the X-axis and go from (0, 0, 0) to (L, 0, 0). Would you agree?

Here is just one bone with a world transform of:

Matrix modelWorld = Matrix.CreateRotationZ(MathHelper.PiOver2);
:
sk.bone.WorldTransform = modelWorld;