btSequentialImpulseConstraintSolver not rotation consistent

[mreuvers]

There seems to be a serious bug present in the btSequentialImpulseConstraintSolver. From our experience the behavior of objects is different if the object is rotated. Let me elaborate by example.

Suppose that I have an object with these dimensions (1, 4, 2) (x, y, z) lying on a flat surface and I apply a central impulse to it into the x direction: the object flies away. So far so good.

If I rotate this object with 90 degrees around its Y axis and use a different scale (2, 4, 1) the object looks exactly the same. In fact it should be the exact same object, it only has an internal rotation. However if I apply the same central impulse to this object, the object flies away in a completely different manner! It definitely doesn't produce the same flightpath as the first example, while theoretically it should! This only happens if the object is in contact with the ground, it won't happen in mid-air. So I'm suspecting that something really fishy is going on in the btSequentialImpulseConstraintSolver, as that one is responsible for handling the collision response.

In fact, this bug makes it very hard for us to create levels, since objects behave differently when rotated. When we use the ODE constraint solver, we didn't observe these rotation problems. So we're probably sticking to that solver, until this issue is... solved

Did anyone else notice this behavior?

[Erwin Coumans]

In fact, this bug makes it very hard for us to create levels, since objects behave differently when rotated. When we use the ODE constraint solver, we didn't observe these rotation problems. So we're probably sticking to that solver, until this issue is... solved

The new Bullet constraint solver uses the same, but optimized, innerloop as the ODE solver. The only different that might cause this behaviour is the difference in friction model setup.

If you can reproduce the issue in a Bullet demo, I'll make sure it will be fixed asap. Can you help with that?
Thanks,
Erwin

[mreuvers]

If you can reproduce the issue in a Bullet demo, I'll make sure it will be fixed asap. Can you help with that?

Sure, I'll try to reproduce that first thing on Monday!

Have a great weekend!

[sparkprime]

If you are using a triangle mesh, this could be a duplicate of

http://www.bulletphysics.com/Bullet/php ... f=9&t=3052

Although it theoretically should be the same, the numbers are different and slight fp errors could cause it to 'dig into' the triangle edges when it wouldn't otherwise do so. However I may also be projecting my own problems onto other peoples' problems

[mreuvers]

If you are using a triangle mesh, this could be a duplicate of

http://www.bulletphysics.com/Bullet/php ... f=9&t=3052

Although it theoretically should be the same, the numbers are different and slight fp errors could cause it to 'dig into' the triangle edges when it wouldn't otherwise do so. However I may also be projecting my own problems onto other peoples' problems

No we're not using that. It's simply a boxed shape (btBoxShape) placed on another boxed shape. I provided Erwin with an example, so hopefully this can be sorted out.

Cheers

[Erwin Coumans]

Thanks Martijn for the reproduction case. These are several issues, most related to the friction model settings that cause the rotation, and some due to impact without sufficient number of contacts.

The latest trunk exposes more advanced friction settings, and selects the friction setting that matches ODE quickstep.

Check out this issue. It has an updated reproduction case to compare friction beween ODE solver and Bullet solver. You can dynamically switch solver, rotating the shape and select scaling coefficient. This friction demo will be added to the Bullet demos by default. I'll improve the friction model, so it is better than ODE quickstep, by using a central friction model with rotational friction. The benefit is that the object can slide along arbitrary directions, without added rotation. Right now, both Bullet and ODE diverge from the friction direction. This is because the friction is approximated by a pyramid that is aligned with the world axis, instead of using a cone (or pyramid aligned with the velocity direction).

Thanks,
Erwin

[Erwin Coumans]

Hi Martijn,

Can you confirm that the latest trunk solves your issue?

Thanks,
Erwin
by the way: you can compare with ODE quickstep using this modified demo attached to this issue.

[mreuvers]

I've assigned one of our designers to check the differences in their levels. Btw I still only use

SOLVER_USE_WARMSTARTING

Not any of the newly added defines (SOLVER_USE_1_FRICTION_DIRECTION, SOLVER_ENABLE_FRICTION_DIRECTION_CACHING, SOLVER_ENABLE_VELOCITY_DEPENDENT_FRICTION_DIRECTION)

should the fix also work when only using SOLVER_USE_WARMSTARTING?

Cheers