Navigation Mesh

[3Dski7059]

The navigation mesh appears to be messed up. The brown bounding box is huge, while the blue mesh ares fits the floor. The player can move outside of the blue mesh area and off the edge of the floor when using the ThirdPersonControls. I'm seeing that the brown bounding area is controlled by the "Tile Resolution", but the player is still allowed to move out of that area. The navmesh also doesn't ignore the Player if its place prior to the navmesh being added/calculated. The redish-brown rect is my player. The blue mesh covered the area fine until it recalculated with my player present.

[Josh]

Okay, everything there looks correct to me.

The orange bounding box shows the volume the navmesh can possibly cover.

The blue tiles all look correct.

Your player entity is set to be a navigation obstacle, so it is being considered in the navmesh calculation. You can uncheck the nav obstacle property to prevent this.

Player physics are completely separated from navmesh pathfinding. Navmesh pathfinding uses Agents.
https://www.ultraengine.com/learn/NavAgent?lang=cpp

Agents only respond to navmeshes and to other agents. They can't see the physics of the world. It's a totally separate system. In Leadwerks these were inseparable but in Ultra you have a lot more control.

This allows you to do things like create multiple navmeshes, one for big characters and one for small characters. You can make characters that are controlled by both physics and navigation, or you can have an army of characters that are only using fast navmeshes.

[beo6]

What are "fast navmeshes"? What is the difference to normal navmeshes and how to use them? I don't see a parameter for these.

[Josh]

I mean that navmesh movement will be faster than player physics because it is much simpler. This can make a significant difference when large numbers of characters are in use.

[beo6]

Okay. thanks for the clarification.

Is there a way to update parts of a navmesh?

For example, when placing a building in a RTS game. Can the Navmesh be updated so that newly placed building is an obstacle now?
 

[Josh]

Yes, navmeshes update automatically on a separate thread.

[3Dski7059]

Huge thanks for the explanations! Is there documentation on these details yet... Did I fail to find info I should have found?

[Josh]

No, although this could certainly be explained better. I have trouble writing general documentation that isn't exact technical information.

[3Dski7059]

My 2 takeaways are, don't forget to exclude the player as an obstacle and the mesh does not prohibit falling off an edge (you need to create an actual physical boundary).  The first was an oversight and the second was a lack of understanding of what to expect with than edge case without physical barriers.

I almost forgot to mention not understanding what the orange was all about. A large part of this was, it somehow got very large during one of my experiments, even though I couldn't think of anything thing I did to make it so huge.  So, is the user supposed to increase of decrease the size themselves to control the computation of the navmesh?

[Josh]

1 hour ago, 3Dski7059 said:

My 2 takeaways are, don't forget to exclude the player as an obstacle and the mesh does not prohibit falling off an edge (you need to create an actual physical boundary).  The first was an oversight and the second was a lack of understanding of what to expect with than edge case without physical barriers.

Not exactly...Player physics and navigation are two completely separate things. If a character is using physics the navmesh will have no effect on them. If a character is using a navmesh, they won't go over an edge, and they will just stay on the surface.

The outline of the navmesh is the volume for which the navmesh is calculated. Everything in that volume will be considered when building the navigation data. Navmeshes are not infinite, they need a defined volume.