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 4의 내부 렌더러 디자인에 대한 높은 수준의 개요입니다. 이전 Godot 버전에는 적용되지 않습니다.

이 페이지의 목표는 `Godot의 디자인 철학 <https://contributing.godotengine.org/en/latest/engine/guidelines/best_practices.html>`__에 가장 잘 맞는 디자인 결정을 문서화하는 동시에 새로운 렌더링 기여자에게 출발점을 제공하는 것입니다.

내부 렌더링에 대한 질문이 여기에 답변되지 않은 경우 Godot 기여자 채팅 <https://chat.godotengine.org/channel/rendering>`__의 ``#rendering` 채널에 자유롭게 문의하세요.

참고

이 페이지의 개념을 이해하는 데 어려움이 있는 경우 `LearnOpenGL <https://learnopengl.com/>`__과 같은 OpenGL 튜토리얼을 진행하는 것이 좋습니다.

최신 하위 수준 API(Vulkan/Direct3D 12/Metal)를 효과적으로 사용하려면 상위 수준 API(OpenGL/Direct3D 11)에 대한 중간 지식이 필요합니다. 다행히도 기여자가 하위 수준 API를 직접 사용하여 작업할 필요는 거의 없습니다. Godot의 렌더러는 Vulkan/Direct3D 12/Metal에 대한 추상화인 OpenGL 및 RenderingDevice를 기반으로 완전히 구축되었습니다.

렌더링 메서드

Forward+

이것은 조명에 대한 클러스터형 접근 방식을 사용하는 포워드 렌더러입니다.

클러스터링된 조명은 컴퓨팅 셰이더를 사용하여 조명을 3D 절두체 정렬 그리드로 그룹화합니다. 그런 다음 렌더링 시 픽셀은 자신이 속한 그리드 셀에 어떤 조명이 영향을 미치는지 조회하고 해당 픽셀에 영향을 미칠 수 있는 조명에 대해서만 조명 계산을 실행할 수 있습니다.

이 접근 방식은 데스크톱 하드웨어에서 렌더링 성능을 크게 향상시킬 수 있지만 모바일에서는 효율성이 크게 떨어집니다.

모바일

이는 조명에 대한 전통적인 단일 패스 접근 방식을 사용하는 포워드 렌더러입니다. 내부적으로는 **Forward Mobile**이라고 합니다.

모바일 플랫폼용이지만 데스크톱 플랫폼에서도 실행할 수 있습니다. 이 렌더링 방법은 모바일 GPU에서 잘 수행되도록 최적화되었습니다. 모바일 GPU는 배터리 사용량, 열, 데이터 읽기 및 쓰기의 전체 대역폭 제한에 대한 고유한 제약으로 인해 데스크톱 GPU와 비교할 때 아키텍처가 매우 다릅니다. Compute 셰이더도 지원이 매우 제한되어 있거나 전혀 지원되지 않습니다. 결과적으로 모바일 렌더러는 래스터 기반 셰이더(조각/정점)만 사용합니다.

데스크톱 GPU와 달리 모바일 GPU는 *타일 기반 렌더링*을 수행합니다. 전체 이미지를 단일 단위로 렌더링하는 대신 이미지는 모바일 GPU의 더 빠른 내부 메모리에 맞는 더 작은 타일로 나뉩니다. 각 타일은 렌더링된 다음 대상 텍스처에 기록됩니다. 이 모든 작업은 그래픽 드라이버에서 자동으로 발생합니다.

문제는 이로 인해 기존 접근 방식에 병목 현상이 발생한다는 것입니다. 데스크톱 렌더링의 경우 모든 불투명 형상을 렌더링한 다음 배경, 투명 형상, 후처리를 처리합니다. 각 패스에서는 현재 결과를 타일 메모리로 읽고 해당 작업을 수행한 다음 다시 작성해야 합니다. 그런 다음 다음 패스로 이동하기 전에 모든 타일이 완료될 때까지 기다립니다.

The first important change in the mobile renderer is that the mobile renderer does not use the RGBA16F texture formats that the desktop (Forward+) renderer does. Instead, it uses an R10G10B10A2 UNORM texture format unless the rendering/viewport/hdr_2d project setting is enabled. This halves the bandwidth required and has further improvements, as mobile hardware often further optimizes for 32-bit formats. The tradeoff is that by default, the mobile renderer has limited HDR capabilities due to the reduced precision and maximum values in the color data.

When the rendering/viewport/hdr_2d project setting is enabled, the mobile renderer uses the same RGBA16F renderers as Forward+. This allows for full HDR support, but also increases bandwidth usage and can reduce performance on mobile GPUs or integrated graphics.

