Bullet 2.62 BasicDemo and restitution?

[rrg]

I simplified the Bullet 2.62 BasicDemo so that there was a single dynamic collision object falling onto the ground plane, and tried altering the restitution value of the dynamic object. It seems that no matter what I pass to setRestitution(), I am unable to prevent the dynamic object from bouncing once it impacts the ground. I've tried altering the size and shape dynamic object as well, but have found no dependable solution. For example, if I switch the dynamic object from a sphere to a capsule shape, it seems less prone to bouncing on impact, although bounce can still occur. Is there a solution for Bullet 2.62? I've seen a forum post indiciating that restitution will be patched in 2.64. Thanks in advance!

[Erwin Coumans]

Is there a solution for Bullet 2.62? I've seen a forum post indiciating that restitution will be patched in 2.64. Thanks in advance!

It was already fixed in Bullet 2.63, but I recommend upgrading to 2.64, which was just released.

You can try to enable an older solver mode, which will enable restitution in 2.62, but I recommend to upgrade to 2.64.

Code: Select all

solver->setSolverMode(btSequentialImpulseConstraintSolver::SOLVER_USE_WARMSTARTING | btSequentialImpulseConstraintSolver::SOLVER_RANDMIZE_ORDER);

Thanks,
Erwin

[melax]

Erwin are you sure that this problem as described is fixed? Technically it isn't an error in the restitution.

Going back to 2.6.2 ... From what I see in the 2.6.2 code is that the restitution works fine. I took appbasicdemo and did 1 sphere dropping onto a static cube. Putting a breakpoint in the code for resolveSingleCollisionCombinedCacheFriendly() in module btsequentialimpulseconstraintsolver.cpp, it appears that penetration has occurred but has been detected by the system so it must fix the situation. So the physics engine give an impulse (velocityImpulse) to the sphere to reduce its velocity to zero (which is correct assuming no bounce) but it also gives an impulse to fix the penetration (penetrationImpulse). The velocity you see would be the result of this additional impulse. I didn't see bullet try to remove the effect this extra impulse has on velocity after the positions are updated. But I could have easily missed something.

To test my theory on your computer try positioning the sphere at slightly different heights and see if the amount of bounce changes. I suspect that where it hapens to be when it hits the ground has more to do with the amount of bounce than the shape (sphere vs capsule).

I just downloaded and tried 2.6.4 and Im not sure if this has been fixed. I seem to still get the bounce. I could have missed something.

the forum wont let me attach a .cpp file. I took app basic demo and just started just a single sphere from a higher position and waited a few seconds after the program started until it finally fell and hit the box.

What about Erin Catto's suggestion of after doing the solver phase and getting the velocities that will be used to update the positions, you then go back into the solver but ignore penetration and iterate a few more times to see what velocity you really want to have:

1 solver
2 store velocity
3 set penetration error to zero
4 solver (ignoring penetration)
5 store this velocity too
6 update rigidbody positions using the first velocity
7 set rigidbody velocity to the second velocity.

[Dirk Gregorius]

Stan,

why are you storing all these velocities? Basically you just do:

1) Update velocities
2) Correct velocities (no stabilization, e.g. no penetration recovery bias)
3) Update positions using corrected velcities
4) Correct positions

The last step is difficult though. First you are solving a non-linear system (since position constraints are non-linear while velocity constraints are usually linear). Second, since you are altering the positions now your Jacobian is not constant over the iteration. Wich leaves you basically three options:

1) You use you initial Jacobian (the one you used alread for the velocity correction)
2) You update your Jacobian once after the position update
3) You update the Jacobian for every constraint in every iteration (this is basically Jacobsen)


First one is relatively fast, but seems to give problems with high angular velocities (seems somewhat plausible since it is linearization like Baumgarte and suffers from similar problems). The second seems to work well and appears to be a nice balance between speed and accuracy. The later gives you very good quality, but is quite expensive...


Cheers,
-Dirk

[melax]

Indeed.

I guess I was trying to suggest an implementation that is essentially the same as pseudo velocities, since it looks like the observation made in this thread's initial post is simply an artifact of any basic Baumgarte implementation.

I do agree that its much better to approach it as the 4 steps you describe, especially since it allows for options in dealing with position error. After playing with the demo Erin posted I'm really impressed with the Nonlinear Gauss-Seidel (NGS). It really hit home because the scene with the hanging chain is one that I've had to face before. Its so nice seeing a working solution to that case - other than just using a smaller physics timestep.

[Erwin Coumans]

ok, I assumed the posting was about the broken restitution in Bullet 2.62 (restitution was always zero). However, reading it again, it might be refering to added momentum due to penetration correction (Baumgarte). I'm familiar with several methods to reduce/fix this, so I'll put it on the todo.

Thanks for clarifying this, Stan.
Erwin