**Moderators:** Sascha Willems, Thomas

48 posts
• Page **1** of **4** • **1**, 2, 3, 4

Hi Julio,

I'm getting some wierd behalvior when using the dCustomSlider:

https://youtu.be/JFr9qXdiSSY

There is 1 joint between the rod shape and the "sleeve". It gets into a state where the slider is "lopsided" and takes a long time to return to normal configuration.

I'm pretty sure this happens with the dCustomHinge as well. (maybe all joints?)

I'm getting some wierd behalvior when using the dCustomSlider:

https://youtu.be/JFr9qXdiSSY

There is 1 joint between the rod shape and the "sleeve". It gets into a state where the slider is "lopsided" and takes a long time to return to normal configuration.

I'm pretty sure this happens with the dCustomHinge as well. (maybe all joints?)

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

I see, yes that look wrong.

But not is doesn't necessarily has to happens with all joints, only with joints that inherit from the same base as the slider.

The slider is different the hinges in that hinges lock all three linear degree of freedom while sliders do not.

My guess is that some how the calculation of the pivot some how becomes incorrect.

Or maybe something I suspected was not going to happens, and that is that the penalty error correction, in the joints has been reduced to a bare minumun, after all the derivatives and the solver is exact.

I am almost 100 confident this is the problem.

This is one of the major difference between a force based and an impulse based solver, is difficult to understand numerically, but once we see graphically it is easy to see it. I will try to explain it and do not worry, if this is the problem there is a solution.

You have notice that in Newton, the way contraint violations get resolved, is that the error is eliminated at a more or less constant velocity.

You can see with collision and you see on that slider bug.

What happens is that the engine calculate the contraints derivatives at the time of integration.

These derivative are in the form of an acceleration.

Them the whole system is send to the solver to calculate the force and torque that will satisfy the constraints.

Assuming all the derivatives are correct, and the solver calculation are correct, (I claim they are in newton, or at least is the goal)

The result net force and torque has to be integrated by 0a numerical integration method.

And it is here that the joint can drift apart.

Imagine the forces are such that the integration error is smaller than what the contraint penalty can cope with. This is the case most the time.

The the entire system is stable because the error reduce to zero.

But now imagine a huge impulse is applied, like when you smak the arrage agaisn the floor, even if the solver and the joint is correct, now the numerical integration produces a big error, but since by design the error is reduced at a constant velocity, them you see what you see, the joint come together at a gradual constant velocity.

One of the reasons I do not go about of my way to solve such problems, is that these case are way out of the realm of realism.

If you have areal system and you smack it like that against the floor, believe it will do the bend or break down I, some point.

This is becuase we are talking a several round and g s been generates as reaction forces.

But not is doesn't necessarily has to happens with all joints, only with joints that inherit from the same base as the slider.

The slider is different the hinges in that hinges lock all three linear degree of freedom while sliders do not.

My guess is that some how the calculation of the pivot some how becomes incorrect.

Or maybe something I suspected was not going to happens, and that is that the penalty error correction, in the joints has been reduced to a bare minumun, after all the derivatives and the solver is exact.

I am almost 100 confident this is the problem.

This is one of the major difference between a force based and an impulse based solver, is difficult to understand numerically, but once we see graphically it is easy to see it. I will try to explain it and do not worry, if this is the problem there is a solution.

You have notice that in Newton, the way contraint violations get resolved, is that the error is eliminated at a more or less constant velocity.

You can see with collision and you see on that slider bug.

What happens is that the engine calculate the contraints derivatives at the time of integration.

These derivative are in the form of an acceleration.

Them the whole system is send to the solver to calculate the force and torque that will satisfy the constraints.

Assuming all the derivatives are correct, and the solver calculation are correct, (I claim they are in newton, or at least is the goal)

The result net force and torque has to be integrated by 0a numerical integration method.

And it is here that the joint can drift apart.

Imagine the forces are such that the integration error is smaller than what the contraint penalty can cope with. This is the case most the time.

The the entire system is stable because the error reduce to zero.

But now imagine a huge impulse is applied, like when you smak the arrage agaisn the floor, even if the solver and the joint is correct, now the numerical integration produces a big error, but since by design the error is reduced at a constant velocity, them you see what you see, the joint come together at a gradual constant velocity.

One of the reasons I do not go about of my way to solve such problems, is that these case are way out of the realm of realism.

If you have areal system and you smack it like that against the floor, believe it will do the bend or break down I, some point.

This is becuase we are talking a several round and g s been generates as reaction forces.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

Yeah I have noticed how joints restore back to configuration with a somewhat constant velocity. Is this perhaps a tunable parameter that could be exposed via the sdk? (Not that its a real fix to the root problem, but might be a nice thing to be able to tune ie the "speed of joint restoration").

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