두 번째 중요한 변경 사항은 가능할 때마다 하위 패스를 사용하는 것입니다. 하위 패스를 사용하면 각 렌더링 패스 사이의 타일을 읽고 쓸 때 발생하는 오버헤드를 절약하면서 타일별로 엔드투엔드 렌더링 단계를 수행할 수 있습니다. 단일 타일 내에서 작업하도록 제한되어 있기 때문에 하위 패스를 사용하는 기능은 인접한 픽셀을 읽을 수 없기 때문에 제한됩니다.

서브패스의 이러한 제한으로 인해 글로우 및 피사계 심도와 같은 기능을 효율적으로 구현할 수 없습니다. 마찬가지로 화면 텍스처나 깊이 텍스처를 읽어야 하는 경우 하위 패스 사용 기능을 제한하는 렌더링 결과를 완전히 작성해야 합니다. 이러한 기능이 활성화되면 하위 패스와 일반 패스가 혼합되어 사용되며 이러한 기능은 눈에 띄는 성능 저하를 초래합니다.

데스크탑 플랫폼에서는 하위 패스를 사용해도 성능에 아무런 영향을 미치지 않습니다. 그러나 이 렌더링 방법은 복잡성이 낮고 대역폭 사용량이 낮기 때문에 단순한 장면에서 Forward+보다 더 나은 성능을 발휘할 수 있습니다. 이는 저가형 GPU, 통합 그래픽 또는 VR 애플리케이션에서 특히 두드러집니다.

이 렌더링 방법은 저사양에 중점을 두고 SDFGI 및 :ref:`doc_volumetric_fog`와 같은 고급 렌더링 기능을 제공하지 않습니다. 여러 후처리 효과도 사용할 수 없습니다.

호환성

참고

이는 OpenGL 드라이버를 사용할 때 사용할 수 있는 유일한 렌더링 방법입니다. Vulkan, Direct3D 12 또는 Metal을 사용하는 경우에는 이 렌더링 방법을 사용할 수 없습니다.

이는 전통적인(비클러스터형) 포워드 렌더러입니다. 내부적으로는 **GL 호환성**이라고 합니다. Vulkan을 지원하지 않는 구형 GPU를 위한 것이지만 최신 하드웨어에서는 여전히 매우 효율적으로 작동합니다. 특히, 구형 및 저가형 모바일 장치에 최적화되어 있습니다. 그러나 많은 최적화가 이어져 구형 및 저가형 데스크탑에도 좋은 선택이 됩니다.

모바일 렌더러와 마찬가지로 호환성 렌더러는 3D 렌더링을 위해 R10G10B10A2 UNORM 텍스처를 사용합니다. 모바일 렌더러와 달리 색상은 톤 매핑되고 sRGB 형식으로 저장되므로 HDR이 지원되지 않습니다. 이렇게 하면 톤 매핑 패스가 필요하지 않으며 실질적인 밴딩 없이 낮은 비트 텍스처를 사용할 수 있습니다.

호환성 렌더러는 조명이 있는 객체를 그리는 데 기존의 순방향 단일 패스 접근 방식을 사용하지만, 그림자가 있는 조명을 그리는 데는 다중 패스 접근 방식을 사용합니다. 특히 첫 번째 패스에서는 그림자 없이 여러 개의 조명을 그릴 수 있고 그림자가 있는 최대 하나의 DirectionalLight3D를 그릴 수 있습니다. 각 후속 패스에서는 최대 하나의 OmniLight3D, 하나의 SpotLight3D 및 그림자가 있는 DirectionalLight3D를 그릴 수 있습니다. 그림자가 있는 조명은 그림자가 없는 조명과 다르게 씬에 영향을 미칩니다. 조명은 선형 공간 대신 sRGB 공간에서 혼합되기 때문입니다. 이러한 조명 차이는 씬의 모양에 영향을 미치며 호환성 렌더러용 장면을 디자인할 때 이를 염두에 두어야 합니다.

저가형에 초점을 맞춘 이 렌더링 방법은 고급 렌더링 기능을 제공하지 않습니다(모바일에 비해 훨씬 낮음). 대부분의 후처리 효과는 사용할 수 없습니다.

지연 렌더링을 사용하지 않는 이유는 무엇입니까?

포워드 렌더링은 일반적으로 성능과 유연성 사이에서 더 나은 균형을 제공하며, 특히 조명에 대한 클러스터링 접근 방식이 사용되는 경우 더욱 그렇습니다. 지연 렌더링은 어떤 경우에는 더 빠를 수 있지만 유연성이 떨어지며 MSAA를 사용하려면 해킹을 사용해야 합니다. 덜 현실적인 아트 스타일을 가진 게임은 MSAA로부터 많은 이점을 얻을 수 있기 때문에 우리는 Godot 4(예: Godot 3)에 대해 포워드 렌더링을 선택했습니다.

즉, 포워드 렌더러의 일부는 가능한 경우 일부 최적화를 허용하기 위해 지연된 접근 방식으로 수행됩니다. 이는 특히 VoxelGI 및 SDFGI에 적용됩니다.

