Applying forces and delta

[zenith sierra]

Every time I think I understand when to use delta I realise I don't. I understand delta to be the time between frames, and we multiply by it to keep things consistent between different frame rates/refresh rates. This is a function called inside _physics_process. The commented out line is what the tutorial did, above that is what I changed it to. Which is right? lol

func apply_x_force(delta, c_point):
    var dir = global_basis.x
    var state := PhysicsServer3D.body_get_direct_state( car.get_rid() )
    var tire_world_vel := state.get_velocity_at_local_position( global_position - car.global_position )
    var lateral_vel = dir.dot(tire_world_vel)
    target_grip = base_grip
    var desired_vel_change = -lateral_vel * target_grip
    var x_force = dir * desired_vel_change * delta
    # var x_force = dir * desired_vel_change / delta
    var force_position = Vector3(c_point.x - car.global_position.x, c_point.y - car.global_position.y + 0.2, c_point.z - car.global_position.z)
    car.apply_force(x_force, force_position)```

For reference, this is meant to be the sideways force generated by a vehicle wheel against the road. I have raised it up manually a little because I'm tweaking the feel of it lol

[stone seal]

When you use apply_force, the force you apply is automatically multiplied by delta behind the scenes. His original decision to divide the force by delta tells me that he wants those calculations to cancel out, meaning the value of x_force should be applied per frame rather than per second. Why does he want this? No idea, I'm not familiar with the formula. But there's probably a good reason for it.

[zenith sierra]

Awesome, so mine definitely isn't right, and his probably is.
That's all good to know though, thanks!

[short heart]

In physics there are reasons to divide by time to find the rate of change, or with force in particular there are formulas like the calculation of power, momentum or impulse where a force is divided by time.

I don't know what is happening here exactly but this is most likely not am erroneous attempt to make this calculation framerate independent 😉

And just fyi the physics frame rate and delta is fixed for all intents and purposes so multiplying, dividing or leaving it out in this case just changes the magnitude of the result and doesn't do anything fps related

But you still should use and think of the physics delta as if it were variable, just know that it really ain't

[zenith sierra]

Huh, well there is another function that does divide by delta and I know it's calculating the speed the spring is compressing/stretching, so good to know that one is correct.
My understanding of this function is that it isn't calculating any change over time, so I'm really not sure why he divides by delta. I would say the results "feel nicer", at least to me, when I multiply by delta. Is there any harm in multiplying by delta for the apply_force()?

I understand the scaling all changes and I've been tweaking the strengths of the effect when I change how I'm handling delta. But something about multiplying by delta just makes it feel smoother/more consistent.

[short heart]

Since delta is fixed by default to 0.01666.. dividing instead of multiplying by it will increase the result.
The same effect as increasing target_grip by a lot, I guess

[zenith sierra]

is delta still fixed if I have vsync disabled?

[short heart]

The process delta is related to your fps, like the fps you see when talking about video games.
The physics process runs independent of that by default at a stable 60hz and the delta is a fixed 1 / 60th. There can be exceptions but that's very uncommon. The engine will sacrifice fps to keep the physics tickrate stable even if it means the game becomes a slideshow

[zenith sierra]

Sorry but I'm struggling a little to understand. Delta definitely isn't fixed

Amazing, I'm just now noticing I did all of my code in _process instead of _physics_process. I see now, it is fixed under _physics_process.

[zenith sierra]

One final thought on delta, should I be using delta in a lerp?

[short heart]

yes

[zenith sierra]

I appreciate that, thanks for the help ❤️

[craggy beacon]

this depends on what you're trying to do:
delta in a lerp is kinda bad in that it approaches with a curve:
it'll do fps/sec % per frame approach
which means it'll slow down the closer you get. which could be what you want, it'll just change depending on the user's fps (if done in process, not physics_process) so can be weird: slower fps will approach faster but over less frames, but not at a consistent duration as fast fps with slow approach but with more frames per second

there's move_towards() if you want linear approach, and other mathematical equations if you want to change how the approach is handled