I forgot to mention that the shapes are about 1/4 newton units wide. so 1/4 units smaller than I usually test with.

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

what does it mean 1/4 newton units wide?

can you give me the specs so that I can recreate it in the sand box tomorrow?

can you give me the specs so that I can recreate it in the sand box tomorrow?

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

Does the scene serialization work these days? I could send you a newton file of my scene.

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

I would like to say yes, but I do not think joints has been reviewed in a long time.

This could be a good test case to revisit joint serialization.

Later I will set one of the slider demo to see if it .ca recreate that case, them we can put the same parameter you are using.

I am sure this can be resolved without much changes.

This could be a good test case to revisit joint serialization.

Later I will set one of the slider demo to see if it .ca recreate that case, them we can put the same parameter you are using.

I am sure this can be resolved without much changes.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

I am looking at this now and somehow the inertia matrix of the cylinder is being computed wrong. This is why I was also noticing strange behavior with the cylinders in my scene.

The mass matrix for a Cylinder of Radius = 0.5 and Height = 1, Density = 1 comes out to be:

[0.112682 0 0 0, 0 0.0959548 0 0, 0 0 0.112682 0, 0 0 0 1]

which is right when I compare with my manual calculation.

The mass matrix for a Cylinder of Radius = 0.25 and Height = 1, Density = 1 comes out to be:

[0.0191748 0 0 0, 0 0.00599717 0 0, 0 0 0.0191748 0, 0 0 0 1]

which is wrong.

The mass matrix for a Cylinder of Radius = 0.5 and Height = 1, Density = 1 comes out to be:

[0.112682 0 0 0, 0 0.0959548 0 0, 0 0 0.112682 0, 0 0 0 1]

which is right when I compare with my manual calculation.

The mass matrix for a Cylinder of Radius = 0.25 and Height = 1, Density = 1 comes out to be:

[0.0191748 0 0 0, 0 0.00599717 0 0, 0 0 0.0191748 0, 0 0 0 1]

which is wrong.

Last edited by MeltingPlastic on Sun Apr 14, 2019 12:58 pm, edited 2 times in total.

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

Something must be wrong in the following short code:

volume is computed correctly.

mass is computed correctly.

interia matrix is not.

I really don't understand what I could be doing wrong.

The Inertia matrix for Radius = 0.25, Height = 1, Density = 1 should be approx:

[0.076 0 0 0, 0 .024 0 0, 0 0 0.076 0, 0 0 0 1]

I am using these equations as reference:

http://scienceworld.wolfram.com/physics ... inder.html

- Code: Select all

float vol = NewtonConvexCollisionCalculateVolume(resolvedCollision);

NewtonBodySetMassProperties(newtonBody_, mass_, resolvedCollision);

//save the inertia matrix for 2nd pass.

NewtonBodyGetInertiaMatrix(newtonBody_, &finalInertia[0][0]);

URHO3D_LOGINFO("Final Inertia Matrix: " + String(NewtonToUrhoMat4(finalInertia)) + " Mass: " + String(mass_) + " Volume: " + String(vol));

volume is computed correctly.

mass is computed correctly.

interia matrix is not.

I really don't understand what I could be doing wrong.

The Inertia matrix for Radius = 0.25, Height = 1, Density = 1 should be approx:

[0.076 0 0 0, 0 .024 0 0, 0 0 0.076 0, 0 0 0 1]

I am using these equations as reference:

http://scienceworld.wolfram.com/physics ... inder.html

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

It should be almost the exact value that is showing on the analytical formula. Just a little smaller.

I am not at the computer now, but as I remember the the closed primitive use the analytical formula.

Other use the divergence Gaus theorem.

The later has to polygonize the shape using the same function used for debug display. So the result should be very close to the ideal one but smaller.

I will verify that this is the case. But this has been like that for many years.

I am not at the computer now, but as I remember the the closed primitive use the analytical formula.

Other use the divergence Gaus theorem.

The later has to polygonize the shape using the same function used for debug display. So the result should be very close to the ideal one but smaller.

I will verify that this is the case. But this has been like that for many years.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

The inertia been so wrong may a good reason for the wierd behaviour, basically the object act more like a point mass than a solid body.

One trick to improved stability of jointed systems, is to scale the inertia by some larger than one factor.

In older version on the engine this was done based on heuristic, but starting with 3.xx all hacks has been removed, not inertia, mass ratio, angular velocity clamping. This is left to the client application, and is in some demos.

The only trick that was left is the default velocity damping, but that one is a good thing because most real system do experience similar damping.

