[SOLVED] bouncing on joints = EXPLOSION

[blackbird_dream]

afair there is no additional script just one mesh for the front fork:
https://ufile.io/ldp2d

[Julio Jerez]

Sweenie can you add that test as one of the demos, like high mass ratio and commited it?

I was going to check it out, but when I made the same change you did, if could not update GitHub,
I re cloned again, an now I lost the demo.
let us formalize the test as one of the test case in the plugin in this way we all can see what is going on.

on the soft spinning joint, this may be the case because I am removing all of the penalties that keep joint torque there. that value soudl be really, really small.

the old joints has the centripetal acceleration added as external torque, now that's not the case they are support to come out natural from the derivatives, but either there is a bug of I have not gotten there yet. in the joint code there is #if 1 … #else …
that will do the new or old method.

now that I can run teh demos I see that all is correct, for one mode, and all is also correct for the other mode, at the moment some things as messed up.

[Dave Gravel]

Here my demo seen to work good about the bounce problem.
I don't have test all again, but already I can see it is better now

Edited:
Sorry about the purple objects at the end, It is not related to newton,
It is my personal modified jiglib physics.
I use it for make personal tests.

https://www.youtube.com/watch?v=lLQkb0NsDE4

[blackbird_dream]

what release do you use?

[blackbird_dream]

ok I built a brand new unity project after recompiling the last release of Newton and Unity plugin and the bug looks fixed.
Here is the whole package for the unity demo project (no files missing):
https://ufile.io/p0isn
Now I must understand why the changes were not taken into account in my old project after updating the 3 dll files (NewtonPlugin.dll, NewtonWrapper.dll in the Assets/Plugins folder and NewtonPluginEditor.dll in Assets/Editor).

it seems that lots of things have changed. Now my truck doesn't behave like it did
my tire model has been strongly affected

[blackbird_dream]

The new build seems more explosive.
Sweenie,
In your last build there is no option to calcuate the inertia. I modified dnewtonby.cpp, dnewtonbody.h and newtonbody.cs according to:
https://github.com/ple666/NewtonUnityPlugin/commit/155d56b4bda48c215a24575b4e97c6d9ff6f1deb
Am I still correct ?
It seems to be correct and it improve the global dynamic behaviour of the vehicle. However I must calculate the inertia of the swing axle. If not the truck explodes. it s better indeed.

[Julio Jerez]

it seems that lots of things have changed. Now my truck doesn't behave like it did
my tire model has been strongly affected

yes this is true but that can be controlled, if you want you exact old behavior for the tires
the tire collision must implement something like this.

Code: Select all

static int OnAABBOverlap(const NewtonJoint* const contact, dFloat timestep, int threadIndex)
{
   NewtonContactJointResetSelfJointsCollision(contact);
   return 1;
}


what this does is that do not add the tire to be solve by teh joint solver.
In general the new method should be better, but since you put so much work on what you have, maybe you want to keep it for a while.

It is long to explain, but what happen is that the tires are now too rigid, since the joint solver gives the rigid body solution in one tick each time.

Tires are not rigid or soft bodies, they are in between some sort of plastic bodies.
an iterative solver has a lag in generation the reaction forces, therefore for the wrong reason they lead to a better solution for tire simulation than an eact solver.
Modeling a tire with an iteration solver works in the sence that a broken clock can be right twice a day. but they do work if you manage to get the right tweaks and massaging.

I would prefer to use the exact solver and get the spiky answers and fix by adding joint relaxation that can be predictable and controllable, than using the ieteration solver that add the "relaxation" in the form of poor convergece but that is not controllable.

My recomenedation first you get what you had bfore but implenetiuon a tire material callback that calls NewtonContactJointResetSelfJointsCollision(contact);

and then you can try improving the model if you feel like.

I am not sure if we add support for material but the call back is there, I believe this has to be done via a script callback, I have not run the unity plugin is a while.
the plugin in has the AABB callback that clue the engine and the high level

Code: Select all

