Physics weirdness: Predicting character jump force to reach set height.

Unity Engine
1

Having a slight problem with trying to predict what force to apply to my character’s jump action to reach a set height.

I think my math is correct but I’ll go over it anyway.

In order to calculate the desired velocity I use this basic formula:

FinalVelocity² = InitalVelocity² - (2 * RateOfDeceletation * Distance)

I grabbed this from some random website. I assume it’s correct.

Switching stuff around, as we know the FinalVelocity will be 0 (at the apex of the jump) and given the InitalVelocity (JumpForce) and a RateOfDeceletation (Gravity) I can arrive at the stopping distance (JumpHeight) like so:

JumpHeight = JumpForce² / (2 * Gravity)

The inverse of this being

JumpForce = SquareRoot(Gravity * JumpHeight * 2)

Yet, if I put all this into unity the results from the physics simulation are usually off by 10 to 15% and it seems to vary a lot based on the physics timestep. I’ve tried using rigidbody.AddForce() with the appropriate force modes as well as adjusting the rigidbody.velocity value directly in case Physx was doing something weird with object mass and size calculations but it never runs how it should.

If I plug in a jump height of 2.0 units and calculate the correct jump force, my character jumps 2.22 units high with a physics timestep of 0.03 and 2.14 units high with a physics timestep of 0.02

I can fudge the formula to get it to work. For example:

SquareRoot(Gravity * JumpHeight * 1.75)

The above gets much closer for a physics timesetp of 0.03, but I just don’t like breaking the laws of physics and I’m worried I’ve missed a caculation somewhere.

Does anyone have any insights to share about Unity’s physx hat could explain this?

2

Maybe this is a more simplistic answer than you’re looking for, but in short, you’re solving the problem analytically and PhysX is using an integrator, so the results are unlikely to match up exactly. Making the fixed time step smaller (if that’s supported - can’t remember off the top of my head) should improve things, but that’s probably not a particularly suitable solution, IMO.

Generally speaking, I’m not sure how viable trying to predict the behavior of PhysX in a deterministic fashion will be; if possible, it might be better to opt for a different approach that doesn’t require that.

3

Hmm, insightful, thanks.

I think I’ll stick to my fudged analytically approximation though. I need to use a rigidbody instead of a character controller as it’s rotation restricted and I’m working on a 2D mario-world-like-gravity puzzle platformer for iOS. You can lower the timesetp but of course that’s a performance kill for iOS.

With past platform games I’ve worked on it’s always been very handy to be totally deterministic with the character metrics. You can’t really design solid platforming gameplay without knowing exactly how high/far a character can jump. I also don’t want to re-create all the physics from scratch for performance reasons and need the rigid-body to correctly interact with other physics elements in the levels.

Close enough should be good enough for my needs though and your insights have put me at ease that I was somehow messing up the calculations. Thanks again Jesse!