2D 모드에서 Recast 그래프를 사용하려면 dimensions 필드를 "2D"로 변경해야 합니다. 또한, RecastGraph.rasterizeColliders 옵션이 활성화되어 있어야 합니다. 2D 모드에서는 Recast 그래프가 메시가 아닌 콜라이더만 래스터화할 수 있기 때문입니다. 그래프의 방향과 크기를 장면에 맞게 조정한 후, 그래프를 스캔할 수 있습니다.
가장 눈에 띄는 그래프 설정 변경 사항은 다음과 같습니다:
그래프를 2D 모드로 변경했습니다.
그래프의 셀 크기를 약간 줄여서 세계를 더 정확하게 표현합니다.
캐릭터 반경도 장면에서 사용될 에이전트의 크기를 반영하도록 변경되었습니다.
그래프의 경계 상자가 세계에 맞도록 변경되었습니다.
그래프가 기본값인 메시 대신 콜라이더를 래스터화하도록 변경되었습니다.
'Background Traversability' 설정이 "Walkable"로 설정되었습니다. 이는 장애물이 아닌 모든 것을 보행 가능하게 만들기 위함입니다.
Tilemaps
타일맵은 타일맵 GameObject에 TilemapCollider2D 컴포넌트를 추가하고, 해당 객체가 Recast 그래프의 레이어 마스크에 포함되어 있는 한 Recast 그래프에서 지원됩니다.
이 에이전트의 경우, 회전 모드를 "Hide"로 설정했습니다. 이는 에이전트의 변환이 회전하지 않도록 하기 위함입니다. 대신, 에이전트가 바라보는 방향을 나타내기 위해 다른 스프라이트가 사용됩니다.
MecanimBridge2D 스크립트는 다음 애니메이터 파라미터를 사용하여 이동 속도를 애니메이터 컴포넌트로 전달합니다:
InputMagnitude: 에이전트의 자연 속도로 정규화된 이동 속도입니다. 에이전트가 자연 속도로 이동할 때는 1, 정지해 있을 때는 0입니다.
X: 에이전트의 자연 속도로 정규화된 수평 이동 속도입니다.
Y: 에이전트의 자연 속도로 정규화된 수직 이동 속도입니다.
애니메이터 컨트롤러에서 루트에는 두 가지 상태가 있습니다: **Moving**과 **Idle**. 이 두 상태는 InputMagnitude가 충분히 높은지 여부에 따라 전환됩니다.
Moving 블렌드 트리는 X 및 Y 파라미터에 따라 다양한 애니메이션을 블렌딩합니다. 각 애니메이션은 캐릭터를 애니메이트하기 위해 스프라이트 시퀀스를 재생합니다. Unity가 클립 간을 블렌딩할 때, 블렌드 트리에서 가장 높은 가중치를 가진 스프라이트를 사용합니다. Moving 블렌드 트리는 또한 InputMagnitude 파라미터에 의해 속도가 곱해지도록 구성되어 있어, 에이전트가 이동하는 속도에 따라 애니메이션이 빠르거나 느리게 재생됩니다.
Recast 그래프는 지형을 래스터화하기 전에 메시로 변환합니다. 지형을 래스터화할 때 성능을 향상시키기 위해 높이 맵이 다운샘플링됩니다. RecastGraph.terrainSampleSize 필드를 사용하여 Recast 그래프가 높이 맵을 얼마나 다운샘플링할지 조정할 수 있습니다. 값이 낮을수록 더 정확한 그래프가 생성됩니다. 더 높은 값을 사용하면 스캔 속도가 약간 빨라지며, 런타임에서 그래프 업데이트를 수행하려는 경우 특히 중요합니다.
지형의 나무는 자동으로 감지되어 그래프에 추가됩니다. 그러나 나무에서는 콜라이더만 래스터화됩니다. 나무 프리팹의 메시를 래스터화하는 것은 지원되지 않습니다. 이는 모든 나무의 모든 메시를 래스터화하는 것이 스캔 시간을 매우 길게 만들 수 있기 때문에 일반적으로 원하는 설정입니다. 나무의 콜라이더는 RecastGraph.rasterizeColliders 필드 설정에 관계없이 래스터화됩니다.
이 장면에서는 RecastGraph 나 GridGraph 모두 잘 작동할 수 있습니다. 그러나 이 예제에서는 Recast 그래프가 임의로 선택되었습니다.
지면이 거의 평평하기 때문에 Recast 그래프는 기본 설정에서 많은 수정을 필요로 하지 않습니다. 가장 눈에 띄는 변경 사항은 다음과 같습니다:
그래프의 셀 크기가 약간 줄어들어 세계를 더 정확하게 표현합니다.
캐릭터 반경도 장면에서 사용될 에이전트의 크기를 반영하도록 변경되었습니다.
그래프의 경계 상자가 세계에 맞도록 변경되었습니다.
레이어 마스크는 기본 레이어만 포함하도록 변경되었습니다. 이는 이 장면의 모든 장애물이 기본 레이어에 있기 때문입니다.
Tags that influence traversability
장면에는 빨간 복도와 파란 복도가 하나씩 있습니다. 또한 빨간 에이전트와 파란 에이전트 두 개가 있습니다. 빨간 에이전트는 빨간 복도만 통과할 수 있고, 파란 에이전트는 파란 복도만 통과할 수 있습니다.
이는 태그를 사용하여 구현되었습니다. 빨간 복도의 지면에는 "Red" 태그가 할당되었고, 파란 복도에는 "Blue" 태그가 할당되었습니다. 마찬가지로 에이전트는 기본 지면 태그와 자신의 색상에 해당하는 태그만 통과할 수 있도록 구성되었습니다.
복도의 지면 타일에는 RecastMeshObj 컴포넌트가 추가되었습니다. 이를 통해 Recast 그래프가 이 메시를 스캔하는 방식을 변경할 수 있습니다. 이 경우, 표면 유형이 "태그가 있는 보행 가능 표면"으로 변경되었고, 태그는 각각 "Red" 또는 "Blue"로 변경되었습니다.
에이전트의 경우, FollowerEntity 컴포넌트가 태그를 고려하도록 약간 조정되었습니다. 특히 "Tags" 항목 아래에서 각 봇이 통과할 수 없는 태그가 비활성화되었습니다.
예를 들어, 빨간 봇이 경로를 계산할 때는 모든 파란 태그 노드를 통행 불가로 간주합니다.
이전 섹션에서 설명한 태그를 기반으로, 장면에는 또한 검은색 영역이 있습니다. 이 영역은 두 에이전트 모두 통과할 수 있지만, 파란 에이전트는 큰 우회를 하지 않는 한 이 영역을 피하려고 합니다.
첫 번째 비디오에서는 우회가 상대적으로 짧아서 파란 에이전트가 검은색 영역을 피합니다. 하지만 두 번째 비디오에서는 우회가 더 길어져서 파란 에이전트가 대신 검은색 영역을 통과하기로 결정합니다.
이 설정 방식은 FollowerEntity 컴포넌트의 "Tags" 항목 아래에서 "BlackHighPenalty" 태그가 파란 에이전트에게 높은 페널티로 설정된 것입니다. 지면은 이전 섹션에서 설명한 것처럼 RecastMeshObj 컴포넌트를 사용하여 "BlackHighPenalty" 태그로 태깅되었습니다.
그래프의 모든 노드를 매 프레임마다 이동시키는 것은 느리고, 이미 계산된 경로에 이 정보를 전파하는 것도 매우 까다롭습니다. 그래서 여기서 사용하는 이동 스크립트(LocalSpaceRichAI)는 이를 피합니다.
장면의 그래프는 실제로 정적입니다. 우주선이 움직이는 동안에도 같은 위치에 머물러 있습니다. 그러나 게임이 시작될 때 그래프가 스캔되면 우주선의 위치가 기록됩니다. 경로를 계산할 때 이동 스크립트는 자신의 위치와 목적지를 변환하여 우주선이 여전히 초기 위치에 있는 것처럼 보이도록 합니다. 이는 스캔된 그래프와 완벽하게 일치하게 합니다. 마찬가지로 경로를 따를 때는 경로상의 모든 점을 현재 우주선의 위치와 회전을 고려하여 변환합니다.
이 방법에는 몇 가지 제한이 있습니다. 예를 들어, 내비메시 컷팅 및 기타 그래프 업데이트는 작동하지 않습니다. 하지만 우주선이 어떻게 움직이든 경로를 따르는 데는 문제가 없습니다.
Detailed setup
장면은 다음과 같이 구성됩니다:
1. 우주선 추가: 이는 어떤 메시 또는 메시의 집합일 수 있습니다.
2. Recast 그래프 추가: 초기 위치에 있는 우주선을 커버하도록 구성됩니다.
3. 에이전트 추가: 에이전트를 우주선 GameObject의 자식으로 추가하여 우주선과 함께 이동하도록 합니다. 4. LocalSpaceGraph 컴포넌트 추가: 우주선 GameObject에 추가하여 우주선의 초기 위치를 추적하고, 에이전트가 우주선의 좌표 시스템과 세계 좌표 시스템 간을 번역할 수 있도록 합니다. 5. LocalSpaceRichAI 컴포넌트 추가: 에이전트에 추가하고, LocalSpaceGraph 컴포넌트를 LocalSpaceRichAI.graph 필드에 할당합니다.
6. 우주선 이동: BezierMover 컴포넌트를 사용하여 이동시킵니다. 이 컴포넌트는 매끄러운 곡선을 따라 일련의 점을 통해 우주선을 이동시킵니다.
참고 Interactable 컴포넌트는 예제 장면을 위한 매우 간단한 상태 기계 구현입니다. 실제 게임에서는 더 고급 상태 기계 구현을 사용하는 것이 좋지만, 이 스크립트는 게임용 상태 기계 코드를 작성하려는 경우 좋은 예제가 될 수 있습니다.
클릭했을 때 다음과 같이 구성됩니다:
플레이어가 바닥의 어느 곳을 클릭했을 때와 동일한 "여기로 이동" 파티클 효과를 생성합니다.
에이전트를 빨간 점으로 이동시키고, 콘솔을 향해 회전시킵니다.
여러 파티클 효과를 생성합니다.
문의 애니메이터 컴포넌트에서 "open" 파라미터를 true로 설정합니다. 이렇게 하면 문 열기 애니메이션이 재생됩니다.
문의 애니메이터는 열림 상태 또는 닫힘 상태 중 하나일 수 있습니다. 애니메이터가 "open" 파라미터의 변화를 감지하면 적절한 전환 애니메이션을 재생하고 다른 상태로 이동합니다. 열림 애니메이션이 시작되면 이 NavmeshCut 이 비활성화되어 에이전트가 문을 통과할 수 있게 됩니다.
참고 대신 콜라이더를 DynamicGridObstacle 컴포넌트와 함께 사용하여 문 주변의 그래프를 다시 계산하도록 트리거할 수도 있습니다. 이 접근 방식은 Bridge 섹션에서 사용됩니다.
Bridge
이동 가능한 다리는 처음에는 통행할 수 없지만, 에이전트를 빨간 점 옆에 있는 콘솔로 이동시켜 위치로 옮길 수 있습니다.
이는 문과 매우 유사한 방식으로 구성되어 있습니다. 주요 차이점은 애니메이션에 있습니다. 다리 애니메이션이 끝나면 콜라이더 객체가 활성화되거나 비활성화되며, 이 콜라이더 객체에는 DynamicGridObstacle 컴포넌트도 부착되어 있습니다. 콜라이더를 활성화하거나 비활성화하면 DynamicGridObstacle 컴포넌트가 다리 주변의 그래프를 처음부터 다시 계산하게 됩니다. 이는 내비메시 컷팅보다 훨씬 강력한 작업으로, 그래프의 어느 부분이든 변경할 수 있으며, 일부만 제거하는 것이 아닙니다. 그러나 그래프의 복잡성에 따라 속도가 느려질 수 있습니다.
참고 DynamicGridObstacle 컴포넌트는 원래 그리드 그래프만 지원할 때 이러한 이름이 붙여졌습니다. 이제는 Recast 그래프에서도 사용할 수 있으므로 이름이 다소 오해의 소지가 있습니다. 이름은 향후 업데이트에서 변경될 수 있습니다.
Chest
장면에는 클릭하여 열 수 있는 상자가 있습니다. 상자에 대한 자세한 설명은 " Chests " 섹션에 나와 있습니다.
이 예제 장면은 3D 게임에서 Recast 그래프를 사용하는 방법을 시연합니다. 또한 Interactable 컴포넌트를 사용하여 간단한 상호작용 객체를 만드는 방법을 시연하며, 오프-메시 링크와 NavmeshCut 컴포넌트를 사용하여 Recast 그래프에 동적 장애물을 만드는 방법을 포함하고 있습니다.
장면에는 하나의 에이전트가 있으며, 바닥을 클릭하여 이동시킬 수 있습니다. "P" 키를 누르면 작은 상자가 바닥에 떨어지는 형태의 동적 장애물을 생성할 수 있습니다.
이 장면에서 사용된 그래프는 RecastGraph입니다. Recast 그래프가 선택된 이유는 다음과 같습니다:
이 장면에 존재하는 돌출부와 다리를 지원하기 때문입니다.
필요한 수준의 디테일을 쉽게 표현할 수 있기 때문입니다. 이 장면에 존재하는 동적 장애물을 높은 정밀도로 쉽게 지원할 수 있기 때문입니다.
이 장면에는 계층화된 그리드 그래프도 사용할 수 있었습니다. 하지만 동적 장애물을 잘 표현하려면 더 높은 수준의 디테일이 필요했을 것입니다. 이 장면은 계층화된 그리드 그래프가 제공하는 세밀한 태그와 페널티 지원의 이점을 누리지 못하며, 세계 자체가 그리드 기반이 아니기 때문에 Recast 그래프가 더 적합합니다.
Chests
이 예제 장면에는 플레이어가 클릭하여 열 수 있는 몇 개의 상자가 포함되어 있습니다.
이 상자들은 Interactable 컴포넌트를 사용하여 상자의 애니메이션과 캐릭터의 움직임을 제어하는 간단한 상태 기계를 구현합니다.
참고 Interactable 컴포넌트는 예제 장면을 위한 매우 간단한 상태 기계 구현입니다. 실제 게임에서는 더 고급 상태 기계 구현을 사용하는 것이 좋지만, 이 스크립트는 게임용 상태 기계 코드를 작성하려는 경우 좋은 예제가 될 수 있습니다.
메인 카메라에 있는 TargetMover 컴포넌트는 플레이어가 상호작용 가능한 객체를 클릭했는지 감지하고, 클릭 시 상호작용을 시작하는 코드를 포함하고 있습니다. 이 경우, 상호작용 객체는 다음 단계를 수행하도록 구성되어 있습니다:
플레이어가 바닥의 어느 곳을 클릭했을 때와 동일한 "여기로 이동" 파티클 효과를 생성합니다.
에이전트를 상자로 이동시키고, 상자를 향해 회전시킵니다.
상자 열기 애니메이션을 재생하고, 일부 파티클 효과를 생성합니다.
Off-mesh link
맵의 한 구석에는 에이전트가 뛰어내릴 수 있는 절벽이 있습니다. 이는 NodeLink2 컴포넌트를 사용하여 구현되었습니다.
오프-메시 링크는 일반적으로 연결되지 않은 내비메시의 두 부분을 연결합니다. 이들은 절벽에서 뛰어내리기, 사다리 오르기, 문 열기 등의 동작에 사용됩니다.
이 오프-메시 링크는 절벽 상단의 시작 지점과 절벽 하단의 끝 지점으로 구성되어 있습니다. 링크는 또한 에이전트가 절벽을 뛰어올라가려 하지 않도록 단방향으로 설정되어 있습니다. 에이전트가 절벽을 뛰어내리는 대신 돌아서 가도록 유도하기 위해 비용 계수는 2로 설정되었습니다. 비용 계수가 1이면 링크를 통해 이동하는 비용이 정상적인 내비메시에서 같은 거리를 이동하는 것과 동일하다는 의미입니다.
게임 모드에서 "P" 키를 누르면 작은 상자가 땅에 떨어지는 형태의 동적 장애물이 생성됩니다. 이 장애물은 NavmeshCut 컴포넌트를 사용하여 내비메시에 영향을 줍니다.
Recast/Navmesh 그래프에서 내비메시 컷팅은 타일을 처음부터 다시 계산하는 것보다 상당히 빠릅니다. 그러나 새로운 부분을 추가할 수 없고, 내비메시의 일부만 제거할 수 있기 때문에 약간 제한적입니다. 결과 내비메시는 처음부터 다시 계산한 것만큼 좋지는 않지만, 대부분의 게임에서는 동적 장애물에 대해 내비메시 컷팅이 훌륭한 해결책입니다.
상자에 대한 내비메시 컷은 큐브를 근사한 반경을 가진 구 형태로 구성되어 있습니다. 해상도가 6일 때, 내비메시 컷은 내비메시에서 육각형 모양을 제거합니다. "박스" 형태로 구성할 수도 있었지만, 구 형태가 약간 더 간단하고, 둥근 모양이 상자 주위의 이동을 더 부드럽게 만듭니다.
이 스크립트는 다음 애니메이터 파라미터를 사용하여 이동 속도를 애니메이터 컴포넌트로 전달합니다:
NormalizedSpeed: 세계 단위로 측정된 이동 속도를 MineBotAnimation.naturalSpeed 및 캐릭터의 스케일로 나눈 값입니다. 에이전트가 자연 속도로 이동할 때는 1이 되고, 정지해 있을 때는 0이 됩니다.
애니메이터 컨트롤러에서 루트에는 두 가지 상태가 있습니다: forward와 idle. 이는 두 개의 애니메이션 클립으로, NormalizedSpeed가 충분히 높은지 여부에 따라 전환됩니다. forward 애니메이션 클립은 NormalizedSpeed 파라미터에 의해 속도가 곱해지도록 설정되어 있어, 에이전트의 이동 속도에 따라 애니메이션이 빠르거나 느리게 재생됩니다.
다음은 경로를 검색할 때 발생할 수 있는 오류입니다. 이러한 오류는 치명적인 것이 아니며, 시스템이 어떤 이유로 인해 유효한 경로를 찾을 수 없다는 것을 의미합니다.
Couldn't find a node close to the start point(시작 지점 근처에 노드를 찾을 수 없음
경로 요청이 시작되면 시스템은 경로의 시작 지점에 가장 가까운 노드(그리드 그래프의 타일 하나, 네비게이션 메쉬/리캐스트 그래프의 삼각형 하나, 포인트 그래프의 점 하나)를 찾습니다. 이 검색은 제한된 범위를 가지지만, 일반적으로 실용적인 목적을 위해 충분합니다. 따라서 그래프의 (이동 가능한) 노드와 전혀 가까이 있지 않은 지점에서 경로를 요청하면 이 오류가 기록됩니다.
이 오류를 해결하는 방법:
경로 요청의 시작 지점이 올바른지 확인하십시오.
포함된 이동 스크립트 중 하나를 사용 중인 경우, AI가 그래프와 합리적으로 가까운 곳에서 시작하도록 하십시오.
Couldn't find a node close to the end point(끝 지점 근처에 노드를 찾을 수 없음)
이 오류는 위의 오류와 매우 유사합니다. 그러나 끝 지점에 가장 가까운 노드를 찾을 때 시스템은 해당 노드가 이동 가능할 뿐만 아니라 시작 노드에서 도달할 수 있어야 한다는 추가 제약 조건을 가집니다. 이 오류는 일반적으로 AI가 맵의 한쪽 끝에 있는 작은 방에 갇혀 있고, 매우 먼 지점으로 이동하라는 명령을 받았을 때 발생합니다. 끝 지점에 가까운 노드를 찾으려면, 시작 노드에서 도달할 수 있는 노드만 검색할 수 있기 때문에 매우 큰 거리를 검색해야 합니다.
이 오류를 해결하는 방법:
이전 오류를 참조하십시오.
There is no valid path to the target(대상까지 유효한 경로가 없음)
이 오류는 PathNNConstraint 클래스에서 상속받지 않거나 해당 클래스의 논리를 사용하지 않는 사용자 지정 NNConstraint를 경로 객체에 제공한 경우에 발생합니다.
Searched whole area but could not find target(전체 영역을 검색했지만 대상을 찾을 수 없음)
이는 시작 노드에서 끝 노드로의 가능한 경로가 없다는 것을 의미합니다. 일반적으로 태그를 사용하고 일부 태그를 통과할 수 없도록 설정한 경우에 발생합니다. 일반적인 이동 가능성에서는 시스템이 그래프의 어떤 노드에서 어떤 다른 노드로 도달할 수 있는지를 미리 계산하지만, 태그를 사용할 때는 이를 할 수 없습니다.
이미지는 모든 태그를 통과할 수 있을 때 검색된 노드를 보여줍니다. 빨간 사각형 안의 모든 노드에 수정된 태그가 있는 것을 확인하십시오.
이 이미지는 태그가 변경된 빨간 사각형 안의 노드를 통과할 수 없을 때 검색된 노드를 보여줍니다. 시작 노드에서 도달할 수 있는 모든 노드가 검색된 것을 확인하십시오.
No open points, the start node didn't open any nodes(열린 지점이 없음, 시작 노드가 노드를 열지 않음)
이 오류는 이전 오류의 특별한 경우입니다. 경로에서 단일 노드만 검색되고 경로의 끝을 찾을 수 없을 때 기록됩니다. 이 특정 오류는 종종 그리드 그래프의 간단한 구성 오류로 인해 발생합니다. AI에 콜라이더가 있고 해당 콜라이더가 그래프 설정의 Height Testing 레이어 마스크에 포함되어 있으면 그래프가 AI의 머리 위에 노드를 배치할 수 있습니다(이미지 참조).
결과적으로 AI는 매우 작은 방에 갇혀 있다고 생각하고 그곳에서 나갈 수 없게 됩니다.
이 오류를 해결하는 방법:
AI가 Height Testing 레이어 마스크에 포함되지 않은 레이어에 있는지 확인하십시오.
Canceled path because a new one was requested(경로 취소됨: 새로운 경로가 요청되었기 때문)
Seeker 컴포넌트는 한 번에 하나의 경로 요청만 처리합니다. 경로 요청은 비동기적으로 처리되기 때문에 스크립트가 이전 경로가 완전히 계산되기 전에 새로운 경로를 계산하려고 시도할 수 있습니다. 에이전트가 맵의 다른 부분으로 텔레포트한 경우, 이전 경로 계산은 쓸모없게 될 수 있기 때문에 이러한 상황이 발생할 수 있습니다. 이러한 경우, Seeker는 이전 경로 요청을 취소하고 이 오류 메시지를 실패 이유로 설정합니다.
일반적인 경로 계산 시에도 이 메시지가 표시된다면, 스크립트가 새로운 경로 계산을 시작하기 전에 이전 경로가 계산되기를 제대로 기다리지 않았기 때문일 수 있습니다. Seeker가 계산을 완료했는지 확인하려면 Seeker.IsDone 메서드를 호출하거나 OnPathComplete 콜백이 호출될 때까지 기다릴 수 있습니다.
Canceled by script(스크립트에 의해 취소됨 (Seeker.CancelCurrentPathRequest))
이 오류 메시지는 이전 오류 메시지와 매우 유사하지만, 특정 스크립트가 Seeker.CancelCurrentPathRequest 메서드를 사용하여 경로 요청을 취소했음을 의미합니다. 경로가 스크립트에 의해 명시적으로 취소되었기 때문에 스크립트가 무엇을 하는지 알고 있다고 가정할 수 있으며, 이 메시지가 표시되더라도 걱정할 필요는 없습니다.
There are no graphs in the scene(씬에 그래프가 없음)
AstarPath 컴포넌트에 그래프가 전혀 포함되어 있지 않습니다. 파일에서 그래프를 로드하거나 스크립트를 사용하여 그래프를 생성하는 경우, 다른 스크립트가 경로를 요청하기 전에 이러한 작업이 완료되지 않은 것으로 보입니다.
그래프 오류
일부 메쉬가 정적으로 배치됨...
일부 메쉬가 정적으로 배치되었습니다. 이러한 메쉬는 기술적인 제약으로 인해 네비게이션 메쉬 계산에 사용할 수 없습니다. 런타임 동안 스크립트는 정적으로 배치된 메쉬의 데이터를 액세스할 수 없습니다. 이 문제를 해결하는 한 가지 방법은 캐시된 시작(인스펙터의 Save & Load 탭)을 사용하여 게임이 실행되지 않을 때만 그래프를 계산하는 것입니다.
유니티의 정적 배치 시스템은 여러 드로우콜을 단일 드로우콜로 결합하여 게임의 성능을 향상시킬 수 있기 때문에 훌륭합니다. 그러나 이 과정에서 유니티는 이 패키지의 스크립트가 런타임 중에 메쉬 데이터를 읽을 수 없게 만듭니다(유니티 편집기를 제외하고). 리캐스트 그래프의 경우, 이러한 메쉬를 런타임 중에 그래프를 생성하는 데 사용할 수 없음을 의미합니다.
이 이미지는 유니티가 정적 배치에 사용하는 토글을 보여줍니다.
이 오류를 해결하는 방법:
레캐스트 그래프를 생성하기 위해 메쉬 대신 콜라이더를 사용할 수 있습니다(리캐스트 그래프 설정 참조). 일반적으로 콜라이더는 렌더링에 사용되는 메쉬보다 상세하지 않기 때문에 이 방법은 일반적으로 더 빠릅니다.
그래프를 편집기에서 계산한 다음 게임을 시작할 때 파일에서 그래프를로드 할 수 있습니다. 이 패키지에있는 'Cached Startup' 기능을 사용하여이 작업을 매우 쉽게 수행 할 수 있습니다. 이렇게하면 게임의 시작 시간이 크게 개선되며 파일에서 그래프를로드하는 것이 처음부터 생성하는 것보다 훨씬 빠릅니다. 단점은 런타임 중에 생성되는 절차적 레벨에서 작동하지 않는다는 것입니다. 자세한 내용은 그래프 저장 및 로드를 참조하십시오.
패키지가 올바르게 설치되거나 업그레이드되지 않으면 컴파일러 오류가 발생할 수 있습니다. 패키지를 방금 업그레이드 한 경우 UnityPackages가 뭔가를 망가뜨렸는지 확인하는 가장 쉬운 방법은 AstarPathfindingProject 폴더(그리고 있다면 AstarPathfindingEditor 폴더도)를 삭제하고 패키지를 다시 가져오는 것입니다.
Unity의 NavMesh Agent는 내장된 로컬 회피 기능을 가지고 있습니다. 이 패키지에서는 로컬 회피가 대신 RVOController라는 별도의 컴포넌트에 의해 처리됩니다. 이미 이동 스크립트가 있는 객체에 RVOController를 첨부하면 자동으로 감지되어 로컬 회피가 Unity 패키지와 유사하게 작동합니다. 또한 모든 계산을 처리하고 글로벌 시뮬레이션 설정을 갖춘 RVOSimulator 컴포넌트의 단일 글로벌 인스턴스가 필요합니다.
이동 스크립트와 상호 작용할 때, Unity 패키지와 이 패키지의 이름이 다시 다릅니다. 다음은 가장 많이 사용되는 속성/메서드와 이 패키지에서 해당하는 속성/메서드 목록입니다. 여기서는 모든 이동 스크립트(AIPath/AILerp/RichAI 등)가 구현하는 인터페이스인 IAstarAI 인터페이스를 참조합니다.
