Newton 4 Question: Material Properties (COF, COR)

[Bill]

Hello,

I've just started playing around with Newton 4 and I'm struggling to understand how to set up the materials/properties for pairs of materials.

In Newton 3.x, I would do something like the following:

Code: Select all

// Create the floor
NewtonBody* theFloorBody = createFloorBody();
int floorMaterial =  NewtonMaterialCreateGroupID(world);
NewtonBodySetMaterialGroupID(theFloorBody, floorMaterial);

// Create a sphere
NewtonBody* theSphereBody = createSphereBody();
int sphereMaterial =  NewtonMaterialCreateGroupID(world);
NewtonBodySetMaterialGroupID(theSphereBody , sphereMaterial);

// Set properties for floor/sphere contact
NewtonMaterialSetDefaultElasticity(world, floorMaterial, sphereMaterial, 0.8);
NewtonMaterialSetDefaultFriction(world, floorMaterial, sphereMaterial, 0.25, 0.20);


Is there a similarly simple way to do this in Newton 4? I can't seem to figure it out!

Thanks for whatever help you can provide.

[Julio Jerez]

for newton 4.00 we remove the material graph and replaced with each collision shape having a material record.
the material graph is more correct but is start to get limited because it was based of bodies not of shapes, and trying to make it based on shape add too much complexity that most people never really used.
instead, we moved that functionality to the end application.

there is a demo in the sandbox that implements the same functionality of 3.xx you can see in file
...\newton-4.00\applications\ndSandbox\ndContactCallback.h

it uses a map to store shapes material pair. Here the app can use whatever it wants and is far more flexible.

you can use as it or as a template to make your own version. then you register an instance with your version of the world. like in file ..\newton-4.00\applications\ndSandbox\ndPhysicsWorld.cpp

then you just register the pairs as you like, look at example
..\newton-4.00\applications\ndSandbox\demos\ndBasicFrictionRamp.cpp

it registers a pair but the pair has many different friction coefficients, even if they are the same materialpair,
this is much harder in 3.x than it is now with a more flexible end app system

[Bill]

Thank you for the information. I think I somewhat understand, but can you please verify if these are the basic steps?

1) Create my own class that inherits from ndContactNotify. Let's say that the class I make for this is called MyAppNewtonContactNotify, for example.

2) Implement my own RegisterMaterial and GetMaterial methods in MyAppNewtonContactNotify, basically by copying the code in the example you provided (ndContactCallback.h). This is what will allow me to have a somewhat similar system as what was available in Newton 3.xx for specifying properties by material pairs.

3) Tell my ndWorld about all of this by calling the following after I create the world:

Code: Select all

world->SetContactNotify(new MyAppNewtonContactNotify);

4) Register each material pair (and then set its friction values, restitution value, etc.) like the following:

Code: Select all

ndContactCallback* const callback = (ndContactCallback*)world->GetContactNotify();
int sphereMaterial = 0; // Make each material number a unique integer
int floorMaterial = 1; // Make each material number a unique integer
ndMaterial& material = callback->RegisterMaterial(sphereMaterial, floorMaterial);
material.m_staticFriction0 = 0.25;
material.m_staticFriction1 = 0.25;
material.m_dynamicFriction0 = 0.2;
material.m_dynamicFriction1 = 0.2;
material.m_restitution = 0.8;

(...and then repeat the above for each material pair.)

Does this sound approximately correct, or have I completely misunderstood?

Thanks a lot for your help!

[Julio Jerez]

yes.
you got it, far better than I explained.

edit:
please do not forget to sync, I finally found that moronic bug that was hunting me for month.
at theis point the only solver ready is the default, but the others will be activated soon.

[Julio Jerez]

if you read this, please sync again, I added the avx2 solver that was disabled, and it really makes a huge difference.
this is very, very close to the first stable release for this year.

[Bill]

Okay, thanks for the heads-up. It'll probably be after the holidays when I get back to working on this, but I'll be sure to update the library with the latest from the repository first.

Quick question related to the material properties: why are there two staticFriction and two dynamicFriction properties, instead of just one for each?

Code: Select all

material.m_staticFriction0
material.m_staticFriction1
material.m_dynamicFriction0
material.m_dynamicFriction1

[Julio Jerez]

Ha nice, by that time you will be able to just get the stable release.

On the material, you are correct, it should just be one.
But this is the point where the implementation and the theory start to diverge.
The implementation has to deal with discrete time steps, tolerance, numerical errors, incomplete approximate solutions, the non elastic nature of rigid simulation and so on.

Imagine using only on contact direction.
There are two cases. Static fraction and kinetic friction.

For static friction, the direction of the acceleration is unknown, at the time of the contacts calculation.
It is possible to incorporate the contact direction as a least square optimization that select the direction a maximum acceleation from an array of predefined directions.
Some advanced physic solvers use an octagon or some other regulat polygon around the contact point and select among those directions, of the vertices, but that makes the solver n time more expensive as it now has one normal and n/2 posible directions.
So these solvers can only be used for small number of contacts.

