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...
성능
컬링
Godot는 뷰포트 외부에 있는 객체 렌더링을 방지하기 위해 뷰 프러스텀 컬링을 자동으로 수행합니다. 이는 작은 영역에서 진행되는 게임에는 적합하지만 더 큰 레벨에서는 빠르게 문제가 될 수 있습니다.
오클루전 컬링
예를 들어, 마을을 산책할 때 현재 거리에 있는 건물 몇 개와 하늘, 머리 위로 날아다니는 새 몇 마리만 볼 수 있습니다. 그러나 순진한 렌더러에 관한 한 여전히 마을 전체를 볼 수 있습니다. 그것은 단지 여러분 앞에 있는 건물을 렌더링하는 것이 아니라, 그 뒤에 있는 거리, 그 거리에 있는 사람들, 그 뒤에 있는 건물들을 렌더링할 것입니다. 눈에 보이는 것보다 10배 또는 100배 더 많이 렌더링하려고 시도하는 상황에 빠르게 직면하게 됩니다.
Z-버퍼는 일반적으로 GPU가 앞쪽에 있는 개체만 완전히 음영 처리하도록 허용하기 때문에 상황이 보이는 것만큼 나쁘지는 않습니다. 이것은 *깊이 프리패스*라고 불리며 Forward+ 또는 호환성 렌더링 방법을 사용할 때 Godot에서 기본적으로 활성화됩니다. 그러나 불필요한 개체로 인해 여전히 성능이 저하됩니다.
렌더링할 양을 잠재적으로 줄일 수 있는 한 가지 방법은 **폐색을 활용**하는 것입니다. Godot는 폐색기 노드를 사용하여 폐색 컬링에 대한 접근 방식을 제공합니다. 씬에서 오클루전 컬링을 설정하는 방법에 대한 지침은 :ref:`doc_occlusion_culling`를 참조하세요.
참고
어떤 경우에는 더 많은 폐색 기회를 추가하기 위해 레벨 디자인을 조정해야 할 수도 있습니다. 예를 들어 플레이어가 너무 먼 곳을 보는 것을 방지하기 위해 더 많은 벽을 추가해야 할 수 있습니다. 이렇게 하면 오클루전 컬링 기회가 손실되어 성능이 저하됩니다.
투명한 물체
Godot는 성능을 향상시키기 위해 Material 및 :ref:`셰이더 <class_Shader>`별로 개체를 정렬합니다. 그러나 투명한 물체에는 이 작업을 수행할 수 없습니다. 투명한 물체는 뒤에서 앞으로 렌더링되어 작업 뒤에 있는 것과 혼합됩니다. 따라서 투명 물체를 가능한 한 적게 사용하십시오. 개체에 투명도가 있는 작은 섹션이 있는 경우 해당 섹션을 자체 재질을 사용하여 별도의 표면으로 만들어 보십시오.
자세한 정보는 GPU 최적화 문서를 참조하세요.
세부 수준(LOD)
어떤 상황에서는, 특히 멀리 떨어져 있는 경우에는 **복잡한 형상을 간단한 버전으로 대체**하는 것이 좋습니다. 최종 사용자는 아마도 큰 차이를 느끼지 못할 것입니다. 멀리 있는 많은 나무를 살펴보세요. 다양한 거리에서 모델을 교체하기 위한 몇 가지 전략이 있습니다. 더 낮은 폴리 모델을 사용하거나 투명도를 사용하여 더 복잡한 형상을 시뮬레이션할 수 있습니다.
Godot 4는 세부 수준을 제어하는 여러 가지 방법을 제공합니다:
:ref:`doc_mesh_lod`를 사용하여 메시 가져오기에 대한 자동 접근 방식입니다.
:ref:`doc_visibility_ranges`를 사용하여 3D 노드에 구성된 수동 접근 방식입니다.
Decals 및 :ref:`lights <doc_lights_and_shadows>`는 각각의 거리 페이드 속성을 사용하여 세부 수준의 이점을 누릴 수도 있습니다.
이러한 접근 방식은 독립적으로 사용할 수도 있지만 함께 사용할 때 가장 효과적입니다. 예를 들어 가시 범위를 설정하여 플레이어로부터 너무 멀리 떨어져 있어 알아차릴 수 없는 입자 효과를 숨길 수 있습니다. 동시에 메시 LOD를 사용하여 파티클 효과의 메시를 원거리에서 덜 세밀하게 렌더링할 수 있습니다.
가시성 범위는 원거리 형상에 대한 *임포스터*를 설정하는 좋은 방법이기도 합니다(아래 참조).
광고판과 사기꾼
LOD를 처리하기 위해 투명도를 사용하는 가장 간단한 버전은 빌보드입니다. 예를 들어 단일 투명 쿼드를 사용하여 멀리 있는 나무를 표현할 수 있습니다. 물론, 서로 앞에 많은 나무가 있지 않는 한 렌더링하는 데 매우 저렴할 수 있습니다. 이 경우 투명도가 채우기 속도를 잠식하기 시작할 수 있습니다(채우기 속도에 대한 자세한 내용은 최적화(Optimization) 참조).
대안은 하나의 나무뿐만 아니라 여러 나무를 그룹으로 함께 렌더링하는 것입니다. 이는 게임에서 영역을 볼 수 있지만 물리적으로 접근할 수 없는 경우 특히 효과적일 수 있습니다.
다양한 각도에서 객체의 뷰를 미리 렌더링하여 임포스터를 만들 수 있습니다. 또는 한 단계 더 나아가 임포스터로 사용할 개체의 뷰를 텍스처로 주기적으로 다시 렌더링할 수도 있습니다. 멀리서 볼 때 화각이 크게 바뀌려면 뷰어를 상당한 거리로 이동해야 합니다. 작업하기가 복잡할 수 있지만 만들고 있는 프로젝트 유형에 따라 그만한 가치가 있을 수 있습니다.
자동 인스턴싱 사용
이 기능은 모바일이나 호환성이 아닌 Forward+ 렌더러에서만 구현됩니다.
씬에 동일한 객체가 많이 있는 경우 자동 인스턴스화를 사용하여 그리기 호출 수를 줄일 수 있습니다. 이는 동일한 메시와 재질을 사용하는 MeshInstance3D 노드의 경우 자동으로 발생하므로 수동 설정이 필요하지 않습니다.
자동 인스턴싱이 효과적이려면 재질이 불투명하거나 알파 테스트(알파 가위 또는 알파 해시)되어야 합니다. 알파 블렌드 또는 깊이 프리패스 머티리얼은 이런 식으로 인스턴스화되지 않습니다. 대신 아래 설명된 대로 MultiMesh를 사용해야 합니다.
수동 인스턴싱 사용(MultiMesh)
여러 개의 동일한 개체를 같은 장소나 근처에 그려야 하는 경우 대신 :ref:`MultiMesh <class_MultiMesh>`을 사용해 보십시오. MultiMesh를 사용하면 매우 적은 성능 비용으로 수천 개의 객체를 그릴 수 있으므로 무리, 풀, 입자 및 수천 개의 동일한 객체가 있는 모든 것에 이상적입니다.
MultiMesh 사용 문서도 참조하세요.
조명 굽기
조명 개체는 가장 비용이 많이 드는 렌더링 작업 중 하나입니다. 실시간 조명, 그림자(특히 다중 조명) 및 :ref:`전역 조명 <doc_introduction_to_global_illumination>`은 특히 비용이 많이 듭니다. 저전력 모바일 장치가 처리하기에는 너무 많은 것일 수 있습니다.
**베이킹된 조명 사용을 고려**(특히 모바일의 경우) 이것은 환상적으로 보일 수 있지만 역동적이지 않다는 단점이 있습니다. 때때로 이것은 가치 있는 절충안입니다.
구운 라이트맵 사용에 대한 지침은 :ref:`doc_using_lightmap_gi`를 참조하세요. 최상의 성능을 위해서는 조명의 베이크 모드를 기본 **동적**이 아닌 **정적**으로 설정해야 합니다. 이렇게 하면 조명이 베이크된 메시에서 실시간 조명을 건너뛸 수 있기 때문입니다.
정적 베이킹 모드를 사용하는 조명의 단점은 구운 조명이 있는 메시에 그림자를 투사할 수 없다는 것입니다. 이렇게 하면 실외 환경과 동적 개체가 포함된 장면이 평면적으로 보일 수 있습니다. 성능과 품질 사이의 균형을 잘 맞추려면 DirectionalLight3D 노드에 대해 **동적**을 유지하고 대부분의(전부는 아니지만) 옴니 및 스포트라이트에 **정적**을 사용하는 것입니다.
애니메이션 및 스키닝
일부 플랫폼에서는 스키닝 및 모핑과 같은 애니메이션 및 정점 애니메이션이 매우 비쌀 수 있습니다. 애니메이션 모델의 경우 폴리카운트 수를 상당히 낮추거나 특정 시간에 화면에 표시되는 폴리곤 수를 제한해야 할 수도 있습니다. 멀리 있거나 가려진 메시의 애니메이션 속도를 줄이거나, 플레이어가 애니메이션이 중지되는 것을 알아차리지 못할 경우 애니메이션을 완전히 일시 중지할 수도 있습니다.
VisibleOnScreenEnabler3D 및 VisibleOnScreenNotifier3D 노드는 이러한 목적에 유용할 수 있습니다.
커다란 세계
큰 세계를 만드는 경우 작은 게임에서 익숙할 수 있는 것과는 다른 고려 사항이 있습니다.
전 세계를 이동할 때 필요에 따라 로드할 수 있는 타일로 큰 세계를 구축해야 할 수도 있습니다. 이렇게 하면 메모리 사용이 통제되지 않는 것을 방지하고 필요한 처리를 로컬 영역으로 제한할 수도 있습니다.
큰 세계에서는 부동 소수점 오류로 인해 렌더링 및 물리적 결함이 있을 수도 있습니다. 이 문제는 doc_large_world_coordinates`를 사용하여 해결할 수 있습니다. 큰 세계 좌표를 사용할 수 없는 경우 플레이어를 중심으로 세계 방향을 지정하거나(다른 방향이 아닌) 원점을 주기적으로 이동하여 사물의 중심을 ``Vector3(0, 0, 0)` 중심으로 유지하는 등의 기술을 사용할 수 있습니다.