Where to apply Delta Time multiplier

[Kreeba 15]

Hi. I get the concept of Delta Time, but one thing I have always struggled with is exactly where to apply the multiplier on movement calculation. For example, this is my movement code:

    protected updatePosition(deltaTime: number = 1) {
        //Speed
        if (this.state.targetSpeed != 0) {
            if (this.state.targetSpeed > this.state.currentSpeed) {
                this.state.currentSpeed += this.characteristics.handling.acceleration
            }
            if (this.state.targetSpeed < this.state.currentSpeed) {
                this.state.currentSpeed -= (this.characteristics.handling.acceleration * 2)
            }
        } else {
            this.state.currentSpeed = 0
        }

        //Calculate Acceleration
        let accelerationVector = {
            x: this.state.currentSpeed * 0.02 * Math.cos((this.state.currentHeading - 90) * (Math.PI / 180)),
            z: this.state.currentSpeed * 0.02 * Math.sin((this.state.currentHeading - 90) * (Math.PI / 180))
        }

        //Apply Acceleration Vector onto Movement Vector
        this.state.movement.x += accelerationVector.x
        this.state.movement.z -= accelerationVector.z

        //Multiply Drag (also corrects momentum issues)
        this.state.movement.x *= this.characteristics.handling.drag
        this.state.movement.z *= this.characteristics.handling.drag

        //Apply movement vector to position
        this.state.position.x += this.state.movement.x
        this.state.position.z += this.state.movement.z
    }

My delta time is leavling out as '1' if the game is running correctly at 60fps. Where do I add the deltaTime multiplier? On every caclulation, on just the application at the end?

[Raggar 140]

this.state.position.x += this.state.movement.x * deltaTime
this.state.position.z += this.state.movement.z * deltaTime

I would use it like that, instead of applying to to all the calculations.

I'm not sure whether or not applying it to the calculations would change the end-result of the position, compared to applying it directly to the position. You know....  math

[fenomas 204]

You want to be multiplying by the time factor twice - once when converting acceleration to velocity and once when converting velocity to position.

acceleration = force/mass + gravity
velocity += impulse/mass + acceleration * dt
velocity *= drag
position += velocity * dt

The usual thing is to have "dt" be an actual time value in seconds, rather than a scaling factor - that way the acceleration value will be a familiar sort of "spatial units per second per second" value. If you assign "dt" to be 1, that works out the same math-wise but your acceleration value will be in (spatial units per 1/60th of a second) squared.

[Raggar 140]

3 hours ago, fenomas said:

You want to be multiplying by the time factor twice - once when converting acceleration to velocity and once when converting velocity to position.

Care to explain why you would do it like this?

[fenomas 204]

2 hours ago, Raggar said:

Care to explain why you would do it like this?

Velocity is the change in position per unit of time, right? For example, if a video game character is moving at 10 meters per second, and the physics engine wants to know how far the character will move in 1/60th of a second, the answer is (10 m/s) * (1/60 s) = one sixth meter, right?

Well, all those things are also true for acceleration and velocity - acceleration is a measure of how much the velocity changes per unit of time, so if you want to know how much the velocity changes in 1/60th of a second you multiply that time value by the acceleration.

In mathy terms, you multiply by time twice when converting acceleration to position because acceleration is the second derivative of position, with respect to time.

[Kreeba 15]

8 hours ago, fenomas said:

You want to be multiplying by the time factor twice - once when converting acceleration to velocity and once when converting velocity to position.

acceleration = force/mass + gravity
velocity += impulse/mass + acceleration * dt
velocity *= drag
position += velocity * dt

The usual thing is to have "dt" be an actual time value in seconds, rather than a scaling factor - that way the acceleration value will be a familiar sort of "spatial units per second per second" value. If you assign "dt" to be 1, that works out the same math-wise but your acceleration value will be in (spatial units per 1/60th of a second) squared.

What is the difference between impulse and force and how are they calculated?

[fenomas 204]

27 minutes ago, Kreeba said:

What is the difference between impulse and force and how are they calculated?

Think of impulse as something that affects things once, instantaneously, while a force is something that acts gradually, starting and stopping at different times. E.g. to make the character move when the player presses a key you want a force, but to make the character jump you probably want to apply an impulse.

