Newton 3 to Newton 4 migration questions

[JoshKlint]

Yep, this is much faster:

[Julio Jerez]

that's the payoff of making a Lock and atomic free solver.
you have to scarify some flexibility. but the rewards are well worthy.

that Amdahl law is not a joke the moment there are more than one core in the system.
https://en.wikipedia.org/wiki/Amdahl%27s_law
and newton 3.xx suffered a lot from it.

the engine, in theory, now scales almost lineal with hardware threads.
but that is not a practical truth, because as the threads count increases, them memory bandwidth
start becoming the bottleneck.
however, at least with the new CPUs with lots more cache, that problem is also mitigated.

also, another good news is that, it seems at first that you have to give up few things for the benefit of others,
but the reality is that as the engine start to the form.
the things you have to give up, subtly because possible in a different way, sometime in an even better way.

one case is the CCD, you were talking about before.
next year I will be added, I just do not have the time to do it know.

plus using more than one sub step goes a long way to solve that problem.

glad you get a your start now.

edit:
ah, and another thing out of a lock free solver.
the AVX2 solver for the first time we can see it significantly faster that all others.
give it a try, It is supported by practically 100% of the PC ecosystem out there.

[JoshKlint]

I am getting a lot of crashes in ndWorld::AddBody > inline ndVector Floor(), when the body uses a ndShapeStatic_bvh shape. It looks like this assert is failing:

Code: Select all

ndAssert (ret.m_f[0] == ndFloor(m_f[0]));

Here is the vertex data for the first mesh that crashes:

Code: Select all

-0.363887, -3.55271e-15, -0.630272
-0.363887, 0.273553, -0.630272
-0.727775, 2.11758e-22, 3.79982e-08
-0.727775, 0.273553, 3.79982e-08
-0.363887, 3.55271e-15, 0.630272
-0.363887, 0.273553, 0.630272
0.363887, 3.55271e-15, 0.630272
0.363887, 0.273553, 0.630272
0.727775, -4.23516e-22, -7.59964e-08
0.727775, 0.273553, -7.59964e-08
0.363887, -3.55271e-15, -0.630272
0.363887, 0.273553, -0.630272

This is the ndVector that fails:

Untitled.jpg (240.8 KiB) Viewed 9795 times

[JoshKlint]

Unrelated to the issue above, I think the tolerance in the TestOrthogonal() method here should be higher:

Code: Select all

void ndJointBilateralConstraint::CalculateLocalMatrix(const ndMatrix& globalMatrix, ndMatrix& localMatrix0, ndMatrix& localMatrix1) const
{
   ndAssert(globalMatrix.TestOrthogonal());
   localMatrix0 = globalMatrix * m_body0->GetMatrix().Inverse();
   localMatrix1 = globalMatrix * m_body1->GetMatrix().Inverse();
}

The dot products of my matrices are all at least 0.97 but the test is failing because the tolerance is 1.0e-4f.

[JoshKlint]

How do we associate our own object with an ndBody? There does not seem to be a SetUserData() method? What should be used instead?

[Julio Jerez]

The body has a ndNotify,
You subclass it and add where ever element you want.
The You can just get the notify object from a body.

Or you get the oveiaded notify callback.

On the assert, you have point that are on the order of 1e-15
And 1e-22

Those values can't be rounded but a simd instruction.
And that a good thing, because front ther that kind of object will have an almost infinite length as far as 32 int operation are concert.

A matrix with non orthogonal axis, or with non unit length axis is the problem, not the test function.

If those matrices come from a modeling package, what I
Think is that the have a build in scale.

You can just decompose it into the product of theree values.

Shape axis, scale, and the orthogonal matrix.

You can check the fbx loader in the sdk, it had thos kind of conversion to extract scale from matrices.

[JoshKlint]

The matrix comes from my own calculation that creates a 4x4 matrix from a single vector. I don't see anything wrong with it:

Code: Select all

