Improving collision between dynamic and kinematic entities

[snoozbuster]

I had a whole big post but then I accidentally closed Firefox. Anyway.
I updated, but it didn't fix the problem. Here's my joint setup.

Code: Select all

            // zeroAxis is -Vector3.UnitX, rotationAxis is Vector3.UnitY, angle is pi, rotateTime is 2
            baseJoint = new RevoluteJoint(null, modelList[0].Ent, center, rotationAxis);
            baseJoint.Motor.IsActive = true;
            baseJoint.Motor.Settings.Mode = BEPUphysics.Constraints.TwoEntity.Motors.MotorMode.Servomechanism;
            baseJoint.Motor.Settings.Servo.SpringSettings.StiffnessConstant = 0;
            baseJoint.Motor.Settings.Servo.SpringSettings.DampingConstant /= 12;
            baseJoint.Motor.Settings.Servo.Goal = 0;
            baseJoint.Motor.Settings.Servo.MaxCorrectiveVelocity = angle / rotateTime;
            baseJoint.Motor.Settings.Servo.BaseCorrectiveSpeed = angle / rotateTime;
            baseJoint.Motor.Basis.SetWorldAxes(rotationAxis, zeroAxis);
            baseJoint.Motor.TestAxis = zeroAxis;
            baseJoint.Limit.IsActive = true;
            baseJoint.Limit.MinimumAngle = 0;
            baseJoint.Limit.MaximumAngle = angle;
            baseJoint.Limit.Basis.SetWorldAxes(rotationAxis, zeroAxis);
            baseJoint.Limit.TestAxis = zeroAxis;

