Open louhy opened 5 years ago
Thank you for documenting this issue.
No problem. It does bother me a little that the issue goes away when solverNumIterations is increased high enough. It makes me wonder whether it's not technically a bug and more a matter of native being a slightly more accurate simulation (I can't imagine why that would be).
I believe that invoking updateBound()
during setScale()
will fix this, for native Bullet at least.
Looks like jme3-jbullet
's GImpactCollisionShape.java
has an update issue similar to that in jme3-bullet
:
cShape = new GImpactMeshShape(tiv);
cShape.setLocalScaling(Converter.convert(worldScale));
((GImpactMeshShape)cShape).updateBound();
cShape.setLocalScaling(Converter.convert(getScale()));
cShape.setMargin(margin);
I'll try moving the updateBound()
into setScale()
in jme3-jbullet
.
@louhy please confirm the fix is good. Also, check whether there's a similar issue with GImpactCollisionShape.setMargin()
.
Nice find! Will double check this fix for you. I think we should make a separate dedicated test for it too (using the code above or a variant), ex "TestIssue1120.java". If there's any way to add me as a second assignee here so I don't forget, feel free.
GitHub allows me to assign up to 10 people to an issue. You're in!
I think I have bad news, good news, great news:
Bad: One problem with adding a test based on code above is that it's using GImpact shapes for some primitives where technically you wouldn't do that in practice (your setting a good example suggestion in the other issue). It may be hard to replace those with other shapes while still reproducing a fall through. For JBullet those cylinders still fall through the mesh. Native is fine, but I don't believe this particular test showed an issue for native. But it's a 0.2 radius GImpact cylinder... do we really care?
Good: The current GImpactShape test demonstrates fall-through (and crazy bounces) with the kettle when scale is increased to 1.8.
Great: When I run the current GImpactShape test against the current master version, not only is this fixed, but JBullet performs WAY better and the crazy bounciness seems totally gone (from testing so far). JBullet actually passes the test criteria now if you're patient waiting for things to go inactive.
I think this restores my faith in JBullet's usefulness...
If 0.2-radius GImpact cylinder falls through in jme3-jbullet, I think that's an issue. Not a high-priority issue for me, but it's an issue.
So can we close this issue (for the latest master
branch, at least)?
Since this looks way better in master now, I'm fine with considering it closed.
I'd be happy to turn the code here into a slimmed down test PR which demonstrates the GImpact cylinder fall through if you'd like.
I'd like to play with that slimmed-down test case.
Hmm, maybe we shouldn't have closed this since the OP is specifically for the JBullet fall-through issue (which still remains). Anyway, I've got a smaller test case eliminating the distractions, and fairly minimal code.
Running this one at half speed by default since it moves kind of fast. I've also made the speed variable. (Don't forget to switch to JBullet before testing.) PR coming next...
Re-opening as suggested.
I keep forgetting what this was referring to (own comments about this being "fixed" above confusing me), so attaching a reminder animation of what this test currently does when you enable JBullet for this test...
This issue is still evident in v3.4.0-beta4.
This issue was discovered while putting together the following test draft. Behavior can be reproduced in JBullet only (tests with native bullet work fine).