As for how to calculate them, usually they're arbitrary numbers that you chose based on how fast to move the character, how they jump, etc. I just put them in the sample code as an example of what a slightly more general physics loop would look like.

[Kreeba 15]

Thanks. I am looking to standardise my physics terminology. I like your little guide . Do you have any resources for setting up a physics loop for non physicists?

I have found that I am now getting a little bit of rubber banding when the server syncs with the client, so I think it is working. I now need to compensate for the network delay

[JCPalmer 725]

I do not profess to be familiar with physics, at least not recently.  I do think whatever you do, things should not measured or judged by frame per second, but rather units of time.  Why?  It is not going to serve you well, if you later which to deploy on Webvr.  There the max is 90, not 60 fps.

Personally, do all my animation queuing in terms of the desired result, maybe a step (or a left & a right step), in the amount of time required.  If you stamp the time when the event gets taken off the queue, you merely calculate where it is to be, morph target or bone matrix state at any given time.  This is blissfully un-aware of the max fps of a platform.  It is also a little more forgiving if your game just has a little too much stuff to really sustain the max FPS.  50 FPS is pretty playable.

For acceleration, I handle that by passing how many times to repeat, and the amount of time the last repeat is to run in.  Here is a scene accelerating using this in the beginning.  If you do not know how many repeats are going to be needed, you can place a function at the end of the event, submitting another event to the queue with less time.

Again, probably wrong for physics, but I am building for morphing (speech / emotions), and choreographed mobility.  The time unit thing is still the way to do.

[JCPalmer 725]

Oh, if forgot, for smooth acceleration within an event,  I have a number of paces (sine, elastic, cubic, bezier curve, etc).  BJS does not call them paces, but it has the same (I stolen them from them).

[Kreeba 15]

14 minutes ago, JCPalmer said:

I do not profess to be familiar with physics, at least not recently.  I do think whatever you do, things should not measured or judged by frame per second, but rather units of time.  Why?  It is not going to serve you well, if you later which to deploy on Webvr.  There the max is 90, not 60 fps.

Personally, do all my animation queuing in terms of the desired result, maybe a step (or a left & a right step), in the amount of time required.  If you stamp the time when the event gets taken off the queue, you merely calculate where it is to be, morph target or bone matrix state at any given time.  This is blissfully un-aware of the max fps of a platform.  It is also a little more forgiving if your game just has a little too much stuff to really sustain the max FPS.  50 FPS is pretty playable.

For acceleration, I handle that by passing how many times to repeat, and the amount of time the last repeat is to run in.  Here is a scene accelerating using this in the beginning.  If you do not know how many repeats are going to be needed, you can place a function at the end of the event, submitting another event to the queue with less time.

Again, probably wrong for physics, but I am building for morphing (speech / emotions), and choreographed mobility.  The time unit thing is still the way to do.

*note to self: don't target webvr...

..problem solved

I think this is a little overkill for my needs, however its great to add it to the thread. I am targeting Desktops and low powered mobiles, then trying to keep them in sync with the server.

[fenomas 204]

15 hours ago, Kreeba said:

Thanks. I am looking to standardise my physics terminology. I like your little guide . Do you have any resources for setting up a physics loop for non physicists?

I have found that I am now getting a little bit of rubber banding when the server syncs with the client, so I think it is working. I now need to compensate for the network delay

I think the easiest thing is to peek inside an existing engine. You might look, for example, at voxel-physics-engine (by me  ), which is a lot more bite-sized than production engines (all the relevant code is in index.js and rigidBody.js), and see what it's doing.

 

Addendum: to speak briefly to JC's point about timesteps, there are fundamentally two ways of doing physics. The Easy Way is to update your physics before each render, using the time since the previous render as a timestep, and The Right Way is to fix your timesteps and decouple physics from rendering. The former is simple and intuitive, and fine for any kind of starter project (and indeed lots of AAA games even use it), but if you like this stuff and want to learn the real deal you should eventually look at the latter way, and either use it, or at least have a clear idea of what its benefits are and why you're okay without them.

[JCPalmer 725]

If you have integration of multiple serialized animations with sound, there is also The Only Way.

[bzor 0]

@fenomas would drag also need to use dt as it's modifying velocity every frame?

[aWeirdo 338]

@bzor
Do you mean Drop & Drag, with your mouse? 

 

Edit; 
Oh holy necro.. 😂