Movement is framerate-dependent?

[ArtemPindrus]

Hey, I made a game for a game jam recently that uses your plugin for character controller.

What I discovered is that if people play it on low framerate the character seems to be moving slower.

During my testing I found out that it's indeed true.

I the video below you can see that at Physics FPS 60 character moves correctly at ~3m/s.
BUT, changing it to lower rates results in lower actual speed of controller, although the velocity I supply to out Vector3 Velocity of KinematicMoveUpdate() is the same.

2025-06-30.22-13-05.mp4

This is the script I use for controller:
https://github.com/ArtemPindrus/FreakyController/blob/main/Source/FreakyController/Controller.cs

[Zode]

Hmm, shouldn't be. I'll try to investigate soon.
Are you using KCC's interpolation at the moment? Have you tried without the interpolation? edit: just saw the toggle in the video.
Its the only place that uses Time.DeltaTime multiplication in relation to movement 🤔
Also: luckily the physics FPS is a fixed tickrate, it will not change based on the end user's system's speed, so for now it shouldn't be a problem but ideally this end result should be same no matter that physics tickrate there is.

[ArtemPindrus]

Yeah, I'm aware that physics rate is fixed, but...
It doesn't make sense for lower update rate to produce lower actual speed.
Lower update rate == greater time delta; and that time delta should be a scalar of velocity somewhere.
Velocity of x should be velocity of x, regardless of update rate.

Edit:
For example rigidbody with velocity (0,1,0) will displace by 1 meter upwards every second, regardless of whatever physics update rate I set.
And this is what I expect from a controller as well.

[ArtemPindrus]

Video for demonstration purposes with a plain rigidbody:
https://github.com/user-attachments/assets/7e993955-770a-4e7d-97eb-d2f73d9a2413

And this is a script attached to Rb:

public class TestRB : TaskScript
{
    public Vector3 velocity;

    private RigidBody rb;

    public override async void OnAwake() {
        rb = Actor.As<RigidBody>();

        try {
            await DisplacementTracker();
        } catch { }
    }

    public override void OnUpdate() {
        rb.LinearVelocity = velocity;
    }

    private async Task DisplacementTracker() {
        while(true) {
            Vector3 pos = rb.Position;

            await FlaxTasks.Delay(1, DestroyedCancellationToken); // just delays by 1 second (synced with Update loop)

            Debug.Log($"Displacement {rb.Position - pos}");
        }
    }
}

[ArtemPindrus]

I tested controller with the same approach as Rigidbody above and found an interesting thing. Maybe it will give you a hint of what's happening.

I set velocity to a constant here:

public void KinematicMoveUpdate(out Vector3 velocity, out Quaternion orientation)
{
    orientation = Quaternion.Identity;
    velocity = new(0,0,-1); // constant velocity

    return;
    // ....
}

Also awake method sets up a displacement tracker after every second similar to script above.

And the thing is... displacement every second seems to be a multiple of physics update rate (let PUR).
Meaning that when PUR is 60 displacement is (0,0,-60), when it's 10 displacement is (0,0,-10).

2025-07-01.06-28-58.mp4

[Zode]

It doesn't make sense for lower update rate to produce lower actual speed. Lower update rate == greater time delta; and that time delta should be a scalar of velocity somewhere. Velocity of x should be velocity of x, regardless of update rate.

Very much agreed, and what is curious is that almost all of the code is just shapecasts with some math, and the character is clearly not interacting with any dynamic rigidbodies where deltaTime could have a finger in things at quick glance on the vids.
Thanks for the extra info, it'll help with figuring out what exactly is causing it. At the latest i'll have a looksie at the weekend, earliest on thursday, currently life is pretty busy during the week since i am in the process of changing locations 😅

[Zode]

Okay so, i've figured out what is happening here: basically KCC still operates the same, its just that the perceived speed is slower since the user script (the one that supplies the velocity for KCC) is not compensating for the additional time between ticks.
60 processing ticks in a second * 1 unit velocity every tick = 60 units traveled in a second.
15 processing ticks in a second * 1 unit velocity every tick = 15 units traveled in a second.
See the problem 😁 ?

Luckily the fix is simple, its just a matter of multiplying the velocity given to KCC with Time.DeltaTime. Seems like i need to update the examples to do this too, since it never occurred to me to change the physics tick rate during runtime so it never became an "issue" for me.

I believe in your situation it would be:

    public void KinematicMoveUpdate(out Vector3 velocity, out Quaternion orientation)
    {
        Accelerate();
        ApplyGravity();
        velocity = MovementVelocity + gravityVelocity;

        orientation = Quaternion.Identity;
    }

changed to

    public void KinematicMoveUpdate(out Vector3 velocity, out Quaternion orientation)
    {
        Accelerate();
        ApplyGravity();
        velocity = (MovementVelocity + gravityVelocity) * Time.DeltaTime;

        orientation = Quaternion.Identity;
    }

Not sure if KCC should multiply this on its own upon receiving the velocity from the callback 🤔

[ArtemPindrus]

Yeah, I see the problem.

In KinematicCharacterController.cs you do a similar thing in multiple places:

//no collision, full speed ahead!
TransientPosition += _internalVelocity;

meaning, adding velocity to position, which is physically incorrect.

I've tried to superficially go through the code in my fork and multiply the values I thiiink need to be scaled by DeltaTime and things seem to be working correctly, but I'm not that familiar with codebase to be confident that I haven't broke a million of other things😅

EDIT:
I wonder what approach KCC for Unity takes?
Does it account DeltaTime internally? 🤔

[Zode]

meaning, adding velocity to position, which is physically incorrect.

Its not really a velocity but that made sense to my 3AM brain back then, I should refactor that and change its name to be more accurate 😅
Its more like the distance left to travel in that processing tick, so when its being added in that case it means it can travel the full distance supplied for that frame.

I've tried to superficially go through the code in my fork and multiply the values I thiiink need to be scaled by DeltaTime and things seem to be working correctly, but I'm not that familiar with codebase to be confident that I haven't broke a million of other things😅

Story of my life 😭

EDIT: I wonder what approach KCC for Unity takes? Does it account DeltaTime internally? 🤔

To my knowledge it does not do anything of such, its been a while since I worked with it but I do remember having to multiply by deltatime, I could check and adjust within the experimental branch for upcoming changes unless someone has an issue with the automatic pre-application of deltatime. I haven't been able to figure out a reason why not to do it, since it fixes a bug and even with manually ticked KCC (eg. due to online rollback) it should not matter as each tick should have the same deltatime value anyways as PhysX really does not like changing tick lengths.

[ArtemPindrus]

Its more like the distance left to travel in that processing tick

Oh, I see. Then my temporary solution doesn't make sense.

Well then, I'm gonna stick to scaling velocity in script for now.
This behavior should be probably documented to not cause confusion.