Question/Discussion - Vehicle movement: PathBehaviours about yuka HOT 5 CLOSED

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 ;)

from yuka.

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.

from yuka.

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 :)

from yuka.

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.

from yuka.

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

from yuka.