Forcing body to position/orientation

[Julio Jerez]

Ok JoeJ and PJani, I think I have a quiker way for debugging problematic scenes. in your application you can insert this call.

NewtonSerializeToFile(scene->GetNewton(), "filename.bin");

and it will save the scene, to a binaty file, then you can import that scene in the snadbox demo and see if it works.
then when you see the Bug you can simply send me the saved file and I cna debug that.

it does not save joints yet I will do that later, bu this will clarify if the problems come from joint or from collision or from bad data.
I think this is easier and more secure than sending applications demos using share sites.


you have to sync to later SVN to use teh later serialization.

edit:
in case you sync alreay, do it again there was a bug with compoind serialization and it is fixed now.

[JoeJ]

I tried it out. The Collision bug is not replicable inside sandbox - i thought this will happen.

First i'll go back to use newton as dll to see if it still happens.
Currently i don't use static or dll, i compile it inside my project.

If this does not help, maybe i've done something wrong on updating latest changes.
I'll compare my source against sandbox.

Also i'll try CCD.

I' ll let you know if i find something...

Julio, maybe you should try to debug with my exe, does it work?
I did not change anything the last months, except replacing NewtonCreateDynamicBody, NewtonBodySetMassMatrix___, NewtonBodySetCentreOfMass___
It's still possible that the bug is in newton.


Note: The Serialization did not save orientation correctly.
I have ramp with bodies sliding down to test friction.
But in the saved scene the ramp has no rotation.


Edit: Julio, i saw your pm. i'll remove collada lib and send again.

[Julio Jerez]

I can ot run you exe because the collada dll, if you can make it without that dll it will be gradt.

also the serialize should work, if there is a bug it must be fixed, this make mush eassier to debug problems in general.
I saw that orientaion bug and I forget to fix it. I will do it tonight

The other thing is that, using lib or DLL has more advanatge than just adding the file to a project.
It make it more modular, and easier to refactor, and debug.

anyway if you make the exe agin I will try that. I am sure the bug is in Newton.

[PJani]

Cool that serialization is working again!

JoeJ you were saying you are using Quaternions for limts, how do you limit their rotation? Because i was searching using google but i didn't found anything useful.

[Julio Jerez]

Ok I fixed the oritation matrix bug. now serialization sould be correct.

can you guys try and see if you can reproduce the bug, i like to get that out of the way before continuing.

[JoeJ]

JoeJ you were saying you are using Quaternions for limts, how do you limit their rotation? Because i was searching using google but i didn't found anything useful.

For each body you define constraint space:
matrix cs0 = pody0.world * joint.localMatrix0;
matrix cs1 the same way.

Let's assume that the 'pin vector' is the x-axis of that space.
F. ex. Shoulder is body0, Arm is Body1.
Than cs1.xaxis would point from the joint along the arms length, and rotates with the arm.
cs0.xaxis would point from tho joint to the direction, where the arm is in most relaxed position, and rotates with shoulder.
I hope that's clear.


The limit is done using 2 angular limits.

1. 'Cone' or 'Swing' limit (easy - prevent right arm from moving outside a cone defined by cs0.xaxis and limitangle)
You take the angle between cs0.xaxis and cs1.xaxis.
if it is larger then the cone-limit, you need to costrain using:

fixangle = angle - limitangle;
swingAxis = cs0.xaxis.Cross(cs1.xaxis).Unit(); // maybe you need to swap
NewtonUserJointAddAngularRow (joint, fixangle, swingAxis);
NewtonUserJointSetRowMinimumFriction (joint, 0.0); // important: allow the arm to move inside the cone


2. Twist limit (not so easy - prevent arm from unlimited rotation around it's length):
Take the relative rotation from cs0 to cs1.
See how much rotation is around x axis*
If it is larger than limit, proceed like above, as rotation axis you can use either cs0.xaxis OR cs1.xaxis OR average of them.


I use quats mostly when it comes to rotations just because i'm used to it.
They are not necessary here, but i've read the term 'quaternion twist' often, and i think it refers exactly to point 2.

*) Here a code fregment that computes that with quaternions:

Code: Select all

sQuat q0, q1;
         BodyGetRotation (body0, q0); q0 *= localRot0; // same as 'cs0' in text above, but in quat form
         BodyGetRotation (body1, q1); q1 *= localRot1;

         // factor rotation about x axis: sQuat qt = q0.Inversed() * q1; float halfTwistAngle = atan (qt[0] / qt[3]);
         float twistAngle = 2.0 * atan (
            ( ( ( (q0[3] * q1[0]) + (-q0[0] * q1[3]) ) + (-q0[1] * q1[2]) ) - (-q0[2] * q1[1]) ) /
            ( ( ( (q0[3] * q1[3]) - (-q0[0] * q1[0]) ) - (-q0[1] * q1[1]) ) - (-q0[2] * q1[2]) ) );

// WARNING: i use quaternion form (x,y,z, w) - Julio uses (w, x,y,z) - BodyGetRotation does the conversation for me

sVec3 twistAxis = sVec3(dir0+dir1).Unit(); // use average axis

         if (twistLimitAngleP == twistLimitAngleN) // this joint does NOT allow twisting
         {
            NewtonUserJointAddAngularRow (joint, twistAngle - twistLimitAngleP, (float*)&twistAxis);
         }
         else if (twistAngle > twistLimitAngleP) // ...otherwise i use two limits, joint can twist between those
         {
            NewtonUserJointAddAngularRow (joint, twistAngle - twistLimitAngleP, (float*)&twistAxis);
            NewtonUserJointSetRowMinimumFriction (joint, 0.0f);
         }
         else if (twistAngle < twistLimitAngleN)
         {
            NewtonUserJointAddAngularRow (joint, twistAngle - twistLimitAngleN, (float*)&twistAxis);
            NewtonUserJointSetRowMaximumFriction (joint, 0.0f);
         }