Also, there was some funkiness that changed when I updated. I had a rectangular prism that slid back and forth as a machine, and I'm using TriangleMesh.GetVerticesAndIndicesFromModel to create a MobileMesh with MobileMeshSolidity.Counterclockwise. I know I could use a Box, but the trouble with that is the class for models just generates all the collision from the provided Model. It'd be difficult to change now. Anyway, prior to updating boxes would clip halfway through it and jitter around, but now they touch it and adhere to the surface while spinning madly all over it (probably due to slightly negative friction, although that doesn't explain why they just attach themselves to the model). I thought it could be a MobleMeshSolidity problem, but there's no reason a simple rectangle should have clockwise-culled sides. None of my other models do, to my knowledge. If you want to look at it, I can attach the model to the next post.

EDIT: Also, could a LineSliderJoint be used to create a kind of belt-like object, like this, in which the axis of rotation is not the same as the axis of sliding?

[Norbo]

I updated, but it didn't fix the problem. Here's my joint setup.

Could you provide an isolated, complete configuration in the BEPUphysicsDemos? There's missing information there that prevents me from being able to easily debug it; if everything (entities, all variables, joints, etc.) is available, I can take a closer look. At the moment, I don't see anything particularly wrong. Filling in the information gaps with guesses seems to produce a fully functioning configuration.

(probably due to slightly negative friction, although that doesn't explain why they just attach themselves to the model).

Negative friction is a big no-no. It could explain a lot strange behavior.

If you want to look at it, I can attach the model to the next post.

That could be helpful, if it isn't just caused by friction issues. An accompanying configuration for the mobile mesh isolated in a demo would help guarantee reproduction, too.

Also, could a LineSliderJoint be used to create a kind of belt-like object, like this, in which the axis of rotation is not the same as the axis of sliding?

Yup. Remember, a LineSliderJoint is just a combination of other constraints. Its angular joint is a RevoluteAngularJoint like you've been working with already.

[snoozbuster]

Could you provide an isolated, complete configuration in the BEPUphysicsDemos?

Insert this into the RobotArmDemo:

Code: Select all

            Space.ForceUpdater.Gravity = new Vector3(0, -9.81f, 0);
            Entity ground = new Box(Vector3.Zero, 30, 1, 30);
            Space.Add(ground);

            // baseJoint is a RevoluteJoint that's a member of the demo.
            Box e = new Box(new Vector3(0, 2, 0), 1f, 1f, 0.25f, 10);
            baseJoint = new RevoluteJoint(null, e, e.Position + new Vector3(e.HalfWidth, 0, 0), Vector3.UnitY);
            baseJoint.Motor.IsActive = true;
            baseJoint.Motor.Settings.Mode = BEPUphysics.Constraints.TwoEntity.Motors.MotorMode.Servomechanism;
            baseJoint.Motor.Settings.Servo.SpringSettings.StiffnessConstant = 0;
            baseJoint.Motor.Settings.Servo.SpringSettings.DampingConstant /= 12;
            baseJoint.Motor.Settings.Servo.Goal = 0;
            baseJoint.Motor.Settings.Servo.MaxCorrectiveVelocity = MathHelper.Pi / 2.25f;
            baseJoint.Motor.Settings.Servo.BaseCorrectiveSpeed = MathHelper.Pi / 2.25f;
            baseJoint.Motor.Basis.SetWorldAxes(Vector3.UnitY, -Vector3.UnitX);
            baseJoint.Motor.TestAxis = -Vector3.UnitX;
            baseJoint.Limit.IsActive = true;
            baseJoint.Limit.MinimumAngle = 0;
            baseJoint.Limit.MaximumAngle = MathHelper.Pi;
            baseJoint.Limit.Basis.SetWorldAxes(Vector3.UnitY, -Vector3.UnitX);
            baseJoint.Limit.TestAxis = -Vector3.UnitX;

            Space.Add(e);
            Space.Add(baseJoint);

            // in the keyboard stuff, N sets the goal to pi and M sets it to zero.

Sometimes it will work, but most of the time it'll just jiggle.

Negative friction is a big no-no. It could explain a lot strange behavior.

But it usually works fine. Its mainly there so boxes will slide down slopes better.

That could be helpful, if it isn't just caused by friction issues. An accompanying configuration for the mobile mesh isolated in a demo would help guarantee reproduction, too.

I'll get that to you next reply.

Also, could a LineSliderJoint be used to create a kind of belt-like object, in which the axis of rotation is not the same as the axis of sliding?

Yup. Remember, a LineSliderJoint is just a combination of other constraints. Its angular joint is a RevoluteAngularJoint like you've been working with already.

Gotcha. Just making sure, I didn't want to start it and discover it wouldn't work.

[Norbo]

It appears the issue is just that both directions to the goal have exactly equal angular distance. It chooses one, but gets blocked by the limit. The motor has no knowledge of the limit, as they are separate constraints, so it cannot know to always go the other way.

But it usually works fine. Its mainly there so boxes will slide down slopes better.

In the development version, friction coefficients are blended multiplicatively by default. A negative coefficient will make the combined coefficient negative. If the final used coefficient is negative, all sorts of badwonk will occur.

The friction blending function can be changed in the MaterialManager if you'd like to use a different system (such as averaging, as it was before). However, I would recommend always avoiding negative coefficients to avoid any situation where the combined coefficient is negative.

[snoozbuster]

Well, if both the friction coefficients are negative, won't multiplying them make them turn out positive?

It appears the issue is just that both directions to the goal have exactly equal angular distance. It chooses one, but gets blocked by the limit. The motor has no knowledge of the limit, as they are separate constraints, so it cannot know to always go the other way.

Ah, that makes sense. Is it an easy fix? It seems that instead of always picking the shortest distance, a servo should rotate the full angle... I mean, if I wanted a machine to rotate 3pi/2 radians in one direction, how could that happen? I suppose I could set the xAxis and testAxis to pi/2 and then rotate pi rads. Oh well. Nice to know anyway.

[Norbo]

It seems that instead of always picking the shortest distance, a servo should rotate the full angle...

There is no concept of a 'full angle' for it to use; every frame, it sees what the angular distance from the current state to the goal is and acts upon that. The fundamental purpose of a servo constraint is to 'achieve a goal as directly as possible,' as opposed to 'achieve a goal in an arbitrary way.'

I mean, if I wanted a machine to rotate 3pi/2 radians in one direction, how could that happen? I suppose I could set the xAxis and testAxis to pi/2 and then rotate pi rads. Oh well. Nice to know anyway.

The easiest way to accomplish nontrivial goals is to treat it as an animation with multiple frames and assign the goal according to the animation. Setting the goal to a midpoint angle before moving on would indeed be a special case of this approach.

[snoozbuster]

Alright. I'll post if I have any more problems.