void Mat4::MakeDir(const Vec3& dir, const int axis)
   {
      Vec3 ii, jj, kk;
      switch (axis)
      {
      case 0:
         ii = dir.Normalize();
         jj = Vec3(0, 1, 0);
         if (Abs(jj.Dot(ii)) > 0.5) jj = Vec3(0, 0, 1);
         kk = ii.Cross(jj);
         jj = -ii.Cross(kk);
         break;
      case 1:
         jj = dir.Normalize();
         ii = Vec3(1, 0, 0);
         if (Abs(jj.Dot(ii)) > 0.5) ii = Vec3(0, 0, 1);
         kk = jj.Cross(ii);
         ii = -jj.Cross(kk);
         break;
      case 2:
         kk = dir.Normalize();
         ii = Vec3(1, 0, 0);
         if (Abs(kk.Dot(ii)) > 0.5) ii = Vec3(0, 1, 0);
         jj = kk.Cross(ii);
         ii = -kk.Cross(jj);
         break;
      }
      i.x = ii.x; i.y = ii.y; i.z = ii.z;
      j.x = jj.x; j.y = jj.y; j.z = jj.z;
      k.x = kk.x; k.y = kk.y; k.z = kk.z;
   }

[JoshKlint]

On the assert, you have point that are on the order of 1e-15
And 1e-22

Those values can't be rounded but a simd instruction.
And that a good thing, because front ther that kind of object will have an almost infinite length as far as 32 int operation are concert.

Okay, but what should be done about it? How to fix this?

[Julio Jerez]

The construction of the matrix is not normalizing the vertor perpendicular to the plane. Try adding that like below and to all the other cases.

case 0:
ii = dir.Normalize();
jj = Vec3(0, 1, 0);
if (Abs(jj.Dot(ii)) > 0.5) jj = Vec3(0, 0, 1);
kk = ii.Cross(jj);
Kk = kk.normalize()

jj = -ii.Cross(kk);
break;
case 1:

On the assert on floor, I was wrong,
A value with an exponent of e to a negative power should be between -1 and zero.

The assert is telling you that some how the rounding failed, which I have not idea why, since it is using a standard library function.
The data you produced in no way will cause the floor to fail.

[JoshKlint]

The construction of the matrix is not normalizing the vertor perpendicular to the plane.

That works. I always assumed the cross product of two normallized vectors would also be normalized, but I guess not.

What is the reference body for the kinematic controller? Why is it needed? Newton 3 only needs one body to create a kinematic joint.

[Julio Jerez]

Well. Yes that's part of the baby sister cauching newton 4 is not longer doing.

Joints need two bodies as parameter, you can use any two bodies for that joint. I believe you are referring to the sentinel body.

The sentinel body is an implicit static body, that is part of the world but not part of the scene and it is used for those cases.

In previous versions of the engine there was lot of hidden logic to deal with that, but in some cases it just create problem.
Now the sentinel is exposed to the app, and you can use it or not as a component of a joint.

[JoeJ]

I always assumed the cross product of two normallized vectors would also be normalized, but I guess not.

Wow. You're really, really late with figuring this out.

[JoshKlint]

It appears that ndJointKinematicController rotation does not work? The joint is either slack or locked into the current rotation with no change, depending on the max angular friction value. Linear friction works as expected.

[JoshKlint]

Is there some functionality that is equivalent to the old NewtonWorldForEachBodyInAABBDo() command? I see an ndWorld::BodiesInAabb() method, but I don't see a parameter to define an AABB?

[Julio Jerez]

ah, yes.
Sync, they are in now.

on the ndJointKinematicController joint, you set m_full6dof

notice that when m_full6dof is on, this is quite different than mode m_linearPlusAngularFriction
m_linearPlusAngularFriction is a special mode for picking object from the screen, it is meant to act as dry friction so friction is a coeficient, and target omega is high. this joint calculates an adaptive friction so that it can pick objects with a wide range of mass and inertia.

when using m_full6dof, target omega should be a reasonably value, in a range from 1 to 15 rad per seconds or so.
Friction is a fix max torque which should be relatively high, it will act different depend on the mass of the target body, the engine does not try to secund guess anything, what you pass is what you get.
this is how linear constraint act, so should not be a surprise,