Ticked Vehicle's newVelocity and newAcceleration

[BigToeProductions]

Thanks for the great tool!

I am using TickedVehicles and SteerForPursuit. I have been trying to figure out how to get rid of the deceleration of the ticked vehicle as it gets closer to the target. I would prefer it kept a constant speed and rammed into the target. (Maybe I should be using SteerForSpeed in addition to the SteerForPursuit?)

When I was looking at the code in TickedVehicle, I didn't understand what was happening with the newVelocity and newAcceleration variables in the CalculateForces() method. (I have pasted here.)

            Vector3 newAcceleration = (clippedForce / Mass);

    if (newAcceleration.sqrMagnitude == 0)
    {
        ZeroVelocity();
        DesiredVelocity = Vector3.zero;
    }

    /*
        Damp out abrupt changes and oscillations in steering acceleration
        (rate is proportional to time step, then clipped into useful range)

        The lower the smoothRate parameter, the more noise there is
        likely to be in the movement.
    */

    if (_accelerationSmoothRate > 0)
    {
        _smoothedAcceleration = OpenSteerUtility.blendIntoAccumulator(_accelerationSmoothRate,
                                    newAcceleration,
                                    _smoothedAcceleration);
    }
    else
    {
        _smoothedAcceleration = newAcceleration;
    }

    // Euler integrate (per call time) acceleration into velocity

    var newVelocity = Velocity + _smoothedAcceleration * elapsedTime;

    // Enforce speed limit
    newVelocity = Vector3.ClampMagnitude(newAcceleration, MaxSpeed);
    DesiredVelocity = newVelocity;

It appears that newVelocity is declared and assigned to _smoothedAcceleration * elapseTime. But then when we enforce the speed limit we just write over the value that was just assigned.

At first I thought the this:

newVelocity = Vector3.ClampMagnitude(newAcceleration, MaxSpeed);

...Needed to be changed to this:

newVelocity = Vector3.ClampMagnitude(newVelocity, MaxSpeed);

But then I realized that I am probably just confused. Any clarification of what is happening there would be awesome.

Thanks!

[ricardojmendez]

I do believe you're right - that seems to be a typo that has been there for a bit, and I probably didn't notice since it wasn't affecting my game directly. Let me confirm, since I did the change months back - even if it was intentional it bears better documentation at the very least.

[ricardojmendez]

This is sort of a bug, in the sense that it shouldn't be on the TickedVehicle class. This sort of behavior is appropriate for bipeds, and the code initially came from the re-working of AutonomousVehicle when I was changing it to interpret Velocity differently (on 65d15d9). The reason why it doesn't affect my game is because I'm precisely working with bipeds, not vehicles, but it would make vehicles turn faster than they probably should.

Let me figure out the best way to handle both cases. Meanwhile, your expected correction is accurate if you are dealing with AutonomousVehicles.

[ricardojmendez]

I'm sorry that replying to this issue completely slipped by me.

Your reading of the issue is correct - adding the acceleration to the velocity is effectively being disregarded. This is because of a combination of factors, but it boils down to (effectively) that we should not be doing this at all:

var newVelocity = Velocity + newAcceleration * elapsedTime;

That's because the steering behaviors are expected to return a desired velocity, not an acceleration (which would be a delta from the current one). I'll remove that leftover line to avoid confusion.

[ricardojmendez]

Resolved on commit 1fc6b4e.

[ricardojmendez]

See also this piece for acceleration changes: http://arges-systems.com/blog/2014/01/30/unitysteer-acceleration-smoothing-changes/