btSequentialImpulseConstraintSolver experiments/improvements

[GoogleCodeExporter]

Please find attached some modifications of the solver and the generic 6dof. 
These modifications are not bugfixes but rather experiments/improvements. 

We are creating an engineering application dealing with human ergonomics thus 
our ragdoll implementation consists of about 80 bones. Because of the long 
chains and relatively big mass differences in this ragdoll the original solver 
implementation did not perform too well when e.g. one of the fingers or the 
head was "picked" with a constraint. That was the reason why we started 
researching possibilities to make it better for our case.

We know that the solution provided is neither nice nor complete and it can not 
be integrated directly but we would have liked to share it with the community 
if someone needs it, or has ideas how it can be further developed.

The modification consists of 5 more or less independent parts:
-SPGS
-NNCG
-JointWarmStart
-SOR
-InitDeltaVelocity

The first three can be turned on and off with these defines: NNCG and SPGS and 
JOINT_WARMSTART.
Also these flags can be used:

btGeneric6DofConstraint::sAllowSPGS (bool)
btSequentialImpulseConstraintSolver::m_AllowNNCG, 
btSequentialImpulseConstraintSolver::m_AllowNNCGContact (bool)
btSequentialImpulseConstraintSolver::m_JointWarmStartFactor (0==off, 
0.2~0.4==on)
btSequentialImpulseConstraintSolver::m_RelaxationFactor (1==off, 1.2~1.4==on)
btSequentialImpulseConstraintSolver::m_InitDeltaVelocity (bool)

SPGS is a special add-on to PGS. Currently only work with the 6dof joints 
without motors, bounce or cfm.
With this all 6dof joints (more specifically there solver joints) can be active 
even if there are gaps between the lower and upper limits. (Current solver 
handles these gaps by deactivating a solver joint if two rigidbodys' distance 
or subtended angle are between these gaps)
This makes a chain much more stiff and also solve a few very bad artifacts when 
the chain is pulled with a relatively big force at one end.
The trick is to calculate two RHS values and switch between them during the 
solving.

NNCG is a very simple implementation of 
Morten Silcowitz-Hansen, Sarah Niebe, Kenny Erleben: A nonsmooth nonlinear 
conjugate gradient method for interactive contact force problems.
It works very well. Practice showed that the spikes mentioned in the document 
is not an issue. At least in our test environment. We are planning to deal with 
it later.
m_AllowNNCG turns it on only for user constraints, m_AllowNNCGContact turns it 
on for all constraints (including contact and friction).
Only one can be used.
Though NNCG can work without SPGS it emphasizes heavily the original problems 
of the PGS those were solved by the SPGS, so it is better to use both or just 
the SPGS.

JointWarmStart is an experiment to use warmstart for non-contact joints. This 
works well if the error is big and the solver can't solve it in one step, but 
not really helpful otherwise. 

With m_RelaxationFactor one can turn on the over relaxation feature. Based on 
our meassures it is always better to use it, but visualy it wasn't trivially 
that good.

InitDeltaVelocity is just an obsolete solution for the problem around the 
handling of the external forces in the math of the original solver.

Authors: Gabor Puhr, Norbert Sarkozi

The patch is provided for rev2613.

Original issue reported on code.google.com by nsark...@gmail.com on 4 Sep 2013 at 10:40

Attachments:

• solver_NNCG_SPGS.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for sharing, this sounds exciting!

The NNCG method uses the projected conjugate gradient, I couldn't find it in 
your patch. Did you implement PCG?

When you apply your patch to a fresh Bullet revision 2613 checkout (no other 
changes) it seems that there is no friction for contacts anymore (check out the 
BasicDemo). Is that a known issue?

Original comment by erwin.coumans on 4 Sep 2013 at 5:00

[GoogleCodeExporter]

Gabor admitted that though he didn't check the full proof and understood the 
Math only in a level to be able to implement it; it seemed to him that the 
solution in the cited documentation based on the simple Projected Gauss Seidel. 
So he used the one already implemented in the Bullet.

You are right the friction didn't work. It was unfortunately a bug. The reason 
why we didn't find it was that the friction in our primary tests are not too 
determinative. For our defense: this happened, because the solverconstraints of 
the frictions weren't initialized to zero similary to the solverconstraints of 
the user joints. :-(
We have fixed it now.
Also we added a little test to the fixed patch to be able to check the benefit 
more easily.
Please check the RagdollDemo. Lift the snake with the mouse and shake it a 
little. By default the NNCG+SPGS are on. You can turn those off with 'e'.
The iterationcount is quite high so Release version is recommended.
Please note that: at one end a cube is loose. This behavior is not lost with 
NNCG+SPGS.
The benefit of SPGS is not that clear here. In our more complex test cases 
without this the system would blow off.

Original comment by nsark...@gmail.com on 5 Sep 2013 at 12:05

Attachments:

• solver_NNCG_SPGS.patch

[GoogleCodeExporter]

Thanks for sharing, I'll check it out. The patch has some conflicts with latest 
trunk, need to look into that.

Original comment by erwin.coumans on 8 Sep 2013 at 5:02

[GoogleCodeExporter]

The btNNCGConstraintSolver is in latest trunk and in the github repo.
If certain things are missing, please report at 
https://github.com/bulletphysics/bullet3

Original comment by erwin.coumans on 30 Mar 2014 at 5:52

• Changed state: Fixed