## Object going past Hinge Constraint Limits

Posts: 2
Joined: Thu Mar 26, 2020 6:58 am

### Object going past Hinge Constraint Limits

Hey guys, I'm new to Bullet.

I added a hinge constraint with a small angle limit. In order for this pinball flipper to work properly it needs super high torque/velocity. I've tried both setting angular velocity, and torque. I also played around with the motorSetTarget and other Motor settings but it was really slow no matter what settings I put in for the motor. I have everything working except the engine isn't respecting that this object should never go past the angle limits imposed. I'd think there has to be a way to hard cap the limit.

In the image, green are my limits, and red is how far past the limit the object has rotated. Is there a simple way to fix this? I tried tweaking softness, biasfactor, and relaxation factor. Right now they are all set to zero and work best. If I lower the angular velocity much slower, then it will work as expected, but I need high velocity.

Also, just curious, why does adding a hinge constraint to an object removed all effects of gravity? Is there a way around this. I was thinking of if you had a car in the air and the door opened on a hinge.

Thanks
hinge.jpg (200.55 KiB) Viewed 181 times

drleviathan
Posts: 597
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

### Re: Object going past Hinge Constraint Limits

What size of fixed substep are you using? Default is 1/60 of a second, and if your flipper is rotating too fast then it could probably "tunnel" past the limit by one whole substep's worth of distance. If your substep is long then try using a smaller substep.

The center of mass (COM) of the flipper is its origin <0,0,0> in its shape's local-frame. If you pivot the flipper at its COM then there will be zero net torque on it from gravity. Which makes me wonder... did you perhaps build the flipper's geometry such that its origin is at the hinge pivot? If so, then you should compute its true COM and shift the shape's geometry so that point is at its local-frame origin.

Posts: 2
Joined: Thu Mar 26, 2020 6:58 am

### Re: Object going past Hinge Constraint Limits

Ah whoops, should have figure this out since I've been in games for 10 years now. Thanks. I re-checked the function signature and saw it runs at a fixed step of 60Hz and you pass in the true frametime and max sub-steps. Should have realized this. My code is running well over 500FPS currently so I can spare a much lower physics timestep.

As for the gravity thing. I get what you mean. I'm not actually intending the object to rotate around the fixed position hinge.What I'm wondering is, how do you get the hinge constraint to also be affected by gravity?

What I was curious about was for instance again if I drop a car from the sky and I have a hinge constraint on the doors, well gravity is still affecting the hinges (whole system). So the car falls and I still have a constraint hinge on the doors. I didn't see an API call to allow constraints themselves to get pulled by gravity. Are they all fixed position by default? The demos that come with Bullet I saw the same thing happening that they are all fixed position.

drleviathan
Posts: 597
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

### Re: Object going past Hinge Constraint Limits

Typically a constraint connects two objects: objectA and objectB. The local-frame transform of the constraint pivot needs to be defined in the local-frame of each object and the constraint will work hard to align those two local-frame pivots on top of each other in the world-frame. One way to think about it: the constraint doesn't care where the pivots end up in the world-frame, as long as the two local-frame pivots end up overlapping, so it tries to take the shortest path. When both objects are dynamic then it should Just Work, and gravity will also be at play.

However, many constraints allow you to connect one objectA to the world (objectB is null object). The world-frame is not affected by gravity, and in this case the local-frame pivot point for the null objectB is fixed in the world-frame.