Refactoring joints

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Refactoring joints

Postby Julio Jerez » Fri Mar 02, 2018 12:14 pm

Hey Joe I was trying to add the enhanced to the solver to see if the jitter of the tread goes away.

And already did it, and it seem to work fine with the forklift, but blows away with the tank.

So I start debugging it, and the reason was is that that model has about 800 rows, had to believe until you take the joint count 143 and multiply them by 6
This optimization add the self contact was row, that put the count well over a thousand rows, and that where it goes up.
The reason is that the memory to build the matrix is allocated on the stack, by the data strructure to hold so many rows becomes 1.5 meg
In fact with out the optimization the memory is about 0.7 meg, so it was very making it. If I continue doing more structural joints, of if I place several tanks it will blow up anyway if the collide,
Therefore I will mage so that the work contain all he memory it need regardless the optimization.

The drawback is that the engine will use way, way more memory, but memory is the cheapest resource on a computer anyway.

The reason the memory grows so fast, is the the storage is quadratic to the number of rows.

Anyway I hope to have this working tomorrow, and my hope is that the tank is rock solid, stable and accurate in all circumstances.

My only concern is that it may be a lot slower, but that's the challenge.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Sat Mar 03, 2018 11:26 am

ok guys I now commited a quick prototype of the change to teh solver to fixed the jitter in a large array of joints.
It does no goes to reat yet because is not final, but you cna see that there is not jitter anywhere,
The reason in no resting is because teh solve do no converge to zero, yet instead to a close value tha have to be above the threshold for sleeping.

if you guys sync and drive, you will notice this vehicle behaves different tha that previous model.

Thsi model try to resolve all joints, so when the vehicle is a rest the suspension are expanded and they try to stretch the threads and is a fight between the thread and the suspension.
when the vehicle start to move the forward torque lean the vehicle and the suspension compressed leaving the threads room to move and the simulation is easier on the solver.
The torque never goes away because there are lot of internal friction generate by teh tread links.

This is the first time I see that a solve is faster when the bodies are moving that when eh bodies are at rest.

