Refactoring joints

[JoeJ]

Works quite well.
July version still feels more stable but that's only because it has weak pick force

I suggest you add this as a new demo and rename it to Joes Test or something.
You could then delete my joints from Standard Joints.

See the defines on the top of the files and run those cases. Only the last might show a problem eventually.

https://gist.github.com/JoeJGit/7e269bdee6994c34b54011918f69b8cd

(To make a proper pull request i think i would need to delete my July version, update, make request... using the gist seems easier.)

[Julio Jerez]

Ok Joe, I am now going for top to bottom testing all demos and fix the low lever as needed.
now I got to the Gyor demo whi I used before to test the derivative.
I commited the demo with only one flywheel, and you can hwo is fail when spinning a high speed.

if you get the there the same demo with the code that was commited on the 28 or before, you will see that the right way of to have those derivative, we can not go with tweaking the wrong top make it right, is better to tweak the right to make it wrong

so whe I will do is add the derivatives by this time I will be careful and place and if def so that if can be compared without reverting the sdk so far back.

anyway I will continue writing the derivative because we must have it working for all cases.

[Julio Jerez]

Ok the second equation the the one we all know which f = m * a. But this equation is also derived from the linear momentum like the torque. This is

p = m * v

And the derivative is

p' = m * v' + m' * v

in Newton we make the assumption that mass is constant so the derivative is zero. And we get

p' = m * v' = m * a

and Newton second law of motion say that the derivative of the momentum respect to time is equal to the external forces acting on the body.

So we start with the two basic equation of motion of a free body.

1- M * A = F
2- I * B = T - W x (I * W)

I am using B to represent angular velocity,
And upper case to sign this are vectors and matrices.

Ok at this point we only have the equation of motion of a free body, next we will used Langragian mutiplyer to constrain the motion by adding some external force and torque generated by the constraint.

[Julio Jerez]

Ok I now consolidated the version that was commuted on December 31 with the current version.

I compared the two and they seem to behave more or less the same.

In your demo you can detach the two part if you pull and wiggled it, but this is not different than how it was before, or I think is not, but I can't tell since I am bias.

Anyway if you have time maybe you can check it out and tell me if this is ok.

Later I will write the second part of the equation so that we know what assumption I made to fix the errors.

I believe that my asumption was totally wrong, but not the derivative.
Also you said you found a problem with the joint, so if you fix it, can you check that, as well?

[JoeJ]

Ok I now consolidated the version that was commuted on December 31 with the current version.

I compared the two and the seem to behave more or less the same.

In your demo you can detach the two part if you pull and wiggled it, but this is not different than how it was before, or I think is not, but I can't tell seems I am bias.

I tried it too and it is fine
The wiggling on pulling is ok. Problem was only that the joint bounced of the limit cone.
(older Newton version from July had no wiggling only because of its weak pick force)

Also you said you found a problem with the joint, so if you fix it, can you check that, as well?