클러스터형 지연 렌더러는 향후 개발될 수 있습니다. 이 렌더러는 유연성보다 성능이 선호되는 상황에서 사용할 수 있습니다.

렌더링 드라이버

Godot 4는 다음의 그래픽 API를 지원합니다:

불칸

이것은 Godot 4의 주요 드라이버이며, 대부분의 개발 초점은 이 드라이버에 맞춰져 있습니다.

Vulkan 1.0은 기본으로 필요하며 선택적인 Vulkan 1.1 및 1.2 기능이 사용 가능한 경우 사용됩니다. `volk <https://github.com/zeux/volk>`__은 Vulkan 로더로 사용되고, `Vulkan Memory Allocator <https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator>`__은 메모리 관리에 사용됩니다.

Vulkan 드라이버를 사용할 경우 Forward+ 및 Mobile :ref:`doc_internal_rendering_architecture_methods`가 모두 지원됩니다.

Vulkan 컨텍스트 생성:

Direct3D 12 컨텍스트 생성:

방향

Vulkan과 마찬가지로 Direct3D 12 드라이버는 최신 플랫폼만을 대상으로 합니다. Windows와 Xbox를 모두 대상으로 하도록 설계되었습니다(반면 Vulkan은 Xbox에서 직접 사용할 수 없음).

Forward+와 Mobile :ref:`doc_internal_rendering_architecture_methods`는 모두 Direct3D 12와 함께 사용할 수 있습니다.

:ref:`doc_internal_rendering_architecture_core_shaders`는 Vulkan 렌더러와 공유됩니다. 셰이더는 Mesa NIR(`추가 정보 <https://godotengine.org/article/d3d12-adventures-in-shaderland/>`__)을 사용하여 :abbr:`SPIR-V(Standard Portable Intermediate Representation)`에서 :abbr:`DXIL(DirectX Intermediate Language)`로 변환됩니다.

이 드라이버는 아직 실험적이며 Godot 4.3 이상에서만 사용할 수 있습니다. Direct3D 12를 사용하면 창 최적화 및 자동 HDR과 같은 Windows 11의 Direct3D 독점 기능을 지원할 수 있지만 Vulkan은 여전히 대부분의 프로젝트에 권장됩니다. 자세한 내용은 `Direct3D 12 지원을 도입한 풀 요청 <https://github.com/godotengine/godot/pull/70315>`__를 참조하세요.

금속성

Godot는 모든 Apple Silicon 하드웨어(macOS ARM)에서 작동하는 기본 Metal 드라이버를 제공합니다. MoltenVK 변환 레이어를 사용하는 것과 비교하면 특히 CPU 바인딩 시나리오에서 훨씬 더 빠릅니다.

Forward+와 Mobile 렌더링 메서드 모두 Metal과 함께 사용할 수 있습니다.

:ref:`doc_internal_rendering_architecture_core_shaders`는 Vulkan 렌더러와 공유됩니다. 셰이더는 SPIRV-Cross를 사용하여 GLSL에서 :abbr:`MSL(Metal Shading Language)`로 변환됩니다.

Godot는 `MoltenVK <https://github.com/KhronosGroup/MoltenVK>`__를 통해 Metal 렌더링도 지원합니다. 이는 기본 Metal 지원을 사용할 수 없을 때(예: x86 macOS) 대체 수단으로 사용됩니다.

Since Godot 4.7, Metal 4 is now used when supported. All Apple Silicon hardware supports Metal 4, but it must be running macOS 26 or later, or iOS 26 or later. Metal 3 is automatically used as a fallback on older macOS and iOS versions. See the pull request that introduced Metal 4 support for more information.

OpenGL

이 드라이버는 OpenGL ES 3.0을 사용하며 Vulkan을 지원하지 않는 레거시 및 저가형 장치를 대상으로 합니다. OpenGL 3.3 Core Profile은 데스크탑 플랫폼에서 이 드라이버를 실행하는 데 사용됩니다. 데스크탑의 대부분의 그래픽 드라이버는 OpenGL ES를 지원하지 않기 때문입니다. WebGL 2.0은 웹 내보내기에 사용됩니다.

It is possible to use OpenGL ES 3.0 directly on desktop platforms by passing the --rendering-driver opengl3_es command line argument, although this will only work on graphics drivers that feature native OpenGL ES support (such as Mesa).

OpenGL 드라이버에서는 호환성 렌더링 방법만 사용할 수 있습니다.

:ref:`doc_internal_rendering_architecture_core_shaders`는 Vulkan 렌더러와 완전히 다릅니다.

이 드라이버는 무엇보다 저사양 장치를 대상으로 하기 때문에 많은 고급 기능이 지원되지 않습니다.

렌더링 드라이버/메서드의 요약

