Door knocked off hinge constraint by collisions

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Door knocked off hinge constraint by collisions

Post by bteitler » Mon Jan 13, 2014 1:09 pm

I'm new to Bullet, and I'm trying to get a simple door set up. The door should be attached rigidly to the world and swing between 0 and 90 degrees. By "rigid", I mean that the door hinge should not be breakable or bendable by objects that collide with it. I'm using the following constructor for my hinge:

Code: Select all

btHingeConstraint::btHingeConstraint(btRigidBody & rbA,
const btVector3 & pivotInA,
const btVector3 & axisInA,
bool useReferenceFrameA = false 
)	
I end up with a door that is "floating" in space anchored at the hinge axis, but can swing along that axis. I have used "setLimit" function to specify the angle constraint. If I apply small forces to the door it seems to move correctly and respects the angle constraint until... I apply too much force to the door (i.e. through a ball at it with a large mass). Then it kind of "bounces" out of it's location and springs back to its location. The hinge axis will actually change to accommodate the colliding object, and then spring back to its original position.

I have also tried attaching the door to another rigid body with mass 0. However, the exact same thing happens! Can what I want be done? Essentially I want the two anchoring points of the door to have static position constraints just like rigid bodies with mass 0 do.

bwelch
Posts: 48
Joined: Thu Dec 12, 2013 4:04 pm

Re: Door knocked off hinge constraint by collisions

Post by bwelch » Mon Jan 13, 2014 2:20 pm

Unfortunately, I don't have much to suggest; I've been trying to solve the same problem with other constraint types and haven't had much luck. Try searching these forums for BT_CONSTRAINT_STOP_CFM and BT_CONSTRAINT_STOP_ERP. I don't fully understand what these parameters do and how they work, but playing with the values does modify the behavior of constraints, and you may be able to get your door close enough to acceptable for you.

I'll be monitoring this thread in the hopes that there's a better method for getting "unbreakable" constraints.

Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

Re: Door knocked off hinge constraint by collisions

Post by Moose » Mon Jan 13, 2014 2:37 pm

bteitler wrote:If I apply small forces to the door it seems to move correctly and respects the angle constraint until... I apply too much force to the door (i.e. through a ball at it with a large mass). Then it kind of "bounces" out of it's location and springs back to its location. The hinge axis will actually change to accommodate the colliding object, and then spring back to its original position.
I have exactly the same problem and unfortunately can't contribute much. In the forum there is much talk about this and much parameters are suggested. My 2 cents are not to worry about them too much. I have literally spent quite a few days (6) fiddling about with all of them and all I can say is that they seem to have no effect whatsoever. Most are undocumented and it's just an endless trial and error with little return on invest. Most times you don't even know which range is sensible. More like 0.001 or 10000? You never know. In my opinion. Sorry if this sounds harsh. This is just my experience with it.

The only thing I did with visible effect was cranking up the iteration depth. The default values and recommendations are mostly in the ranges between 10 and 50. I have set it to about 1000 now and there has been some improvement. At cost of CPU. Your hinge will still wobble though so don't expect too much.

This is what I have set now for reasonable results:

m_dynamics_world->getSolverInfo().m_damping = 1.0f; // bullet default 1.0
m_dynamics_world->getSolverInfo().m_tau = 0.6f; // bullet default 0.6
m_dynamics_world->getSolverInfo().m_numIterations = 100; // bullet default 10
m_dynamics_world->getSolverInfo().m_solverMode |= SOLVER_USE_2_FRICTION_DIRECTIONS | SOLVER_RANDMIZE_ORDER | SOLVER_SIMD;

For each constraint I set the num_iterations for 1000. I don't know if and in which way the global setting influences this.

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Tue Jan 14, 2014 12:28 am

Hmm.. disappointing to see that this is not a simple task. In my mind, "constraint" means actually constrained... not kind of sort of springy system. I don't think I can use Bullet if I can't get this to work right. I think just fiddling with parameters without a guarantee of rigidity is going to deteriorate really quickly when I start building complex levels. Is there some other strategy people use for doors? Or another free library commonly used that you know has this feature? I'd ideally like one that already has Java bindings available.

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Tue Jan 14, 2014 5:33 am

I tried every combination of high/low values of BT_CONSTRAINT_STOP_CFM, BT_CONSTRAINT_ERP, BT_CONSTRAINT_STOP_CFM, and BT_CONSTRAINT_STOP_ERP. It either did something crazy like ignoring my angle constraints, or there was no visible effect (hinge still jiggles all over).