One trick to improved stability of jointed systems, is to scale the inertia by some larger than one factor.

In older version on the engine this was done based on heuristic, but starting with 3.xx all hacks has been removed, not inertia, mass ratio, angular velocity clamping. This is left to the client application, and is in some demos.

The only trick that was left is the default velocity damping, but that one is a good thing because most real system do experience similar damping.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

it seems the formula on that side is incorrect. the newton one the is correct.

look at the list of inertia values here in Wikipedia. and check o the solid cylinder.

https://en.wikipedia.org/wiki/List_of_moments_of_inertia

just make sure the calculation is correct, I overloaded the function that calculate the mass properties of a collision shape for a cylinder.

and the analytical values matches the calculated value form the integration according to the wikipedia expression. but does no matched the one in worphan

give that I am tow independent method that yield the same result, I say is the one in newton that so right.

you can check it out by syncing and setting a break point on line 204 file

...\sdk\dgPhysics\dgCollisionCylinder.cpp

uncomment the analytical expression and the step over to calculate the numerically integrated one.

with in the numerical error coming form the polygonal approximation of the surface done by the numerical integration. the value are equivalent.

The reason this was changed to use the integration and no the analytical formula is that in the engine cylinder can have tow radius. and is more difficult to have a general analytical expression for that kind of shape, if you have a general way of doing the same thong.

look at the list of inertia values here in Wikipedia. and check o the solid cylinder.

https://en.wikipedia.org/wiki/List_of_moments_of_inertia

just make sure the calculation is correct, I overloaded the function that calculate the mass properties of a collision shape for a cylinder.

and the analytical values matches the calculated value form the integration according to the wikipedia expression. but does no matched the one in worphan

give that I am tow independent method that yield the same result, I say is the one in newton that so right.

you can check it out by syncing and setting a break point on line 204 file

...\sdk\dgPhysics\dgCollisionCylinder.cpp

uncomment the analytical expression and the step over to calculate the numerically integrated one.

with in the numerical error coming form the polygonal approximation of the surface done by the numerical integration. the value are equivalent.

The reason this was changed to use the integration and no the analytical formula is that in the engine cylinder can have tow radius. and is more difficult to have a general analytical expression for that kind of shape, if you have a general way of doing the same thong.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

The equations look the same to me on both sites: Ix and Iy from wikipedia just need algebraically distributed to match the form in the wolfram page:

https://drive.google.com/open?id=1QOi6J ... ymcjxa2aF4

I'll try using the sandbox and doing some tests.

https://drive.google.com/open?id=1QOi6J ... ymcjxa2aF4

I'll try using the sandbox and doing some tests.

Last edited by MeltingPlastic on Sun Apr 14, 2019 4:54 pm, edited 1 time in total.

- MeltingPlastic
**Posts:**221**Joined:**Fri Feb 07, 2014 11:30 pm

yes I guess they are the same, that would be a very big error, but still remain the fact you are getting those extrange value that I do not see.

I just double checked and the value I am getting for a cylinder of r = 0.25, h = 1.0

is

// numerical calculated

m_inertia {m_f=0x068c56b0 {0.0308950618, 0.0987808779, 0.0987808779, 0.000000000}

analytical calculated

Ixx 0.0312500000 float

Iyy 0.0989583358 float

no sure how you got those values. are you shape scaled? the numerical calculation also have the ability to consider the shape scales, that another reason why using it in favor If the closed form.

I just double checked and the value I am getting for a cylinder of r = 0.25, h = 1.0

is

// numerical calculated

m_inertia {m_f=0x068c56b0 {0.0308950618, 0.0987808779, 0.0987808779, 0.000000000}

analytical calculated

Ixx 0.0312500000 float

Iyy 0.0989583358 float

no sure how you got those values. are you shape scaled? the numerical calculation also have the ability to consider the shape scales, that another reason why using it in favor If the closed form.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

I am guessing your object either has scale or has an offset center of mass from the geometrical center of the shape. Function NewtonBodySetMassProperties use paraller axis theorem to calculate offset inertia.

https://en.wikipedia.org/wiki/Parallel_axis_theorem

is the furmula under the line Tensor generalization. At that point you lose hope of using analytical expression anymore, you have to truth the numerical calculation.

https://en.wikipedia.org/wiki/Parallel_axis_theorem

is the furmula under the line Tensor generalization. At that point you lose hope of using analytical expression anymore, you have to truth the numerical calculation.

- Julio Jerez
- Moderator
**Posts:**11086**Joined:**Sun Sep 14, 2003 2:18 pm**Location:**Los Angeles

48 posts
• Page **1** of **4** • **1**, 2, 3, 4

Users browsing this forum: No registered users and 3 guests