Real-Time Physics Simulation Forum

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-23T09:29:18+00:00

Hi,

I tried and it seems it works well now.

Thanks
Gabor

Statistics: Posted by Gabor Puhr — Fri Aug 23, 2013 9:29 am

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-21T23:08:54+00:00

It should be fixed by now, I introduced this bug a while ago.

Can you try latest SVN trunk?
http://code.google.com/p/bullet/source/detail?r=2645

Thanks for the report!
Erwin

Statistics: Posted by Erwin Coumans — Wed Aug 21, 2013 11:08 pm

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-21T15:27:00+00:00

Hi,

Something like this?:

btRigidBody* rbs[6];
for(int i=0;i<6;++i)
{
btCollisionShape* shape = new btBoxShape(btVector3(btScalar(0.1),btScalar(0.1),btScalar(0.1)));
btTransform transform;
transform.setIdentity();
transform.setOrigin(btVector3(-1-i*0.2,3,0));
rbs = localCreateRigidBody(i ? 1 : 0,transform,shape);
}

for(int i=0;i<5;++i)
{
btTransform localA,localB;
localA.setIdentity(); localB.setIdentity();
localA.setOrigin(btVector3(btScalar(-0.1), btScalar(0), btScalar(0.)));
localB.setOrigin(btVector3(btScalar(0.1), btScalar(0), btScalar(0.)));
btHingeConstraint* con = new btHingeConstraint(*rbs,*rbs[i+1], localA, localB);

const float d = 1.2;
if(i==0) con->enableAngularMotor(true,4.8f /d,100000000);
if(i==1) con->enableAngularMotor(true,0.1f /d,100000000);
if(i==2) con->enableAngularMotor(true,3.0f /d,100000000);
if(i==3) con->enableAngularMotor(true,1.9f /d,100000000);
if(i==4) con->enableAngularMotor(true,0.05f/d,100000000);

m_dynamicsWorld->addConstraint(con, true);
}

With this I couldn't see any differences between the two versions.

Is this the case that you described?

Best Regards
Gabor

Statistics: Posted by Gabor Puhr — Wed Aug 21, 2013 3:27 pm

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-18T07:24:30+00:00

Hi,
Would you be so kind to describe me a simple case when it fails so I can test that?

Make six bodies and connect them by six hinge joints. Enable motors on those hinges but make the motor weaker than what it needs to be to keep the hinge up (i.e. if it needs 2 units to stay still, put only 1.5, then 1.0, etc until it falls). The system just fails to include gravity into calculations (just like the current system messes with joint strength and can cause joints to fall out of place)

Statistics: Posted by Basroil — Sun Aug 18, 2013 7:24 am

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-09T09:19:20+00:00

Hi,

Though you are right that I made several (successful) changes in the solver to make it more stable, I tested this particular change also with the original solver.
I couldn't see any problem with the factory Ragdoll demo regarding the gravity.
In the other hand when I changed the picking constraint to simple force pull the new version became much better, as with the old you can tear down the hand of the demo ragdoll independently how much iteration you set for the solver.

With my extended solver I can handle a ragdoll with 84 joints without problem and this change solve the same problem there that arise when I pull it with force.
Also my ragdoll became calm much faster when lying on to floor.

Would you be so kind to describe me a simple case when it fails so I can test that?

Thanks
Gabor

Statistics: Posted by Gabor Puhr — Fri Aug 09, 2013 9:19 am

Re: Why use m_linearVelocity in solveGroupCacheFriendlySetup

2013-08-08T04:13:56+00:00

Well, for one, gravity no longer has the proper effect on joint chains

I can't seem to get it to work properly with anything but the simplest of setups, perhaps you've made changes to the joint solvers?

Statistics: Posted by Basroil — Thu Aug 08, 2013 4:13 am

Why use m_linearVelocity in solveGroupCacheFriendlySetup?

2013-07-31T10:58:03+00:00

Hi,

Based on Erin Catto: Iterative Dynamics with Temporal Coherence, in btSequentialImpulseConstraintSolver::solveGroupCacheFriendlySetup
this:

solverBody.m_linearVelocity += body->getTotalForce()*body->getInvMass()*infoGlobal.m_timeStep;
solverBody.m_angularVelocity += (body->getTotalTorque()-gyroForce)*body->getInvInertiaTensorWorld()*infoGlobal.m_timeStep;

should be this:

solverBody.m_deltaLinearVelocity += body->getTotalForce()*body->getInvMass()*infoGlobal.m_timeStep;
solverBody.m_deltaAngularVelocity += (body->getTotalTorque()-gyroForce)*body->getInvInertiaTensorWorld()*infoGlobal.m_timeStep;

I made a quick test and the latter was much better. (both the visual and the aggregated error at the end of the frame)
Is it a typo or you could find a few cases where the original was more stable?

Thanks
Gabor

Statistics: Posted by Gabor Puhr — Wed Jul 31, 2013 10:58 am