I have been trying to get a speed and dampening based off of a time and distance, but I have been encountering some weird problems where unity would decrease the velocity after a second more than it should by the dampening. If the physics updates in fixedupdate the velocity after a second is constant, but still not in line with what it should be with the dampening, but not at all in update. Here I would like to ask why the velocity calculation is 1 / (1 + dtime * damp) instead of 1 / (damp + 1) ^ (1 / dtime), so the velocity is constant over x seconds if the dampening is the same. The current system means objects slow down more at higher frame rates and makes velocity unpredictable at unfixed framerate. it is still hard to find a speed and dampening based off of a time and distance and have it be exact due to framerate changes but at least keeps velocity in line with the dampening across variable frame rates. if there are any reasons that the current system is better I would like to know, because all I could think of was simplicity for both readers and the computer. Thank you!
My Test
It doesn’t help that you’ve tagged your post with 2D and 3D physics which are different back-end systems. Your “My Tests” is an empty bit of code so that doesn’t clarify anything.
For 2D physics which currently uses Box2D v2 you can see the damping equation here where “h” is the time-step and “v” is the linear velocity: box2d/src/dynamics/b2_island.cpp at 411acc32eb6d4f2e96fc70ddbdf01fe5f9b16230 · erincatto/box2d · GitHub
Frame-rate is nothing to do with this if you’re running in the fixed-update.
Yes, I agree that it wouldnt have a problem if physics is in fixedupdate, but I would also like a system for players to control fixedupdate time for less desync for higher end pcs or turn it down for slower updates but less computation power, and even across different fixedupdate times the velocity after say 1 second changes, making it harder to predictably gauge how fast or how far it will be after x seconds based on a speed and dampening. My change makes the speed more predictable, but the distance still varies. I also do see that my test did not save and I have already fixed it. I appreciate the reply and taking your time to help me.
I have found a fix, although it is not the most elegant and seems pretty computation intensive, but a solution it is. I used integrals to find the distance, since it is pretty much just the area under the curve of speed / (dampening ^ time), which lead me to the equation
distance = ( 1 - 1 / ( dampening ^ ( ln (speed) / ln (dampening) ) ) ) * speed / ln (dampening)
This was nice because I thought I could then relate the dampening and speed to the distance. This gave the problem of: This feels impossible, but this was only a product of being stuck on thinking the distance and time = dampening, and dampening and time = speed. This ended being the furthest from right, because it looked more like this:
flowchart
Distance --> Speed
Speed -->Dampening
Time-->Dampening
Speed-->NewDistance
Dampening-->NewDistance
NewDistance-->Equals?
Distance-->Equals?
Equals?-->Yes
Yes-->Return:speed
Equals?-->No
No-->DivideAndConquer
DivideAndConquer-->Speed
As a result of this dampening is just the time’th root of speed.
Although this works and doesnt seem to break (at least not yet), this doesn’t actually solve my second problem of distance also not being constant over framerates, which I saw as another problem for integrals to solve. With this one I only wanted from t0 → t1 so it ended up being pretty much the same integral.
DeltaDistance = ( 1 / (d ^ t0) - 1 / (d ^ t1) ) * speed / ln(dampening)
I feel like this can be pretty intense on the computer if many objects are moving at once, so I would only use this where you want something to be super precise, even though I am using it for a particle system lol, the problem just got me really interested. If you have anything to add, or improve on (because I heavily doubt this the best or even a good solution). Thank you!