If scaling is applied to a collision object with a GImpact shape, it no longer collides properly with other physics objects. This issue was discovered by @louhy recently, in master branch, with both jme3-jbullet and jme3-bullet.
Enabling CCD and increasing solverNumIterations didn't seem to help.
On the web, I found a programmer's guide for GImpact:
http://gimpact.sourceforge.net/reference_html/programmers_guide.html
It says:
"At end, you must call btGImpactMeshShape.updateBound for ensure that the shape will build its internal Box set structure"
Currently jme3-bullet-native calls updateBound() during createShape(long) but not during setScale(Vector3f). Thus, scaling results in a size mismatch between the collision shape and its box set structure in GImpact. The more you scale up the collision shape, the worse the mismatch becomes.
If scaling is applied to a collision object with a GImpact shape, it no longer collides properly with other physics objects. This issue was discovered by @louhy recently, in
masterbranch, with bothjme3-jbulletandjme3-bullet.Enabling CCD and increasing
solverNumIterationsdidn't seem to help.On the web, I found a programmer's guide for GImpact:
http://gimpact.sourceforge.net/reference_html/programmers_guide.html
It says:
"At end, you must call btGImpactMeshShape.updateBound for ensure that the shape will build its internal Box set structure"
Currently
jme3-bullet-nativecallsupdateBound()duringcreateShape(long)but not duringsetScale(Vector3f). Thus, scaling results in a size mismatch between the collision shape and its box set structure in GImpact. The more you scale up the collision shape, the worse the mismatch becomes.