현재 가능한 렌더링 API + 렌더링 메서드 조합은 다음과 같습니다:

  • Vulkan + Forward+ (선택적으로 macOS 및 iOS에서 MoltenVK를 통해)

  • Vulkan + 모바일 (선택적으로 macOS 및 iOS에서 MoltenVK를 통해)

  • Direct3D 12 + Forward+

  • Direct3D 12 + 모바일

  • Metal + Forward+

  • Metal + 모바일

  • OpenGL + 호환성 (선택적으로 Windows 및 macOS에서 ANGLE을 통해)

각 조합에는 고유한 제한 사항과 성능 특성이 있습니다. 풀 요청을 열기 전에 가능하다면 모든 렌더링 방법에 대한 변경 사항을 테스트하십시오.

중급 추상화(Mid level abstraction)

참고

OpenGL 드라이버는 RenderingDevice 추상화를 사용하지 않습니다.

최신 저수준 그래픽 API의 복잡성을 더 쉽게 관리하기 위해 Godot는 RenderingDevice라는 자체 추상화를 사용합니다.

이는 최신 렌더링 방법을 위한 코드를 작성할 때 실제로 Vulkan, Direct3D 12 또는 Metal API를 직접 사용하지 않는다는 것을 의미합니다. 이는 OpenGL과 같은 API보다 여전히 낮은 수준이지만 RenderingDevice가 많은 API 관련 문제를 추상화하므로 렌더러 작업이 더 쉬워집니다. RenderingDevice는 WebGPU와 유사한 수준의 추상화를 제공합니다.

구현

구현

구현

핵심 렌더링 클래스 아키텍처

이 다이어그램은 RenderingDevice 추상화를 포함하여 Godot의 렌더링 클래스 구조를 나타냅니다:

../../_images/rendering_architecture_diagram.webp

https://github.com/godotengine/godot-demo-projects

맞춤 메시

GLSL에서 영감을 얻은 셰이더 언어 <doc_shading_language>를 사용한 텍스트 기반 셰이더.

이러한 핵심 셰이더는 편집기에 내장되어 있으며 컴파일 타임에 템플릿 바이너리를 내보냅니다. 해당 GLSL 셰이더에 대한 변경 사항을 보려면 편집기를 다시 컴파일하거나 템플릿 바이너리를 내보내야 합니다.

높이 매핑, 굴절 및 근접 페이드와 같은 일부 머티리얼 기능은 코어 셰이더의 일부가 아니며 대신 Godot 셰이더 언어(GLSL 아님)를 사용하여 기본 BaseMaterial3D에서 수행됩니다. 이는 재료에서 활성화된 기능에 따라 필요한 셰이더 코드를 절차적으로 생성하여 수행됩니다.

규칙에 따라 이름에 ``_inc``가 포함된 셰이더 파일은 더 나은 코드 재사용을 위해 다른 GLSL 파일에 포함됩니다. 이를 달성하기 위해 표준 GLSL 전처리가 사용됩니다.

경고

핵심 재료 셰이더는 기본 BaseMaterial3D 및 사용자 정의 셰이더와 함께 씬의 모든 재료에 사용됩니다. 결과적으로 이러한 셰이더는 성능 문제를 방지하고 셰이더 컴파일이 너무 느려지지 않도록 가능한 한 단순하게 유지되어야 합니다.

셰이더에서 if 분기를 사용하는 경우 셰이더에서 VGPR 사용량이 증가하므로 성능이 저하될 수 있습니다. 이는 주어진 프레임에서 모든 픽셀이 true 또는 ``false``로 평가되는 경우에도 발생합니다.

#if 전처리기 분기를 사용하는 경우 필요한 셰이더 버전 수가 씬에서 늘어납니다. 최악의 경우 단일 부울 ``#define``를 추가하면 해당 씬에서 컴파일해야 할 수 있는 셰이더 버전 수가 두 배 늘어날 수 있습니다. 어떤 경우에는 Vulkan 특수화 상수를 더 빠른(그러나 더 제한적인) 대안으로 사용할 수 있습니다.

이는 핵심 셰이더와 BaseMaterial3D 모두에 Godot의 새로운 내장 머티리얼 기능을 추가하는 데 높은 장벽이 있다는 것을 의미합니다. BaseMaterial3D는 기능이 활성화된 경우 셰이더 코드만 포함하기 위해 동적 코드 생성을 사용할 수 있지만, 프로젝트에서 이러한 기능을 사용할 경우 여전히 더 많은 셰이더 버전을 생성해야 합니다. 이로 인해 복잡한 3D 장면에서 셰이더 편집 끊김 현상이 더 눈에 띄게 될 수 있습니다.

자세한 내용은 셰이더 순열 문제 및 GPU에서 분기 블로그 게시물을 참조하세요.

핵심 GLSL 소재 셰이더:

재료 셰이더 생성:

Forward+ 및 모바일 렌더링 방법을 위한 기타 GLSL 셰이더:

