You get six decimal digits of precision in a float. Your number is a rounding error. Floating point math is an approximation and is filled with rounding errors. The fact that you're relying on it being more precise suggests you're misusing them. Direct comparison and direct equality tests are typically a bug.

Think about what a velocity difference that small means. Unless you're talking about enormous distances or enormous times — far greater than typically used in games — those numbers won't be noticed by a human. If you really must have something affected by such a small tolerance, you'll need to do something other than an iterative approach. When accumulation would give overwhelming accumulated error, direct computation from base values rather than accumulation over time is often the right approach. In a physics system like you describe you're talking of being too near the limits of what makes sense to compute, and also a reason that physics systems become difficult to develop.

Many systems have functions that limit precision and drop very small numbers. For example, Unreal often uses a constant “KINDA_SMALL_NUMBER” of 1e-4f for tolerance and truncating, and uses FMath functions like IsNearlyEqual(), IsNearlyZero(), IsWithin() and similar for comparison, and Unity has Mathf.Approximately() for similar use.

Again, floating point is an approximation and you only get six decimal digits of precision.

That means the numbers must be treated as equivalent, -8.033333 and -8.033325 are within rounding error of the same number. You are misunderstanding how they work if you don't treat them as equivalent. It is not just that a human wouldn't notice, they are approximation of the same value.

Many floating point operations work within a tolerance; you can compute it twice with the same input values and get slightly different results and still be valid. You can also have the same printed value but with results that are not binary identical. There are even results that equality tests with == will show they are equivalent but comparing the results with memcmp() show they are different binary values.

If you don't know what you are doing, I would limit your comparison to five digits. That is still accurate within the width of a human hair if you are working in meters. It takes both education and experience to get a feel for how floating point numbers work. It is best to get rid of the misconception that they are an exact number. That means both are -8.0333.

The problem is not exactly with float precision as frob says, but is a problem with how you detect and handle the collision logic with the ground.

The first thing you need is a way to detect the collision in a robust way. It seems like you are just checking to see if the velocity is the opposite of the starting velocity when jumping. This will not work very well (due to precision and accumulated error). You want to detect collisions based on the position. For example, if the ground is at Y=0, the player is in collision if position.y ≤ 0.

The second thing you should do is to correct for any interpenetration of the player and the ground once there is a collision. If the ground is at Y=0 and the player position.y = -0.1, then you need to push the player out of the ground so that it rests on the ground but does not penetrate it. This is easily done in simple cases if you know the surface normal of the ground plane (n=(0,1,0) in this case), and penetration depth (0.1 in this case). Move the player the penetration depth distance along the normal vector to push player out of the ground.

The third thing you need is a better system for time integrating the positions of objects (what is in your apply() function). The canonical form of semi implicit euler integration is like this:

1. Set force vectors for all objects to 0.
2. Apply forces (e.g. gravity force = g*mass)
3. Integrate force to velocity: velocity += force * deltaTime / mass
4. Detect collisions (use velocity for continuous collision detection)
5. Resolve collisions (e.g. resolve penetrations and solve constraints)
6. Integrate velocity to position: position += velocity * deltaTime

You should probably just use the engine's built-in physics engine if it has one, it will simplify a lot of tasks, especially collision detection and response.

For some background information about why floating point behavior is what it is, search for “what every programmer should know about floating point”.

Floating point error aside, the fact that you are not scaling acceleration by delta is a red flag. Your character will move faster on faster computers and slower on slower computers, which is almost certainly not what you want.

…or he could fix the timestep of his simulation.

alvaro said:

…or he could fix the timestep of his simulation.

Yes, using _physics_process (fixed frame rate) instead of _process (variable frame rate) would also work. Although I would still recommend multiplying by delta, just to make it easier to change the physics frame rate later.