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...

라이트맵 전역 조명 사용

베이크된 라이트맵은 씬에 간접(또는 완전히 베이크된) 조명을 추가하기 위한 워크플로입니다. VoxelGI 및 SDFGI 접근 방식과 달리 베이크된 라이트맵은 런타임 시 리소스를 거의 소비하지 않기 때문에 저가형 PC 및 모바일 장치에서 잘 작동합니다. 또한 VoxelGI 및 SDFGI와 달리 베이크된 라이트맵은 직접 조명을 저장하는 데 선택적으로 사용할 수 있으므로 성능이 더욱 향상됩니다.

VoxelGI 및 SDFGI와 달리 구운 라이트맵은 완전히 정적입니다. 일단 구운 후에는 전혀 수정할 수 없습니다. 또한 씬에는 반사 기능을 제공하지 않으므로 내부에서 :ref:`doc_reflection_probes`를 함께 사용하거나 외부에서 Sky를 사용하는 것이 좋은 품질을 얻는 데 필요합니다.

구워지기 때문에 VoxelGI 및 SDFGI보다 가벼운 번짐 문제가 적고 간접광이 더 좋아 보이는 경우가 많습니다. 단점은 라이트맵 베이킹이 VoxelGI 베이킹에 비해 시간이 더 오래 걸린다는 것입니다. VoxelGI 베이킹은 몇 초 안에 완료될 수 있지만, 라이트맵 베이킹은 몇 분 정도 걸릴 수 있습니다. 이로 인해 반복 속도가 크게 느려질 수 있으므로 실제로 조명의 변화를 확인해야 하는 경우에만 라이트맵을 굽는 것이 좋습니다. 라이트맵은 GPU에서 베이킹되므로 중급 또는 고급 전용 GPU가 있는 경우 라이트 베이킹이 더 빨라집니다.

베이킹 라이트맵은 구운 재질의 UV2 슬롯도 예약합니다. 즉, 더 이상 재질(내장 표준 재료 3D 및 ORM 재료 3D 또는 사용자 정의 셰이더)에서 다른 목적으로 사용할 수 없습니다.

유연성이 부족함에도 불구하고 베이크된 라이트맵은 일반적으로 (주로) 정적 장면에서 최고의 품질과 성능을 동시에 제공합니다. 이는 라이트맵이 비디오 게임의 전역 조명을 위한 가장 오래된 기술임에도 불구하고 게임 개발에서 여전히 널리 사용되는 이유입니다.

더 보기

LightmapGI가 귀하의 요구 사항에 적합한지 확실하지 않습니까? Godot 4에서 사용할 수 있는 GI 기술 비교는 :ref:`doc_introduction_to_global_illumination_comparison`를 참조하세요.

시각적 비교

LightmapGI가 비활성화되었습니다.

LightmapGI가 활성화되었습니다(간접 조명 베이크만 사용). 직접 조명은 여전히 실시간이므로 게임 플레이 중에 미묘한 변화가 가능합니다.

LightmapGI가 활성화되었습니다(직접 및 간접 조명 베이크 포함). 성능은 최고이지만 시각적 품질이 낮습니다. 오른쪽 상단 모서리에 있는 흐릿한 태양 그림자를 확인하세요.

다음은 LightmapGI와 VoxelGI의 모습을 비교한 것입니다. 라이트맵이 더 정확하지만 래핑되지 않은 텍스처에 조명이 있다는 사실로 인해 문제가 발생하므로 전환 및 해상도가 그다지 좋지 않을 수 있습니다. VoxelGI는 정확도가 떨어지지만(근사치이므로) 전체적으로 부드러워 보입니다.

SDFGI는 LightmapGI에 비해 정확도도 떨어집니다. 그러나 SDFGI는 베이킹할 필요 없이 대규모 오픈 월드를 지원할 수 있습니다.

설정하기

경고

웹 편집기에서 라이트맵 베이킹은 그래픽 API 제한으로 인해 지원되지 않습니다. 웹 플랫폼에서는 다른 플랫폼에서 구운 렌더링 라이트맵만 지원됩니다.

참고

LightmapGI 노드는 LightmapGI 노드(형제)와 동일한 레벨에 있는 노드 또는 LightmapGI 노드의 자식 노드인 노드만 베이크합니다. 이를 통해 여러 LightmapGI 노드를 사용하여 씬의 다양한 부분을 서로 독립적으로 베이킹할 수 있습니다.

우선, 라이트매퍼가 작업을 수행하려면 베이킹할 객체에 UV2 레이어와 텍스처 크기가 필요합니다. UV2 레이어는 객체의 모든 면이 UV 맵에서 자체 위치를 갖도록 보장하는 보조 텍스처 좌표 세트입니다. 면은 텍스처의 픽셀을 공유하면 안 됩니다.

개체에 고유한 UV2 레이어와 텍스처 크기가 있는지 확인하는 몇 가지 방법이 있습니다.

씬 가져오기 시 언래핑(권장)

대부분의 시나리오에서는 이것이 사용하기에 가장 좋은 접근 방식입니다. 유일한 단점은 대형 모델의 경우 가져올 때 포장을 푸는 데 시간이 걸릴 수 있다는 것입니다. 그럼에도 불구하고 Godot는 다시 가져오기를 통해 UV2를 캐시하므로 필요할 때만 재생성됩니다.

파일 시스템 도크에서 가져온 씬을 선택한 다음 가져오기 도크로 이동합니다. 여기에서 다음 옵션을 수정할 수 있습니다.

메시 > 라이트 베이킹 옵션은 **정적 라이트맵(VoxelGI/SDFGI/LightmapGI)**으로 설정되어야 합니다.

임포트 시 언래핑할 때 Meshes > Lightmap Texel Size 옵션을 사용하여 텍스처 크기를 조정할 수 있습니다. 낮은 값은 더 자세한 라이트맵을 생성하여 베이킹 시간이 길어지고 라이트맵 파일 크기가 커지는 대신 시각적 품질이 높아질 수 있습니다. 0.2``의 기본값은 중소 규모 장면에 적합하지만 더 큰 장면의 경우 ``0.5 이상으로 늘릴 수도 있습니다. 간접 조명은 저주파 데이터이므로 간접 조명만 베이킹하는 경우 특히 그렇습니다. 즉, 정확하게 표현하기 위해 고해상도 텍스처가 필요하지 않습니다.

이 옵션을 설정하면 씬 내의 모든 메시에 UV2 맵이 올바르게 생성됩니다.

경고

씬 내에서 메시를 재사용하는 경우 발견된 첫 번째 인스턴스에 대해 UV가 생성된다는 점을 명심하세요. 메시를 다른 스케일로 재사용하는 경우(그리고 스케일이 절반 또는 두 배 이상 크게 다른 경우) 라이트맵이 비효율적으로 만들어집니다. 이를 방지하려면 MeshInstance3D 노드의 GeometryInstance3D 섹션에서 라이트맵 배율 속성을 조정하세요. 이를 통해 특정 MeshInstance3D 노드에 대한 라이트맵 세부 수준을 *증가*시킬 수 있습니다(감소할 수는 없음).

또한 *.unwrap_cache 파일은 UV2 다시 가져오기가 플랫폼과 엔진 버전 전반에 걸쳐 일관성을 보장하므로 버전 제어에서 무시하면 안 됩니다.

Godot 내에서 풀어보세요

경고

가져온 3D 씬에서 이 메시 메뉴 작업을 사용하는 경우 씬을 다시 로드하면 생성된 UV2가 손실됩니다.

Godot에는 메쉬를 풀고 UV 채널을 시각화하는 옵션이 있습니다. MeshInstance3D 노드를 선택한 후 3D 편집기 뷰포트 상단의 Mesh 메뉴에서 찾을 수 있습니다.

그러면 베이킹에 사용할 수 있는 두 번째 UV2 좌표 세트가 생성됩니다. 또한 텍스처 크기도 자동으로 설정됩니다.

3D 모델링 소프트웨어에서 포장 풀기

마지막 옵션은 즐겨 사용하는 3D 앱에서 수행하는 것입니다. 이 접근 방식은 일반적으로 권장되지 않습니다. 그러나 이러한 접근 방식이 존재한다는 것을 알 수 있도록 설명합니다. 가장 큰 장점은 자주 다시 가져오고 싶은 복잡한 객체의 경우 Godot 내에서 텍스처 생성 프로세스가 상당히 비용이 많이 들 수 있으므로 가져오기 전에 래핑을 해제하는 것이 더 빠를 수 있다는 것입니다.

두 번째 UV2 레이어에서 언랩을 수행하기만 하면 됩니다.

그런 다음 3D 씬을 정상적으로 가져옵니다. 가져온 후에 메시의 텍스처 크기를 설정해야 한다는 점을 기억하세요.

임포트 시 외부 메시를 사용하면 크기가 유지됩니다. 3D 모델링 소프트웨어의 대부분의 언래퍼는 신속하게 작동하도록 설계되어 있으므로 품질 지향적이지 않습니다. 더 나은 포장 풀기를 위해서는 주로 솔기나 기타 기술을 사용해야 합니다.

프리미티브 메시를 위한 UV2 생성하기

참고

이 옵션은 BoxMesh, CylinderMesh, PlaneMesh 등과 같은 기본 메시에만 사용할 수 있습니다.

기본 메시에 UV2를 활성화하면 구운 조명을 수신하고 이에 기여할 수 있습니다. 이는 특정 조명 설정에서 사용될 수 있습니다. 예를 들어 라이트맵을 베이킹한 후 발광 재료가 있는 토러스를 숨겨 토러스 모양을 따르는 영역 조명을 만들 수 있습니다.

기본적으로 기본 메시에는 리소스를 절약하기 위해 생성된 UV2가 없습니다(이러한 메시는 게임플레이 중에 생성될 수 있으므로). 인스펙터에서 기본 메시를 편집하고 Add UV2**를 활성화하여 엔진이 기본 메시에 대한 UV2를 절차적으로 생성하도록 할 수 있습니다. 기본 **UV2 패딩 값은 가장자리에 너무 많은 공간을 낭비하지 않고 대부분의 라이트맵 블리딩을 방지하도록 조정됩니다. 특정 프리미티브 메시에서만 라이트맵 블리딩이 발견되면 **UV2 패딩**을 늘려야 할 수도 있습니다.

라이트맵 크기 힌트**는 라이트맵 텍스처에서 단일 메시가 차지하는 크기를 나타내며, 이는 메시의 크기 속성과 **UV2 Padding 값에 따라 달라집니다. **라이트맵 크기 힌트**는 수동으로 변경하면 안 됩니다. 씬을 다시 로드하면 수정 사항이 손실되기 때문입니다.

CSG 노드를 위한 UV2 생성하기

Godot 4.4부터 :ref:`CSG 노드 및 자식 노드를 MeshInstance3D <doc_csg_tools_converting_to_mesh_instance_3d>`로 변환할 수 있습니다. 다음 단계에 따라 CSG 노드에서 라이트맵을 굽는 데 사용할 수 있습니다.

• 루트 CSG 노드를 선택하고 3D 편집기 뷰포트 상단에서 **CSG > Bake Mesh Instance**를 선택합니다.

• 방금 구운 루트 CSG 노드를 숨깁니다(자동으로 숨겨지지 않습니다).

• 새로 생성된 MeshInstance3D 노드를 선택하고 **Mesh > Unwrap UV2 for Lightmap/AO**를 선택합니다.

• 라이트맵을 굽습니다.

팁

씬 트리에 원본 CSG 노드를 유지하여 필요할 경우 나중에 형상을 변경할 수 있도록 하십시오. 형상을 변경하려면 MeshInstance3D 노드를 제거하고 루트 CSG 노드를 다시 표시하십시오.

UV2 체크하기

앞서 언급한 Mesh 메뉴에서는 UV2 텍스처 좌표를 시각화할 수 있습니다. 문제가 있는 경우 메시에 다음과 같은 UV2 좌표가 있는지 다시 확인하세요.

씬 설정하기

작업을 수행하기 전에 LightmapGI 노드를 씬에 추가해야 합니다. 이렇게 하면 인스턴스화된 장면에서도 해당 씬의 모든 노드(및 하위 노드)에서 라이트 베이킹이 활성화됩니다.

하위 씬는 베이커에서 지원되므로 여러 번 인스턴스화할 수 있습니다. 각 인스턴스에는 자체 라이트맵이 할당됩니다. 일관되지 않은 라이트맵 텍셀 스케일링 문제를 방지하려면 앞서 언급한 메시 스케일링에 대한 규칙을 준수해야 합니다.

메시 설정하기

MeshInstance3D 노드가 베이킹 프로세스에 참여하려면 베이크 모드를 Static**으로 설정해야 합니다. 베이크 모드가 **비활성화 또는 **동적**으로 설정된 메시는 라이트매퍼에서 무시됩니다.

씬 임포트 시 라이트맵을 자동 생성하면 자동으로 활성화됩니다.

조명 설정하기

조명은 기본적으로 간접 조명으로만 베이킹됩니다. 즉, 섀도우 매핑과 조명은 여전히 동적이며 움직이는 객체에 영향을 주지만 해당 조명에서 반사되는 빛은 구워집니다.

조명을 비활성화하거나(베이크 없음) 완전히 베이크할 수 있습니다(직접 및 간접). 이는 조명의 Bake Mode 메뉴에서 제어할 수 있습니다.

이 모드는:

비활성화

라이트맵을 베이킹할 때 라이트는 무시됩니다. 폭발, 무기 효과 등의 동적 조명 효과에 사용하는 모드입니다.

경고

라이트를 숨겨도 라이트맵 베이킹 결과에는 아무런 영향이 없습니다. 이는 Visible 속성을 비활성화하여 Light 노드를 숨기는 대신 비활성화된 베이킹 모드를 사용해야 함을 의미합니다.

