Box freezes in mid air after bouncing.

Box freezes in mid air after bouncing.

I have a level set up where I have a box on the ground and I have a smaller box bouncing on it

This is the code I use to set that up.

hkVector4 halfExtents(0.5f, 0.5f, 0.5f);
    hkpBoxShape* boxShape = new hkpBoxShape(halfExtents);

    hkpRigidBodyCinfo ci;
    ci.m_shape = boxShape;
    ci.m_position = hkVector4(0, 30, 0);
    ci.m_motionType = hkpMotion::MOTION_DYNAMIC;

    const hkReal boxMass(10.0f);
    hkMassProperties massProps;
    hkpInertiaTensorComputer::computeShapeVolumeMassProperties(boxShape, boxMass, massProps);
    ci.m_restitution = 1.0f;

    hkpRigidBody* rigidBody = new hkpRigidBody(ci);
    box = static_cast<hkpRigidBody*>(g_pWorld->addEntity(rigidBody));


    hkVector4 he(20.0f, 2.0f, 20.f);
    hkpBoxShape* bs = new hkpBoxShape(he);
    hkpRigidBodyCinfo cis;
    cis.m_shape = bs;
    cis.m_position = hkVector4(0, -2, 0);
    cis.m_motionType = hkpMotion::MOTION_FIXED;
    cis.m_restitution = 1.0f;
    hkpRigidBody* rigidBodyz = new hkpRigidBody(cis);

I have 2 boxes drawn on the screen and I update the transform for the dynamic on by geting the position from it like this.

hkVector4 pos = hkbox->getPosition();
UpdateBoxTransform(pos(0), pos(1), pos(2))

And when I do that the dynamic box bounces off the static box and as soon as its about to loose its upper velocity after bouncing and about to go for another bounce it freezes and stops in mid air.

Does anyone know how to solve the issue and is there anything I'm doing wrong? Thank you!

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Arturs L.

Interesting, the only thing that I can think of immediately is that it might be that the box is jumping high enough that is leaving the broadphase. The broadphase is an AABB that should enclose all your simulated world. This is described in the docs: Havok Physics 2012 -> Simulating a Physics 2012 World -> Creating a World.

There's a callback you can set when an object is leaving the broadphase and by default the behavior is that the entity gets removed as it leaves the broadphase. So what might be happening is that the jumping cube leaves the broadphase and as a consequence we remove the entity from the world, the rigid body is then not going to be updated anymore.

The broadphase size should be set so that all your objects that you want simulated always stay inside the broadphase, as handling objects outside of it is more expensive for collision detection.

A very interesting step that you should look into doing for your game is implementing the Havok Visual Debugger interface so that you can connect the Havok VDB to your game and see the physics side of things as they evolve. :)

Take a look at the docs: Common Havok Components -> Visualization -> Remove visualization with the Visual Debugger. With the visual debugger you can visualize stuff like the broadphase size and debug into these problems more easily.

With the VDB you can also record your physics scenes and post these recordings on the forum so that we can take a look and help you figure out what's going wrong.

Hope this helps!


Try not to become a man of success, but rather try to become a man of value.

Thanks for the reply but I fixed this problem a while back. When I create my world i should have set the m_enabledeactivation to false and that solved it.

Ah great to know, good job tracking that down!

I'm still not sure why a box would ever deactivate in mid-air, I think maybe the box was exiting the broadphase and the out of broadphase handler was trying to deactivate it?

Did you figure out why the box was being deactivated?

In general, deactivation should be enabled as it allows the physics scene to scale keeping the performance to a reasonable level by carefully deactivating stuff that doesn't need to be simulated.


Try not to become a man of success, but rather try to become a man of value.

Hmm, I have this problem when I have the scene running it becomes laggy and some warning shows that timestep has been decreased by 4. Could that be because of deactivation set to false because you mentioned something about performance in your comment above.

Hi Artus,

What I imagine is happening (although I can't be sure because I haven't seen it) is that as your box reaches the height of its arc and so its movement slows down right before it starts coming back down, at this point it is barely moving between each frame, and our deactivation is kicking in, because the solver considers the body to have not moved "significantly" for a number of frames.

As Daniele said above, you definitely want to keep deactivation on if you can. What you can do though is tweak the when a body should be considered deactivated. There is hkpWorldCinfo::m_deactivationReferenceDistance which will apply to all bodies in the world and changes what is considered "significant" movement. And you can also set the deactivation type per body (if for example there is one body you want to be sure will never deactivate) in the cinfo struct, hkpRigidBodyCinfo::m_solverDeactivation. Have a look at the header each of these values are in for more details in the comments, and let us know if anything there isn't clear.

Amy Developer Support Engineer Havok

Also have a look at section Optimizing a Simulation -> Tweaking Physics 2012 Behavior -> Deactivation, in our physics manual for more details and explanations about our deactivation system.

Amy Developer Support Engineer Havok

Thank you for the reply. I'll definitely have a look at that section in the manual, and hope that everything works fine in the end.

Login to leave a comment.