[JoeJ]

Ok I fixed the oritation matrix bug. now serialization sould be correct.

can you guys try and see if you can reproduce the bug, i like to get that out of the way before continuing.

Static orientation fixed now, but still no luck reproducing coll. bug in sandbox.

[Julio Jerez]

Ok now I can run you demo. This is what I am seeing.
I save your scene and load in the sandbox demo, and could no reproduce the bug there.
then I try to do what you say in the PM.
I move the cursor over the capsule, then if I drag it capsule down it penetrate the floor box with almost no effort.

I noticed that when I pick a body is you demo the body is no free to rotate? it is like the body is being moved kinematically, by setting the velocity or the position.
how are you doing the dragging the body? are you using some kind of joint?
can you tell me about that?

[Julio Jerez]

Ok I see you are using a joint to grag the body.

can you tell me how you are you making that joint?
are you using something like the kinatic joint from the joint library?
if you tell hwo you implemted that "grab and drag" joint, I can try implement the same thing in the sand box and see if I can reproduce the bug more eassy.

[JoeJ]

The 'Grab' joint is nearly a kinenatic joint, with the 'Gramm-Schmidt' fix you suggested, see
http://newtondynamics.com/forum/viewtopic.php?f=26&t=7332

But i use also a force / torque method of interaction.
Force calculation is done like in your demo, when i started newton, 2 years ago.

You can set both on and of, like i wrote in readme. Note that also both can be on, taht's default.
Use "handJoint" checkbox to disable the grab joint - the bug still happens.
Use "handPow" checkbox to disable the force / torque method.



By default anything is free to rotate (except the damping you use in kinematic joint).
You can mark "handRot" to manipulate rotation EDIT: setting angles for this seems not possible anymore.
(Rightclick a value, keep butten pressed and move up / down)

Rotations are set either by the kineamatic joint and/or by the 'convert angular velocity to torque' - formula
i teach everyone here. I never set velocity directly.



Note: I see, the bug is MUCH older than we thought! - i did not realize it creeped in.
I'll see when that happened, but that'll need some time...

[Julio Jerez]

In teh demo when I try

iteraction tool methods (not relevant, because both give bug):
force driven, if "handPow" is checked, see "Physics Props"-window, top row right
joint driven, if "handJoint" is checked, see "Physics Props"-window, top row right


when I click handJoint I still see the joit being created, I beleiev I also check handPow and teh joint si created.
Is the joint alway created?
also if you use the foce moev only do the penetation happens?

the code should work in all cases as l;ong as teh joint has reasoble friction limits, I see the you do set limit to 10000 nt, what I can reprduce si testion withpo teh joint acting.
I will add the joing pick body mode tonight to the demo to see if I can reprduce it.

[JoeJ]

when I click handJoint I still see the joit being created

Yes, if it is turned off, i return at the first line in its callback and do not set any rows.
But it is created / deleted on pick up / release body.
I tried to disable it completely now to be sure it is not the joint and the bug still happens!

the code should work in all cases as l;ong as teh joint has reasoble friction limits, I see the you do set limit to 10000 nt, what I can reprduce si testion withpo teh joint acting

I don't use usual world scale, my world is 10 times bigger than recommended, but that never was a problem.
I did that because most physics engines say: "don't create body smaller than 10cm"
But because ragdoll foot is small, i scaled anything up at the price of smaller worlds.
I tried to find a friction value that is small, but large enough to carry any body in the scene.

Good news: The bug did not show up at the point, where i moved from 2.0 to 3.0
I'll look further...

[Julio Jerez]

Good news: The bug did not show up at the point, where i moved from 2.0 to 3.0
I'll look further...

Ha ok now we know for sure that this is a new bug.

to clarify when controlled by force both the external force and the control jopint are there bu teh joint rturen zeor DOF.
I will add some hack to teh code to veryfy that thist is not intruced because the joint is malfunctioning even if it has not DOF.
I have teh feeling it is that. Then I will add the joint pick to the demo.

Are you using the exact solve of the iteratiove solver mode, can you do this test for me.
I have the feeling this bug is related to the exact solver in core 300,
set the solver mode to 1, and see if the bug still happens.
I can no do it now.

[JoeJ]

I will add some hack to teh code to veryfy that thist is not intruced because the joint is malfunctioning even if it has not DOF.

I've allready removed the joint completely, but the bug is still there.
I use iterative Solver with 4 iterations.
I'll do some testing with alternates and CCD next.

I found the last newton sdk without the bug, it seems to be from 22.11.2011.
I'm unsure about dates at those backups i have - can i determinate a revision number or something else to be more specific?


EDIT:

Solver model results:
1: a little easier to provoke the bug than with 4 iter.
0: assert failed because of grab joint: dgWorldDynamicsSimpleSolver Line 222, Expression: row->m_diagDamp >= 0.1
I dont think this has to do with our problem? I removed joint again and the bug is still there, but more easy to provoke.
Its as easy to provoke with force now than with joint and iterative solver.

CCD:
It's not possible to test.
On a limitid scene of only 2 bodies - ground and capsule - i enable it for capsule and get:
Assert failed ...dgBody.cpp Line 274, Expression: 0
When i click retry, i get to dgBroadPhase.cpp Line 967

[JoeJ]

Tried again in Sandbox.
I had luck - for a moment it was possible to drag the capsule inside ground.
That's not so unusual and was always possible with large force for a short time, but this one looked like the bug.

I think you can replicate this way:
Change your grab forde so it acts at body center of mass, not at pick hitpoint.
That's the real difference between our pick stuff!

I hope this helps...