Incorrect paths/no paths being returned in unknown circumstances

[SgtLion]

While I remember, I just want to also say thanks for making such an awesome seeming module ;)

Hey - Still not entirely sure if this is solely me doing something wrong, but trying to run this on my project. I bake the navmesh and it looks all pretty and nice and correct, but the paths being returned are leading my NPCs to walk through walls dangit.

I'm reproducing this issue on many levels, I've plopped together a very simple one, two rooms joined by a doorway. Even when the destination is a space in the same room, the actor feels a need to be a dang ghost. And another actor on the same level isn't getting any paths returned to him at all, again for reasons I can't discern. And this ain't including any real-time changes or baking.

Minimal reproduction project here:

godotnavlitenowork.zip

I've tried tweaking the hell out of y-values, origins, navmesh parameters, shifting the doorway, but I can't work out the issue or what might possibly be causing it. Please let me know if I can try anything else/provide any further info. I fear I'm just being a dunderhead.

[MilosLukic]

You should draw the path lines when debugging pathfinding. I used https://github.com/klaykree/Godot-3D-Lines with your project and I got this - you get the correct path but your character is not following it correctly. You should also reset the parameters, because to default values, it works ok with them (as far as i've seen).

PS: Kudos for providing the debug project - it makes my life a lot easier!

[SgtLion]

Thanks for the helpful response! And, trying to make it easier is literally the least I can do when asking for help~

Very good call on the drawing lines - I've implemented those and it's now clear the issue is find_path's approximated start and end points. Which would also explain why no path was being returned in some cases.

Looks like my first example path was unlucky, I don't think they're being followed wrongly. See here: To get my path, I run detour_nav.find_path(global_transform.origin, target).

• Blue line is between global_transform.origin of the NPC and the first point of the path
• Green is between last point of the path and the true target.

It's like the navigation's calculated closest points are offset from the the true closest points by Vector3(-15,0,0), give or take a bit..

In fact, when you adjust both the origin and target fed into find_path by exactly Vector3(15,0,0), it's a lot closer to correct.

Making this weird adjustment makes the whole thing just about functional for me.

I can't find anything to suggest why the start/end points are -15x offset in the first place. Also stuff about minor errors.

I should just also note that if you sub out the nodes for Godot's in-built navigation nodes in this scene, all the navigation works perfectly fine.

New debug-friendly version with fancy 3D lines and adjustment: godotnavlitealmostwork2.zip

[SgtLion]

Looking further, I see now that the minor errors are just the navigation pathfinding to the nearest navmesh tile edge, I'm assuming this part is expected functionality.

That being said, it's also clear that when one does start messing with the the cell size or tile size, to try make it more precise, it starts exacerbating this -15x offset business.

When I change tile size to 32, my adjustment to the find_path parameters instead has to be Vector3(25, 0, 0) to make it work correctly again.

On tile size 16, the adjustment has to be approx. Vector3(27.5, 0, 0) to work correctly again.

I can at least mostly make this work for what I need now :) But there's still definitely something fishy still going on.

[MilosLukic]

Yeah, this seems like an issue - I've been digging a little bit and it seems the issue is with the navigation mesh aabb positioning - for example if I positioned your floors so that navigation meshes AABB's center was near the V3(0, 0, 0), the problem with offset disappeared (I didnt have to add 15 to x axis, I had default tilesize) and also the offsets from target and source were minimal (because I didnt put it exactly on V3(0, 0, 0)).

I will have to fix this bug in the code in the near future, as soon as I find some time to work on it.

[SgtLion]

Ah, great - Makes sense. Thanks for sparing the time to look into this! If I get time myself, I'll try to have a looksie, myself.

[maddeem]

I also have this issue despite the navigation mesh and it's parents being at V3(0,0,0) Offsetting it helps, but is not much of a solution.

[SgtLion]

Can you confirm that the parameters for tile size etc. are all set to their defaults?

Otherwise, the issue is not just the V3 of the nodes, but the generated mesh's AABB center - If this is being caused by the same issue, you should be able to make a given set of surfaces work perfectly by offsetting (check .tscn file to find the offset of the AABB, move the nodes so it is at 0 in the .tscn file, then try again).

[MilosLukic]

I'm currently working on other non-Godot projects, so my help with issues is a bit limited. But with some knowledge of C++ it shouldn't be too hard to fix the issue (knowledge of C++ is pretty much necessary if you want to do some serious projects in Godot :). I'm more than happy to review and accept PR's that address the issue or add new features.