동적

이는 기본 모드이며 성능과 실시간 친화성 사이의 절충안입니다. 간접 조명만 베이크됩니다. LightmapGI가 없으면 직접 조명과 그림자는 여전히 실시간입니다.

이 모드를 사용하면 조명의 색상, 에너지 및 위치를 미묘하게 변경하면서 여전히 상당히 정확하게 보일 수 있습니다. 예를 들어, 이를 사용하여 간접광이 구워진 깜박이는 정적 횃불을 만들 수 있습니다.

섀도우 마스크 모드의 값에 따라 여전히 DirectionalLight3D를 위해 멀리 있는 구워진 그림자를 얻을 수 있습니다. 이를 통해 가까이 있는 그림자는 실시간으로 표현되고 동적 오브젝트를 보여주는 반면, 멀리 있는 정적 오브젝트는 여전히 그림자를 드리울 수 있습니다.

정적

간접광과 직접광 모두 베이크됩니다. 정적 표면은 조명 및 그림자 계산을 완전히 건너뛸 수 있으므로 이 모드는 거리에 따라 결코 사라지지 않는 부드러운 그림자와 함께 최고의 성능을 제공합니다. 실시간 조명은 더 이상 구운 표면에 영향을 미치지 않지만 동적 개체에는 여전히 영향을 미칩니다. 라이트에 모두 베이킹 모드를 사용하는 경우 동적 개체는 구운 표면에 실시간 그림자를 드리우지 않으므로 대신 얼룩 그림자와 같은 다른 접근 방식을 사용해야 합니다. 얼룩 그림자는 데칼 노드로 구현할 수 있습니다.

게임 플레이 중에는 조명을 전혀 조정할 수 없습니다. 조명을 이동하거나 색상(또는 에너지)을 변경해도 정적 표면에는 아무런 영향을 미치지 않습니다.

베이킹 모드는 조명별로 조정할 수 있으므로 하이브리드 베이킹 조명 설정을 만드는 것이 가능합니다. 널리 사용되는 옵션 중 하나는 베이크 모드를 동적**으로 설정한 실시간 방향 조명을 사용하고 OmniLights 및 SpotLights에는 **정적 베이크 모드를 사용하는 것입니다. 이는 동적 개체가 야외 영역에 실시간 그림자를 드리울 수 있도록 하면서 좋은 성능을 제공합니다.

완전히 구운 조명은 조명 노드' **크기**(전방향/스팟) 또는 **각거리**(방향) 속성을 활용할 수도 있습니다. 이를 통해 시전자와 그림자 사이의 거리가 증가함에 따라 크기가 증가하는 사실적인 반그림자가 있는 그림자가 가능해집니다. 또한 동적 개체에만 실시간 그림자가 렌더링되므로 실시간 PCSS 그림자에 비해 성능 비용이 낮습니다.

굽기

베이크 프로세스를 시작하려면 LightmapGI 노드를 선택할 때 3D 편집기 뷰포트 상단에 있는 Bake Lightmaps 버튼을 클릭하세요.

씬 크기, 베이킹 방법 및 선택한 품질에 따라 몇 초에서 몇 분(또는 몇 시간)이 걸릴 수 있습니다.

경고

라이트맵 굽기는 특히 결과 텍스처가 큰 경우 많은 비디오 메모리가 필요할 수 있는 프로세스입니다. 내부 제한으로 인해 생성된 텍스처 크기가 너무 크면(비디오 메모리가 많은 시스템에서도) 엔진이 충돌할 수도 있습니다.

충돌을 방지하려면 Import Dock의 라이트맵 텍셀 크기가 충분히 높은 값으로 설정되어 있는지 확인하세요.

트윅

• 품질: 낮음, 중간, 높음, 울트라의 4가지 베이킹 품질 모드가 제공됩니다. 품질이 높을수록 시간이 더 걸리지만 노이즈가 적고 보기 좋은 라이트맵이 생성됩니다. 직접적인 조명을 거의 또는 전혀 받지 못하는 발광 재료나 영역에서 특히 차이가 두드러집니다. 각 베이킹 품질 모드는 프로젝트 설정에서 추가로 조정할 수 있습니다.

• 슈퍼샘플링: 더 높은 해상도로 라이트맵을 생성한 다음 다운샘플링합니다. 이렇게 하면 노이즈와 빛 누출이 줄어들고 작은 규모의 디테일로 더 나은 그림자가 생성됩니다. 그러나 이를 사용하면 라이트맵 베이킹 중 베이킹 시간과 메모리 사용량이 늘어납니다. **수퍼샘플링 요소**는 다운샘플링 전에 라이트맵이 렌더링되는 크기를 변경합니다.

