Question/Discussion - Vehicle movement: PathBehaviours

[getarun]

Vehicles steered by a combination of onPathBehaviour/followPathBehaviour do not stop a their last waypoint, but overshoot and turn around afterwards. This can be "fixed" by either increasing the tolerance (makes to vehicle stop ahead to the last point) or changing their related weights. A weight ratio 1/100 seems to stop the character early, but this makes it skip edges of the navMesh (though the path is calculated appropriately). I tried to set .radius to make it follow the path more conscientiously, but no effect.
This occurs in a variety of examples (either 3rd party & yuka published). 1
Since documentation tells my to use followPath together with the onPath behaviour to realize accurate path following, but examples do not show this, I like to ask for an opinion on how to address/fix this. 2

I am confused by _arrive and _seek properties wihtin a followPathBehaviour. Are these used to move the character to the last waypoint of the path and manage deceleration distance and brake force? Since both receive a single target (no path) to go to, solely navigating with these in conjunction with a navMesh seems unwanted. Why are these present / named with a leading underscore?

The box-farming lady approaches her missing boxes just fine, but she does not use navMeshes and is controlled by with a single arriveBehaviour (Girl.js: 37ff, Goals.js: 217ff). 3 Ideally, I'd like to have her movement on an accurate (pre-calculated) path within the navMesh.

[Mugen87]

Hi @getarun! First of all thank you for using the engine 😉 !

The FollowPathBehavior class internally uses seek and arrive to guide a vehicle along its path. ArriveBehavior is only used for the last waypoint. If your vehicle overshoots right now, it's recommended to increase the tolerance. That simply means that the game entity will halt a bit earlier before actually reaching its destination.

Notice that the "right" value for tolerance sensitively depends on the overall combination of the vehicle's force and the weights of its active steering behaviors. That means you have to try out a bit until you figure out an appropriate value.

BTW: It's not possible that a game entity strictly follows a path on its edges right now. We would need a separate steering behavior for this although I don't think it's possible to model this movement with forces. The problem is that a vehicle would need the ability to abruptly change its movement direction on sharp angles which is something that can't be modeled with steering behaviors (I think). Such a movement would also not look very natural compared to the current result of FollowPathBehavior.

[getarun]

Hi, thanks for the reply.
We started with yuka to solve path finding on navMeshes. Your implementation of triggers and gameEntity props are nice features in our case. Your work is appreciated and helps to keep stuff clean.

We figured out some parameter combinations that helped to improve the behavior with a more sensitive approach.
Browsing through the onPathBehevior.js i noticed that the force calculation bases on a estimated position via a factor.
Maybe reducing it will result in smaller steps along the given path. I'll find out.

I agree with you that a path as guidance for the vehicle is enough and a strict clamp would look unnatural. Following the path strictly would indeed imply rather harsh changes on the edges.

A small sandbox example to showcase the addressed part is in progress and will be added if this is still open for a little.

Have a nice evening ;)

[m4cn4ir]

Hi Mugen87,

thanks for your quick reply and your help. We are super happy that we found Yuka! We prepared this sandbox.

We want to achieve a fluid movement of the skinnedmesh. Therefore we use the followPath & onpath steering behavior with navmeshes. This works already quite well. However there are some details we just can´t figure out:

• The avatar should start and stop walking immediately without acceleration or deceleration. It should move with constant walk speed. The current problem is, that the avatar walks too slow on small distances. The movement speed of long distances is "ok". In any case I want the avatar to be faster on short/middle distances. Problem: Increasing maxSpeed/maxForce then will lead to "overshootings" on long distances. ( the avatar is so fast, he glitches out of the path, and also crashes into the target, overshoots and spirals back.. its rather spectacular :D ) Increasing maxSpeed to 10 already triggers this effect - even without increasing the avatars short distance speed.

An idea would be to use an initial momentum (p=mv) instead of applying force over time. It would be applied on the segments start and applied inversely at its end. Earlier, you mentioned this would lead to an abrupt movement. That will probably be an issue. Before we used navmeshes & Yuka, we handled the movement with useSpring. It was very direct yet the springyness made it fluent. Maybe there is a way to combine these or find a similar approach?

• Another question is how to reset the walk animation after the avatar has arrived (set to idle). We tried path.finish(), however it returns true as soon as the avatar arrives at the last path segment - not the actual target. Is there any callback that triggers when the avatar arrived? Our first idea was to check if velocity is greater than 0 in useFrame but that ain´t pretty.

Vielen Dank und viele Grüße :)

[Mugen87]

The avatar should start and stop walking immediately without acceleration or deceleration.

This is not something you can model with forces. You always have an acceleration/deceleration if you apply a force to a vehicle with a given mass.

Maybe there is a way to combine these or find a similar approach?

I've never worked with useSpring but it should be no problem to implement the movement of your game entities differently (meaning not with steering behaviors). Keep in mind that the result when calling NavMesh.findPath() is a simple array of waypoints. That should be easy enough to process.

Is there any callback that triggers when the avatar arrived?

No since it's hard to define the conditions for the arrived status. When using forces, it's unlikely that the game entity ever reaches the exact destination. So a strict equal operation between the game entity's position and the waypoint is almost never true.

The typical way for solving this issue is to compute the (squared) euclidean distance between the game entity's position and the waypoint and consider the entity as arrived when a certain threshold is reached. The value of this threshold is use case specific.

Consider the following: If you are in a building and what to go from one room into another, you set yourself a mental destination point. However, it does not matter if you reach this point to 100%. A small deviation of a few centimeters (or even a meter in some scenarios) is absolutely fine.

[Mugen87]

Closing. Feel free to chat about more details at discord: https://discord.gg/MhnFwYM