[SOLVED] Player doesn't use NavMesh correctly, jumps over obstacle instead

Dear everybody,
I am still fiddling around with the NavMesh navigation.
I’ve come to a point where I can generate pretty good looking meshes and want to use them now to send a figure to a goal.
I wanted to test this with an obstacle.
I have a scene (basically a street) with an obstacle that leaves at each side a space to allow passage.
The navmesh that is generated looks perfect. It “hugs” the obstacle.
Now, I want to send an avatar from one side of the obstacle to the other side.
Depending on where the goal is, the avatar either jumps the obstacle or stands in front of it and “is stuck”.
The waypoints generated indeed lead over the obstacle.
Why oh why does the Navigation alghorithm not use the space at either side of the obstacle?
Why do the waypoints lead over the obstacle?

I dont think that I can provide code because this is part of my thesis work.
I just would like to know if anyone has faced a similar problem and can point me into the right direction.

If there’s anything else I can provide (except code), please let me know.


Edith: I should say that I’ve already checked that I set the gravity of the player AFTER adding it to the physics space.

1 Like

Ok. I will bite, you are using jme3-recast correct?


If you see the navmesh is traveling though the space around the obstacles and the path is not then maybe it’s a radius problem with the path finding filter.

The fact you say the path is traveling over the obstacle is wierd since that implies the navmesh is saying that space is navigable which indicates you have navmesh parameter problems as well, unless you are using offmesh connections, in which case that is expected behaviour.

Not easy to tell with the info given, usually this kinda thing is a filter parameter problem if the navmesh truly is accurate.


First of all, thank you very much for the answer!
What information would you guys need to get a better idea of what I’m doing?
I can check with my supervisor and ask what info I am allowed to post and what not.
OR: I try to come up with an even more minimal example.
Edith: My supervisor will have time tomorrow.
Let me try to come up with a better explanation of what I am doing exactly. Will take a few minutes.

well, usually you should not share “oryginal” code, not share overall game ideas and not share graphic content that should not leak. its also odd you write here then instead of supervisor, when he dont told you what you can write.

Anyway i think navmesh preview (just navmesh geom screenshot) and what library you use for it would make some sense.

1 Like

Yeah. I’ll wait 'til tomorrow. Me asking here shouldn’t be a problem (my supervisor encouraged me asking here before) but I just want to make sure.

A tip, you can also run your navmesh parameters through blenders navmesh generator to compare your navmesh to it. This will allow you to fine tune the parameters quickly and visually rather effortlessly.

Both meshes should look identical.

1 Like

Okay, guys. I checked back with my supervisor.
I am allowed to ask questions on here, so we’re good.
But I still would like to ask that nobody posts any complete solution per se.
I would like to discuss the problem I am having and only the specific problem.
Here’s what I’m doing:

-Take jme3-artificial-intelligence
-Take jme3-ai doc example (doc-examples/src/com/jme3/examples/jme3ai at master · jMonkeyEngine/doc-examples · GitHub)

-use a test scene which is basically a walkable area with an obstacle and one agent
-load that scene into jme3 sdk
-generate a navmesh using sdk and save it in the scene
-load the navmesh in the code using the example posted above
-get weird waypoints from the navmesh

My problem are the weird waypoints.

Let me illustrate (sorry. can’t embed pictures for some reason):

That is the scene. You can see the avatar, the obstacle and the waypoints.
0 is where the avatar starts.
1 is in mid air, same height as 2.
2 is ON the obstacle.
3 is where I want the avatar to go.

I get two types of behavior:
-Avatar goes near 2, but is stuck at ground level and doesn’t move anymore.
-Avatar jumps over obstacle (in point 2) and goes to destination (3).

The navmesh itself looks alright (top view):

It indeed hugs the obstacle. (And the navmesh generated with blender looks almost identical, it doesn’t hug the obstacle that well, but the triangles are similar (in the mathematical sense).

I would try to generate the navmesh just using the procedural method, but I couldn’t manage to do so. But I think the navmesh itself is okay, so that shouldn’t be a problem.

Again, I am not looking for a solution, I just would like to know why I am getting those waypoints. I would expect the waypoints to move AROUND the obstacle, not on top of it.

Edith: This (https://blender.stackexchange.com/a/76097) answer on SO states (rightfully - come to think of it) that there should be not waypoints at all in places outside of the navmesh. I was of the opinion that the polygon engulfing the obstacle is not part of the navmesh. I checked the number of triangles; furthermore, that is not a triangle but a trapezoid-y thing. Which makes the waypoint there even weirder.


Try using imgur to post images. The links posted dont work for me.


edit: You can just edit the links in above post rather than posting again if want.


Ok, I am having to assume you are using jme3-ai ie critterai since you are using the navmesh from SDK and mentioned the jme3ai tutorial.

First thing I would look at is from overhead, looking down at waypoints, do they have the same pattern as is shown in yellow in this image. This would be the path that should be taken.

If the pattern is the same, then it suggests that the navmesh in memory is offset.

If you are using a navmesh built from SDK and pathfinding from a library other than jme3ai, that may be the problem.

Ill comment more after response.


This may be the answer.

When using the SDK to create the navmesh, it will call this method,

This terrain2mesh method has offsets built into it, why it does I do not know.

I assume its to keep the navmesh offset from the underlying geometry, for visual debugging or maybe its defensive coding against some bug in critterai, not sure why.

I pointed this out one time in a forum post about it but got crickets in response so I just defensive coded around it myself.

You can do this when you procedural build the navmesh inside the findGeometries method by adding something like this,

//must offset due to terrain2mesh offsetting
g.setLocalTranslation(spatial.getLocalTranslation().subtract(new Vector3f(-0.5f, m_cellHeight, -0.5f)));

after this line,

The offset was .5 wu in my case but may be different in yours. Notice that height is also offset by cell height.

Edit: The only way I can think of to offset when using the SDK is maybe offset the scene but that will lead to other problems I bet.

1 Like

First, thanks so much for the response!
I’ll quote and answer in pieces:

You are correct. Sorry, I thought that was obvious from the jme3-ai part.

I would say so, yes. I have only measured that using my fingers ( :slight_smile: ), but the waypoints are pretty close to what you have drawn here.

Nope, both from jme3-ai.

I’ll try creating the navmesh procedurally, once I’ve figured out how to do that correctly.
I’ll report back as soon as I have something going!

Thanks so much for the help, I really appreciate it!

Edith: Just a status report: I can generate a Nevmesh procedurally!!! \o0/
But I forgot the parameters with which I created the NavMesh that I want to test. I got to fiddle around with that first, so I can get the identical Navmesh. Might take a while. ( -.-’ )

Okay. I’ll make a new post, I think this is easier to read:

When I use the procedural method (with the parameters from before), I get a Navmesh which is pretty close. Not 100% the same (there is an offset), but pretty close.
I tried to offset the spatials like you suggested.
Didn’t work well. The waypoints were way better, but the avatar got stuck at the edges of the obstacle.
When I set the offset to 0.0, it works.
I’ve checked more complex maps; it works, too.
So I think this can be regarded as closed.
Thanks so much for the answers, it helped a ton!

1 Like

Exactly. The reason I didn’t do this was I do not know why the offset is even there so I just defensive coded around it in the findGeometries method instead so that the terrain2mesh kept the authors intended use.

Reversing the offsets prior to creating the navmesh, one way or another, is all that seems to matter in the end anyway.

1 Like