호환성 렌더링 방법을 위한 기타 GLSL 셰이더:

2D 및 3D 렌더링 분리

참고

다음은 Compatibility가 아닌 Forward+ 및 Mobile 렌더링 방법에만 적용됩니다. 여러 뷰포트를 사용하면 호환성 렌더러를 사용할 때 이를 에뮬레이트하거나 2D 해상도 크기 조정을 수행할 수 있습니다.

Godot의 2D 렌더링은 LDR sRGB-space에서 수행되는 반면 3D 렌더링은 HDR 선형 공간을 사용하므로 2D와 3D는 별도의 버퍼로 렌더링됩니다.

2D 렌더링에 사용되는 색상 형식은 RGB8입니다(뷰포트의 투명 속성이 활성화된 경우 RGBA8). 3D 렌더링은 24비트 부호 없는 정규화된 정수 깊이 버퍼를 사용하거나, 24비트 깊이 버퍼가 하드웨어에서 지원되지 않는 경우 32비트 부호 있는 부동 소수점을 사용합니다. 2D 렌더링에서는 깊이 버퍼를 사용하지 않습니다.

3D 해상도 스케일링은 이중선형 스케일링을 사용하는지 FSR 1.0 스케일링을 사용하는지에 따라 다르게 수행됩니다. 이중선형 스케일링을 사용하는 경우 특별한 업스케일링 셰이더가 실행되지 않습니다. 대신, 뷰포트의 텍스처가 확장되어 선형 샘플러로 표시됩니다(하드웨어에서 필터링이 직접 발생함). 이를 통해 이중선형 3D 스케일링 성능을 극대화할 수 있습니다.

RenderSceneBuffersRD의 configure() 함수는 해상도나 배율이 변경되면 2D/3D 버퍼를 재할당합니다.

동적 해상도 스케일링은 아직 지원되지 않지만 향후 Godot 릴리스에서 지원될 예정입니다.

2D 및 3D 렌더링 버퍼 구성 C++ 코드:

FSR 1.0:

애니메이션 설정

2D 조명 렌더링은 단일 패스로 수행되어 많은 양의 조명으로 더 나은 성능을 제공합니다.

모든 렌더링 방법에는 성능 향상을 위한 2D 일괄 처리 기능이 있으며, 이는 화면에 텍스트가 많을 때 특히 두드러집니다.

MSAA는 2D에서 활성화되어 "자동" 선 및 다각형 앤티앨리어싱을 제공할 수 있지만 FXAA는 2D 렌더링이 시작되기 전에 계산되므로 2D 렌더링에 영향을 주지 않습니다. Line2D 노드 또는 일부 CanvasItem draw_*() 방법과 같은 Godot의 2D 그리기 방법은 MSAA가 필요하지 않은 삼각형 스트립 및 정점 색상을 기반으로 하는 자체 앤티앨리어싱 방법을 제공합니다.

뷰포트에서 LightOccluder2D 노드를 나타내는 2D 부호 있는 거리 필드는 사용자 셰이더가 요청하면 자동으로 생성됩니다. 이는 2D 전역 조명과 같은 사용자 정의 셰이더의 다양한 효과에 사용할 수 있습니다. 2D에서 입자 충돌을 계산하는 데에도 사용됩니다.

2D SDF 생성 GLSL 셰이더:

애니메이션 설정

Reverse Z

All of Godot's renderers use reverse Z. This means that the depth buffer is inverted, with 1.0 representing the near plane and 0.0 representing the far plane. This allows for better precision, especially at long distances.

애니메이션 설정

Forward+ 렌더러에서 Vulkan 인스턴스화는 성능을 위해 동일한 불투명 또는 알파 테스트된 객체의 렌더링을 그룹화하는 데 사용됩니다. (알파 블렌딩된 객체는 인스턴스화되지 않습니다.) 이는 정적 메쉬 병합만큼 빠르지는 않지만 여전히 인스턴스를 개별적으로 컬링할 수 있습니다.

조명, 데칼 및 반사 프로브 렌더링

참고

데칼 렌더링은 현재 호환성 렌더러에서 사용할 수 없습니다.

Forward+ 렌더러는 클러스터 조명을 사용합니다. 이렇게 하면 원하는 만큼 많은 조명을 사용할 수 있습니다. 성능은 주로 화면 범위에 따라 달라집니다. 그림자 없는 조명은 화면에서 많은 공간을 차지하지 않으면 거의 무료일 수 있습니다.

모든 렌더링 방법은 동시에 최대 8개의 방향성 조명 렌더링을 지원합니다(단, 둘 이상의 조명에 그림자가 활성화된 경우 그림자 품질이 낮음).

