Simulation crashes when rigid body leaves broadphase world?

Simulation crashes when rigid body leaves broadphase world?

Well, right now I'm having a slight problem. The rigid bodies update and such, but after hkpWorld::stepDeltaTime() is called four times, the program crashes. Now, the error report outputs this:
.WorldBroadPhaseBorderhkpBroadPhaseBorder.cpp(125): [0xf013323d] Assert : '0
Entity left the broadphase. See hkpWorldCinfo::BroadPhaseBorderBehaviour for details.'

But I am calling this before creating the world ( m_info = hkpWorldCinfo )

Now, why would this happen? It does it as well when I leave the broadphase world size at its default value as well.

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

Hey benny53,

Your application will crash if rigid bodies leave the broadphase. You should have the broadphase size set so that this never happens. For some reason, the position of one or more of your rigid bodies is changing so that it's outside of the broadphase of your world. Can you debug and see if this is happening to any of your rigid bodies? I'm not sure how many rigid bodies you have in your simulation, but if there aren't many you could look at the position of each one when you crash and then see where it's going bad.

The default size is 1000.0f, which means as long as the x, y and z components of the position of every rigid body are between -500.0f and +500.0f they're within the broadphase.

Once we find out why your rigid bodies are leaving the broadphase we can fix this problem. What sort of interactions are happening in your simulation? Are you calling setPosition() on any of your bodies or doing applyForce() or apply[Linear/Angular]Impulse()?


Ok, I got it working. It seemed almost as if the gravity was being applied way to much by the numbers output by the console I was using. You can see it in these two lines output from the console:
{X:0 Y:61.53209 Z:0}
{X:0 Y:1.767788 Z:0}

That is just before it hits the box. The step before that it output {X:0 Y:117.0275 Z:0}. So its moving about 40 units per step, which seems a little much since the default is -9.8f or something of that nature. But this may be normal, who knows.


That certainly is big change. I would expect a 40 unit change after 2.86 second of simulation* but not after only 4 steps.

It sounds like you don't have anything to stop your rigid body from falling out of the broadphase. This is done by making sure that it will be caught by a fixed rigid body (hkpRigidBody set up with motion type MOTION_FIXED). Have a look at the Add/Remove Bodies demo to see how this sort of arrangement of rigid bodies is done. (Physics->Api->Dynamics->World->Add Remove Bodies).


s = 0.5 * a * t^2
-40 =~ 0.5 * -9.8 * 2.86^2
(1 Havok unit = 1 meter)

Yeah, it seems large.

I have something now, whereas before I did not. Before it was deliberate though, because somehow I was getting access violations so I had to rewrite my code ( couldn't find out where before ). I have a box now, and it does stop the dynamic rigid body. However, the values of the X and Zvalues have very large float numbers ( I believe just many post decimal numbers though ). It was running for 4 steps because of the position put it at in the hkpRigidBodyCinfo. The larger Y value I had, the longer it would take to crash ( however it seems that Havok predicted the crash almost, as my program cut input before the rigid body would leave the bounds, however, if there was something to hault its downward fall, it wouldn't crash and would receive input. )

These are three positions output consecutively by my programs main loop.

{X:5 Y:117.0275 Z:0}

{X:5 Y:61.53209 Z:0}

{X:5 Y:1.767788 Z:0}

As you can see, the difference between the last two steps Y value is 60 units, then the first two steps difference is approximately 56. Why would it be moving this greatly? Mind you this box begins at positive 450, however that should not affect this problem at all, right?

450 meters is a quater of a mile high. Falling from that height, by the time you get to zero I can imagine you'd be going pretty fast, and since havok isn't doing wind resistance or anything there's no drag so you don't reach terminal velocity you'll just keep accelerating. The next question is how big is your gravity set to?

Try starting the box closer to the ground maybe? Also, make sure you're stepping the simulation with a valid DT, it should be around 0.016 for about 60 frames per second.

Yeah, I figured out that it was gaining speed over time by looking at the values output by my console. I set it lower then realized this. And my gravity is default right now, so approximately -9.8f I believe.

How can I make it, like in the demos, the app doesn't crash when a rigid body leaves the broadphase world?

To stop the assert when the object hits the edge of the world, check out the comments on hkpWorldCinfo::BroadPhaseBorderBehaviour. The default value is BROADPHASE_BORDER_ASSERT, but you could change it to REMOVE_ENTITY or FIX_ENTITY just as easily. DO_NOTHING is not recommended for performance reasons. You can also define your own custom behavior by subclassing hkpBroadPhaseBorder - see the FountainDemo for an example.

As for the objects falling too fast, are you accidentally using a big timestep? You'll usually want to use 1/30 or 1/60 (depending on your game's framerate).

johnb003, getting off topic, but you can simulate drag with linear damping by setting hkpRigidBodyCinfo::m_linearDamping, or you could fake critical velocity with m_maxLinearVelocity. Our damping force is proportional to the velocity, whereas IIRC, high velocity air resistance is proportional to the square of the velocity. But if you really wanted to, you could increase the damping value based on the velocity to simulate "real" air.

Yeah, was apparently using a gigantic timestep. found that out when I went in and added graphical representations of the rigid bodies. It explained everything weird that was happening. And I'll look into all the border behaviors.

Thanks for clarifying Chris. I didn't mean to suggest it wasn't possible, just as an explaination of why Benny's objects were reaching such high speeds, given the defaults.

And yep, drag would be based on speed squared and surface area.

Login to leave a comment.