• 바운스: 간접 조명에 사용할 바운스 수입니다. 기본값(3)은 굽는 시간과 품질 사이에서 적절한 절충안입니다. 값이 높을수록 빛이 멈추기 전에 더 많이 반사되어 간접 조명이 더 부드러워 보입니다(그러나 재질과 형상에 따라 더 밝아질 수도 있음).

• 바운스 간접 에너지: 조명의 간접 에너지를 베이킹할 때 사용할 전역 승수입니다. 이는 각 조명의 간접 에너지 값을 곱합니다. ``1.0``와 다른 값은 물리적으로 정확하지 않지만 예술적 효과를 위해 사용할 수 있습니다.

• 방향: 활성화되면 라이트맵의 방향 정보를 저장합니다. 이렇게 하면 구운 표면, 특히 완전히 구운 조명의 노멀 매핑된 재질의 모양이 향상됩니다(직사광도 구운 것이므로). 단점은 방향성 라이트맵을 렌더링하는 데 비용이 약간 더 든다는 것입니다. 또한 베이킹하는 데 더 많은 시간이 필요하므로 파일 크기가 더 커집니다.

• 섀도우마스크 모드: None 이외의 모드로 설정하면, Dynamic 글로벌 일루미네이션 모드가 적용된 씬의 첫 번째 DirectionalLight3D의 정적 그림자가 섀도우마스크라는 별도의 텍스처에 구워집니다. 이 기능을 사용하면 카메라와의 거리에 관계없이 멀리 있는 정적 오브젝트가 다른 정적 오브젝트에 그림자를 드리울 수 있습니다. 자세한 내용은 섀도우마스킹 섹션을 참조하세요.

• 인테리어: 활성화하면 환경 조명이 소싱되지 않습니다. 빛 누출을 방지하려면 순수 실내 장면에 사용하세요.

• 바운스에 텍스처 사용: 활성화하면 조명 정보가 포함된 텍스처가 생성되어 어느 정도 정확도를 희생하면서 간접 조명 생성 속도를 높입니다. 저해상도 라이트맵이나 표면 전체에 걸쳐 라이트맵을 크게 늘리는 UV를 사용할 때 형상에 추가 빛 누출 아티팩트가 나타날 수 있습니다. 확실하지 않은 경우 활성화된 상태로 두세요.

• 디노이저 사용: 활성화되면 노이즈 제거 알고리즘을 사용하여 라이트맵의 노이즈를 크게 줄입니다. 이로 인해 베이킹 시간이 늘어나고 가끔 아티팩트가 발생할 수 있지만 그 결과는 대개 그만한 가치가 있습니다. 자세한 내용은 :ref:`doc_using_lightmap_gi_denoising`를 참조하세요.

• 디노이저 강도: 생성된 라이트맵에 적용되는 노이즈 제거 단계의 강도입니다. 값이 높을수록 노이즈 제거에 더 효과적이지만 정적 그림자의 그림자 세부 묘사가 줄어들 수 있습니다. 노이즈 제거가 활성화되어 있고 노이즈 제거 방법이 :abbr:`JNLM(Non-Local Means with Joint Filtering)`(:abbr:`OIDN(Open Image Denoise)`에는 노이즈 제거 강도 설정이 없음)인 경우에만 효과적입니다.

• 바이어스: 3D 단위의 그림자에 사용할 오프셋 값입니다. 베이킹 후 라이트맵에 가벼운 번짐이나 어두운 점 문제가 발생하는 경우를 제외하고는 일반적으로 이 값을 변경할 필요가 없습니다. 이 설정은 구운 표면에 투사된 실시간 그림자에 영향을 주지 않습니다(동적 베이킹 모드를 사용하는 조명의 경우).

• 최대 텍스처 크기: 생성된 텍스처 아틀라스의 최대 텍스처 크기입니다. 값이 높을수록 생성되는 슬라이스 수가 줄어들지만 텍스처 크기에 대한 하드웨어 제한으로 인해 모든 하드웨어에서 작동하지 않을 수 있습니다. 확실하지 않은 경우 기본값인 ``16384``로 그대로 두세요.

• 환경 > 모드: 라이트맵을 베이킹할 때 환경 조명이 소싱되는 방식을 제어합니다. 씬**의 기본값은 외부 부품이 보이는 레벨에 적합합니다. 순수 실내 장면의 경우 빛 누출을 방지하고 베이킹 속도를 높이려면 **비활성화**로 설정하세요. 실제 씬의 환경 하늘과 다른 환경 조명을 사용하려면 **Custom Sky 또는 **Custom Color**로 설정할 수도 있습니다.

