이 페이지에서는 AStarQuery 클래스에서 제공하는 몇 가지 구성 옵션에 대해 설명합니다.
간단한 경로 계산 API를 사용하는 경우에는 이러한 옵션을 사용할 수 없거나 기본값으로 설정합니다. 봇에 대해 이러한 옵션을 설정하려면 봇에서 사용하는 NavigationProfile을 사용자 정의하거나 NavigationProfile에서 쿼리를 검색하여 설정하고 Bot::ComputeNewPathAsync()를 호출할 때 제공합니다. 이러한 다른 방법에 대한 자세한 내용은 정적 경로 가져오기을(를) 참조하십시오.
대부분의 경우 경로 계산에 사용할 시작점과 대상점은 모두 NavMesh 경계 내의 지면에 있습니다. 이 일반 시나리오에서 쿼리는 쿼리를 초기화할 때 제공한 시작점과 대상점에 해당하는 NavMesh 삼각형 찾기를 투명하게 처리합니다.
그러나 게임에서 NavGraph 및 스마트 오브젝트를 광범위하게 사용하면 봇이 NavMesh 경계 외부에서 NavGraph를 가로지르는 중간에 경로 계산을 시작하도록 할 수 있습니다. 마찬가지로 봇이 NavMesh 경계 외부의 NavGraph 가장자리 또는 정점에 있는 대상으로 이동하도록 할 수 있습니다. 그러나 3D 공간의 임의 점을 NavGraph 정점 및 가장자리와 연결하는 기본 제공 공간화 시스템은 없습니다.
쿼리의 시작이나 대상으로 사용되어야 하는 NavGraph 정점 또는 가장자리에 대한 포인터로 AStarQuery를 명시적으로 설정하면 이러한 경우를 지원할 수 있습니다. 다음 메서드를 사용하십시오.
void AStarQuery::SetStartNavGraphEdgePtr(const NavGraphEdgePtr& startNavGraphEdgePtr, NavGraphEdgeDirection navGraphEdgePathfindMode); void AStarQuery::SetStartNavGraphVertexPtr(const NavGraphVertexPtr& startNavGraphVertexPtr); void AStarQuery::SetDestNavGraphEdgePtr(const NavGraphEdgePtr& startNavGraphEdgePtr, NavGraphEdgeDirection navGraphEdgePathfindMode); void AStarQuery::SetDestNavGraphVertexPtr(const NavGraphVertexPtr& startNavGraphVertexPtr);
예를 들어 봇이 사다리를 오르는 과정에서 경로를 다시 계산하도록 하려면 봇이 현재 따르고 있는 NavGraph 가장자리를 경로 계산의 시작점으로 사용하도록 경로 찾기 쿼리를 설정할 수 있습니다.
가장자리를 시작점 및 끝점으로 설정하는 메서드는 지정된 가장자리를 양방향으로 가로지를 수 있는지 여부를 나타내는 추가 열거 값을 허용합니다. 예를 들어 봇이 사다리를 따르는 동안 새 경로가 시작 가장자리를 따라 한쪽 방향으로 이동하도록 할 수 있습니다. 그러면 봇이 사다리 가운데에서 방향을 변경할 수 있습니다. 그러나 봇이 점프를 제어하는 스마트 오브젝트를 사용하고 있으면 시작 가장자리를 따르는 이동 방향이 한 방향으로만 이동하도록 강제하여 봇이 점프 중간에 방향을 변경하지 못하도록 할 수 있습니다.
또한 이러한 메서드 중 하나를 사용하여 NavGraph 정점이나 가장자리를 쿼리의 시작 또는 대상으로 설정하면 쿼리에 대해 시작점을 설정했는지 대상 위치를 설정했는지에 관계없이 재정의합니다.
경우에 따라 경로 찾기 쿼리의 시작점 또는 대상점이 약간 NavMesh 경계 외부에 있을 수 있습니다. 예를 들면 다음과 같습니다.
AStarQuery에서 시작점이나 대상점에 유효한 NavMesh 삼각형을 찾을 수 없는 경우 점이 NavMesh 경계 외부에 있다고 간주합니다. 이 경우 근처의 NavMesh에 후킹하려고 합니다. InsidePosFromOutsidePosQuery를 실행하여 NavMesh 내부에서 가장 근접한 유효한 점을 찾고 유효한 해당 점(및 연결된 NavMesh 삼각형)을 경로 계산의 시작 또는 대상으로 사용합니다. NavMesh를 통과하는 경로가 성공적으로 계산되면 작은 세그먼트가 경로에 추가되어 원래의 잘못된 시작점부터 첫 번째 경로 노드까지 연결하거나 마지막 경로 노드에서 원래의 잘못된 대상점까지 연결합니다.
NavMesh에 대해 검색된 X축 및 Y축을 따라 시작점에서 대상점까지의 최대 거리는 TraversalParameters::m_fromOutsideNavMeshDistance 및 TraversalParameters::m_toOutsideNavMeshDistance에서 설정됩니다. 기본 최대 거리는 1.5f미터입니다. 검색은 m_fromOutsideNavMeshDistance 및 m_toOutsideNavMeshDistance와 동일한 X 및 Y축의 절반 범위를 사용하여 시작점 및 대상점 주위의 축에 정렬된 경계 상자 내에서 삼각형을 찾습니다.
AStarQuery는 경로 계산의 성능을 향상시키는 데 사용할 수 있는 여러 가지 옵션을 제공합니다.
A* 알고리즘을 사용하여 시작점에서 연결할 수 없는 대상점에 대한 경로를 찾는 경우(예: 고립된 섬 또는 지붕) 알고리즘은 결국 전체 지세를 탐색한 후에 요청한 대상에 대해 경로가 존재할 수 없음을 확신합니다. 맵이 큰 경우 이러한 불가능한 경로 요청으로 인해 엄청난 CPU 시간이 낭비될 수 있습니다.
예를 들어 아래 이미지에서는 왼쪽의 큰 전체 영역을 탐색한 후에야 A*에서 물의 먼 쪽으로 가능한 경로가 없음을 확인할 수 있습니다.
이러한 가능성을 방지하기 위해 AStarQuery의 전파는 범위가 시작 위치와 대상 사이의 직선으로부터 미터 단위로 수평(X,Y) 평면에서 측정되는 2D 상자 내로 제한됩니다.
예를 들어 아래 이미지에서는 흰색 화살표로 표시된 상자의 범위와 함께 녹색으로 표시된 제한 상자를 보여줍니다. 이 2D 상자의 외부 영역은 탐색되지 않습니다.
경우에 따라 시작점에서 경로 계산의 대상점을 직접 연결할 수 있습니다. 이러한 경우 A* 알고리즘을 시작하고 NavData를 검색하며 정적 경로를 미세 조정하는 데 불필요한 CPU 리소스가 너무 많이 사용됩니다. 따라서 시작점에서 대상까지의 직접 경로를 경로로 바로 채택하고 A* 계산을 완전히 건너뛰는 것이 더 효율적입니다.
이러한 경우를 처리하기 위해 AStarQuery는 CanGo 쿼리를 내부적으로 수행하여 대상에 대한 직접 경로에 장애물이 없는지 여부를 테스트합니다. 장애물이 없을 경우 AStarQuery는 직접 경로를 바로 채택합니다.
그러나 연결 테스트가 사용되지 않으므로 확인 작업에 매우 작은 CPU가 사용됩니다. 따라서 이 확인을 수행하면 시작점에서 대상에 직접 연결할 수 있는 경로 요청의 하위 세트에 대한 성능은 향상되지만 직접 경로에 장애물이 없는 경우 확인 자체에서 불필요한 CPU를 사용하게 됩니다. 연결 확인을 활성화하면 게임에서 직접 연결할 수 있는 경로 요청 수와 A*를 사용해야 하는 수 사이의 비율에 따라 전체 성능이 향상되거나 향상되지 않을 수 있습니다.
연결 확인을 수행하면 시작점에서 경로 요청의 대상에 직접 연결할 수 있는 가능성에 비례하여 전체 경로 찾기 성능이 향상될 가능성이 더 많습니다. 따라서 장애물이 적게 있는 넓게 펼쳐진 지세에서나 매우 짧은 경로를 자주 계산해야 하는 경우(예: 다른 캐릭터를 따르는 경우) 이 직선 확인을 활성화하는 것이 좋을 수 있습니다.
직선 테스트가 성공하면 A*가 시작되지 않습니다. 따라서 시작점과 대상 사이에 있는 NavGraph가 고려되지 않습니다. NavMesh를 통한 이동 비용(예: 텔레포터)보다 낮은 사용자 정의 비용으로 NavGraph를 사용하는 경우 봇은 경로가 A*에 의해 계산될 때와 같은 방식으로 해당 NavGraph를 포함하는 경로를 선호하지 않습니다.