I notice that interactions between colliding rigid bodies and the line where the static hinge should rest don't really work correctly either. Often objects go through the door, pushing the hinge out of position instead of reflecting as I'd expect.

Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

Re: Door knocked off hinge constraint by collisions

Post by Moose » Tue Jan 14, 2014 10:34 am

I hear ya.
About alternatives or rather an evaluation thereof you may want to read this:
http://elib.dlr.de/79462/1/74320346.pdf

HTH,
Moose

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Wed Jan 15, 2014 12:30 am

The paper is interesting but seems to be a more general bench-marking comparison. It might tell me what implementations are more accurate in some aggregate case over random common setups (chuck a bunch of moving objects together), where I basically want to know a very a specific question: Are constraints between moving and static objects rigid?

I've read some posts on the forum that seem to indicate that dynamic to dynamic object constraints don't have this issue. Maybe I can do something hacky like attaching to a dynamic object with large mass where I continually update position / velocity to 0. That should at least tell me if what I want even makes sense in the context of how the physics algorithms work (which I don't really know).

I guess I could also actually build a hinge the way you would in the real world and see how that performs.

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Wed Jan 15, 2014 1:03 pm

I tried various tricks like setting linear / angular factors of dynamic bodies with high mass to 0 and attaching a door via constraint. The constraint still wobbles exactly like before unfortunately.

So instead I modeled a hinge from a compound body of cylinder + box for the door, with center of mass in the middle of the box. I stuck it in between 2 cube hubs that are static, and it seems to work reasonably well. It will still wobble, but only as much as the extra space is available in the hub and it makes intuitive sense.

bwelch
Posts: 48
Joined: Thu Dec 12, 2013 4:04 pm

Re: Door knocked off hinge constraint by collisions

Post by bwelch » Wed Jan 15, 2014 2:13 pm

Can you show us? I'd like to see what worked for you either by screenshot or video and/or code.

User avatar
Erwin Coumans
Site Admin
Posts: 4189
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Door knocked off hinge constraint by collisions

Post by Erwin Coumans » Thu Jan 16, 2014 12:53 am

Ideally you reproduce the issue in one of the Bullet demos, for example the Bullet/Demos/ConstraintDemo.
Here are some ideas to improve/solve the issue:

The iterative constraint solver might not be able to converge to the right solution, especially if the masses of the objects involved are very different. Make sure to use small offset for the attachment frames of the two hinge bodies. In other words, use a static object next to the door and attach the hinge against this static object. You can also improve the results, by making the masses of the door and colliding object (bal) more similar, increase the mass of the door. Also, you could 'fake' the inertia tensor of the door to make the hinge more stable: use a btSphereShape that encapsulates the door, to compute the inertia tensor. Using a smaller internal timestep can help too.


The best solution is to use the btMultiBody for the door, and assigning a 'revolute' joint. It uses Featherstone constraints, and there will be no gap. I am currently migrating all Bullet 2.x code in the new Bullet 3 repository, and look into creating a new demo to show how this works. In the meanwhile, you could experiment with the Bullet/Demos/FeatherstoneMultiBodyDemo.
bteitler wrote:I tried various tricks like setting linear / angular factors of dynamic bodies with high mass to 0 and attaching a door via constraint. The constraint still wobbles exactly like before unfortunately.
It should be possible to set all 3 linear factors to zero, and set 2 angular factors to zero. In that case, there is no constraint necessary. Just make sure that the door 'hinge' is aligned with its center of mass.

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Thu Jan 16, 2014 6:46 am

Erwin Coumans wrote:The iterative constraint solver might not be able to converge to the right solution, especially if the masses of the objects involved are very different.
I keep reading this in multiple places and I don't really understand what is meant by it. Is it that larger forces create more instability due to the discrete nature of the algorithm (deeper penetrations to resolve?). Or are you trying to say that more equal masses are more accurate regardless of force? That is if I threw 2 stacked objects of smaller mass at the constraint, it would be more rigid than 1 object of the combined mass thrown at it?
Erwin Coumans wrote:It should be possible to set all 3 linear factors to zero, and set 2 angular factors to zero. In that case, there is no constraint necessary. Just make sure that the door 'hinge' is aligned with its center of mass.
I tried this, and it appears to work as expected for the most part when colliding with dynamic objects. Unfortunately, I don't really want the center of mass on the hinge. I want it in the middle of the door (as you would expect in reality) so gravity will turn the door if it is orthogonal to gravity (think sideways door). Is there a way to put the center of mass somewhere other than the rotational axis?
bwelch wrote:Can you show us? I'd like to see what worked for you either by screenshot or video and/or code.
It's pretty much what you expect:
Image
The two small boxes are static hubs. The door/flap is a compound shape made up of a cylinder and a box. The center of mass / origin is in the center of the box so it will behave realistically. Pretty much everything is default settings, so no friction on the hubs. I'm assuming you could make the hubs not colliding with anything exceptthe door and not render them if you had to.

User avatar
Erwin Coumans
Site Admin
Posts: 4189
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Door knocked off hinge constraint by collisions

Post by Erwin Coumans » Thu Jan 16, 2014 5:13 pm

bteitler wrote:
Erwin Coumans wrote:The iterative constraint solver might not be able to converge to the right solution, especially if the masses of the objects involved are very different.
I keep reading this in multiple places and I don't really understand what is meant by it.
In a nutshell, the iterative solver doesn't find a good solution when there are multiple constraints (contact, hinge) and bodies with large differences in mass (even 1kg vs 100kg is large). No good solution means that the constraints are still violated at the end, and this can be visible as penetration or gaps in the constraints.
Is there a way to put the center of mass somewhere other than the rotational axis?
You can wrap your collision shape in a btCompoundShape and shift it using the child transform.

Thanks,
Erwin

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Thu Jan 16, 2014 5:59 pm

Erwin Coumans wrote: In a nutshell, the iterative solver doesn't find a good solution when there are multiple constraints (contact, hinge) and bodies with large differences in mass (even 1kg vs 100kg is large). No good solution means that the constraints are still violated at the end, and this can be visible as penetration or gaps in the constraints.
It's still not clear to me whether the issue is large forces or not. Coming from a (rudimentary) physics background, it doesn't make sense to talk about mass without acceleration and force. If I have 101 objects of mass 1kg, it is clearly possible for mass ratios of 100:1 to occur depending on simulation (drop a stack of 100 straight down onto 1, etc). I guess I'm asking if I have to worry about cases like this causing random instability.
Erwin Coumans wrote: You can wrap your collision shape in a btCompoundShape and shift it using the child transform.
This is actually the first thing I did, but it doesn't change the center of mass of the compound shape (unless there's something else I need to do that I don't know). Here is psuedocode for what I'm doing (I'm actually using the libGDX Java bindings, so real code/example is probably not too useful):

Code: Select all

btBoxShape boxShape = new btBoxShape(new Vector3(aabb.radii.x, aabb.radii.y, aabb.radii.z));
btCompoundShape doorShape = new btCompoundShape();
doorShape.addChildShape(new Matrix4().setToTranslation(0, -aabb.radii.y, 0), boxShape );
The box shape has a center of mass + origin in the center of the box. Since we are making a door, we add it to the compound shape shifted by its half length. This achieve the door having the freedom to rotate like a real door does, since the hinge is now located at (0, 0, 0) with respect to the compound shape. However, as I understand it, the compound shape itself still has a center of mass at (0, 0, 0) (it seems all shapes do no matter what?). Therefore, gravity will still be applied at the hinge, which will do nothing since the linear factor is 0 and no torque is generated.

Am I missing something?
Last edited by bteitler on Thu Jan 16, 2014 6:08 pm, edited 1 time in total.

c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: Door knocked off hinge constraint by collisions

Post by c6burns » Thu Jan 16, 2014 6:02 pm

Large forces can cause the solver not to converge. You can see this clearly by applying a large force to a single body of a ragdoll (in my case).

bteitler
Posts: 10
Joined: Mon Jan 13, 2014 12:47 pm

Re: Door knocked off hinge constraint by collisions

Post by bteitler » Fri Jan 17, 2014 10:26 am

Hmm.. well I'll read up on the stability issues.

Regarding the rigid door issue, I was able to get something that works more or less like what I want while respecting gravity as well, but only for axis aligned doors. I start with a box with center of mass at an edge (for hinge), and set linear factors to 0, and angular factors for 2 of the axes to 0 (this was suggested above). This gives you an axis aligned, anchored, rigid door that doesn't have gravity affect it, since gravity seems to be applied at the center of mass only, which generates no torque. If your door hinge is orthogonal to gravity, then you are done, as interactions seems to behave intuitively at this point. However, if it isn't, then you have to apply gravity yourself per tick. The way I chose to do it was calculate new angular velocity of the door based on the elapsed tick time and current angular velocity. I assume the door behaves like a pendulum (all mass in a single point at a desired radius).

I'd still like a solution that works in the non-axis aligned case though.

Post Reply