Constraint bugs

Constraint bugs

I created a simple custom constraint using the Construction Kit. Here is the code.

kit.setPivotsHelper(pBodyA, pBodyB, hkPivotW);

kit.setAngularBasisABodyFrame();

kit.setAngularBasisBBodyFrame();

kit.constrainAllAngularDof();

A is a Keyframed object in my level, while B is a Dynamic cube. All objects in my test case have a mass of 1.

The basic behavior of the constraint is that B is free to translate but its frame is constrained to always match the frame of A.

In my test situation B is resting on a plane and A is given a rotational velocity of 0.1 along its X axis. B then starts to rotate in synch and therefore rolls forward on the ground.

I am observing 2 bugs:

1: Even if B is given a friction value of zero it still travels on the ground. The motion is slightly slower than with full friction but not by a very noticeable amount. In theory a friction of zero should keep the center of mass of B in a constant position horizontally. Is there something I can do to ensure that objects with zero friction values do not receive any tangeantial forces during contacts?

2: Way more problematic, if B bumps on another Dynamic cube (mass 1) while rolling, it stops rotating and the constrained Keyframed object stops rotating as well! Stepping through shows that both A and B have been deactivated. Am I wrong in assuming that nothing in the simulation should ever be able to modify the linear or rotational velocity of a Keyframed object? Without the full source I cannot tell if A stops rotating because it gets deactivated or if it gets deactivated because it stopped rotating. This behavior only happens at low rotational speeds.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I'vefigured outthe second half of my own question. The constraint has nothing to do with it. Keyframed objects put themselves to sleep if you give themtoo low of a rotational speed. It still seems to be a bug though. Since the speed of the object is set by the user it should not be free to decidethat it wants to go to sleep. Keyframed objects should only go to sleep if their velocity is set to zero.

I guess I'll make my own wrapper to mark keyframed object as not allowed to deactivate if their velocity is not null.

I still have the friction problem though. Even with a sphere on plane contact and zero friction on both objects, if the sphere is given a rotational speed it starts rolling on the plane right away.

Hi laurent_coulon,

For the first question there. I think you want to set your friction value to 1.0 for the box (the highest normal setting). You can go higher than 1.0, but it will give non-physical behavior which is isn't recommended for most cases. If that doesn't give you what you are looking for then you can try playing with the linear or angular damping.

For the second part of your question, you should take a look at the Havok Physics->Havok Dynamics->Rigid Bodies->Deactivation. You can take a look using setDeactivator().

Let me know if this helps.

Thanks,
Sean

Developer Support Engineer
Havok
www.havok.com

Hi Sean,
Thanks for the reply.
I made a wrapper to set my keyframed objects to never deactivate if they have a non-zero velocity. That fixedmy second problem.
The first problem is still there though. I'm not trying to make the object have friction, I'm trying to make it have none. The problem right now is that even a sphere with a friction of 0 rolls forward on the ground when constrained to rotate. The behavior I am looking for is to have objects with 0 friction slide on the spot and not move forward. Is there a quality setting I can use that will force a more accurate friction model?

Hi laurent_coulon,

Okay, I understand better what you are doing now. If you are using a sphere, then I would suggest turning the linear damping of the rigid body up. This will stop the body from moving forward. The friction that we are using is more of a sliding friction then a rolling friction. The damping is a better bet. Try that and if it doesn't work out then we can try some other things.

Let me know how it goes.

Thanks,
Sean

Developer Support Engineer
Havok
www.havok.com

Leave a Comment

Please sign in to add a comment. Not a member? Join today