If I set gravity = 0, nothing falls. If I set it to any other value such as (0.000000005 * accuracy), things fall at an apparently constant speed. I have to conclude that it is not doing what is claimed for it.
I see PhysicsSpace has an applyGravity() method with no detail provided. Am I supposed to be calling this? If so, from where?
related questions:
Why are methods such as “setGravity()” written in such a manner that I must multiply my desired acceleration by the accuracy of the physics layer? Isn’t that something the Bullet code should be doing to spare me knowledge of its inner beauty? Also, why isn’t gravity by default 0, or 9.8-ish, given Bullet’s stated reliance on metric units?
regarding methods such as
void prePhysicsTick(PhysicsSpace space, float f)
Called before the physics is actually stepped, use to apply forces etc.
What is “f”? It’s not explained.
tone
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.
well f indicates that the number being used is a float (as opposed to an int)…
Why are you multiplying the setGravity value by the accuracy? According to the documentation i am looking at setGravity needs to be a vector that indicates the direction and magnitude of the effect. The applyGravity appears to assign this affect to all the objects in the physics space
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
As said in the javadoc (are you using eclipse? read the manual on how to set up javadoc with sources.), you have to either set the gravity globally on the space before adding objects or on single objects after adding them to the physics space. Its not like anything was broken here, its solely how you use it.
Setting Gravity is the first thing I do.
[java]
sApp.getStateManager().attach(sBulletAppState);
PhysicsSpace ps = sBulletAppState.getPhysicsSpace();
ps.setGravity(new Vector3f(0f, 0f, 0f)); // this does nothing … set it however you wish
[/java]
It is a NOP.
My adding a character (which happens later), goes like this:
[java]
// 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());
}
[/java]
tone
The character doesn’t use real gravity or physics at all.
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
I think doing your own character with a ghost control and a kinematic rigid body (or even rag doll control) will give you the best results if the CharacterControl doesn’t do what you want.