jMonkeyEngine.org

You don’t have to multiply anything. You just set an absolute gravity in newton using a vector. Also you don’t have to call anything, gravity is applied automatically. f is tpf, like everywhere in jme.

I was only using PhysicsCharacter.setGravity(float) on my CharacterController.

I had not noticed PhysicsSpace.setGravity(Vector3f) — whose units are not documented.

Playing around briefly, I find that PhysicsSpace.setGravity(Vector3f) reveals it doesn’t appear to function, either.

new Vector(0f, -.00000001f, 0f)
produces the same linear-velocity (as opposed to accelerating) fall as does
new Vector(0f, -1f, 0f)

Indeed, setting it to Vector3f.ZERO produces the same behavior.

Bottom line is that:

A. PhysicsSpace.setGravity(Vector3f) has no effect whatsoever on my character’s behavior.

B. CharacterControl.setGravity(float) turns off “falling” when passed zero, and otherwise enables what appears to be a constant-speed motion downward regardless of whatever positive value is handed in. The speed of this motion seems not to consider the value passed in. Oddly, in a quick test… handing in a NEGATIVE value for this float produces an UPWARD fall whose speed seems to at least honor the magnitude of the number. However, it does not appear to have any basis in physics (at least, it is not modeling units per second acceleration).

Should I try telling Bullet that down is *positive* Y, and tinker with this floating point number? Sadly, I doubt that PhysicsSpace.setGravity(0f, 9.8f, 0f) will be helpful in telling Bullet that gravity should act toward +Y

tone

Setting Gravity is the first thing I do.

        sApp.getStateManager().attach(sBulletAppState);
        PhysicsSpace ps = sBulletAppState.getPhysicsSpace();
        ps.setGravity(new Vector3f(0f, 0f, 0f)); // this does nothing ... set it however you wish

It is a NOP.

My adding a character (which happens later), goes like this:

    // an easy-to-use capsule for walking about
    public Walker(Spatial spatial, float overallHeight, float radius, float stepHeight) {
        mSpatial = spatial;

        // bullet capsule shape expresses its height (2nd parm) as the distance between the center of the hemispheres
        // therefore, to get a capsule of actual height H, send in height = H - (2 * radius)
        CapsuleCollisionShape shape = new CapsuleCollisionShape(radius, overallHeight - (2f * radius), PhysicsSpace.AXIS_Y); // radius, height, Y up

        mBulletCharacterControl = new CharacterControl(shape, stepHeight);

        mBulletCharacterControl.setApplyPhysicsLocal(true); // we may be on board a ship, moving relative to it
        sBulletAppState.getPhysicsSpace().add(mBulletCharacterControl);

        mSpatial.addControl(mBulletCharacterControl);
        mBulletCharacterControl.setUseViewDirection(false);
        mBulletCharacterControl.setPhysicsLocation(mSpatial.getLocalTranslation());
    }

tone

Ahh– that explains it then.

Would I have to look at native code to see how it is trying to use those capabilities it has (because they almost work pretty well and could use a little improvement)?

I’ve got it rigged up that I can walk around on a moving, pitching ship on an ocean surface. The only things slightly wrong with it are that gravity always looks down the ship model’s -Y (a reasonable approximation until it lists heavily — I can live with it), but it works nicely around the stated limitation that a mesh-based physics collider has to be static. I work around that by having my sailor be a scene child of the ship and rely on local rather than global flags for the CharacterControl.

tone