physics: fix assertions when particles get very large positions

Fixes #822
This commit is contained in:
rdb 2020-01-04 21:06:46 +01:00
parent b7017669a1
commit 399797d0b1
3 changed files with 6 additions and 11 deletions

View File

@ -8,6 +8,7 @@ This is a recommended bugfix release, especially for macOS users.
* macOS thirdparty packages are now linked with libc++ (#584)
* Homebrew Python should now locate Panda libraries correctly (#755)
* Work around Tk bug cancelling Load Params in Particle Panel on macOS (#811)
* Fix NaN assertions when particles get very large positions (#822)
* Add support for Autodesk Maya 2020
* Fix maya2egg erroring when running from a pip installation (#709)
* Support .pz and .gz compressed models in deployment system

View File

@ -61,8 +61,7 @@ get_child_vector(const PhysicsObject* po) {
physics_debug(" v "<<v<<" len "<<v.length()
<<" friction "<<friction<<" len "<<friction.length()
<<" dot "<<(normalize(v).dot(normalize(friction))));
assert(friction.almost_equal(LVector3::zero())
|| IS_NEARLY_EQUAL(normalize(v).dot(normalize(friction)), -1.0f));
assert(friction.almost_equal(LVector3::zero()) || v.dot(friction) < 0.0f);
// cary said to cap this at zero so that friction can't reverse your
// direction, but it seems to me that if you're computing: v + (-v * _coef),
// _coef in [0, 1] that this will always be greater than or equal to zero.

View File

@ -89,17 +89,12 @@ get_child_vector(const PhysicsObject *po) {
LPoint3 p = po->get_position();
// get all of the components
int int_x, int_y, int_z;
PN_stdfloat int_x, int_y, int_z;
PN_stdfloat frac_x, frac_y, frac_z;
int_x = (int) p[0];
frac_x = p[0] - int_x;
int_y = (int) p[1];
frac_y = p[1] - int_y;
int_z = (int) p[2];
frac_z = p[2] - int_z;
frac_x = std::modf(p[0], &int_x);
frac_y = std::modf(p[1], &int_y);
frac_z = std::modf(p[2], &int_z);
// apply the cubic smoother to the fractional values
PN_stdfloat cubic_x, cubic_y, cubic_z;