int dNewtonWorld::OnBodiesAABBOverlap(const NewtonJoint* const contact, dFloat timestep, int threadIndex)
{
   NewtonBody* const bodyPtr0 = NewtonJointGetBody0(contact);
   NewtonBody* const bodyPtr1 = NewtonJointGetBody1(contact);
   //dNewtonWorld* const world = (dNewtonWorld*)NewtonMaterialGetMaterialPairUserData(material);
   NewtonCollision* const newtonCollision0 = (NewtonCollision*)NewtonBodyGetCollision(bodyPtr0);
   NewtonCollision* const newtonCollision1 = (NewtonCollision*)NewtonBodyGetCollision(bodyPtr1);
   dNewtonCollision* const collision0 = (dNewtonCollision*)NewtonCollisionGetUserData(newtonCollision0);
   dNewtonCollision* const collision1 = (dNewtonCollision*)NewtonCollisionGetUserData(newtonCollision1);
   //const dMaterialProperties materialProp = world->FindMaterial(collision0->m_materialID, collision1->m_materialID);
   //return materialProp.m_collisionEnable ? 1 : 0;
   return 1;
}


but I forget how the material is supported.
besaically in the call back it needs to get the material from the two colliding shapes, and if one is a tires them make the call to NewtonContactJointResetSelfJointsCollision().

This is why we need to make a demo that recreate all this and if some funtniality is not exposed then add it in.

[blackbird_dream]

oh no I don't use any collider.
I'm using the Pacejka approach, i.e. the torsor (longitudinal force Fx, lateral force Fy, overturning moment Mx, self-aligning moment Mz functions of slip angle and camber angle) given by experiment fittings according to procedural laws and Fz given by the load/deflection measurements.
the wheel mesh is only updated in realtime according to the position and orientation of the tire centre.
After some settings I'm closer now to the model implemented under version 1.5. The model reacts fast and well.
Thks Julio for your great job.
Don't change too many things now

[Julio Jerez]

....
After some settings I'm closer now to the model implemented under version 1.5. The model reacts fast and well.
Thks Julio for your great job.
Don't change too many things now

you said it far better than I could, this solver is the same quality of newton 1.5 and lower, but much better because is also has the all the "know how" that I learned over the years.

The original solve was base of L U factorization, and therefore was far more general and could coupe with singular matrices, however the it was really slow and gave unrealistic solution to ill condition systems. those were legitimate solution numerically but unreality for a rigid body simulation.

since them I learn the trick of adding a matrix regularalizer, which has the effect of simplistic simulation of elasticity which is which it need to resolve it form matrices and that open the door to much better Danzig solvers base of Cholesky and Householder reconstruction, and are order of magnitude fasted but that are far more limited dealing with ill condition system.
The I experiment with an even more special type of solve base of Acyclic Graphs, which are even more restrictive, but that work in linear time.

There improvement are not free the impose a lot of engine high lever filtering as opposed to Newton 1.5 that was capable of solving any anything.

What I am try to say is that Newton 3.14 for a large type of system (vehicle and more articulated bodies) is far better than 1.5 and any other version. But required some massaging of the data.

I had the feeling that after you test it that you will like it better, because I was almost sure that you has to do some calibration to make up for the poor convergence, now whet you input is more close to what you expect as solution.

anyway, there will be a new set of change ha have to so with gyro torques. but that will only affect bodies with high angular velocity. in any case there will be option to turn on an off until we are sure that all system work as expected.

anyway I look forward to see what you get.

[Sweenie]

Hi.

I've added a test scene to the plugin project. Test_01_JointAndHighMassRatio.
It's a box with a mass of 2500 connected to a thin box with a mass of 50 using a slider actuator. Use the up and down arrows to apply a constant global force along the x-axis to the bigger box. I did'nt add any code to control the actuator but didn't think that was necessary in this test since it's the "bouncing" we wanted to test.

[Sweenie]

By the way, i've been using Unity 5.5 for a while now and thinking about upgrading to 2018.1. Is that ok for everyone?

[blackbird_dream]

would it change something in your code ?
I'm afraid my model is not compatible with v5.4.6 which I'm supposed to build for.

[Sweenie]

would it change something in your code ?
I'm afraid my model is not compatible with v5.4.6 which I'm supposed to build for.

Probably not, i guess this would mostly just affect the demo scenes/assets which would be stored with a newer format. Unless the UnityEngine.dll had major changes which would require code changes in the plugin.
What is it in your project that prevents you from using the latest Unity version?

[blackbird_dream]

I'm not the designer of the final simulator. I'm collaborating with a company using v.5.4.6.
My function is to provide them the true physic vehicle model so they can set the Virtual world and pedagogical script with it. I guess they pay lincence fees so they cannot use any product version.

[Julio Jerez]

Sweenie let us do this.

give some day to get the parallel solve to a stable state, then I want to get the vehicle also in a stable state.
Then after that we update the plugin to the version of Unity that is already there, and after we test it we make a Checkpoint in GitHub.

then after the we can update to the latest version and every one have an solution.
does that sound reasonable?