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:
2 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
2 Likes
cc @eoin