Choosing units

[Slick]

I know units are somewhat abstract but normally I just assume meters and the gravity is at lets say -10.

I created a surface (dNewtonCollisionScene) of let's say 7m and then dropped a cylinder of let's say 6cm onto it. I'm finding that the object goes through the dNewtonCollisionScene.

My object in meters is only 0.06 (6cm in m).

I thought initially maybe using a small value for the object length (0.06) might create a problem so I switched to trying to use cm's as my unit. Then I had to adjust gravity x 100. That didn't work either.

It is ok to use small object sizes like 0.06 and if not should I continue trying using cm as my sizing>

[Julio Jerez]

For a small object like that you can set continuous
collision

[Slick]

I remember that function from the past. I looked briefly the other day buy but didn't see it. I will find it. I don't know whether it is a world or object function.

Thanks for the info.

[Julio Jerez]

On the rigid body you just set cc'd on.
Also what fps are you running?
I usually run 60 with two sub steps.
That makes it an effective 120 fps.
This is usually enought for most simulations.
And is very accurate and not much slower that just 60.
I'd try that first see if is ok.

[Slick]

The physics I changed to 60 fps and had it iterate the physics regardless of frame rate.

I haven't had the time yet to turn on continuous collision and I will do that,

[Slick]

I have substeps of 60 fps that i iterate each video frame until used up.

The continuous collision mode did help but I still have a little problem. In my testing you could equate it to something like a small disc or large coin on a table. Most of the time it works but I can see it dropping through the scene sometimes.

Radius is about 6cm and height about 1.5 with a weight of 1kg. Sp radius of about 0.03 and height 0.015.

I could go back to trying everything in units of cm and then match the forces scaled for cm but I would have thought it should work as is.

[Slick]

Video link showing the items sometimes dropping through the surface.



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

[Slick]

Maybe a better one in debugview mode.

Look around the 24 second mark where objects drop through.

https://youtu.be/SOabhYwwesk

[Julio Jerez]

I see, that's not good.
Is there a test that I can check?

[Slick]

Hmm would you need an debug exe that you can use Newton dll to debug? I also updated to the lastest GIT this morning before doing this.

I wasn't sure if my values were too small but they correspond to real world values.

[Julio Jerez]

when I look at teh video, it looks like there are more than one problem

the first one seem to be the puck going over the floor.
the secund seem to be the contact generation been bad.
you can see when the puck is resting on the ground, it jitters. that should not happen.


let us try this to see if we can fix that, I assume you are using function
NewtonSetNumberOfSubsteps on you initialization
like you call NewtonSetNumberOfSubsteps(workd, 2)

please try NewtonSetNumberOfSubsteps(workd, 4)

let us see if it get better, this sould go a long way fixing the puck going over the floor and is probably better than set continue collision.
if the puck still miss collsion then you can set continue collision on the puck


the secudn problem, teh jitter, this I think is becaus ethe default contact threshold, basically this is a feature that when two contact are more some some small distance apart, teh first one is selected and the oeth are discarded. is good for medium size objects, but for a small object teh tow contacts may be needed.

this is a per contact joint funtionality that yo uhave to add to your callback, because is not part opf teh material. the function to controll that are these

Code: Select all

dFloat NewtonMaterialGetContactPruningTolerance(const NewtonJoint* const contactJoint);
void NewtonMaterialSetContactPruningTolerance(const NewtonJoint* const contactJoint, dFloat tolerance);


you can try something like this

Code: Select all

dFloat dist = NewtonMaterialGetContactPruningTolerance(contactJoint);
NewtonMaterialSetContactPruningTolerance(contactJoint, dist * 0.25)

this makes the distance 4 time smaller.
do no make it zero, because thet will generate multiple contact at the same location that will be different by the normal direction. for example when hitting the edge of two faces on teh map.

this feature makes the solver work harder and contacts that are close together increase the condition number of the mass matrix. this is why is no set to a very small value by default.

plase try those two thing and I beleive you will be find. few user has had this problem in the pass and that was how was solved.

[Slick]

Thanks for the detailed ideas. I will try all of this and report back.

I did notice jitters that were beyond what you would see in real life. And obviously falling through an object at virtually no speed doesn't make sense.

I should get to this tomorrow I hope.

[Slick]

It took me a while to get in incorporated correctly but it seems that it is more stable. I will continue and see how it goes.

I still wonder if you are using real world units would it be better to use say a diameter of 6 and use forces based upon cm/s vs using diameter of 0.06 and using m/s.

[Julio Jerez]

O do not know what do you mean real world unit.

1 is a KG
if you say 1 is a meter,
the that mks metric system.

then gravity is 9.8 m/s

[Slick]

I was trying to say is it better to use 6cm and 980cm/s or 0.06m and 9.8? Maybe there is no difference for the engine but I was curious with using low values like 0.06 whether it created any potential problem.