Compound bodies falling through tree collider

[Sweenie]

Hi.

After revision 1818 my compound collider bodies are falling straight through my tree collider.

Also noticed some other stuff which have been going on for some time, not sure after which revision level though.
First my multibody vehicle(the forklift) is behaving very odd when driving ontop of a simple box, doesn't matter if it's static or dynamic. The wheels kind of wobble and suddenly the vehicle can be pushed sideways.
Sometimes the wheels(ChamferCylinders) also sink into the box a bit and quickly pops up again.
If i'm driving on my terrain(tree collider) it behaves ok.

Also noticed that when my vehicles(multibody and raycast) are moving close to a stack of boxes, the stacked bodies wake up even though the vehicles never touches them. Just being near them wakes them up.
Is that a normal behaviour?
Actually you can see this in the Newton demo as well, just run the "Stacked boxes" demo and grab one of the bodies from the pyramid and start swinging it close to the other bodies, you can see that the whole pyramid is waking up even though it never touch them(enable visible collision meshes).

[Julio Jerez]

yes send me that demo before, can you send it again do tah IO can debug it?

[Sweenie]

Sure thing.

Will setup a test demo as soon as I can.

[Sweenie]

Ok, you can download it here... (newton.dll compiled with revision 1842)
http://www.svenberra.net/testnewton.zip

Same as before.
Run c4.exe
Press ~ (or key under Esc) to open console and type load world/test
Type newtondebug in console to show collision mesh.
Also just noticed that the Chamfercylinder collider has a larger radius than before so it looks like wheels are floating...
Hmm, can't remember that i've made any changes regarding wheel radius.

Also removed the forklifter to make the scene less complicated.

[Julio Jerez]

Also just noticed that the Chamfercylinder collider has a larger radius than before so it looks like wheels are floating...

this is a diffrence with 2.0 al older.
chamfer cilimder, and all roin shape nwo us eteh difintion paratmeter as argument.
for example a capsule use to bottom to top as high, now it the the low himesphe centor to high himspehe center

a champhered cylinder, the radio is now the ratios of the cylinder no the half the max diameter from tip to tip.
you can adjust the radio using teh follwing expresion

Champhere cylider ratiopn = radius - width / 2
the value cannot be negative of zero

can you make the fix first and repost the test?

[Julio Jerez]

also sync to svn, I was in the midle of start teh work on joint, and I adde teh RTTI software to joint class.
this add vistual functions so chace are that teh compile exe will no work correctly.

before joints had and int for ID but that could be a problem for Visual debugger and serialization, so I chaneg to sofware based RTTI type info,
I was reluctant to do that because it forces me to use the dContainer class in teh joint library, but that are simple template that do no add much.

anyway sync before you make the size fix to teh round shapes.

[Sweenie]

Ok, synced to 1843.

My vehicle wheel has a radius of 0.5 and a width of 0.5.
Before(the last few months) I used the parameters 0.5(radius) and 0.5(length) when I created the ChamferCylinder.
I now changed the parameters to 0.25(radius) and 0.5(length) and now it looks ok again.

I updated the demo. (The vehicle still bounces around though and falls through the tree collider)

[Julio Jerez]

Ok I runn it,
I see a litlle car, on top of a green box.
the car star rolling, somehow it makes a wierd side move, it look like i lose a contact, and teh oeth etire pus to teh side, but then it get a contact again,
I am assumingh this is part of the bug

then after it reach the box edge in falls and pass trugght a yellow plane as if there was nothing there.
is that plane a collision tree.


I have to go to work now I will debug this tonigh. in the mnean time one thing you can do to add the new serialization
this is very eassy to add, an dthe is a sampel in teh SDK.
that way I can load the output in the SDK sand box and visually see what kind of object we are dealling wit, saving lots of debugging timeh.

the serialition still do not handle joints because I just started revamping the joint system.
but after teh joint system is completed, I will use serialization for in the visual debugger.
Bascially it will save movies tah weeopel can inspect to see what is going on in the physcis scene.
this will make it possible to generate replay that examply reprsouce bugs anywhere.

[Julio Jerez]

Oh I know what I will do.

I will add a Utility function to teh SDK

NewtonFileSerialize (world, filename)

this will do a quick seralization to a file, tha way adding quick serialiion could be done with a single function call.
this will make easier to inspect scene.

[Julio Jerez]

Also noticed that when my vehicles(multibody and raycast) are moving close to a stack of boxes, the stacked bodies wake up even though the vehicles never touches them. Just being near them wakes them up.
Is that a normal behaviour?
Actually you can see this in the Newton demo as well, just run the "Stacked boxes" demo and grab one of the bodies from the pyramid and start swinging it close to the other bodies, you can see that the whole pyramid is waking up even though it never touch them(enable visible collision meshes).