Not sure what you mean but don't forget to add the new version from here: https://gist.github.com/JoeJGit/7e269bdee6994c34b54011918f69b8cd
(I don't know how to make a github request to add a new file)

There i've added motor on the limit rows and the snake tower with procedural animation seems to work as well as with the older ragdoll motor (but you need to enable this using a define on top of the file).
So i'm optimistic twist / swing will do for inverse dynamics.

The joint is not completely polished. It still happens twist and swing axis are not completely orthogonal. I've fixed this by a projection and this works fine, but i do not understand yet why this happens. (Maybe it can happen only when the arc limit is used but not with a simple cone limit)

[Julio Jerez]

Oh now I see, I could not see any pull request, because you put it in your own GitHub.
Ok I will take that file and added as a separate demo to the sandbox.
In the mean time going over the equation I now see my mistakes,

I am trying a different method to implement limits. but this time will be more on the user side than on ether low lever. I see now that solution fix all is quite impossible without an avalanche of function interfaces, and we already have to many of those.

I am tryin this with the slider joint which is the simpler of all. and I committed the first test.
Is no fully complete yet but seem good so far.
if you have time please can you check it out.

is does a dead stop, but is not and the example limits, for that I need a clip function, and will do that later tonight. but all in all this seem quite good.

Please if you have time check it out.

[Julio Jerez]

al right I added the clip function and now is stop dead at the limit with zero over shorting.
this has to be the model for all joint limits, I think.

[JoeJ]

Yes that's very nice.

Is NewtonUserJointCalculateRowZeroAccelaration just a utility or does it some magic that would be impossible to achieve without it?

[Julio Jerez]

oh is was a simple change, the value is calculate for each row.
but is us to try to resolve penetration. and that's a big mistake.

Code: Select all

//desc.m_zeroRowAcceleration[index] = (relPosit * desc.m_invTimestep + relVeloc) * desc.m_invTimestep;
desc.m_zeroRowAcceleration[index] = relVeloc * desc.m_invTimestep;

I change to only calculate the acceleration needed to stop the joint, disregarding the distance.
the is the responasobility of teh joint to do the distance is it desired too.

Thsi permit more flexibility.
1-It is not knows is the error is a constraint violation, so in most case that produce a huge acceleration,
2-even if the error is a constriction violation, is margin the penetration acceleration and teh velocity make difficult to use the value and no matte what tweak is use.

now the joint always knwo that the value is the acceleration that will stop teh joint dead. and can use that as start point to do calculations.

this allown for the joint to extrapolate the contact point a ray case.
basically is say base of teh velocity of the joint point, what fraction of the time step can the joint travel to hit the contact, and if the fraction is smaller that the time step, then
the joint can calculate a velocity that will move the joint to the stop.

teh thsi acceleration is added to the zeroAcceleration. and teh joint will move to a point that is, ideally the stop, in reality very close, but subsequence frame the same condition apply but that the velocity is close to stop.

yes you can do it the joint, it is just the difference between the velocity at teh contact points divided by the time step.
teh reason is in the SDK is because this calculation is different for angular and linear of other kind of joints. where in the SDK is just the position time the Jacobean.
I will apply the same to spring damper to complete that joint and use that as the model to build the others.

[JoeJ]

Ha, this is awesome I tried it with the picking joint i talked in the VR thread and it works pretty good now. You should add this to the kinematic joint sometime.

[Julio Jerez]

It will be added to all joints where apply.
I will go this weekend revisiting the one by one.
the could past is that it almost eliminate the over shorting that come for using the position error.
can you list the place where you added so that I can past that on the kinematic in the SDK?

[Julio Jerez]

Ok I now completed all option for the slider.I nwo has firction for more relsitic behavior,
and the spring damper nwo har veruy oadr and acurate limits.

That was a problem that I always has we springs damper joints, whips the spring made the limits soft. now because eth joint can anticipate if is going to hit a limit, is can simple switch to hard limit, and us the calculation for implicit spring damper acceleration, and this will work because the acceleration has tree components:

1- the zero stop which set a reference point from which start calculation.
2- the desired velocity to reach the limit
3- the spring only acceleration because we know the velocity will be zero.

These at the things I was talking about that will result in too made function for parameter to have a joint functionality.
The result is a very robust joint.

The disk jitter a lithe at the limit if you pull hard, but that's normal that not a jitter bug, that's the spring reaction when the velocity becomees zero, sicne te spring is quiet stiff and the pulling force is quite strong.
Next I will do the Hinge and move on from there.

Hinge and Sliders are the joint that have more features, once those are rubust and stable the progress goes faster.

[JoeJ]

can you list the place where you added so that I can past that on the kinematic in the SDK?

My joint is too different now from yours.
The idea is that the user sets a constant acceleration value. Then if we put the target at a large distance to the body, the body accelerates for half the distance, and then deaccelerates for the other half so it stops at the target.
When time to target becomes less than 3 timesteps i start to blend with like you did in the slider joint to get a nice stop. Previously this did not work well because of discrete timesteps.

I think this is very useful especially for people that are not that involved into physics, because it generates very natural motion and controlling bodies becomes even easier than with your kinematic joint. E.g. to make a body following a path defined by n control points, you just set the target position to the first and after getting close to the second etc. No need to calculate tangents, splines or any other interpolation, the body will have a nice trajectory, even if you change target positions at any moment.

It works by calculating one trajectory from current body state and a second trajectory with from target position (and velocity). At the time when both trajectories intersect with equal position and velocity is the moment where accelerating / deaccelerating has to be switched.
So the idea is simple and probably it's used a lot for real life problems but i don't know a name for it.
(I also use it to control the inverted pendulum, just that acceleration here becomes position dependent and is no longer constant.)

I may show you sometime if it turns out as useful as i think...

Edit: Reading your post above, maybe we talk about very similar things already

[Julio Jerez]

Hey Joe I now completed the one dof joints, hinge and slider.
I will now do the two dof (universal, sliding contact, cork screw)

but first I will revisit the integration.

if you sync and you run the test, I added another Gyro demo, that if I did not see this video I would said is was a bug:


you can see that the normal Euler integration manage to reproduce it, but the integration is no really very good because is added too much numerical error.

a while back I replaced the integration with the a predictor corrector, which is very good
and should maintain the energy and angular momentum constant but, but this integrator loses too much energy by smoothing the derivative to much.

I does in fact preserve both energy and momentum but is does at the expense of aligning the body to the major angular momentum vector.
I will revisit the integrator maybe I made a mistake, if not, I may maybe replace it with RK4

but the effect is really cool, I will make a side by side video when I have ready.

[JoeJ]

I know this video, or a similar one in a space station.
Interestingly all this stuff - also the flywheels - looks totally logical to me and i expect this behavior
But i still have problems believing that hitting a pencil at its center causes the same linear velocity than hitting it on its end