By adding a shooter to my test program, I convinced myself that the debug shape does not match the physical object unless phyScale=1.
In fact, shape.setScale(phyScale) seems to have no effect on the physical object. Regardless of what value I assign to phyScale, the object behaves as if it has radius of 0.4 world unit, a cylinder height of 0.8 wu, and a total height of 1.6 wu.
Meanwhile, phyScale=2 results in a debug shape with a radius of 1.6 wu and a total height of 4.8 wu. I expected it to be twice the size of phyScale=1, in other words, radius of 0.8 wu and a total height of 3.2 wu. Apparently phyScale gets applied to the radius twice and never to the cylinder height.
So now I have two issues: (1) I can’t set the scale using setScale() and (2) when I use setScale(phyScale) with phyScale>1, the debug shape doesn’t match the physics object.
I’ll poke around in the JME3 source code, but the physics section is rather obscure so I’d appreciate some help here.
It won’t be in jME before we move to native bullet completely, but it should be in the alpha native bullet implementation already. jbullet doesn’t seem to be extended anymore. jME gets a mesh from the bullet debug system, it doesn’t do much more than display it.
It won't be in jME before we move to native bullet completely, but it should be in the alpha native bullet implementation already. jbullet doesn't seem to be extended anymore. jME gets a mesh from the bullet debug system, it doesn't do much more than display it.
Native bullet provides a friendly runtime warning that "CapsuleCollisionShape cannot be scaled" and generates a debug shape that's not scaled. Good enough!
I this is probably from a workaround warning that was in the initial jbullet version but was removed as the statement isn’t exactly true (its just a bug in bullet and only applies to immovable shapes). When we finally move I’ll remove that check too.
I’ve hit this issue again, this time in JME 3.1-stable, using native Bullet and a BoxCollisionShape (which is scalable).
Apparently the native getVertices() method invoked by DebugShapeFactory.getDebugMesh() takes the shape’s scale into account. If the collision shape has scale != (1,1,1) when getDebugMesh() is invoked, the debug mesh reflects that scaling. Later, when the debug mesh is rendered, the shape’s scale is also applied to the geometry (by the AbstractPhysicsDebugControl’s controlUpdate() method).
To summarize, the scale is applied 2x in the visualization, which explains why it doesn’t match the physics. The issue is currently present in the JME ‘master’ branch (on which 3.2 will be based). I will file an issue and submit a fix.