Oh I forget about that, this is new for Newton 300. but you are correct is not completely correct.
This is what happen. In older cores contacts were generated at the Narrowphase pass, so only link that actually collide has contact joints.
The problem with this is that this makes the memory manager to do a lot of work creation and destroying joints.
In core 300 the joint are created at the BroadPhase AABB intersection.
This has several advantages.
-no need for padding AABB for continue collision sine CC of AABB is a close form problem that can be tested in contact time.
This is actually already done in the broad phase and the all hierarchical tree -collision.
-Save a lot of in memory manager in creation of detritions of joints.
-Is geared to Parallel programming. I do no know if you see it but there is a Parallel solves that solve all island at once in one go.
From time to time I make this solver the default. And tshi will be the OpenCL solver. This used to be the CUDA solver,
but I abandoned because did not CUDA support Atomics at the time, and I have to do lot of contrive red black partition that reduced solver coverage more than the gain it provided.
Id did not realize that if and dynamics body i close to another dynamics body that is already sleeping it will wake up the island.
In fact this work because there engine is so stable that some time I have to wrestle it so that is doe no bring a stack to sleep too soon.
I actually have a hack to prevent bodies form going to sleep.
The reason why it will wake up the island is because the technique for determine if an island is slipping is color coding the islands.
if an island has a color and touch another island of different color, the new island is painted to the color of the current island.
Static bodies are exceptions their color is transparent so the scanner only see the island they are connect at a time.
This allows static bodies to be connecting to multiple islands and no wake them up.
To sole this all I have to do is to dynamics bodies with contact joint with zero contact point as transparent.
Thanks you, very good find, because it will increase performance by a lot.
I will fix this bug first, since it can be reproduced in the demos.

As a side note: I bet you have not seem too many physics engines wheren island of stacked bodies wake up before you touch then and the state put?

[Sweenie]

Hi.

I switched to the normal cylinder collider for the wheels and that works perfectly, so it seems I only get this odd behaviour with the Chamfer cylinder, though a few months ago the chamfer cylinder worked fine as well.

[Julio Jerez]

yes that is correct, in newton 300 all closed from shape have special collision funtions. a close form shape is a shape shape tha can be descrive by a mathematical expresion.
It may be that the funtion for a chaphere cyloider still have a bug.
but if is world fix it because the collsion witeh a chapher cylider is of teyh oder of hundred of time faste that with a cylider.
( soem time later cyloder will aslo have a partial close form narrow phase function for when teh collide in teh roudn surface)
I will debug that and see what is wrong.

[Julio Jerez]

Ok I was trying to demo the demo, by it simpel crash with te the new DLL because I was in the middle of chagin chale dshape of teh mesh to ne a const object.
also I added teh RTTI to teh class librarye, an dtha added vitual fiontion to teh classes.
one of those two things is making it crash, you need to update and relink to the dll

also you cna do trhi teh function afte you mak eteh scene

NewtonSerializeToFile (newtonWorld, pathfileName);

and then load the serialzed outpuit in the SDK sandbox demo.
Id does not serialize jopint yet, bu I will add add that thsi weekend.

[Sweenie]

Ok, I've updated the demo so just download the same file again.
http://www.svenberra.net/testnewton.zip

I also serialized the world with the new function and imported it into the sandbox.
Worked great although in my demo the Z-axis is up so everything was turned 90 degrees.

I've included the serialized world in the demo, it's called newton.bin

[Julio Jerez]

Hi.
Is that a normal behaviour?
Actually you can see this in the Newton demo as well, just run the "Stacked boxes" demo and grab one of the bodies from the pyramid and start swinging it close to the other bodies, you can see that the whole pyramid is waking up even though it never touch them(enable visible collision meshes).

wow you are right, there is a bug some where.
when I wrote that I actually do filter contact joints with zeor contact, the test is in function void dgWorldDynamicUpdate::BuildIsland ()

when si buidl the jopint list it does that this check
for (dgBodyMasterListRow::dgListNode* jointNode = body->m_masterNode->GetInfo().GetFirst(); jointNode; jointNode = jointNode->GetNext()) {
dgBodyMasterListCell* const cell = &jointNode->GetInfo();
dgConstraint* const constraint = cell->m_joint;

if (!((constraint->GetId() == dgContactConstraintId) && (((dgContact*)constraint)->m_maxDOF) == 0)) {
dgBody* const body = cell->m_bodyNode;


I test this a lot and I worked, but all my test were with small island.
Howver you are correct the is a bug because when I do what you say, is does in facrt wake up the island.
In I thing this is a bug in teh contact cache no lreaning teh active contact count and terefor ethe test in invalid because it see a numnbe of contact even uf teh are not active.
I will check in out