**Moderators:** Sascha Willems, Thomas

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

makes sense. I double checked my math and Yes I made a hand-calculation mistake.

In my pipeline I can specify Scale and/or Original Dimensions of Collision Shapes.

Using both methods seems to be working and I am double checking the numbers. It all works out. Sorry for that.

So now I am wondering if my cylinders in my game are just too small? When building the cylinders I get

Final Inertia Matrix: [0.00102273 0 0 0, 0 0.00102273 0 0, 0 0 2.34265e-05 0, 0 0 0 1]

Edit:

the cylinders still seem "Jumpy":

https://www.youtube.com/watch?v=V6uubKn ... Vw&index=1

In my pipeline I can specify Scale and/or Original Dimensions of Collision Shapes.

Using both methods seems to be working and I am double checking the numbers. It all works out. Sorry for that.

So now I am wondering if my cylinders in my game are just too small? When building the cylinders I get

Final Inertia Matrix: [0.00102273 0 0 0, 0 0.00102273 0 0, 0 0 2.34265e-05 0, 0 0 0 1]

Edit:

the cylinders still seem "Jumpy":

https://www.youtube.com/watch?v=V6uubKn ... Vw&index=1

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

Final Inertia Matrix: [0.00102273 0 0 0, 0 0.00102273 0 0, 0 0 2.34265e-05 0, 0 0 0 1]

what are you try to do a thin rod?

a value like 2.34265e-05 sounds really bad. this will be like try to figure out information out noise in floating point.

try reading the mass matrix, the scale the inertias by say a factor from 2 to 5.

also maybe even clamp so that not value is too small.

what are you try to do a thin rod?

a value like 2.34265e-05 sounds really bad. this will be like try to figure out information out noise in floating point.

try reading the mass matrix, the scale the inertias by say a factor from 2 to 5.

also maybe even clamp so that not value is too small.

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

what is that? some kind of a lego game.

yes that seem like a this is a skew inertia problem hat can only be solve by higher time step and high floating prion accuracy.

try hacking the inertia for this very skewed objects.

some like

1-Read the inertia.

get the maximum if the three values,

if it is too small try scaling by some factor large than 1.0, in general 2.0 if very effective.

the other two you can try that not value is more that sat 5 to 10 time bigger of smaller r that the large one.

this will still give you plausible behavior, cylinder will act as cylinder, by the will be more like hollow cylinders rather that thin rods.

yes that seem like a this is a skew inertia problem hat can only be solve by higher time step and high floating prion accuracy.

try hacking the inertia for this very skewed objects.

some like

1-Read the inertia.

get the maximum if the three values,

if it is too small try scaling by some factor large than 1.0, in general 2.0 if very effective.

the other two you can try that not value is more that sat 5 to 10 time bigger of smaller r that the large one.

this will still give you plausible behavior, cylinder will act as cylinder, by the will be more like hollow cylinders rather that thin rods.

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

Yeah the plan is a "interlocking physics toy" game. Physics is the main gameplay mechanic. Players will be able to attach objects to each other and create complex contraptions. I've seen some pretty good results with recent tests. I do expect that players could make some contraptions that explode perhaps. But it can be managed I think.

The Cylinder has:

mass = .0242

Volume = 1.55291

Length: 1

Radius: 0.0625

Ok I'll try what you suggest and put some limits on relative factor of inertia values.

I may also just try "scaling" everything up in the game. so that the cylinders have length=4 and radius=0.25f for example.

The Cylinder has:

mass = .0242

Volume = 1.55291

Length: 1

Radius: 0.0625

Ok I'll try what you suggest and put some limits on relative factor of inertia values.

I may also just try "scaling" everything up in the game. so that the cylinders have length=4 and radius=0.25f for example.

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

scaling does not solve this kind of problems.

the problem is right here

Length: 1

Radius: 0.0625

the ratio there is about to 15, by inertia are square quantity

so and inertia for that kind of inertia ratio end of wit a diagonal matrix lei this

1 0 0

0 1 0

0 0 0.0004

that a factor of 1 in more than 200

and that a very conservative rough calculation, in reality particle about 1 in 1000

the generate matrix known in numerical analysis as high condition number or ill conditioned.

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

this is high end analysis but I can tell you of the top of my head that a matrix like that has a condition number from 100 to 1000.

in practice to invert a matrix you need about twice the number of digits as the number of digit in the condition number. this means that with a 24 bit mantissa a matrix with a condition number of 1000 can't be inverted reliably.

essentially the matrix inversion yield a matrix that when multiplied by the original does not yield an identity matrix.

the problem is right here

Length: 1

Radius: 0.0625

the ratio there is about to 15, by inertia are square quantity

so and inertia for that kind of inertia ratio end of wit a diagonal matrix lei this

1 0 0

0 1 0

0 0 0.0004

that a factor of 1 in more than 200

and that a very conservative rough calculation, in reality particle about 1 in 1000

the generate matrix known in numerical analysis as high condition number or ill conditioned.

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

this is high end analysis but I can tell you of the top of my head that a matrix like that has a condition number from 100 to 1000.

in practice to invert a matrix you need about twice the number of digits as the number of digit in the condition number. this means that with a 24 bit mantissa a matrix with a condition number of 1000 can't be inverted reliably.

essentially the matrix inversion yield a matrix that when multiplied by the original does not yield an identity matrix.

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

doing trick like that is how I make my living. this required a lot of experience in numerical analysis because people do not even understand why it fail and immidially blame the technology.

but this has nothing to do with technology, it has to do with how continued precision floating point numbers are represented using finite precision in a computer.

but this has nothing to do with technology, it has to do with how continued precision floating point numbers are represented using finite precision in a computer.

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

Ok - I am seeing better behalvior when setting Inertia Matrix values to be close to each other.

I'll let you know if I see weird joint behavior again once I get that part working. But it should be a bit better now that the bodies are more stable.

I'll let you know if I see weird joint behavior again once I get that part working. But it should be a bit better now that the bodies are more stable.

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

Even after hacking the inertias I am seeing offcenter pivoting of the slider constraint.

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

you may be right an dthe is a fundamental bug is the slider joint.

the funtion that submit the constraing try to project the pivot to the slider position liek this

but this is a big mistake, because the design of the constraint assume the pivots do no move relative to each other. be projection the base pivot to the position of teh sliding pivot I am in effect adding a relative velocity between the pivots.

thsi implied two thing a relative derivative which is a big deal since affect all other joints, plus a Coriolis term.

I will revisit that slider joint thsi weekend and see if this is a problem, but I believe that moving the pivot is not correct.

I never notice because slider are mostly use on this that ten to move slowly, and the effect off moving the pivot is generally compensated by the joint penalty.

anyway I will check it out

the funtion that submit the constraing try to project the pivot to the slider position liek this

- Code: Select all
`const dVector& pin = matrix1[0];`

const dVector& p0 = matrix0.m_posit;

const dVector& p1 = matrix1.m_posit;

dVector projectedPoint = p1 + pin.Scale (pin.DotProduct3(p0 - p1));

NewtonUserJointAddLinearRow(m_joint, &p0[0], &projectedPoint[0], &matrix1[1][0]);

but this is a big mistake, because the design of the constraint assume the pivots do no move relative to each other. be projection the base pivot to the position of teh sliding pivot I am in effect adding a relative velocity between the pivots.

thsi implied two thing a relative derivative which is a big deal since affect all other joints, plus a Coriolis term.

I will revisit that slider joint thsi weekend and see if this is a problem, but I believe that moving the pivot is not correct.

I never notice because slider are mostly use on this that ten to move slowly, and the effect off moving the pivot is generally compensated by the joint penalty.

anyway I will check it out

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

I am going over that joint looking at thsi problem in particular,

regard this idea

achieving a constant is a eassy concept speed is quite difficult to archive, the problem is that tha whole idea of contain dynamic is that the constraint most be workless.

this is to say tha the relative motion on the constraint line of action most be zero.

this is stated as J dot v = const.

that is J is the line of action, and v is the relative velocity between teh tow point of contact.

so if I apply a contact velocity that is too high, at some point when teh error is reduced It must apply some acceleration so that is does no over shoot. thsi acceleration the propagate over the entire system adding extra gratuities energy.

the method I use is to use an implicit integration of a very high spring and damper that is always calculation the accelration to reach zero velocity at the zero error point. this paraments are calibrate for a 1/60 fps, and I never change them, I suppose I can recalibrate them, but leaving them for the end user is a recipe for disaster.

Liek you said, doing that is no a real problem, I rather find out what the two bodies are separating after a subthem violent contact, I beleive the reason is that the contact joint is no considering the gyro and centripetal derivative. I always consider that contacts are a spurious thing no worth conspiring gyro effect, by that fact is that smacking the wat you are doing does produce huge angular velocities that is not considered by the contact than is not passed to the connected bodies and the bodies move with different acceleration.

I am working on that over the weekend and them we can test again.

regard this idea

MeltingPlastic wrote: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").

achieving a constant is a eassy concept speed is quite difficult to archive, the problem is that tha whole idea of contain dynamic is that the constraint most be workless.

this is to say tha the relative motion on the constraint line of action most be zero.

this is stated as J dot v = const.

that is J is the line of action, and v is the relative velocity between teh tow point of contact.

so if I apply a contact velocity that is too high, at some point when teh error is reduced It must apply some acceleration so that is does no over shoot. thsi acceleration the propagate over the entire system adding extra gratuities energy.

the method I use is to use an implicit integration of a very high spring and damper that is always calculation the accelration to reach zero velocity at the zero error point. this paraments are calibrate for a 1/60 fps, and I never change them, I suppose I can recalibrate them, but leaving them for the end user is a recipe for disaster.

Liek you said, doing that is no a real problem, I rather find out what the two bodies are separating after a subthem violent contact, I beleive the reason is that the contact joint is no considering the gyro and centripetal derivative. I always consider that contacts are a spurious thing no worth conspiring gyro effect, by that fact is that smacking the wat you are doing does produce huge angular velocities that is not considered by the contact than is not passed to the connected bodies and the bodies move with different acceleration.

I am working on that over the weekend and them we can test again.

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

alright I finished support for gyro for all joints including contacts, and on all solvers.

It made a big improvement on the double hinge and all the gyro demos now work as Newtonian physics dictated (within the limit of numerical integration errors of course)

if you are reading this please try the slider again but when you crated the bodies

call function void dgBody::SetGyroMode(bool state) on the participants bodies.

I had not tested with all joints yet, I will do it this weekend and if this behaved as expected, I will make gyscopic torques an unconditional funtionality that has to be turned off by setting the inertia like we has been discussing.

I never liked the option but I had to added it because Gyro torques are very non linearly and the predictor corrector integrator I had before did not quite handled very well.

now the integration is implicit for in all solver so maybe we call let gyro be on by default

one of the reason I did this is because I am working on a dynamic ragdoll that the limbs are all very skew shapes and there the motors do not behave as expected because of the missing gyro torques.

setting the inertia spherical is not really a good solution.

I though this was not going to be a problem, but it turned out that muscles make high move at high speed and stops that generate significant gyro torques on the limbs. but that a different story.

anyway I just wanted to let you know that there was a change that might help with this problem, or maybe not.

It made a big improvement on the double hinge and all the gyro demos now work as Newtonian physics dictated (within the limit of numerical integration errors of course)

if you are reading this please try the slider again but when you crated the bodies

call function void dgBody::SetGyroMode(bool state) on the participants bodies.

I had not tested with all joints yet, I will do it this weekend and if this behaved as expected, I will make gyscopic torques an unconditional funtionality that has to be turned off by setting the inertia like we has been discussing.

I never liked the option but I had to added it because Gyro torques are very non linearly and the predictor corrector integrator I had before did not quite handled very well.

now the integration is implicit for in all solver so maybe we call let gyro be on by default

one of the reason I did this is because I am working on a dynamic ragdoll that the limbs are all very skew shapes and there the motors do not behave as expected because of the missing gyro torques.

setting the inertia spherical is not really a good solution.

I though this was not going to be a problem, but it turned out that muscles make high move at high speed and stops that generate significant gyro torques on the limbs. but that a different story.

anyway I just wanted to let you know that there was a change that might help with this problem, or maybe not.

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

Hi Julio,

Sounds Great! I'll merge the changes in.

Sounds Great! I'll merge the changes in.

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

I just integrated master, and the behavior is the same with the slider joint. Even using hacked inertia, the joint can still wobble.

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

Ok I will recreate that demo on the standard joint demo.

can you tell me the specifications so that I can get a close match?

I just tried all joint and the seem to work fine, no explosion or weird behavior

the is a flag that is use to enable and disable the effect is in file ..\sdk\dgPhysics\dgBody.cpp

line 78. // m_gyroTorqueOn = true;

if you uncommand that will make the gyro on all dynamics bodies.

the problem wit the standard joint demo is that there are not too many adulation there move at high speed, so is difficult to reproduce the bug. The one that do spin fast, only one component of the angular velocity is height so the gyro is small, Gyro torque as a nasty quantity than is very not intuitive. It is the ten generated by the expression

as you can see when Omega is small the whole expression is small even smaller and banish.

This is why you see that most physics engines can get away ignoring this value especially the one base of impulse. The problem happen when tow of the component of Omega are larger that 1.0 and the inertia matrix is non uniform, when this si the case torque that move the bodies sideway are produced and they are hard to integrated with accuracy.

The roller corset demo move fast but the angular velocity are still small, I nee to make a demo that really exposes the problem to see what is going on. It may no even be Gyro, but we have that missing.

can you tell me the specifications so that I can get a close match?

I just tried all joint and the seem to work fine, no explosion or weird behavior

the is a flag that is use to enable and disable the effect is in file ..\sdk\dgPhysics\dgBody.cpp

line 78. // m_gyroTorqueOn = true;

if you uncommand that will make the gyro on all dynamics bodies.

the problem wit the standard joint demo is that there are not too many adulation there move at high speed, so is difficult to reproduce the bug. The one that do spin fast, only one component of the angular velocity is height so the gyro is small, Gyro torque as a nasty quantity than is very not intuitive. It is the ten generated by the expression

- Code: Select all
`crossPrudoct (omega, omega * inertia Matrix))`

as you can see when Omega is small the whole expression is small even smaller and banish.

This is why you see that most physics engines can get away ignoring this value especially the one base of impulse. The problem happen when tow of the component of Omega are larger that 1.0 and the inertia matrix is non uniform, when this si the case torque that move the bodies sideway are produced and they are hard to integrated with accuracy.

The roller corset demo move fast but the angular velocity are still small, I nee to make a demo that really exposes the problem to see what is going on. It may no even be Gyro, but we have that missing.

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

the rod:

Length: 4 * .25

Diameter: 1 * .25;

the outer body (cube):

length: 2 * .25

width : 1 * .25

height: 1 * .25

the constraint pivot is in the center of both bodies. with sliding limits turned on.

I'll work on getting a packaged demo for you.

Length: 4 * .25

Diameter: 1 * .25;

the outer body (cube):

length: 2 * .25

width : 1 * .25

height: 1 * .25

the constraint pivot is in the center of both bodies. with sliding limits turned on.

I'll work on getting a packaged demo for you.

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

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

Users browsing this forum: No registered users and 4 guests