NavMesh: Paths don't follow NavMesh surface

When finding a path from e.g. the bottom of a hill to a point over the hill, the path waypoints form a straight line through the hill, instead of following its surface. I can see the purple debug navmesh following the terrain, but the path doesn’t. I’ll try to create PG when I get more time, but I’m almost certain I saw this behavior with existing navmesh PGs. Is this a known issue?

I think a PG would be a great help. Note that most team members are on vacation, so expect delays in responses.

Yeah, no rush. Here’s a PG:
Also a screenshot of the issue:

Not sure why the debug mesh cuts off. In my game the mesh follows the hill, but the issue is the same: the path is a straight line, through the geometry.

My agents don’t normally sink into the ground because I move them with moveWithCollisions. But they get placed in the ground during level load because I interpolate path positions, based on time. E.g. when you enter a level when an NPC is supposed to be walking from A to B, it gets placed somewhere along that path. But the path goes through the ground…

NavMesh needs to get the appropriate navmeshParameters.
You can try a few more times to get closer to the correct answer.

1 Like

This is better, thanks. But while the agent follows the hill, the path still goes through it.

You could consider using a physics engine. like Havok

@musk Is the playground really how it is supposed to work? If you console log a path that goes over the ramp, you will get two path waypoints. But should there not be 3 waypoints: one additional point on the peak?

Also, above I was talking about traversing the ramp from valley-peak-valley. Now, instead, try going from off the ramp over one of the vallies (parallel to the peak line). You should see how you will get a path accounting for the height differences (terrain-ramp-ramp-terrain) - as it should do in the other case.

Use case: preview a path line.

I tried using Bullet a while back, but the performance on mobile is atrocious. Maybe Havok is faster, but anyway, it would be a pretty big change at this point.

:sweat_smile: You are right. I missed it. I did some testing and the computePath does not get the change on the Y axis. The y value is only changed in update. I need to summon the master of Recast @Cedric . And it’s the Christmas vacation, so stay tuned.

1 Like

It looks like compute path only update Y for points where there is a break. if 2 points form a line without a break, then it’s assumed to be on the same Y.

With breaks, it does not appear:

I’ll take a look this week to see if I can improve it.

A workaround is to so a bunch of raycasts along the path lines but this will be costly.

1 Like

I’ve found a solution. Let me do the PRs and release a new recast package…

1 Like