Kreeba

Where to apply Delta Time multiplier

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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 :P

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :D ), 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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.