I have read the threads, and trying to get a grip. The deeper you sink into the physic engine thoughts, the more complex thing become, like real life.
Is this right? :
If I call newtonupdate with the elapsed time since the last call, it will perform right as long as the framrate does not drop below 60 fps, because the lowest value is clamped to 1/60. (Not performing right if the framerate is above 1/1000 either, but that will never happen at least not with DBPRo)
Simplified thesis:
So what happens, if the framerate is 30, Newton will still update the physics to 1/60 resulting in slow motion like effects. We think that e.g. the car should move as far as it does in 1/30 of a sec, but newton only moves it as far as 1/60'th second takes it.
Solution in the 30 fps case:
Call newtonupdate twice every frame with the updatetime set to 1/60. ?
-------
In the Carlab I have clamped the FPS rate to 60 in DBPRo, that means that Newton is performing updates with the timestep 1/60 as long as the computer have enough performance to do 60 loops / sec. IF the fps sinks below 60 the application should perform in a slowmotion like behaviour regarding to physics.
The car feels jumpy at newton update times at 60 , this must be because of the newton system really needs to make calculations above (ca)80 times / sec to make any vehiclejoint perform well. The movement of the system gets a bit too long when making updates below 80 updates/sec.
But if the system goes FASTER than 80 fps, then the newton update would perform right as it only gets smaller updatetimes as long as it is inside the scope of 60-1000 fps. BUT what happens if the application adds a force at higher rate/sec on a faster computer than on a slower, then each update will get a higher frequency of force adding to the system. The total sum of force added to the system Integral gets higher then !
I guess that the best approach would be to LOCK the application looptime to a specific maximum value and perform multiple calls to newtonupdate each with the same fraction of the correct TOTAL time each program loop. If all fractions each loop are added the result should be the same as the actual time of the last loop.
The complexity of the system decides how much the maximum update time Newton needs each Callback. (Minimum framerate , minimum fraction of a second) A very complex system such as a vehicle needs some more precision each call to perform realistic ! So it needs more calculations/ second to make it stable. And this is good as long as the mother application does not perform slower each loop that the actual time needed for each system.
Oh and if the Vsync option is used, we have another Clamped framerate which is hard to predict in an application to deal with right.
(Am I completely out riding the bike, or it is somewhat like this it really works) ?
Paouuh, now I need to think a bit about how to solve this in the code.