BEPUphysics

Well, Thanks this to this post viewtopic.php?f=4&t=2065, I've got some turrets working well on my tanks.

I have another problem now though. This video shows the issue http://www.youtube.com/watch?v=WPYiqpxj7C0. To describe it, you'll see the turrets tracking the camera (viewer). All seems fine. I flick to controlling the large cylinder and apply some impulse to the entity - The turrets are attached to it (via RevoluteJoint's). When I flick back to the flying camera, you'll see over time that the joint constraints drift from their original instantiated position relative to the large cylinder. I'm using the debug drawerer. See the red lines from the constraint position extending and the turret orientation loosing the plot. I can't figure out why this is happening. The Tanks don't appear to exhibit this although they are a lot smaller.

Regarding the cylinder entity, the Orientation is currently forced to be upright with a yaw setting each frame (via setting the OrientationMatrix). ApplyImpulse is based on that OrientationMatrix...

BEPUEntity.ApplyImpulse(Vector3.Zero, BEPUEntity.OrientationMatrix.Forward * -5000f * ControlSchema.LeftStick.Y);

Appreciate any advice!?

...I did have SingleEntityAngularMotor keeping the thing up right (1 for each axis ... Up, Right, Forward for yaw, pitch and roll), but that's another post/problem to come.

If the velocities of the involved entities do not match their motion (as in the change in position and orientation), constraints will tend to fail. I would recommend disabling any teleportation (e.g. setting Position or OrientationMatrix directly) to help narrow down the cause.

If no problem occurs when teleportation is disabled, then the velocities just don't match the motion well enough for constraints to function.

One way to ensure correct physical behavior is to stick to physically valid states. Setting velocities, applying forces, and using constraints instead of setting position/orientation will let constraints work properly.

I did have SingleEntityAngularMotor keeping the thing up right (1 for each axis ... Up, Right, Forward for yaw, pitch and roll), but that's another post/problem to come.

Note that a SingleEntityAngularMotor controls all three degrees of freedom at once by striving for a goal orientation. If there are 3 separate motors with different orientation targets working on the same entity, the constraints will fight.

OK. Thanks Norbo. I'll go back to using the angular motor constraint and forces. The cylinder is very heavy and thinking back, I think I might have had springsettings too weak when I had one Motor before I ended up with three. I'll have a play around using forces et al and post back. I must admit, when I resorted to forcing orientation, I did wonder if I'd mess up the simulation.

Thanks again

Norbo wrote: Note that a SingleEntityAngularMotor controls all three degrees of freedom at once by striving for a goal orientation. If there are 3 separate motors with different orientation targets working on the same entity, the constraints will fight.

Well, as recommended, I went back to using the SingleEntityAngularMotor with a Goal of Quaterrnion(Vector.Up,yawGoal) and much higher stiffness and damping values (to compensate the weight of the cylinder) and things appear to be stable. Many thanks for the guidance.