I have a scene with some static cube geometries (no ODE bodies), and some dynamic cubes with bodies. On Windows, ODE gives a bNormalizationResult failed assertion when a dynamic cube collides with something. On Linux (Ubuntu) everything runs fine. Any idea what I’m doing wrong? Will I have to recompile Panda or something?
This is not a problem in Panda, but in ODE.
I’m pretty sure other ODE users have had this problem before:
google.com/search?hl=en&q=bN … tionResult
I realize it’s an ODE problem. However, the error in question seems to originate from ODE’s normalize function, which could be called by any number of functions in ODE. Any idea how to debug it without making a completely new C++ project?
After some more testing and experimentation, the problem seems to occur in edge case scenarios when FPS lag causes objects to penetrate deeper than normal. The error now occurs rarely enough to be overlooked. But now my question is, how can I disable the assert to keep the app from crashing every time this happens?
DISCLAIMER: while I’m familiar with both ODE and Panda, I haven’t used the version of ODE integrated into Panda.
With ODE (or most any physics simulation library) it is generally recommended to run at a fixed frame rate. You might want to try picking a reasonable frame rate, say 60 FPS, adding delays to the Panda loop when a single loop finishes more quickly than 1/60th or a second, and if a frame takes longer than 1/60th of a second just treat it as 1/60th of a second anyways. In this final case you will get some slowdown, but the physics system will remain stable.
A simpler solution for the long frame problem that might suffice if your game physics are otherwise stable would be to simply have a maximum threshold for frame time, and if a frame exceeds it then simply divide the time slice in half and run the ODE update twice (or more times, if necessary, to ensure that each time slice is within limits). This will help prevent over penetration. however, if ODE updates take a significant part of your frame time, then it is possible that the doing multiple updates per frame could make each frame longer than the last, requiring an exploding number of updates.
Since I’m not familiar with the specifics of the ODE integrated into Panda I’m not sure if either of these solutions present any real difficulty, but they should be pretty straightforward.
In general it is impossible to guarantee that a complex physics simulation always runs at a consistent and high framerate, so that safest thing to do is the first suggestion, use a fixed frame rate for physics updates to ensure stability and let the actual game slow down if necessary if your hardware can’t keep up with the processing load.
Here’s a code sample showing how to do run the ODE loop at a constant timestep without affecting the FPS (I don’t know how accurate this is):
panda3d.org/manual/index.php/Simul … sics_World
(Original viciously stolen from drwr.)
[edit @ pro-rsoft] Thanks for the reference, looks like it implements what Arkaein was talking about.
Still, I don’t want the whole game to crash any time there’s a minor glitch. Will I have to recompile to disable the asserts?
I don’t know. You should ask at some ODE forum or so – you shouldn’t really expect to find much ODE experts here.
Right. I’ll post back here for future reference if I find anything.