모바일 렌더러는 각 메시 *리소스*에 영향을 미치는 OmniLights 8개 + SpotLights 8개로 제한되는 단일 패스 조명 접근 방식을 사용합니다(카메라 뷰에서는 OmniLights 256개 + SpotLights 256개로 제한됨). 이러한 제한은 하드코딩되어 있으며 프로젝트 설정에서 조정할 수 없습니다.

호환성 렌더러는 하이브리드 단일 패스 + 다중 패스 조명 접근 방식을 사용합니다. 그림자가 없는 조명은 단일 패스로 렌더링됩니다. 그림자가 있는 조명은 여러 패스로 렌더링됩니다. 이는 모바일 장치의 성능상의 이유로 필요합니다. 결과적으로 그림자를 드리우는 조명이 많으면 성능이 제대로 확장되지 않습니다. 한 번에 카메라 절두체에 그림자가 있는 조명 몇 개만 두고 해당 조명을 분산시켜 각 객체가 한 번에 1~2개의 그림자 조명에만 닿도록 하는 것이 좋습니다. 한 번에 표시되는 최대 조명 수는 프로젝트 설정에서 조정할 수 있습니다.

세 가지 방법 모두 그림자가 없는 조명은 그림자가 있는 조명보다 훨씬 저렴합니다. 성능을 향상시키기 위해 조명은 조명이 수정되거나 해당 반경 내의 객체가 수정될 때만 업데이트됩니다. Godot는 현재 정적 그림자 렌더링과 동적 그림자 렌더링을 분리하지 않지만 이는 향후 릴리스에서 계획되어 있습니다.

클러스터링은 Forward+ 렌더러에서 반사 프로브와 데칼 렌더링에도 사용됩니다.

Area lights make use of the Linearly Transformed Cosines technique.

그림자 매핑

Forward+ 및 Mobile 방법 모두 :abbr:`PCF(Percentage Closer Filtering)`를 사용하여 그림자 맵을 필터링하고 부드러운 반그림자를 만듭니다. 고정된 PCF 패턴을 사용하는 대신 샘플 수를 변경하고 품질을 원활하게 변경할 수 있는 보겔 디스크 패턴을 사용합니다.

Godot는 또한 보다 사실적인 그림자 반그림자 렌더링을 위해 백분율 근접 소프트 그림자(PCSS)를 지원합니다. PCSS 그림자는 모바일 렌더러에서 사용하기에는 너무 까다롭기 때문에 Forward+ 렌더러로 제한됩니다. PCSS는 또한 vogel-disk 모양의 커널을 사용합니다.

또한 두 가지 섀도우 매핑 기술 모두 픽셀 단위로 커널을 회전하여 언더샘플링 아티팩트를 완화하는 데 도움이 됩니다.

호환성 렌더러는 DirectionalLight3D, OmniLight3D 및 SpotLight3D 조명에 대한 그림자 매핑을 지원합니다.

여러 인스턴스

참고

Forward+ 렌더러에서만 사용할 수 있으며 모바일 또는 호환성 렌더러에서는 사용할 수 없습니다.

Godot는 `Spartan Engine <https://github.com/PanosK92/SpartanEngine>`__의 이전 TAA 구현을 기반으로 하는 사용자 정의 TAA 구현을 사용합니다.

시간적 안티앨리어싱이 작동하려면 모션 벡터가 필요합니다. 모션 벡터가 올바르게 생성되지 않으면 카메라나 객체가 움직일 때 고스팅이 발생합니다.

모션 벡터는 주 자료 셰이더의 GPU에서 생성됩니다. 이는 현재 렌더링된 프레임에 대한 정점 셰이더 외에도 이전에 렌더링된 프레임(이전 카메라 변환 포함)에 해당하는 정점 셰이더를 실행한 다음 이들 간의 차이를 색상 버퍼에 저장하여 수행됩니다.

또는 FSR 2.2를 자체 임시 안티앨리어싱 알고리즘을 제공하는 업스케일링 솔루션으로 사용할 수도 있습니다. FSR 2.2는 AMD의 참조 코드를 직접 사용하는 대신 RenderingDevice 추상화 위에 구현됩니다.

TAA 해결:

FSR 2.2:

벡터 내장 타입

참고

VoxelGI 및 SDFGI는 Forward+ 렌더러에서만 사용할 수 있으며 모바일 또는 호환성 렌더러에서는 사용할 수 없습니다.

LightmapGI *베이킹*은 Forward+ 및 모바일 렌더러에서만 사용할 수 있으며 편집기 내에서만 수행할 수 있습니다(내보낸 프로젝트에서는 수행할 수 없음). LightmapGI *렌더링*은 호환성 렌더러에서 지원됩니다.

Godot는 복셀 기반 GI(VoxelGI), 부호 있는 거리 필드 GI(SDFGI) 및 라이트맵 베이킹 및 렌더링(LightmapGI)을 지원합니다. 원하는 경우 이러한 기술을 동시에 사용할 수 있습니다.