For kinetic friction, the direction is determined by the direction of the tangent velocity at the contact point. So in theory there should be only one direction.

But as I said, the details run into the edge cases. When the speed of a moving body is on verge that is going form kinetic to static, it does not happens at the time step, it usually happen in between, specially whe there are multiple colliding bodies.
So having one direction causes the body jitter and change direction so slightly.
You probably seen those problem with some engines.

What I do is similar to the least square approximation, but I only use two perpendicular directions,
The for kinetic friction one direction is align to the contact tangent speed, for max friction, the other is perpendicular, and at low speed that perpendicular pick up the slack on the deviation.

For static friction, I use the contact acceleration direction from a previous frame to determine the alignment, this is not as good as selecting one from a set, but since I allow for both directions what we get is one direction producing the large friction, while the other is most the time almost zero, and non zero when the actual contact acceleration is very different from the previous.

[Bill]

Very interesting! The implementation side sounds a lot more complicated than what is taught in basic physics classes.

So, as a user of the library, should I just always set the two static friction values equal to each other, as well as the two kinetic friction values equal to each other?

[Julio Jerez]

that's because is classes they are supposed to teach the theory not that implementation.
believe me you are better off knowing the theory.
if you did not know it, you wouldn't be curious as to why there are two friction values in this implementation.

So, as a user of the library, should I just always set the two static friction values equal to each other, as well as the two kinetic friction values equal to each other?

yes, for most cases you set both directions to the same values.

notices that using the two directions is not incorrect, the reason is that friction values are vectors, and any vector can be decompose into mutually perpendicular component.

and like I said before, since we align the one of the two direction to either the contact tangent velocity or the tangent acceleration, si that the other direction in general is a friction value near zero, with the exception when the values changes during the intermediate calculation of the faction magnitude. In which case the small one is non zero.

there is also another benefit of having two independent contact direction, this is for nonelastic materials, which can have different frictions in different directions, the best example is a car tire.

the Brush time model, explicitly uses different friction curves for longitudinal and lateral friction.

finally, now that you mention it, in the future we can consider one optimization like for example
just use one direction when the magnitude of the contact speed, is strong enough that is unlikely to change, this could be a substantial performance gain in memory and speed, since is reduces a contact from three to two rows. that's very attractive to just pass it off.
so I put it in the back burner.

[Julio Jerez]

alright, I now made the very first stable release. which will be the base line for all versions.
this way I can keep adding functionality and we have that fall back.

It has double and single precision.
one curious thing that I noticed, is that for the first time in more than 30 years programing for x86
I see a significant difference between double and single precision.

on paper single precision should be literally twice as fast double, for the single reason that offer tice the throughput of floatps. However, this is just a theorical limit.
when adding the memory bandwidth, branching, and atomic operation in the case of multicore code, these issues dominate the code and the performance.
It takes a real effort to get close to that theoretical limit.

this is one for the reason that you see libraries like Linpack, gal, Mathematica, also professional videos games made but stablished developers, or libraries made by hardware maker like AMD, Intel Nvidia, Apple, and others.
they use tricks that on the surface you see it and do not make sense, but that translate to huge differences in performance.

take for example this code.

Code: Select all

template <class T> inline T dMax(T A, T B)
{
   return (A > B) ? A : B;
}


you would expect that a compiler will use a conditional move. but you will be very wrong, for some reason many compilers will issue a compare test, and the claim seem to be that conditional move are slower. than the compare, test a jump.

In my experience, this is simply not true, but the is nothing than can be done, is we are going to use that function let it be the standard one or a use defined one.
I have seemed case with compiler like Clang that is you use std::max it will issue the conditional move, but if you issue your own code, it will not. That blow my mind for a long time and I thought it was a mistake I made, but after testing and testing, no, somehow the compiler made special notation for the standard library.

anyway, imaging you have a function like that is a tight loop, with a random probability that a and b are one smaller than the other. at best you get 50% probability of a branch misprediction.
and in today's cpus, a branch misprediction is far worse one of the worse performance offenders

so for my to remove that compiler uncertainty, for the case of integer compare.
I am doing if like this

Code: Select all

ndInt32 dMax(ndInt32 A, ndInt32 B)
{
        ndInt32 mash = (A-B)>>31;
   return  (mask & B) | (~mask & A);
}


now that code uses instructions that can be issue in parallel, super scalar and is branch less 100% of the time.

the results of these optimizations id that, indeed the loop is not only significant faster, but we can see the real difference when using f32 and f64
now f32 when using avx2 is more than twice as fast as when using double because the loops gat closer to that theoretical limit, before the difference was marginal.

It took almost three months to go over making the solve lock, atomic free and branch less as much as possible, many, many bugs, but the results make a difference for the first time.