Running with the current cvs code, I’m crashing inside CollisionTraverser::traverse. It’s coming about because of the call from r_traverse_single to level_state.any_in_bounds(), which is getting bad node_gbv’s. Looks like they are BoundingSphere’s so they pass the is_of_type check, but then have NaN’s for center/radius, so it asserts and crashes further down.
Importantly, it seems to happen much more when I flatten_strong my terrain geometry.
Anyone run into a similar issue or have any tips?
If you end up with NaN’s in any of your transforms, they will contaminate your bounding volumes and eventually cause all sorts of problems.
NaN’s can be introduced accidentally by application code, for instance by making a calculation that divides by zero, or inverts a singular matrix, though Panda does try hard to catch and report this mistake early. It’s still possible to do it accidentally, though.
It’s also possible to contaminate the scene graph if you’re working in threads and have an unprotected race condition somewhere.
Another possibility is that you somehow have left open a floating pointer or other kind of memory error. This is hard to do in Python, but not impossible.
On the other hand, since you reference C++ method names, maybe you are coding in C++. In this case it is very easy to introduce a memory error, which often results in NaN’s in the scene graph.
David
Thanks for the response. Turned out our source data which was generating our terrain had some bad data in it (elevation values of 10^38 ). Sanitizing those values fixed our issue.
Be nice if there was an assert earlier, at the point when the bounding box is being calculated though.
I’ll check the bounding-box generation code for proper asserts. Note that bounding boxes are computed implicitly on an on-demand basis, though, so that probably wouldn’t have been triggered any sooner for you, and it wouldn’t have been any more informative.
The time when it would have been useful to detect this kind of error is at the time the vertices were added. I guess I could put an assert inside GeomVertexWriter::add_data3f(), though I’ve been trying to limit the assertion checks in that very low-level code, for the performance implications. Even though this is technically a non-production build (since asserts are still enabled), people do use it to evaluate Panda’s performance, and an assert down there can make a measurable impact on lots of different systems.
David