라이트맵 베이킹은 Vulkan 컴퓨팅 셰이더를 사용하여 GPU에서 수행됩니다. GPU 기반 라이트매퍼는 Lightmapper 클래스에서 상속되는 LightmapperRD 클래스에서 구현됩니다. 이를 통해 추가 라이트매퍼 구현이 가능해지며 Godot 3.x에 있는 CPU 기반 라이트매퍼의 향후 포트를 위한 길을 열어줍니다. 이렇게 하면 호환성 렌더러를 사용하는 동안 라이트맵을 베이킹할 수 있습니다.

핵심 GI C++ 코드:

코어 GI GLSL 셰이더:

라이트매퍼 C++ 코드:

라이트매퍼 GLSL 셰이더:

피사계 심도

참고

Forward+ 및 모바일 렌더러에서만 사용할 수 있으며 호환성 렌더러에서는 사용할 수 없습니다.

Forward+ 및 모바일 렌더러는 DOF 렌더링에 대해 서로 다른 접근 방식을 사용하여 서로 다른 시각적 결과를 제공합니다. 이는 대상 하드웨어의 성능 특성과 가장 잘 일치하도록 수행됩니다. Forward+에서는 DOF가 계산 셰이더를 사용하여 수행됩니다. 모바일에서는 DOF가 조각 셰이더(래스터)를 사용하여 수행됩니다.

상자, 육각형 및 원형 보케 모양을 사용할 수 있습니다(가장 빠른 것부터 가장 느린 것까지). 선택적으로 피사계 심도를 모든 프레임에 지터링하여 시간적 안티앨리어싱이 활성화된 경우 모양을 개선할 수 있습니다.

피사계 심도 C++ 코드:

피사계 심도 GLSL 셰이더(계산 - Forward+에 사용됨):

피사계 심도 GLSL 셰이더(래스터 - 모바일에 사용됨):

화면 공간 효과(SSAO, SSIL, SSR, SSS)

참고

Forward+ 렌더러에서만 사용할 수 있으며 모바일 또는 호환성 렌더러에서는 사용할 수 없습니다.

Forward+ 렌더러는 스크린 공간 주변 폐색, 스크린 공간 간접 조명, 스크린 공간 반사 및 서브서피스 스캐터링을 지원합니다.

SSAO는 Intel의 `ASSAO <https://www.intel.com/content/www/us/en/developer/articles/technical/adaptive-screen-space-ambient-occlusion.html>`__(Vulkan으로 변환)에서 파생된 구현을 사용합니다. SSIL은 SSAO에서 파생되어 고성능 간접 조명을 제공합니다.

SSAO와 SSIL이 모두 활성화되면 SSAO와 SSIL의 일부가 공유되어 성능에 미치는 영향을 줄입니다.

SSAO, SSIL 및 SSR은 성능 향상을 위해 기본적으로 절반 해상도로 수행됩니다.

SSR makes use of a Hi-Z buffer to improve performance. This Hi-Z buffer is generated from the depth buffer in a compute shader. See the pull request that overhauled SSR for more information.

GLES3: 스크린 공간 반사.

GLES3: 스크린 스페이스 앰비언트 어클루전(SSAO).

화면 공간 간접 조명 GLSL 셰이더:

스크린 공간 반사 GLSL 셰이더:

서브서피스 산란 GLSL:

하늘 렌더링

더 보기

셰이더

Godot는 하늘 배경을 렌더링하기 위해 셰이더 사용을 지원합니다. PBR 재질에 주변광과 반사를 제공하는 데 사용되는 래디언스 맵은 하늘 셰이더를 기반으로 자동으로 업데이트됩니다.

ProceduralSkyMaterial, PhysicalSkyMaterial 및 PanoramaSkyMaterial과 같은 SkyMaterial 리소스는 하늘 렌더링을 위해 내장된 셰이더를 생성합니다. 이는 BaseMaterial3D가 3D 씬 재질에 제공하는 것과 유사합니다.

자세한 기술 구현은 Godot 4.0의 사용자 정의 하늘 셰이더 기사에서 확인할 수 있습니다.

스카이 렌더링 C++ 코드:

하늘 렌더링 GLSL 셰이더:

체적 안개

참고

Forward+ 렌더러에서만 사용할 수 있으며 모바일 또는 호환성 렌더러에서는 사용할 수 없습니다.

더 보기

공간 셰이더

Godot는 체적 안개 렌더링에 대한 절두체 정렬 복셀(froxel) 접근 방식을 지원합니다. 후처리 필터와 달리 이 접근 방식은 모든 조명 유형에서 작동할 수 있으므로 보다 범용적입니다. 안개는 사용자 정의 동작을 위해 셰이더를 사용할 수도 있습니다. 이를 통해 안개에 애니메이션을 적용하거나 3D 텍스처를 사용하여 밀도를 표현할 수 있습니다.

