I would guess the problem with friction comes from floating point precision. Precision is not infinite, so the computations won’t give exactly the same result for each delta time. As an aside, have you tested with a deterministic lock step?
I noticed deltaTime appears to be in integer milliseconds (7 is the value I noticed). I’ll try to figure out how to set a fixed value of an exact integer milliseconds.
You have some options you can pass to the Engine constructor to set a deterministic lock step (deterministicLockstep, lockstepMaxSteps, timeStep). Also:
2 Likes
How do I set those options in the playground? The variable engine is already initialized?
yes engine is available in the playground
If engine is already constructed in the playground, how do I
In this example playground the engine gets deleted and newly initialized:
You can create your own instance of the engine in the Playground this way:
See also:
3 Likes
Not sure if I set deterministic Lock Step correctly, but I’m still seeing the problem here
Very interestingly, changing timeStep definitely changes the apparent friction. Try 0.1 or 0.2 and the closest pendulum reaches the box corner in about 3 cycles.
A few other things I tried was to accumulate deltaTime and compare to elapsed (from Date.now()). Nothing pops out as indicating a problem. Also queried every axis friction for the distance constraint: all zero. Docs say distance constraint doesn’t have axis friction, so I wasnt expecting any.
Edit: further, 0.1 timestep results in about 5 half-periods until reaching the corner and 0.016 timestep results in about 31 half-periods reaching the corner. 0.1/0.016 is 6.25 meaning that “reaching the corner” is proportional to the timestep. I only looked at the first occurrence and from initial conditions. Interesting observation, though.
I’ve reached a plateau with timestep. My latest iteration contains a constant used for both the engine timestep parameter and the physics setTimeStep():
I also noticed when the rotation for the “string” (cylinder) is vertical, e.g. the ball is straight above the box, there is a slight glitchy movement in the string. This may be related to the ambiguity of getting 180-degree rotation I’ve encountered elsewhere.
I think we have enough data and an easily-editable playground to escalate this issue. Who might best help with the apparent friction being incorrectly added by BABYLON or Havok to this PG, where all friction is supposed to be zero?
All material is set to zero friction and zero static friction, lockstep and framerates are controlled. The PG still demonstrates an unknown friction existing that is proportional to the time step (the tstep variable).
Please help or add an appropriate person to escalate this to. @Evgeni_Popov @birnie @sebavan
3 Likes
cc @eoin
Just checking if you found a solution for this, seems rather interesting
No real solution. I haven’t figured out why the mystery friction exists.
Edit: my current theory is that the linearization of dV near the bottom of each swing inaccurately assumes the calculated value of dV vector is accurate but the application of the constraint essentially pulls the object back to a constrained value.
Put another way: the last time step prior to hanging vertical calculates a dV effectively as tangent to the constraint. Then the next step calculates delta position as past the vertical then pulls the object to the constraint. The next step continues the calculation from the object’s momentum, but we’ve lost the effect of the force of gravity for the small delta between new position back to the vertical. My theory is that this “lost effect of gravity” appears as the mystery friction.