Enabling SOLVER_RANDMIZE_ORDER results in unstable sliding/friction.

[kermado]

The history of this is summarised in a forum post. I am logging this here because I believe that there is a bug in the random constraint ordering.

The friction constraints are randomly shuffled so that the friction constraints for a given contact point do not correspond to the ordering of the penetration constraints. To clarify, if I swap two penetration constraints for a pair of contact points then I expect to also swap the friction constraints for the pair of contact points. However, this is not the case. Currently, the penetration constraints are randomly shuffled. Then the friction constraints are randomly shuffled.

My solution is to use the same swap operations for the friction constraints as for the penetration constraints:

int swapi = btRandInt2(j + 1);

{
	int tmp = m_orderTmpConstraintPool[j];
	m_orderTmpConstraintPool[j] = m_orderTmpConstraintPool[swapi];
	m_orderTmpConstraintPool[swapi] = tmp;
}

if (infoGlobal.m_solverMode & SOLVER_USE_2_FRICTION_DIRECTIONS)
{
	int tmp1 = m_orderFrictionConstraintPool[j * 2];
	int tmp2 = m_orderFrictionConstraintPool[j * 2 + 1];

	m_orderFrictionConstraintPool[j * 2] = m_orderFrictionConstraintPool[swapi * 2];
	m_orderFrictionConstraintPool[swapi * 2] = tmp1;

	m_orderFrictionConstraintPool[j * 2 + 1] = m_orderFrictionConstraintPool[swapi * 2 + 1];
	m_orderFrictionConstraintPool[swapi * 2 + 1] = tmp2;
}
else
{
	int tmp = m_orderFrictionConstraintPool[j];
	m_orderFrictionConstraintPool[j] = m_orderFrictionConstraintPool[swapi];
	m_orderFrictionConstraintPool[j] = tmp;
}

This yields significantly better sliding behaviour whilst also retaining the improved stack stability.

[erwincoumans]

Thanks for the contribution! I have a few other things first, but I will look at it.