Basically what this says is that the suspension are too soft. yet another design [point tha emerge from the simulation. if you make a thread vehicle, the suspension soudl be very stiff if they aren't the thread will wiggle out of control when the vehicle moves.

I am no changing it just yet, I wnat to see first if when I complete the solve that the whole thing goes to sleep and them I can optimized the design a little.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 05, 2018 6:46 pm

Ok Joe, this is no the finale but should be very stable, and yet is does not goes to rest, actually I'd seen it at rest but is unpredictable.
If I compare this to the model that was in 3.13 a year ago, in 3.13 the model goes to rest at an acceleration that much higher that in the version. That suggest me that there most be something wrong with the sleep code, so I took a look and yes that was the problem.

This is what happend, when I started 3.14 I disabled a lot of iterative solve mombe juombo because the plan was to use exact solver as mush a possible. \

I try to import part of the newton 1.5 engine but that could not be straight imported because 1.5 as an exact solve for contact and joint, so it is slow.
In 2.xx we did the iterative solver and to solve the sleep problem I added a progressive sleeping code.
I called a progesive sleep code si one in whic an island goe to sleed in one frame is teh accelrtaion and velocity is below the tolereance, but if is does not the a count is incoreased and an tolererace mutiplier is scale teh torelace then is the bodei is below that new scale torealce fo rteh new numeb of frames, the if goes rto sleep, si it does no the is codn teh cousnte an dteh troleces and try again,
tshi si repeated I believe 8 times, and if istill fail the count is set to zero.
This work remarkably wheel with iterative solvers in sense that if can bring island to rest even is the are truly at rest.
However I never like that because although is make the engine appear stable, it make almost impossible to model a simulation with good accuracy, this is what explain my quest in getting accurate solver. we made good improvement along the way, but that was always a big problems until but the end of 3.13 and starting with 3.14 we change that.

first we start with solving the joint exactly, and that work well until the model hit a contact,
you can see that most model are fine until the collide and the the jitter start.
To solve that we now are adding joints and immediate contacts goes to exact solver, of course this will push the jitter away, but I claim that as the jitter move far away they is no that important anymore.
This strategy solve the problem of self contacts right away, and this is why the vehicle is now so stable. but now we have a new problem which the solver have to be more optimal because now the are lot more friction contacts.

I believe I have tha cover now, howver teh vehiecle is no goin to sleep, and the reason is that
the objet expect the model to go to sleep in one frame. but because the solve is not handling all contacts this will very rarely happens.
The solution is that I need to re enable the progressive sleeping, and that solve the problem.

the big difference is that the progressive sleeping can be a lot more gentle than is was in 3.13 and lower because the vehicle does goes to sleep already.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby JoeJ » Tue Mar 06, 2018 1:24 am

Awesome! :mrgreen:

I also tested my joints stuff - still works very well :D
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Refactoring joints

Postby Julio Jerez » Wed Mar 07, 2018 3:27 pm

Ok re enabled the progressive sleeping code, I has to make some changes form the old mode in 2.xx and 3.13 but I believe this is better.

I also make it so tha the wood labs do no collode with the tires, it si quiet a challeng to p[reven teh wood slab for getting between the tire and the tracks, so I thought that filtering the pair
woodslabs-thread would be a good solution, but that does not really works because the thread as collision objects so if the thread are standing on a wood slab, the thread his the terrain and the tire is lifted on the air and it look really bad. These is however the model for the high performed vehicle where the threads are just object following a spline path the is constrained to the tire points.

for this I am filtering the pairs wood-slabs/tires so the if a wood slab get between the thread and the tires, it will role over, however this is not perfect because when the wood slab hit the body of the vehicle the it can cause weird behavior, specially when the long wood-slabs get inside since they are hold strongly, so actually very interesting see how it try to resolve it, but is no nice if it explode.

One way you prevenet this is by adding a collision shape in the side the thread that prevent anything form getting under the vehicle but thong can get inside the thread since they can be push out.

This is just modeling and tweaking so I am no too worry about this.

The vehicle still do not goes to sleep because the contacts are not solved exactly yet, so I will try to complete the solver improvement to see if we can handle that, but that is just an added bonus, if we can't is not a big problem.

one thong I what to make is to drive a twice the speed (now is going about 40 km/s) so that is more like a real tank, this works fine without the wood slabs but I want to make work for all citations.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Wed Mar 07, 2018 3:41 pm

this were made with newton 1.55 but they run at an insane fps an are very slow, my goal is that these can run on real time:
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Sweenie » Mon Mar 12, 2018 10:35 am

Julio Jerez wrote:I could not resist to try yet another gyro test called phitop
https://www.youtube.com/watch?v=1Tx7FgZuV3U

It is amassing hwo is can be reproduce bu the book, notice how teh start fast and as the rise they a little of angular velocity, by then thank to her explanation this is not a bug is actually conservation of energy, and the top rises it gain potential energy because there center of mass goes up, so teh onel way to get thet energy from is from the angular keneti energy, why will make the object slow down.

The secund reason that slo down is that as it rises it chnge its from an axis with lowes inerta to teh axis with large inretia, so angula velocity soul goes down to make constant.
Thes physics stuff make thing that people will see as a bug very perculiar and interesting.

but once you see it an undertand it, this the intutive way no longer makes sence.

I could not recreate the tiptop one, I made with a ball and a small cylinder, but that does not do it,
The trick of the type top is that is hollow, so the inertia is concentrate on the surface, and the small pin make a large influence, a solid sphere the pin has almost not effect and it aligns sideways, later
I will see if I can model the hollow inertia, which can no be done easy with the compound but can be done from the elements. Tha was we will recreate all edge cases.
I always wnat to simulate these stuff.


Sorry for going off topic but have you tried simulating this one? :D
https://www.youtube.com/watch?v=LmEf7aIhpF8
Sweenie
 
Posts: 498
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 11:13 am

Oh not at all, I was looking forcthst demo for a while, I once saw it at one of the MIT lectures by proffesor Warter Levin but they took many of his lectures down.
Glad you found one.
I see if that one is possible, the trick is that the shape has asymmetrical inertia, plus the friction at the contact point .
If you look carefully the shape is not regular so its com is not at the geometrical origin.

This meand that we can approximated with a scaled sphere with th com offset a little to the side. I will add that one.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 11:54 am

Now that you show it, I looked at some of the other videos that explain the effect.
As we know it is produced by an asymmetrical inertia, bubthe trick is to offset the com in such way that ixx is approximately equal to izz so they will generate a signed gyro torque.

This should be easy to reproduce with a scale sphere with an offset matrix :shock:

It terms out that friction is not part of the effect lie in the phitop.

Also there is a video of one guy making one from a piece of wood, and he made the inertia by carving holes inside, so his model shape have two axis of symmetry, our representation will resemble his.
I am also guessing that this requires a high simulation rate, if you look at the time when the beat is about to reverse, it vibrates really fast, it is possible that the implicit integrator filter that since it extrapolate derivative at the end of the time step.
This was the problem that we have before when using predictor corrector to estimate the angular velocity at the end of dt, it did it by integrating at st and averaging, which good if you want stability but fail at reproducing violent derivative changes, now with the implicit extrapolation, we still have the smoothing problem, but this method can approach sharp derivatives if the time step is short, the other can't.

Well enoghut of that, let us see what we get.

The one thing that bothers me about those university courses, is that they do not teach the student the complete general equation of motion and from there the derive the special cases, instead the start with the special cases and derive some particular expresion as if they were any special.

The result is that the students get the impression that these formulas are special and they apply them in other cases, when in fact these expression comes from setting some variables in the general expression in some particular ways.

Even a renounce experimental scientist like Dr Walter Levin made that mistake so many time.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 4:03 pm

I added the solve optimization, but I found one big problem.

I committed a debug setup so you guys can se what it is.
basically for some reason the skeleton is generation contact in place we it should not,
this is really bad for exact solver and cause an explosion.
there most be a bug in the code that is lettion that happens so I am debuigging it.

However if we are going to handle contact on contractions is joints, I most found a way to deal with singular matrices. the dates way I know to do this for PSD matrices is by calling Cholesky factorization, by this is a very expensive test as is tern out it is what is making the tank really slow.

one way to do it is by adding regulatiozation to self contacts but that is the same a having soft solution. In any case the red dot in the demo should not be happening under any case, there most be a bug some where.

somehow the left foot is make these contacts, but that should not happens
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 6:48 pm

Sweenie wrote:Sorry for going off topic but have you tried simulating this one? :D
https://www.youtube.com/watch?v=LmEf7aIhpF8


ok sweenie, here is my first try, not quite the effect, but you can see that is kind of trying to do it.
I am no sure if it is the shape of the inertia matrix ratio or the simulation rate.

I suspect is a combination, you can see that it try to lift itself from the floor because the com is too high, all the beats I seen are like half the ellipsoid, which means the com is quite low.
I will try some combinations to see how close we get it.

these are the kind of effect that if you see it you think they are bugs. but physics is a wonderful thing. :shock:
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 6:59 pm

I found the Dr Walter Lewin that explain the effect, I believe he explain the trick to get it start it
https://www.youtube.com/watch?v=hmHV-HF-22s

basically is have to start with a rocking motion, and I am applying only a pure rotation around one axis.
I will try that later.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 7:52 pm

Ha I now know what is the trick, this gusy explains it.
https://www.youtube.com/watch?v=AY484PoizvQ
basically it is just setting a non axis aligned inertia matrix, you can see that his model is perfectly symmetry but he make the offset inertia inertia by carving holes inside the body.

This is how people made bowling balls, they place an skew piece of lead inside so that it has some specific skew inertia, back in 2004 I made a modification to a team called True Vision 3d, the requested that support for a bowling game they were making with newton and I added reluctantly.

The show the videos and it was quite cool, the ball did curved, I can no find the youtube video, but I am sure it should be there some archive, it was quiet impressive, but again it run at 300 fps which at the time was quiet expensive.

Anyway and it stands now newton will not be able to do that because if you look at the code, the engine does calculate the full inertia by is assume the principal axis will always be aligned to the principal axis. Here is the code that does that, I even put a comment.
Code: Select all
void dgBody::SetMassProperties (dgFloat32 mass, const dgCollisionInstance* const collision)
{
   // using general central theorem, to extract the Inertia relative to the center of mass
   dgMatrix inertia (collision->CalculateInertia());

   dgVector origin (inertia.m_posit);
   //dgFloat32 mag = origin.DotProduct3(origin);
   for (dgInt32 i = 0; i < 3; i ++) {
      //inertia[i][i] = (inertia[i][i] - (mag - origin[i] * origin[i])) * mass;
      inertia[i][i] *= mass;
      for (dgInt32 j = i + 1; j < 3; j ++) {
         dgFloat32 crossIJ = origin[i] * origin[j];
         inertia[i][j] = (inertia[i][j] + crossIJ) * mass;
         inertia[j][i] = (inertia[j][i] + crossIJ) * mass;
      }
   }

   // although the engine fully supports asymmetric inertia, I will ignore cross inertia for now
   //SetMassMatrix(mass, inertia[0][0], inertia[1][1], inertia[2][2]);
   SetCentreOfMass(origin);
   SetMassMatrix(mass, inertia);
}


so it would seem that this will not be possible, but not really? :mrgreen:
if you look at file ../sdk\dgPhysics\dgDynamicBody.h

Code: Select all
#ifdef DG_USEFULL_INERTIA_MATRIX
   virtual void SetMassMatrix (dgFloat32 mass, const dgMatrix& inertia);
   virtual dgMatrix CalculateLocalInertiaMatrix() const;
   virtual dgMatrix CalculateInertiaMatrix() const;
   virtual dgMatrix CalculateInvInertiaMatrix() const;

   dgMatrix m_principalAxis;
#endif


the support is still there intact, the reason I did not want to do it was because back them we only have one rigid body type. therefore adding the inertial principals axis will make everything bigger and more expensive and lot more unstable hence I made a special build for them, I also added the cll, compatibility because engine is managed code.

Now we have multiple bodies, all we need to do is added and interface to create FullInertiaDynmaicsBody, and move the support to that class, and badabinbadaboom yayayaya we get Rattle
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Julio Jerez » Mon Mar 12, 2018 8:01 pm

Hey Sweeney I hate you, :mrgreen:
you found that stuff and now I will not can't rest until we get the effect, fortunally they is a easy way of doing the effect
https://www.youtube.com/watch?v=ovZ_n6X__9c

basically if we place two shapes, and we glue them with a fix joint all we nee to do is offset the COM of each rigid body, and the solver will do the trick,
This is a smoke test that should show how accurate the solver is. so I will do both the single body, an the multibody.
My greatest disappointment is that I do it and it does not work. so this is a cross road
I really hate you dude. :mrgreen:
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Refactoring joints

Postby Sweenie » Tue Mar 13, 2018 3:01 am

Haha, Newton is getting too realistic and soon I'm afraid you are gonna rip a hole in the time and space continuum so I have to give you physics puzzles to distract you and prevent that from happening. :twisted: :lol:
Sweenie
 
Posts: 498
Joined: Mon Jan 24, 2005 7:59 am
Location: Sweden

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 27 guests

cron