• Gen 프로브 > Subdiv: :ref:`doc_using_lightmap_gi_dynamic_objects`를 참조하세요.

• 데이터 > 라이트 데이터: :ref:`doc_using_lightmap_gi_data`를 참조하세요.

먼 거리의 방향성 그림자를 위한 섀도우마스킹 사용하기

DirectionalLight3D를 사용할 때, 실시간 그림자를 그릴 수 있는 최대 거리는 그림자 최대 거리 속성에 의해 제한됩니다. 이는 넓은 씬에서 문제가 될 수 있는데, 멀리 있는 물체에는 DirectionalLight3D로부터의 그림자가 나타나지 않기 때문입니다. DirectionalLight3D에서 Static 글로벌 일루미네이션 모드를 사용하면 이 문제를 해결할 수 있지만 여기에는 몇 가지 단점이 있습니다:

• 직접 조명과 간접 조명이 모두 구워지기 때문에 동적 객체가 사실적인 방식으로 정적 표면에 그림자를 투사할 수 있는 방법은 없습니다. Godot는 이 경우 "이중 조명" 아티팩트를 피하기 위해 그림자 샘플링을 완전히 건너뜁니다.

• 정적 그림자는 실시간 그림자 캐스케이드가 아닌 라이트맵 텍스처에만 의존하기 때문에 세부적인 부분이 부족합니다.

*섀도우마스킹*을 사용하면 먼 그림자의 이점을 누리면서 이러한 단점을 피할 수 있습니다. 동적 객체는 섀도우마스크로부터 그림자를 받지 않지만, 대부분의 장면이 주로 정적 객체로 구성되어 있기 때문에 시각적 효과가 크게 향상됩니다.

라이트맵 텍스처만으로는 그림자 정보가 포함되어 있지 않으므로 이 그림자 정보를 *섀도마스크*라는 별도의 텍스처에 구울 수 있습니다.

섀도우마스킹은 동적 전역 조명 모드가 있는 씬(트리 순서로 결정됨)의 첫 번째 DirectionalLight3D에만 영향을 미칩니다. 정적 전역 조명 모드에서는 섀도우 마스크를 사용할 수 없습니다. 이 모드는 정적 개체의 그림자 샘플링을 완전히 건너뛰기 때문입니다. 이는 정적 전역 조명 모드가 직접 조명과 간접 조명을 모두 베이크하기 때문입니다.

세 가지 섀도우마스킹 모드가 사용 가능합니다:

• None (디폴트): 섀도우마스크 텍스처를 굽지 않습니다. DirectionalLight3D의 그림자 최대 거리 속성으로 지정된 범위를 벗어나는 방향성 그림자는 보여지지 않습니다.

• Replace: 섀도우마스크 텍스처를 굽고 DirectionalLight3D의 그림자 최대 거리 속성에서 지정된 범위를 벗어날 때 방향성 그림자를 그리는 데 사용합니다. 이 범위 안의 그림자는 완전히 실시간을 유지합니다. 이 옵션은 미묘한 움직임을 보이는 정적 오브젝트(예: 잎 그림자)를 효과적으로 처리할 수 있으므로 대부분의 씬에 가장 적합합니다.

• Overlay: 섀도우마스크 텍스처를 굽고 카메라로부터의 거리에 관계 없이 방향성 그림자를 그립니다. DirectionalLight3D의 그림자 최대 거리 속성의 범위 안의 그림자는 실시간 그림자로 중첩됩니다. 이를 통해 라이트맵 텍셀 밀도에 따라 정적 오브젝트 그림자에 나타나는 "번짐" 효과를 희생하더라도 실시간 그림자와 구운 그림자 사이의 전환이 덜 어색해질 수 있습니다. 또한 이 모드에서는 미묘한 움직임을 보이는 정적 오브젝트(예: 잎)를 제대로 처리할 수 없습니다. 구운 그림자를 시간이 지남에 따라 애니메이션으로 표현할 수 없기 때문입니다. 여전히 카메라가 빠르게 움직이는 씬에서는 이 방법이 Replace보다 더 나을 수 있습니다.

여기에는 비교 목적으로 그림자 최대 거리를 매우 낮게 설정한 씬에서 섀도우마스크 모드를 시각적으로 비교한 것입니다. 파란색 상자는 동적 오브젝트이고, 나머지 씬은 정적 오브젝트입니다. 동적 글로벌 일루미네이션 모드를 사용하는 씬에는 DirectionalLight3D가 하나만 있습니다:

섀도우마스크 모드 비교

참고

라이트맵을 다시 굽지 않고도 Replace**와 **Overlay 섀도우마스크 모드 사이를 전환할 수 있습니다.

베이킹 시간과 품질의 균형 유지

고품질 베이킹은 매우 오랜 시간이 걸릴 수 있으므로(대규모 복잡한 장면의 경우 최대 수십 분) 처음에는 낮은 품질 설정을 사용하는 것이 좋습니다. 그런 다음 씬의 조명 설정에 확신이 생기면 프로젝트를 내보내기 전에 품질 설정을 높이고 "최종" 베이킹을 수행하십시오.

가져온 3D 장면에서 **라이트맵 텍셀 크기**를 늘려 라이트맵 해상도를 줄이면 베이킹 속도도 크게 향상됩니다. 그러나 이 경우 라이트맵을 다시 굽기 전에 모든 라이트맵 3D 장면을 다시 가져와야 합니다.

노이즈 제거

라이트맵 베이킹은 레이트레이싱에 의존하기 때문에 "원시" 베이크된 라이트맵에는 항상 눈에 보이는 노이즈가 있습니다. 특히 햇빛이 들어올 수 있는 작은 구멍이 있는 실내 공간과 같이 반사광이 도달하기 어려운 공간에서 소음이 눈에 띄게 나타납니다. 베이킹 품질을 높이면 소음을 줄일 수 있지만 그렇게 하면 베이킹 시간이 크게 늘어납니다.

잡음 제거 비활성화 및 활성화(기본 JNLM 잡음 제거기 사용) 비교.

베이킹 시간을 너무 많이 늘리지 않고 소음을 방지하려면 디노이저를 사용할 수 있습니다. 디노이저는 최종 구운 라이트맵에서 실행되는 알고리즘으로, 세부 사항을 최대한 보존하면서 노이즈 패턴을 감지하고 부드럽게 만듭니다. Godot는 두 가지 노이즈 제거 알고리즘을 제공합니다:

JNLM(조인트 필터링을 사용한 비로컬 수단)

JNLM은 기본 노이즈 제거 방법이며 Godot에 포함되어 있습니다. *비로컬 수단*으로 알려진 간단하지만 효율적인 노이즈 제거 알고리즘을 사용합니다. JNLM은 컴퓨팅 셰이더를 사용하여 GPU에서 실행되며 Godot 4의 RenderingDevice 기반 렌더러를 실행할 수 있는 모든 GPU와 호환됩니다. 추가 설정이 필요하지 않습니다.

JNLM의 노이즈 제거는 디노이저 사용**이 활성화된 경우 표시되는 **디노이저 강도 속성을 사용하여 조정할 수 있습니다. 값이 높을수록 정적 그림자의 그림자 세부 묘사를 억제하는 대신 노이즈 제거에 더 효과적일 수 있습니다.

JNLM 디노이저 강도 값 비교. 값이 높을수록 세부 묘사가 줄어들 수 있습니다.

OIDN(오픈 이미지 노이즈 제거)

JNLM과 달리 OIDN은 라이트맵 노이즈 제거에 기계 학습 접근 방식을 사용합니다. JNLM에 비해 대부분의 장면에서 더 많은 그림자 세부 정보를 유지하면서 라이트맵에서 노이즈를 제거하도록 특별히 훈련된 모델이 특징입니다.

하드웨어 가속이 구성된 경우 OIDN은 GPU에서 실행될 수 있습니다. 최신 고급 GPU를 사용하면 CPU 기반 노이즈 제거에 비해 50배 이상의 속도 향상을 제공할 수 있습니다.

• AMD GPU에서는 HIP를 설치하고 구성해야 합니다.

• NVIDIA GPU에서는 CUDA를 설치하고 구성해야 합니다. 이는 NVIDIA 설치 프로그램에 의해 자동으로 수행될 수 있지만 Linux에서는 CUDA 라이브러리가 기본적으로 설치되지 않을 수 있습니다. Linux 배포판의 CUDA 패키지가 설치되어 있는지 다시 확인하세요.

• Intel GPU에서는 SYCL을 설치하고 구성해야 합니다.

하드웨어 가속을 사용할 수 없는 경우 OIDN은 멀티스레드 CPU 기반 노이즈 제거로 대체됩니다. GPU 기반 노이즈 제거가 작동하는지 확인하려면 라이트맵을 굽는 동안 GPU 활용 모니터를 사용하고 Godot 편집기에 노이즈 제거 단계가 표시되는 동안 GPU 활용률과 VRAM 활용을 살펴보세요. 이를 위해서는 nvidia-smi 명령줄 도구가 유용할 수 있습니다.

OIDN은 상대적으로 큰 다운로드 크기로 인해 Godot에 포함되지 않습니다. 웹사이트 <https://www.openimagedenoise.org/downloads.html>`__에서 사전 컴파일된 OIDN 바이너리 패키지를 다운로드할 수 있습니다. PC의 위치에 패키지를 추출한 다음 편집기 설정(**파일 시스템 > 도구 > OIDN > OIDN Denoise Path**)에서 ``oidnDenoise` 실행 파일의 경로를 지정합니다. 이 실행 파일은 추출한 바이너리 패키지의 bin 폴더 내에 있습니다.

OIDN 노이즈 제거 실행 파일의 경로를 지정한 후 **Rendering > Lightmapping > Denoiser**를 **OIDN**으로 설정하여 프로젝트 설정에서 노이즈 제거 방법을 변경합니다. 이는 설정이 변경된 후 이 프로젝트의 모든 라이트맵 베이크에 영향을 미칩니다.

참고

노이즈 제거 방법은 편집기 설정 대신 프로젝트 설정에서 구성됩니다. 이는 동일한 프로젝트에 참여하는 여러 팀 구성원이 일관된 결과를 위해 동일한 노이즈 제거 방법을 사용하도록 하기 위해 수행됩니다.

JNLM과 OIDN 잡음 제거기의 비교. OIDN이 어떻게 세부 사항을 더 잘 보존하고 다양한 개체의 이음새를 줄이는지 확인하세요.

동적 객체

VoxelGI 및 SDFGI와 달리 동적 객체는 정적 객체와 다르게 간접 조명을 받습니다. 이는 라이트매핑이 정적 개체에만 수행되기 때문입니다.

동적 객체에 간접 조명을 표시하기 위해 3D 프로브 시스템이 사용되며, 라이트 프로브는 씬 전체에 퍼져 있습니다. 라이트맵을 베이킹할 때 라이트매퍼는 프로브가 받는 간접 빛의 양을 계산합니다. 베이크 모드가 **정적**으로 설정된 조명의 경우에도 직접 조명은 라이트 프로브 내에 저장되지 않습니다(동적 개체는 실시간으로 계속 조명을 받기 때문).

서버로 프로젝트를 내보낼 수 있는 방법이 두 가지 있습니다:

• 자동: Gen Probes > Subdiv**를 **Disabled 이외의 값으로 설정한 다음 라이트맵을 굽습니다. 기본값은 ``8``이지만 베이킹 시간이 길어지고 출력 파일 크기가 커지는 대신 더 큰 값을 선택하여 정밀도를 향상시킬 수 있습니다.

• 수동: 자동으로 프로브를 생성하는 것 외에 또는 그 대안으로 LightmapProbe 노드를 씬에 추가하여 수동으로 라이트 프로브를 추가할 수 있습니다. 이는 동적 객체가 자주 이동하는 영역의 조명 세부 사항을 개선하는 데 사용할 수 있습니다. LightmapProbe 노드를 씬에 배치한 후 라이트맵을 다시 구워야 효과가 있습니다.

참고

라이트맵을 베이킹한 후에는 구운 조명이 동적 객체에 어떻게 영향을 미치는지 나타내는 3D 씬의 흰색 구체를 볼 수 있습니다. 이러한 구체는 실행 중인 프로젝트에 나타나지 않습니다.

편집기에서 이러한 구체를 숨기려면 3D 편집기 상단에서 **보기 > Gizmos > LightmapGI**를 전환하세요("눈을 감은" 아이콘은 기즈모가 숨겨져 있음을 나타냄).

라이트맵 데이터

LightmapGI 노드의 데이터 > 라이트 데이터 속성에는 베이킹 후 라이트맵 데이터가 포함되어 있습니다. 텍스처는 디스크에 저장되지만 여기에는 무거울 수 있는 동적 개체에 대한 캡처 데이터도 포함됩니다. .tscn 형식의 씬을 사용하는 경우 이 리소스를 외부 바이너리 .lmbake 파일에 저장하여 Base64로 인코딩된 바이너리 데이터로 .tscn 씬이 커지는 것을 방지해야 합니다.

팁

생성된 EXR 파일은 필요한 경우 사후 처리를 수행하기 위해 이미지 편집기를 사용하여 보고 편집할 수도 있습니다. 그러나 라이트맵을 다시 베이킹하면 EXR 파일의 변경 사항이 손실된다는 점에 유의하세요.

LightmapGI 아티팩트 줄이기

카메라가 움직일 때 LightmapGI 노드가 나타났다가 사라지는 것을 발견했다면 이는 엔진이 한 번에 너무 많은 LightmapGI 인스턴스를 렌더링하기 때문일 가능성이 높습니다. Godot는 한 번에 8개의 LightmapGI 노드를 렌더링하도록 제한되어 있으며, 이는 일부 인스턴스가 깜박이기 시작하기 전에 최대 8개의 인스턴스가 카메라 뷰에 있을 수 있음을 의미합니다.