Ok, here we go again…
I have hijacked-in 3 core funcs… in lines 1-26. They are over-riding default funcs properly (see console), and all 3 are involved in our issue, here.
Line 265… I’m calling LOCAL setMass(0) when scene isReady… just like other tests we’ve done. Cedric’s setBodyMass(0) work-around line is at line 264… handy for alternative testing. SetBodyMass() is one of the local funcs, too… lines 21-25.
The “L” key currently uses Cedric’s setBodyMass(.1) work-around (line 253)… with a setMass(.1) in line 254, handy for alternative testing.
The only significant difference between setMass() and setBodyMass()… is lines 6-7 impostor param adjusting. SetParam() is also a local func, (lines 15-19), and line 17…
this._bodyUpdateRequired = true; … is the root of all evil. That is the ONLY significant difference between impostor.setMass() and plugin.setBodyMass().
Whatever happens during a “bodyUpdate”… is disrupting our impostor.setMass() calls… making them act differently than plugin.setBodyMass() calls. hmm.
Ok, that’s all I have so far. I’m heading out to try to determine what happens… during a body update.
Anyone want to bet… that the bodyUpdate does an impostor/body replacement, but forgets to re-add the joints that were previously-attached to the original body? (just guessing)
Maybe more precise, perhaps it re-adds the joints ok, but it forgets to set the original collideConnected values FOR those joints? hmm. Help welcome, as always.
Sidenotes: We have a physics method laying around… called… umm… .updateForScaling() or something like that. THAT function… is supposed to be called after you scale a mesh that has an impostor assigned. IT… uses a replace-the-impostor-with-a-new-one operation, which I always thought was a bit dangerous. I wonder if THAT function… re-adds the joints and honors the collideConnected values previously put-onto those joints… so they act the same after the mesh scaling.
I’m not sure that “install a replacement impostor” is EVER a good idea. I know @RaananW somewhat disliked it, but was unable to find a more sane way of updating the scaling on a physics-active mesh.
Cannon might “see” those impostor replacements… and say “ok, i saw an impostor replacement, so all previous joint collideConnected settings for joints attached to the original impostor… are now null and void.” Essentially, Cannon could be erasing all collideConnected data… when it sees the impostor be replaced.
IF… CannonJS stores its collideConnected settings… via .collisionFilterGroup and .collisionFilterMask properties… then OUR setMass->setParam->bodyUpdate must adjust pEngine.collisionFilterGroup and .collisionFilterMask… so that it honors the newly-installed impostor (IF bodyUpdate IS doing a replacement).
---- Update ----
Four occurrences of
_bodyUpdateRequired found on BJS impostor class. One of them… takes us to the plugin… .isBodyInitRequired() area… line 99.
There, yep, old body, new body, all sorts of “fresh init” stuff, which could easily kill any collideConnected settings that WERE on the joints, which are/were attached to the original body.
So, impostor.setMass() calls impostor.setParam()… which sets impostor._bodyUpdateRequired = true… which causes cannonPlugin.isBodyInitRequired() to return true, which causes a replacement of the p-body… which causes our joints to lose their collideConnected settings, which makes impostor.setMass() act differently than plugin.setBodyMass(). Yuh, yuh, yuh. Ugly.
Impostor.setParam() should probably NOT set impostor._bodyUpdateRequired = true… for all param settings… especially not for changes to mass. But maybe more, too (friction, restitution). We don’t have setFriction() and setRestitution() funcs, yet, but, we probably should/could. Maybe impostor.setParam() should NEVER EVER set impostor._bodyUpdateRequired = true.
Disabling line 17 in the above PG… makes the legs “lay flat” better… as they should, but the model slowly sinks thru the ground for some reason. Interesting.
Cannon’s physics body has a .updateMassProperties(), but no .updateFrictionProperties() or .updateRestitutionProperties(). So I suspect Schteppe wants us to avoid on-the-fly friction and resty adjustments.