Dealing with intersection artifacts

[Julio Jerez]

yes I know, I have no forgateen that bug, beleieve me I am the one most interes in correnting it.
The thing is that I try to spreadd to thin covering too many features and I have too many lose end, and before I continue I decided to close some.

Remember I said I was going to add the instance and scale, and after I spend two week on it I fodun myself with a real mess.
so I decide to backup and start adding this decide litle by lithe one step at a time.

I now completed all of teh collsion shapes that will be part of core 300.
There are three new shapes. Tapered capsule, tapered Cylinder and Comvex Polygon.
I also adde dteh HighField collision

I added a lot of emphasis on optimizing collision bewteen Conve shape and convex polygons, tshi sbecause teh large majory of collsion in any application is base of polygon vs conve shape collision.
for that I added new the convex polygon shape, tah can handle any plane collsion as a preprosses face. thise makes collision with mesk literalli twoce as fast and any other version of newton.

I still have three base funtion to complete thIs chapter:
-finish the eadjencey conetivity for highfield (eassy and I think I will cover that today)
-conditionig of edge collision contacts between convex shape and conve polygon, (also easy and I will complate the today), tshi si imprtant fo rteh high quality collision on polygonal meshes
-Add a d presposseing face to collsion trees to remove coplanear face but bollean, right now when a mesh has comp[alna faces the optimixe get confuse and leave hle on teh mesh.
(this will do nes week)
-the write teh SSE version for those functions.

This week I will fix the high energy Bug and check it in, In eh mean time I jsut chek in a version than ignore the SSE unti the new functions are in.

[Julio Jerez]

Also, can you suggest a way to keep the pennies from continuing to settle down in the last part of the animation.? It doesn't look very realistic to me ... I tried increasing friction without success
http://www.hurleyworks.com/media/flash/RevenueStream/RevenueStream.html
-Bird

increasing friction will not work, and if it did it will hide a problem, it should be stable with default settings, I susppect it is because lost of numerial precision in the contact filter rejecting close contacts
that are essencial for the correct solution but because they are too close they get rejected by the contact solver. The result is that contact start to dance around from frame to frame.
there are ways to work it out, what shape are you plassing around the pennies?

is the jiter with the pennies new or has it always being there?
will the ngd file you send reproduce that?

[Bird]

I susppect it is because lost of numerial precision in the contact filter rejecting close contacts
that are essencial for the correct solution but because they are too close they get rejected by the contact solver. The result is that contact start to dance around from frame to frame.
there are ways to work it out, what shape are you plassing around the pennies?

I'm using a cylinder Y shape for the pennies.

is the jiter with the pennies new or has it always being there?
will the ngd file you send reproduce that?

It's always been there but it seems worse for this version because I'm using more substeps. I found that if I increased the substeps so that I call NewtonUpdate with smaller timeSteps then the popping and penetrations go away. For this simulation I had to use 10 substeps to get an error free simulation.

Code: Select all

void NewtonScene::updatePhysics ()
{   TRACE("NewtonScene::updatePhysics")

   // timeStep_ = (1/LW fps)/substeps
   for( int i = 0; i < substeps_; i++ )
      NewtonUpdate (world_, timeStep_, 1);
}

-Bird

[Julio Jerez]

It's always been there but it seems worse for this version because I'm using more substeps-Bird

is that right? or you meant using less substeps.

it does make sence that for that setting ou will have to use more substeps,
is the simulation stable using 10 substep with the last update?
whan you say 10 sub step dos thsi mean you are running at 600 fps? or you mean the solve is steps to 10 substeps?

[Julio Jerez]

remember you are using a gravity value of -30, if you using a metric, this means you are using a very extreme gravity, even bigger than planer Jupiter which is 26 m/sec^2
I am asuming you using represen centimiter of some kind of other metric.
a large gravity will require a higeh simuation rate, because net force will gnertae significan change of position when a body si not in perfect equalibrium.

do you know what unit system you are using?

[Bird]

It's always been there but it seems worse for this version because I'm using more substeps-Bird

is that right? or you meant using less substeps.

it does make sence that for that setting ou will have to use more substeps,
is the simulation stable using 10 substep with the last update?
whan you say 10 sub step dos thsi mean you are running at 600 fps? or you mean the solve is steps to 10 substeps?

In LightWave the fps is usually set by user to 24(film) or 30(video) fps so I need to match that in Newton. I compute the timeStep for NewtonUpate() by dividing the LW fps by the number of substeps. For example if I use 4 substeps then I call NewtonUpdate 4 times using .00833.

Code: Select all

int LWfps = 30;
float lwTimeStep = 1/30 = .0333;
int substeps = 4;
float newtonTimeStep = lwTimeStep/substeps = .0333/4 = .00833;
for( int i = 0; i < substeps; i++)
 NewtonUpdate((world, newtonTimeStep, 1 )

Is that the proper way or am I doing this totally wrong?

-Bird

[Bird]

remember you are using a gravity value of -30, if you using a metric, this means you are using a very extreme gravity, even bigger than planer Jupiter which is 26 m/sec^2
I am asuming you using represen centimiter of some kind of other metric.
a large gravity will require a higeh simuation rate, because net force will gnertae significan change of position when a body si not in perfect equalibrium.

do you know what unit system you are using?

I'm using meters, I just bumped up the gravity to -30 because it make the high-energy popping problem easier to reproduce. The first time I encountered the popping problems in the pennies animation gravity was set to -9.8.

-Bird

[Julio Jerez]

I'm using meters
-Bird

Ha that is good to know, in that case the jiter is normal,because the neet force on teh body mak eteh to take a too large of a displacemen afte each time step.
This is differnt from what I was thinking the bug was.

It is also good to know that an eassy way to reproduce teh high energy bug is but increse the gravity.
The week I will debug that bug. and tyr to get iot fixed tah si teh most imprtant.

as for the jiter, the reason Iwa s thinking that it was haping is becaus ethe collisin shape si small enoght that the contct filter may colapas contact tha di dno nee to colapse.
the for example a cylynder landing in one side on a face.
if this is the case they will be two contacts, one on each side. but since they are so close, the filter will remove one.
then the solve will see only one contact on one side, and the solution will mak the cylnder to rotate a litle over the size that di not have contact.
next time there is more penetration on the side and the contact on the other side will be remove, an dteh oppsite happens.
anyway I will veryfy that this is not the case when I am fix the bug.

[Julio Jerez]

if you are running at 30 fps and you divide by 4 then you are sampling at 120 fps, that sone correct to me.
I suggest you go higher than that for more fidelity maybe 240 or 300.

also do not call the engoine with variable fps. ther are not linear function in the engine than when calculation teh partial derivatives, they assume tha the delta time step is constatnt.
if you call the engine with variable time step the delta time step translate to extra accelerations that are not accound in by the solver and the constraints derivatives.

[Sweenie]

I've seen in the source change log that once in a while you set this variable isInEquilibrium to zero to test stability.
Does it prevent bodies from falling asleep and could it been that this was active and thus the coins never stopped moving?

[Julio Jerez]

yes that variable in the result and the and of all of the IsIn equalibrium bit on all bodies in a island.
when the values is zere it mean all bodies enty a face where the velocity, angular velocity, acceleration and angula accelration is near zero, or below teh solver threshhold.
an that point the deynamica solve start o damp teh velocity until thay all reach zero, and the it stop updating that island until another external action change the state on any of the bodies.
in all my test I alway test with tha variable set to zero, that way It does not hide problems.

some time I check that in but, when I do is by mistake. however it should unly affect the engine performace in speed, not the performance in stability.

[Julio Jerez]

Hey Bird,
I finally got a test the completly exposes the high energy collision bug, or a least I am pretty sure this is the bug.
an the best is that I can reproduce eevery time, and it only uses two bodies, so I soudl be a ble to debug now.

I check it so tha you can see it.
bascally it a ball falling on to of a dougnught, as the ball fall at some point the doghungh moves to the side.
the demo has perfect symetry, and I can see that concat are correct, ther si no way that round off arithmetic can generate that result.

I still do not know where in the engine thsi bug is generated, I have an idea, but I have not tested yet.
the good thing is that the test allows me to debug it and fix it.

[Bird]

I check it so tha you can see it.
bascally it a ball falling on to of a dougnught, as the ball fall at some point the doghungh moves to the side.
the demo has perfect symetry, and I can see that concat are correct, ther si no way that round off arithmetic can generate that result.

Great! Definitely looks like a bug and should be easy to find in a scene so simple. I hope it's easy to fix too.

BTW, I noticed that calling NewtonTreeCollisionSetUserRayCastCallback() causes a crash in the latest versions of Newton.

-Bird

[Julio Jerez]

I beleiv I finally solev this bug.
Thsi was worring me for a while because I coudl not find it, and teh reaosn was that ther was not bug in the solver and the collsion system.
it was a legacy form core 200 in teh conactc cache manifold.
http://newtondynamics.com/forum/viewtopic.php?f=12&t=7183&p=49379#p49379

if you try again I beleive it should be work.

[Bird]

I beleiv I finally solev this bug.
Thsi was worring me for a while because I coudl not find it, and teh reaosn was that ther was not bug in the solver and the collsion system.
it was a legacy form core 200 in teh conactc cache manifold.
http://newtondynamics.com/forum/viewtopic.php?f=12&t=7183&p=49379#p49379

if you try again I beleive it should be work.

I'm still seeing problems in today's build (SVN 1848) with the pennies simulation. Here's a video of the exported scene. http://www.hurleyworks.com/media/flash/NewtonPenniesTest/NewtonPenniesTest.html

And here's the exported scene file http://www.hurleyworks.com/downloads/penniesExport.zip

-Bird