You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we rely on point to point shortest path navigation based on nav-meshes. This approach suffers from two drawbacks that we would like to address:
Pathfinding in larger geometry takes more time. At the same time we tend simulate more agents when using larger areas (most of the time larger also means more complex and more triangles) further compounding the slowdown, i.e. more queries which are slower. With a vector field we expect to be able to use constant time lookup to calculate the desired direction and reduce the compute time for pathfinding a lot.
We often want to handle non-point destinations, e.g. a wide exit area or wide door. With point to point based navigation we currently represent non-point size targets by their center which results in a visible bias in our simulations.
Vector fields are not supposed to fully replace nav-mesh based navigation but complement the navigation where it offers a clear benefit.
The text was updated successfully, but these errors were encountered:
Currently we rely on point to point shortest path navigation based on nav-meshes. This approach suffers from two drawbacks that we would like to address:
Vector fields are not supposed to fully replace nav-mesh based navigation but complement the navigation where it offers a clear benefit.
The text was updated successfully, but these errors were encountered: