Okay, I seriously need some deep info here:

Oct 17, 2010 at 3:57 AM
Edited Oct 17, 2010 at 7:09 PM

I have spent nearly a month trying to get physics to work in a rather unique way.  My game is not using physics just to make dead bodies fall, like many games, it is critical to the gameplay.  It'll be beautiful if I can ever get it to bloody work.  I have swapped through numerous physics engines.  This one seems the most complete, I can actually can step through the code which is supposed to help me out, plus, I can actually talk to the developer, which is a huge bonus!  (And I thank you for your help so far!)  Unfortunately, I am at my wit's end.

These are the common problems I'm having:

1.  Constraint sorting error, as described in another post.

2.  Bodies stop falling and/or ignore all impulses/forces.

3.  If any one of several constrained bodies has a "problem," all the connected bodies ignore impulses/forces.

4.  Speed can be very fast, or very slow.  It doesn't seem to be based on distance.  It is generally based on "how angry constraints are" which makes sense, until I untangle the collision, everything has calmed down, and the speed is still slow.  This is the least of my problems.

It appears if I change nearly /anything/ after I get one of those problems listed above.  In fact, am terribly surprised that you have said you have NOT run into these problems yourself.  Even the least significant change seems to break it.  What this tells me is that you know what you should and should not do, and I don't.  You need to educate me of the rules of your physics engine.

What I need to know:

1.  I need to know how to properly construct boxes, spheres, and meshes WITHOUT usage of the content pipeline.  I have built my own BoxBody, SphereBody, and MeshBody classes, which inherit from RigidBody to do this.  I will share my code if you wish, it isn't anything fancy, pretty much pulled out of your pipeline.  Those basic bodies should probably be included from your engine from the get-go though.  Anyone doing anything even half-way advanced is going to want to save the content pipeline for visual importing.  (In my previous game, I fought the battle of duplicate assets, for two different content processors, and that's just silly.)

2.  I need to know what pieces of information are REQUIRED to make the bodies function properly.  Is assigning a mass required?  Is setting the world required?  Is it required to do a Skin.ApplyTransform?  From what I have seen, if I don't apply those things to every single body, I will get one of those problem listed above.

3.  I assume you should only apply mass, world, etc. only once you have added all parts to the body, yes?

4.  What are the "rules" for changing positions or orientations manually?  It appears if I do nearly any manipulation while the body is added to a physics manager, horrible things happen, resulting in one or more of the issues listed above.  I try to avoid it as much as possible, but sometimes it turns into a thought battle of: should I have a constraint for EVERY single body just to move my constrained bodies together a few units away?  I have tried to use FlashImpulse and SetVelocity to move things as if I was just resetting the position, but neither seem to be able to move all bodies at the same speed.  Any tricks you can think of?

5.  When is the proper time to add/remove constraints?  It appears if I add or remove a constraint at any time except for body creation (before simulation begins), one of the issues above occurs.

6.  Is it bad to change the mass after it has been added to the physics manager?  I assume yes, but I would like to know if I should keep an eye open for that.

I'm sure I'll think of more questions.  I made a demo of what I am trying to do without a physics engine, but I think it will be far more lame and less innovative.  I thank you for all your help... and I really hope you give me the juicy information I need.  I really don't want to gut the physics.

(I apologize for any strange/confusing writing here... I was pretty infuriated at the time! :-P)

Coordinator
Oct 17, 2010 at 9:27 PM
Edited Oct 18, 2010 at 5:03 AM

I haven't done anything as complex as what it sounds like you're trying to do, so I'm not that surprised you're running into issues. My original goal was just simple rigid body kinematics; I consider it a bonus that I got ragdolls working at all.

If you can provide a self-contained repro for each of the problems you're seeing (something I can just drop into the Holodeck sample) I'll look into the issues when I have some time.

As to your questions:

1. If you want to construct bodies without using the pipeline, it would be best to study the pipeline code and do what it does at runtime. For adding primitives like boxes, you would just supply a set of 8 vertices (the corners of the box) to CompiledPolyhedron. Spheres are just a sphere part added to the body's skin.

2. Every body has to have mass properties and a position/orientation, so setting the mass is required and calling SetWorld is required (otherwise the object will just be at the origin).

3. Mass really needs to be calculated appropriately. The inertia tensor would be calculated based on the shape of the object and its mass density (for the purposes of this engine, only a uniform density is supported). The pipeline calls functions that compute the intertia tensor, center of mass, and total mass appropriately. If you aren't using the pipeline, you'll need to understand what the pipeline does or compute those values manually yourself.

4. SetWorld should be used to change position and orientation. However, if you have a bunch of constraints applied and you do a SetWorld to move something around unnaturally, I wouldn't expect the constraints to behave very nicely. If you need something to move under its own force, I would apply forces instead, and let the force compete with the constraints.

5. You should be able to add or remove them at any time, as far as I know. However, if you add a constraint, the bodies should already be in a position to satisfy the constraint.

6. Probably. It's not a scenario I've tested. Changing the mass means you also need to compute an appropriate inertia tensor. Suddenly changing mass may interfere with warm starting in the solver, though.