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.
2 Likes
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.
2 Likes
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…
3 Likes