Pathfinding Stutter

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Victor Hernandez Can
:warning: Old Version Published before Godot 3 was released.

Hello! I’m having this weird stutter for some reason… My setting for the Navigation Poly is putting it inside a tile. Then set the tile map as a child node of Navigation2D. It does work BUT the character stutters at some points. I have checked that every single value is pixel perfect and even the tileset’s.tres file. Even when “working” direction stutters aswell.

Here’s a preview. https://drive.google.com/open?id=0B0tAu5jzckVeVmVYaXdSTXpGVWc

How did you implement path following? It looks like you try to to reach points one after the other, but it never gets to find the first point because some threshold is too small (causing this wiggle back and forth)

Zylann | 2017-01-23 10:45

points = nav.get_simple_path(get_global_pos(), destination,false)
if points.size() > 1:
direction = (points[1] - get_global_pos()).normalized()
motion = (direction * maxSpeed * get_process_delta_time())
move(motion)

from a demo :slight_smile:

Victor Hernandez Can | 2017-01-23 14:14

:bust_in_silhouette: Reply From: masp

Hi, im having similiar problem, decreasing size of collision shape helped a bit, but its still not solution that i’ve been seeking.
And while testing impeimintation from navmesh demo i’ve discovered that camera attached to character breaks pathfinding, maybe theres a bug in navmesh itself.

:bust_in_silhouette: Reply From: MrMonk

same problem here. I’ve been looking at this for about two weeks now, and I’m no closer to a solution. I’m adding here my trials and maybe others can see something that will help. I’m not adding it as a github issue, because I don’t know how to describe the problem.

  1. So the navmesh will give a list of points say, [(350,100), (400, 100) …]. If the position of the object you are trying to move is not at the 100 height, then the move function may fail because the whole move cannot be accomplished, resulting in an unpredictable behavior.
  2. Even if tiles are pixel perfect, there seem to be some pixels out of place, which will results into a “bad” collision with your object.
  3. Both 1 and 2 may bring the object into a situation where the distance that needs to be traveled is less than a pixel, resulting into a normalized direction of: 0.0001 by 0.00033, meaning some extremely small values resulting in very very small speed (or motion as defined in the above code), the 1 or 2 or both will return back the object to the initial distance, less than a pixel and a back and forth movement will occur.

What I did was to remove entirely the collision shape from the moving object, it still happens, maybe less frequent but I can’t be sure, presumably discarding the second point I made.
Another thing I did, was to detect when the distance to travel is less than a pixel, and at that point used a force move, move_to to a distance +1 px further away, this helps most of the times only when you are going: left/right, or up/down, when all directions are needed, then it’s not working since +1 on y and x, will create wiggling.
I looked at the source code… seems complex and difficult to understand, but there were no magical numbers, and the resulting path is always correct… So … back to square one…