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: https://playground.babylonjs.com/#KVQP83#29.
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.
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.
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.
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.
I’ve found a solution. Let me do the PRs and release a new recast package…