![]() |
ezEngine Release 26.9
|
Computes a path through a navigation mesh. More...
#include <Navigation.h>
Public Types | |
| enum class | State { Idle , StartNewSearch , InvalidCurrentPosition , InvalidTargetPosition , NoPathFound , PartialPathSearchLimited , PartialPathUnreachable , FullPathFound , Searching } |
Public Member Functions | |
| State | GetState () const |
| void | Update () |
| void | CancelNavigation () |
| void | SetCurrentPosition (const ezVec3 &vPosition) |
| void | SetTargetPosition (const ezVec3 &vPosition, bool bOptimizeWhenFound=false) |
| Sets the desired target location and starts a path search. | |
| const ezVec3 & | GetTargetPosition () const |
| void | OptimizeCurrentPath () |
| Immediately optimizes the current path corridor (topology + visibility). | |
| bool | IsPointInPathCorridor (const ezVec3 &vPosition, float fHeightTolerance=0.5f) const |
| Checks whether vPosition lies inside the current path corridor. | |
| void | SetNavmesh (ezAiNavMesh *pNavmesh) |
| void | SetQueryFilter (const dtQueryFilter &filter) |
| void | ComputeAllWaypoints (ezDynamicArray< ezVec3 > &out_waypoints) const |
| void | DebugDrawPathCorridor (const ezDebugRendererContext &context, ezColor tilesColor, float fPolyRenderOffsetZ=0.1f) |
| void | DebugDrawPathLine (const ezDebugRendererContext &context, ezColor straightLineColor, float fLineRenderOffsetZ=0.2f) |
| void | DebugDrawState (const ezDebugRendererContext &context, const ezVec3 &vPosition) const |
| float | GetCurrentElevation () const |
| Returns the height of the navmesh at the current position. | |
| void | ComputeSteeringInfo (ezAiSteeringInfo &out_info, const ezVec2 &vForwardDir, float fMaxLookAhead=5.0f) |
Public Attributes | |
| float | m_fPolySearchRadius = 0.5f |
| float | m_fPolySearchUp = 1.5f |
| float | m_fPolySearchDown = 1.5f |
Static Public Attributes | |
| static constexpr ezUInt32 | MaxPathNodes = 64 |
| static constexpr ezUInt32 | MaxSearchNodes = MaxPathNodes * 8 |
| static constexpr float | c_fPathSearchBoundary = 10.0f |
Computes a path through a navigation mesh.
First call SetNavmesh() and SetQueryFilter().
When you need a path, call SetCurrentPosition() and SetTargetPosition() to inform the system of the current position and desired target location. Then call Update() once per frame to have it compute the path. Call GetState() to figure out whether a path exists. Use ComputeAllWaypoints() to get an entire path, e.g. for visualization. For steering this is not necessary. Instead use ComputeSteeringInfo() to plan the next step. Apply your steering behavior to your character as desired. Keep calling SetCurrentPosition() and SetTargetPosition() to inform the ezAiNavigation of the new state, and keep calling ComputeSteeringInfo() every frame for the updated path.
If the destination was reached, a completely different path should be computed, or the current path should be canceled, call CancelNavigation(). To start a new path search, call SetTargetPosition() again (and Update() every frame).
|
strong |
| bool ezAiNavigation::IsPointInPathCorridor | ( | const ezVec3 & | vPosition, |
| float | fHeightTolerance = 0.5f |
||
| ) | const |
Checks whether vPosition lies inside the current path corridor.
Returns true only if the point is directly above/below one of the corridor polygons and within fHeightTolerance of that polygon's surface. This is different from testing whether a point is on the navmesh at all, and different from a raycast: it answers "would moving to this position leave the planned corridor?". Returns false if no path exists.
| void ezAiNavigation::OptimizeCurrentPath | ( | ) |
Immediately optimizes the current path corridor (topology + visibility).
Only has an effect when a path exists (GetState() == FullPathFound or one of the PartialPath* states). This is the on-demand counterpart to SetTargetPosition()'s bOptimizeWhenFound flag.
| void ezAiNavigation::SetTargetPosition | ( | const ezVec3 & | vPosition, |
| bool | bOptimizeWhenFound = false |
||
| ) |
Sets the desired target location and starts a path search.
If bOptimizeWhenFound is true, the corridor is optimized (topology + visibility) once, as soon as the path search finishes. Use this to avoid the weird corridor shapes that the incremental (counter-based) optimization produces right after a repath. The path search is asynchronous, so the optimization cannot happen inside this call - it happens in a later Update() when the search completes.