Gravity force not applied correctly?

[Riesenmumpitz]

@normen

Before you ask, no, you can’t change these parameters in jME.

I know so I have no choice but to access and interfere bullet directly? Aww maaaan
Sh…t I have no idea how to do that.

[normen]

As I said I wouldn’t approach the problem this way. If you continually want to 100% counter gravity I’d not apply gravity in the first place (and re-enable it when the ship is supposed to fall). I don’t at all see the point of doing anything else. If you want a fly-by-wire system I’d counter the actual velocities.

[Riesenmumpitz]

I get your point, but there is a problem. If I set the body gravity to 0 the body can no longer use gravity as a “up” reference which it could need in some occasions like “standing up”. I know that this whole hovercraft thing and standing up sounds very theoretical and constructed.
But
I’m just trying to produce a consistent system of movement where one can decide what kind of movement the body should suffice. I’m just trying to be prepaaaaaaaaaaaaaaaaaaaaaaaared oops my Lion King came through be prepared for whatever movement one would want to implement with my general movement class.

There is another problem: If I set the body gravity to 0 (and I don’t save it in a field, which I find to be messy programming style) the gravity has to be set to the original value from the outside, meaning the class actually making objects of my class. That’s really not cool
and
the outside class has no idea when the movement class would want the gravity back, because the 0 setting happens on the inside.

[normen]

This is what happens when you try and make library classes do what your own code should do. Wrapping the physics object in another object that has the methods you need would be better, then you could also exchange the physics part with any physics engine without having to change the rest of your code. If you already fell into that trap, extending the physics control to add your own methods (or to “catch” when certain things, like gravity direction etc. are set) would be the next best idea.

[Riesenmumpitz]

I thought this whole physic engine forces and acceleration stuff through again. I think I have the explanation for this strange behavior.

I’m applying my “anti-grav-force” in the prePhysicsTick(). But the engine applies the gravity in between the pre- and “post-” physic methods. Obviously one has to calculate velocity changes somehow and the way to do it, is to take whatever force or acceleration is applied and calculate the velocity change depending on the time difference. The consequence is a back and forth of adding tiny velocity changes in the pre- and corephysic methods resulting from the anti- and the gravity forces. Sadly this depends on the actual time the prePhysicsTick() is conducted and thus a tiny velocity residual comes out when there was a sufficient time difference.
I hope you are still with me

That said this is what in my opinion the physic engine SHOULD do:
Take all forces and accelerations that are applied between two physic ticks, add them all together in the ACTUAL physic tick, calculate the resulting velocity change and apply THAT to the body.
That way all forces and accelerations between two physic tick may cancel each other out and a zero velocity would be achievable.

[pspeed]

If it isn’t already doing that then it’s very strange as anything else is a ton more work for the engine… but you’d have to look at the source to be sure.

[Riesenmumpitz]

As you can see in my earlier post 1 and post 5 I already conducted tests for applying a counter force in the prePhysicsTick() to defy gravity and it didn’t work out. So I’m quite sure it doesn’t do what we both are hoping for

Can you help me out and specify what source you mean and maybe where to find that?

[pspeed]

Bullet and JBullet are both open source. I’d have to do the same googling that you’d do.

[Momoko_Fan]

I guess this is it:

bulletphysics/bullet3/blob/master/src/BulletDynamics/Dynamics/btRigidBody.cpp#L216

Gravity is just applyCentralForce(gravity)…

Then in DiscreteDynamicsWorld:

bulletphysics/bullet3/blob/76b80ca71b029d31e2e2f87b38d417343824c9ef/src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp#L442

applyGravity() is called at the very beginning of step simulation.
So essentially its the same as calling applyCentralForce(gravity) in prePhysicsTick.

EDIT: After a bit more research …
applyCentralForce() is just m_totalForce += force * m_linearFactor;
and velocity is computed like this: m_linearVelocity += m_totalForce * (m_inverseMass * step);

EDIT: Just checked JBullet source code. It basically does the same thing.

[pspeed]

So it does treat gravity as a force (ok) and it does add all forces together before calculating the velocity.

So the issue may be when/how OP was applying his negating force as I guess it was applied more than once.

[Momoko_Fan]

Yep… the sum of gravity and the rest of the forces in that tick are applied to the velocity, which is then integrated to compute the transform. The only room for error here is floating point accuracy.

[Denolven]

@pspeed

So the issue may be when/how OP was applying his negating force as I guess it was applied more than once.

@Riesenmumpitz

@Override
public void physicsTick(PhysicsSpace space, float tpf) {
System.out.println("V post physics: " + player.getLinearVelocity());
}

@Override
public void prePhysicsTick(PhysicsSpace space, float tpf) {
System.out.println("V pre physics: " + player.getLinearVelocity());
if (antigravActive) {
player.applyCentralForce(antiGravForce);
}
}

That’s as bare-bone as it can get. I have no idea where an error could be in there. (A standalone test app is in the first posting.)
What is also weird is that the output shows an error of 1/6, or multiples of 1/6, which is quite huge, even for float.

[normen]

Erm, did you guys read the issue/therad I posted. Its the “jitter correction”.

[Riesenmumpitz]

So sad that the “jitter correction” now actually is producing an unwanted movement instead of preventing one