Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

성능

일반적인 탐색 관련 성능 문제는 다음 주제로 분류할 수 있습니다.

• 탐색 메시 베이킹을 위해 씬 트리 노드를 구문 분석할 때 성능 문제가 발생합니다.

• 실제 탐색 메시를 베이킹할 때 성능 문제가 발생합니다.

• NavigationAgent 경로 쿼리에 성능 문제가 있습니다.

• 실제 경로 검색에 성능 문제가 있습니다.

• 내비게이션 지도 동기화 시 성능 문제가 발생합니다.

다음 섹션에서는 프레임 속도에 미치는 영향을 식별하고 수정하거나 최소한 완화하는 방법에 대한 정보를 찾을 수 있습니다.

씬 트리 노드 구문 분석 시 성능 문제

팁

가능한 한 적은 수의 가장자리가 있는 단순한 모양을 사용하는 것을 선호합니다. 원, 구, 토러스처럼 둥근 것은 없습니다.

메시는 GPU에서 복사해야 하고 일반적으로 필요 이상으로 훨씬 더 자세하므로 소스 형상으로 복잡한 시각적 메시보다 물리적 충돌 모양을 사용하는 것을 선호합니다.

일반적으로 탐색 메시를 굽기 위한 소스 형상으로 매우 복잡한 형상을 사용하지 마십시오. 예: 매우 상세한 시각적 메시를 사용하지 마십시오. 모양을 데이터 배열로 구문 분석하고 탐색 메시 베이킹을 위해 복셀화하면 최종 탐색 메시에서 실제 품질 향상이 없기 때문에 오랜 시간이 걸립니다. 대신 매우 단순화된 모양의 세부 수준 버전을 사용하세요. 더 좋은 점은 동일한 형상을 대략적으로만 포함하지만 길 찾기에 충분히 좋은 구운 결과를 생성하는 상자 및 직사각형과 같은 매우 원시적인 모양을 사용하는 것입니다.

내비게이션 메시 베이킹을 위한 소스 지오메트리로 시각적 메시보다 간단한 물리 충돌 모양을 사용하는 것이 좋습니다. 물리 모양은 기본적으로 쉽고 빠르게 분석할 수 있는 매우 제한적이고 최적화된 모양입니다. 반면에 시각적 메시의 범위는 단순한 것부터 복잡한 것까지 다양합니다. 또한 시각적 메시 데이터는 GPU에 직접 저장되고 CPU에 캐시되지 않으므로 시각적 메시 데이터에 액세스하려면 파서가 RenderingServer에서 메시 데이터 배열을 요청해야 합니다. 이를 위해서는 RenderingServer 스레드를 잠가야 하며 렌더링이 멀티 스레드로 실행되는 동안 런타임 시 프레임 속도에 심각한 영향을 미칠 수 있습니다. 렌더링이 단일 스레드로 실행되는 경우 프레임 속도 영향이 더욱 심해질 수 있으며 복잡한 메시에서 메시 구문 분석으로 인해 전체 게임이 몇 초 동안 정지될 수 있습니다.

탐색 메시 베이킹 관련 성능 문제

팁

런타임 시 탐색 메시를 굽는 데 항상 백그라운드 스레드를 사용하는 것이 좋습니다.

NavigationMesh cell_size 및 ``cell_height``를 늘려 더 적은 복셀을 생성합니다.

``SamplePartitionType``를 유역에서 모노톤 또는 레이어로 변경하여 베이킹 성능을 얻으세요.

경고

정밀 오류를 방지하려면 노드를 사용하여 소스 형상을 확장하지 마십시오. 대부분의 배율은 시각적으로만 적용되며 기본 배율이 매우 큰 모양은 축소하는 동안에도 여전히 많은 추가 처리가 필요합니다.

런타임 시 탐색 메시 베이킹은 가능하면 항상 백그라운드 스레드에서 수행되어야 합니다. 작은 크기의 내비게이션 메시라도 프레임 속도가 견딜 수 있는 수준으로 유지되어야 하는 경우 단일 프레임에 압축할 수 있는 것보다 굽는 데 훨씬 더 오랜 시간이 걸릴 수 있습니다.

씬 트리 노드에서 구문 분석된 소스 형상 데이터의 복잡성은 모든 것이 그리드/복셀에 매핑되어야 하므로 베이킹 성능에 큰 영향을 미칩니다. 런타임 베이킹 성능을 위해 NavigationMesh 셀 크기와 셀 높이는 게임의 내비게이션 메시 품질 문제를 일으키지 않고 최대한 높게 설정되어야 합니다. 셀 크기나 셀 높이가 너무 낮게 설정되면 베이킹 시 소스 형상을 처리하기 위해 과도한 양의 복셀이 생성됩니다. 소스 형상이 매우 큰 게임 세계에 걸쳐 있는 경우 베이킹 프로세스가 중간에 메모리가 부족하여 게임이 중단될 수도 있습니다. 일부 성능을 얻기 위해 게임 소스 지오메트리가 얼마나 복잡한지에 따라 파티션 유형을 낮출 수도 있습니다. 예: 대부분 평평한 표면과 블록 모양의 지오메트리를 가진 게임은 베이킹 속도가 훨씬 빠른(예: 거리 필드 패스가 필요하지 않기 때문에) 모노톤이나 레이어 모드를 사용하면 문제를 해결할 수 있습니다.

노드를 사용하여 소스 형상의 크기를 조정하지 마십시오. 잘못 일치하는 정점과 가장자리로 인해 많은 정밀도 오류가 발생할 수 있을 뿐만 아니라 일부 스케일링은 실제 구문 분석된 데이터가 아닌 시각적으로만 존재합니다. 예: 에디터에서 메시가 시각적으로 축소된 경우, 예를 들어 MeshInstance에서 배율을 0.001로 설정하더라도 메쉬에는 베이킹을 위해 처리할 거대하고 매우 복잡한 복셀 그리드가 여전히 필요합니다.

NavigationAgent 경로 쿼리의 성능 문제

팁

NavigationAgent 스크립트의 모든 프레임에서 불필요한 경로 재설정 및 쿼리를 피하세요.

동일한 프레임에서 모든 NavigationAgent 경로를 업데이트하지 마십시오.

사용자 정의 NavigationAgent 스크립트의 논리적 오류 및 낭비적인 작업은 성능 문제의 매우 일반적인 원인입니다. 매 프레임마다 경로를 재설정하는 데 주의하세요. 기본적으로 NavigationAgent는 대상 위치가 변경되거나 내비게이션 지도가 변경되거나 원하는 경로 거리에서 너무 멀어지는 경우에만 새 경로를 쿼리하도록 최적화되어 있습니다.

예: AI가 플레이어에게 이동해야 할 때 대상 위치는 매 프레임마다 새로운 경로를 쿼리하므로 매 프레임마다 플레이어 위치로 설정되어서는 안 됩니다. 대신, 현재 목표 위치에서 플레이어 위치까지의 거리를 비교하고 플레이어가 너무 멀리 이동한 경우에만 새로운 목표 위치를 설정해야 합니다.

매 프레임마다 목표 위치에 도달할 수 있는지 미리 확인하지 마세요. 무고한 검사처럼 보이는 것은 씬 뒤에 있는 값비싼 경로 쿼리와 동일합니다. 어쨌든 새로운 경로를 요청하려는 계획이라면 해당 위치에 도달할 수 있어야 하며 경로를 직접 쿼리해야 합니다. 반환된 경로의 마지막 위치를 보고 해당 위치가 확인된 위치까지 "도달 가능한" 거리에 있는 경우 "이 위치에 도달할 수 있습니까?"라는 질문에 대답합니다. 질문. 이렇게 하면 동일한 NavigationAgent에 대해 프레임마다 두 개의 전체 경로 쿼리에 해당하는 작업을 수행하지 않아도 됩니다.

NavigationAgent의 총 수를 업데이트 그룹으로 나누거나 임의 타이머를 사용하여 모두 동일한 프레임에서 새 경로를 요청하지 않도록 합니다.

실제 경로 검색의 성능 문제

팁

다각형과 가장자리의 양을 줄여 지나치게 상세한 탐색 메시를 최적화합니다.

실제 경로 검색 비용은 게임 세계의 실제 크기가 아니라 내비게이션 메시 다각형 및 가장자리의 양과 직접적인 관련이 있습니다. 거대한 게임 세계가 넓은 영역을 포괄하는 소수의 다각형만으로 매우 최적화된 내비게이션 메시를 사용하는 경우 성능은 허용될 것입니다. 게임 세계가 각각 작은 다각형(예: TileMaps)을 포함하는 매우 작은 내비게이션 메시로 분할되면 길 찾기 성능이 저하됩니다.

일반적인 문제는 경로 쿼리에서 목표 위치에 도달할 수 없을 때 갑자기 성능이 저하되는 것입니다. 이러한 성능 저하는 "정상"이며 탐색 메시가 너무 크고 최적화되지 않아 검색할 다각형과 가장자리가 너무 많기 때문에 발생합니다. 목표 위치에 빠르게 도달할 수 있는 일반적인 경로 검색에서 경로 찾기는 위치에 도달하자마자 조기 종료를 수행하므로 한동안 이러한 최적화 부족을 숨길 수 있습니다. 목표 위치에 도달할 수 없는 경우 경로 찾기는 해당 위치에 절대 도달할 수 없는지 확인하기 위해 사용 가능한 다각형을 통해 훨씬 더 긴 검색을 수행해야 합니다.

내비게이션 지도 동기화 관련 성능 문제

팁

가능한 경우 가장자리 연결 대신 정점을 기준으로 내비게이션 메시 다각형을 병합합니다.

예를 들어 변경사항이 있는 경우 탐색 메시 또는 탐색 영역이 있는 경우 NavigationServer는 탐색 지도를 동기화해야 합니다. 내비게이션 메시의 복잡성에 따라 프레임 속도에 영향을 미칠 수 있는 상당한 시간이 걸릴 수 있습니다.

NavigationServer는 정점 또는 가장자리 연결을 기준으로 탐색 메시를 병합합니다. 정점별 병합은 서로 다른 두 가장자리의 두 정점이 동일한 지도 그리드 셀에 있을 때 발생합니다. 이는 다소 빠르고 저렴한 작업입니다. 가장자리 연결에 의한 병합은 아직 병합되지 않은 모든 가장자리에 대해 두 번째 패스에서 발생합니다. 모든 자유 가장자리는 비용이 많이 드는 거리와 각도에 따라 가능한 가장자리 연결이 있는지 확인됩니다.

따라서 가능한 한 적은 수의 다각형 가장자리를 갖는 일반적인 규칙과는 별도로, 가능한 한 많은 가장자리를 정점으로 미리 병합해야 하므로 더 비용이 많이 드는 가장자리 연결 계산을 위해 몇 개의 가장자리만 남습니다. 디버그 Navigation PerformanceMonitor를 사용하면 사용 가능한 다각형 및 가장자리 수와 병합되지 않거나 정점별로 병합되지 않은 다각형 및 가장자리 수에 대한 통계를 얻을 수 있습니다. 병합된 정점과 가장자리 연결 사이의 비율이 크게 벗어나면(정점은 상당히 높아야 함) 내비게이션 메시가 제대로 생성되거나 매우 비효율적으로 배치됩니다.