FogMaterial 리소스는 FogVolume 노드에 대해 내장된 셰이더를 생성합니다. 이는 BaseMaterial3D가 3D 씬 재질에 제공하는 것과 유사합니다.

자세한 기술 설명은 Fog 볼륨이 Godot 4.0에 도착 기사에서 찾을 수 있습니다.

볼루메트릭 포그 C++ 코드:

체적 안개 GLSL 셰이더:

오클루전 컬링

최신 GPU는 많은 삼각형 그리기를 처리할 수 있지만 복잡한 장면의 그리기 호출 수는 여전히 병목 현상이 될 수 있습니다(Vulkan, Direct3D 12 및 Metal의 경우에도).

Godot 4 supports occlusion culling to reduce overdraw (when the depth prepass is disabled) and reduce vertex throughput. This is done by rasterizing a low-resolution buffer on the CPU using Embree. The buffer's resolution depends on the number of CPU threads on the system, as this is done in parallel. This buffer includes occluder shapes that were baked in the editor or created at runtime. The occlusion culling buffer is jittered by a small amount every frame to help reduce under-sampling artifacts, which would lead to false positives (objects getting occluded when they shouldn't be).

복잡한 차단기는 CPU에 많은 부담을 줄 수 있으므로 구운 차단기는 편집기에서 생성될 때 자동으로 단순화될 수 있습니다.

Godot의 오클루전 컬링은 아직 동적 오클루더를 지원하지 않지만 OccluderInstance3D 노드는 여전히 가시성을 전환하거나 이동할 수 있습니다. 그러나 이 방법으로 복잡한 차단기를 업데이트하면 속도가 느려집니다. 따라서 런타임에 차단기를 업데이트하는 것은 쿼드 또는 직육면체와 같은 단순한 차단기 모양에서만 수행하는 것이 가장 좋습니다.

이 CPU 기반 접근 방식은 포털, 룸 또는 GPU 기반 컬링 솔루션과 같은 다른 솔루션에 비해 몇 가지 장점이 있습니다.

  • 수동 설정이 필요하지 않습니다(그러나 최상의 성능을 위해 수동으로 조정할 수 있음).

  • 프레임 지연이 없습니다. 이는 카메라 컷 중 컷씬이나 카메라가 벽 뒤에서 빠르게 움직일 때 문제가 됩니다.

  • 드라이버 또는 GPU 하드웨어에 따라 예측할 수 없는 동작 없이 모든 렌더링 드라이버 및 방법에서 동일하게 작동합니다.

오클루전 컬링은 OccluderInstance3D *노드*(자체적으로 Occluder3D *리소스*를 사용함)를 사용하여 수행되는 오클루더 메시를 등록하여 수행됩니다. 그런 다음 RenderingServer는 RendererSceneOcclusionCull에서 Embree를 호출하여 오클루전 컬링을 수행합니다.

오클루전 컬링 C++ 코드:

가시성 범위 (LOD)

Godot는 인스펙터에서 사용자가 지정한 거리와 함께 수동으로 작성된 계층적 세부 수준(HLOD)을 지원합니다.

RenderingSceneCull에서 _scene_cull() 및 _render_scene() 함수는 대부분의 LOD 결정이 발생하는 곳입니다. 각 뷰포트는 서로 다른 LOD로 동일한 메시를 렌더링할 수 있습니다(분할 화면 렌더링이 올바르게 보이도록 허용).

가시성 범위 C++ 코드:

자동 메시 LOD

ImporterMesh 클래스는 편집기에서 3D 메시 가져오기 작업 흐름에 사용됩니다. generate_lods() 기능은 meshoptimizer 라이브러리를 사용하여 생성을 처리합니다.

LOD 메쉬 생성은 동시에 그림자 메쉬도 생성합니다. 이는 스무딩 및 재질에 관계없이 정점이 용접된 메시입니다. 이는 그림자를 렌더링하는 데 필요한 정점 처리량을 낮춤으로써 그림자 렌더링 성능을 향상시키는 데 사용됩니다.

RenderingSceneCull 클래스의 _render_scene() 함수는 렌더링 시 사용할 메시 LOD를 결정합니다. 각 뷰포트는 서로 다른 LOD로 동일한 메시를 렌더링할 수 있습니다(분할 화면 렌더링이 올바르게 보이도록 허용).

메시 LOD는 화면 범위 측정항목에 따라 자동으로 선택됩니다. 이는 사용자 개입 없이 해상도와 카메라 FOV 변경 사항을 고려합니다. 임계값 승수는 프로젝트 설정에서 조정할 수 있습니다.

성능을 향상시키기 위해 섀도우 렌더링 및 반사 프로브 렌더링은 자체 메시 LOD 임계값(기본 씬 렌더링과 다를 수 있음)을 선택합니다.

C++ 코드 가져오기 시 메시 LOD 생성:

메시 LOD 결정 C++ 코드: