some issue on dgBody::IntegrateVelocity

[jiandingzhe]

In another thread (viewtopic.php?f=9&t=6972), I asked some question about collision don't work properly. Sometimes the whole program got stuck when an body using convex hull collision hits something else.

I then tried my program in gdb, and hit ctrl-c when the program stucks. I found it is always in this line, which is a while cycle:
newton-dynamics-rev686/coreLibrary_200/source/physics/dgBody.cpp:574

It seems the cycle never get terminated when the collision happens.

So what is m_omega? At what kind of circumstance it would behave in that way?

Code: Select all

void dgBody::IntegrateVelocity (dgFloat32 timestep)
{

    //   IntegrateNotUpdate (timestep);

    m_globalCentreOfMass += m_veloc.Scale (timestep);
    while (((m_omega % m_omega) * timestep * timestep) > (DG_MAX_ANGLE_STEP * DG_MAX_ANGLE_STEP)) {
        m_omega = m_omega.Scale (dgFloat32 (0.8f));
    }
   
    ......


[Julio Jerez]

you have some bad parameter that i smanin the angular velocity become a nan, or infinity.

[Markus]

You might want to have a look at this thread: viewtopic.php?f=12&t=6716

[jiandingzhe]

you have some bad parameter that i smanin the angular velocity become a nan, or infinity.

How could the angular velocity become a NaN?
My scene is simple: an object drops down to another one.
So it's possible my convex hull is still don't have correct size?

[Julio Jerez]

there are ton of reasons that a nan can result form a float op.

if you are using linux you nee to get the lates version form svn and compile with teh new make file with do no has the fast mass flag.
it also have assert in linuyx tha can tell you whn teh nas happens in the first place.

what happen in the body velocity integration is a cause, the value went bad long before that point.

[jiandingzhe]

there are ton of reasons that a nan can result form a float op.

if you are using linux you nee to get the lates version form svn and compile with teh new make file with do no has the fast mass flag.
it also have assert in linuyx tha can tell you whn teh nas happens in the first place.

what happen in the body velocity integration is a cause, the value went bad long before that point.

I print out the transform matrix each time the body transform callback is called, and found it become weird after collision happens:

Before contact happens, the object just drops down normally. After contact happens, its position become -NaN......

Code: Select all

matrix:
   [ 6.90468e-310, 2.33052e-316, 6.90468e-310, 0]
   [ 6.90468e-310, 2.33052e-316, 7.90505e-323, 0]
   [ 2.33052e-316, 2.33052e-316, 2.33052e-316, 0]
   [ 3, 10.6081, 3, 1]
matrix:
   [ 6.90468e-310, 2.33052e-316, 6.90468e-310, 0]
   [ 6.90468e-310, 2.33052e-316, 7.90505e-323, 0]
   [ 2.33052e-316, 2.33052e-316, 2.33052e-316, 0]
   [ 3, 10.3936, 3, 1]
matrix:
   [ 6.90468e-310, 2.33052e-316, 6.90468e-310, 0]
   [ 6.90468e-310, 2.33052e-316, 7.90505e-323, 0]
   [ 2.33052e-316, 2.33052e-316, 2.33052e-316, 0]
   [ 3, 10.1769, 3, 1]
contact happened
matrix:
   [ 6.90468e-310, 2.33052e-316, 6.90468e-310, 0]
   [ 6.90468e-310, 2.33052e-316, 7.90505e-323, 0]
   [ 2.33052e-316, 2.33052e-316, 2.33052e-316, 0]
   [ -nan, -nan, -nan, 1]
t_PhysicObject: /home/yangxi/Downloads/development/ogre_src_v1-7-3/OgreMain/src/OgreNode.cpp:413: virtual void Ogre::Node::setPosition(const Ogre::Vector3&): Assertion `!pos.isNaN() && "Invalid vector supplied as parameter"' failed.



[Julio Jerez]

in is no the last matrix that is wrong, they are all wrong, because they are not unit matrices.

but in any case that does not tell me anything. you need dto build the version wit the assert on, so that you see where it happens.

[jiandingzhe]

in is no the late matrix tah is wron, they are all wrong, because they are not unit matrix.

buit in any case that does not tell me anything. you need dto build the version wit the assert on, so that you see where it happens.

I found it!!!!
It's my fault. I forgot to initialize the offset matrix with identity matrix...