Domain은 Volume으로 BlendMode는 Addtive
월드에 배치된 ExponentialHeightFog에서 Volumetric Fog를 체크해주어야 합니다. 이거 체크 안해줬다가 머티리얼에서 뭘 실수했는지 한참 찾았습니다.

언리얼에서 공식적으로 밀고 있는 기능이 루맨이기 때문에 글로벌 일루미네이션과 리플렉션 모두 기본 메서드가 Lumen으로 되어 있습니다.
글로벌 일루미네이션과 리플렉션은 사실상 한 세트, 묶어서 봐야한다고 합니다.
메서드 선택지 중 플러그인이 존재하는데 이것은 엔진에서 GI를 설정할 수 있는 플러그인 몇 개 있는데 그것을 사용하는 것으로 보입니다.
Method 중 ScreenSpace의 경우 리플렉션은 공식지원이나 GI는 Beata 기능입니다.
하위 버전에는 루멘 대신 레이트레이스라고 되어있는데 현재는 지원하지 않는 기능이니 사용하지 않는 것이 좋습니다.
Method None은 별도의 처리를 하지 않겠다는 의미입니다.
루멘에도 거리에 따른 처리여부 결정 로직이 존재합니다. 멀면 검은색으로 표시, 가까운면 제대로 라이팅 처리
이 경우 바운드 볼륨을 키우거나, 루멘 씬 디테일 값을 증가시키면 포함되기도 합니다. 어디까지나 케이스 바이 케이스라 안 될 수도 있습니다.
Ray Lighting Mode
루멘 리플렉션 부에서 디테일하게 정할 옵션입리고 합니다.
Surface Cache
Hit Lighting
Hit Lighting for Reflections
솔직히 차이를 잘 모르겠습니다.
Surface Cache 캡쳐

Hit Lighting for Reflections 캡쳐

디폴트 설정은 Surface Cache라고 합니다.
루멘 씬 라이팅 퀄리티
루멘씬의 퀄리티를 정합니다. 수치가 높을 수록 퀄리티가 높습니다.
루멘 씬 디테일
루멘으로 처리할 디테일 수치를 증가시킵니다.
올리면 작은 오브젝트더라도 루멘으로 처리되고 수치가 낮을 경우 작은 오브젝트들은 루멘으로 처리되지 않을 수 있습니다.
물론 수치가 높을수록 비용이 증가합니다.
Screen Trace
스크린 스페이스 기준으로 반사를 처리할 지를 결정하는 옵션이라고 합니다.
정확히는 반사가 아니라 스크린 기준으로 광선을 추적할 지 여부라고 합니다.
가끔 반사되면 안 될 것이 반사되는 현상이 발생한다고 합니다.
-> GI 보다는 Relcection에서 더 흔한 표현이며, GI에서도 Screen Trace가 켜져 있으면, 화면에 잡힌 정보 때문에 의도와 다르게 빛이 번지거나(빛샘/오염처럼) 보이는 케이스를 “이상하게 비친다”라고 체감할 수는 있다고 합니다.
카메라 기준으로 반사처리가 진행됩니다.
-> 화면에 있는 정보를 사용하기 때문에 뷰(카메라)에 의존적일 수 있다고 하빈다.
Off

On

파이널 게더 퀄리티
이 값을 올려주면 노이즈를 감소시킬 수 있으나 비용이 증가합니다.
슬라이더로는 2까지 올릴 수 있지만 직접 수를 입력해서 증가시키면 그 이상으로도 늘어납니다.
CVar
스크린 스페이스를 상세 설정하는 옵션은 Detail 패널에 존재하지 않습니다.
각 수치들은 분명히 존재하고 있으며, 콘솔 명령을 통해 조정할 수 있습니다.
r.ssgi로 입력하면 스크린 스페이스 GI에 관련된 옵션들이 6개 정도 나타납니다.
아직 베타여서 제대로 지원이 되질 않는 것으로 보입니다.
이런 ConsoleVariables 들을 영미권에서는 줄여서 C.Var이라고 부르는 듯합니다. 발음 주의
일일히 콘솔창에서 입력해서 사용하는 것은 번거롭습니다.
때문에 베타지만 Console Variables Editor 플러그인이 제공되고 있습니다.


console variables 창 - 변수 등록

이미지처럼 콘솔 변수를 등록해서 수정이 가능하고, 프리셋으로 빼서 저장하고 불러오는 것도 가능합니다.
에디터에서만 사용이 가능하고 런타임 중에는 잘 안 된다고 합니다.
Reflection도 기능은 GI와 비슷하다고 합니다.
Max Roughness To Trace
Max Reflection Bounces
Max Refraction Bounces
굴절, 반사 처리는 많이 수행하면 할수록 그래픽 리소스를 많이 잡아먹습니다.
때문에 Max Refraction Bounces, Max Reflection Bounces을 늘리면 프레임이 확 많이 떨어지게 됩니다.
낮으면 퀄리티가 낮아지고 퍼포먼스가 향상, 높으면 퀄리티가 상승하고 퍼포먼스가 낮아집니다.
리플렉션(정반사) 처리에 관련된 렌더링 파이프라인을 루멘을 사용할 지 스크린스페이스로 사용할 지 선택할 수 있습니다.
Lunmen Reflection과 ScreenSpace Reflection으로 따로 나뉘어져 있습니다.
GI는 SSGI(ScreenSpace Global Illumination)과 루멘 GI(Lumen Global Illumination)로 나뉩니다.
루멘GI는 화면 트레이스 기능으로 스크린 스페이스화 진행이 되고 그 루멘씬으로 이제 cash 처리를 해서 레이트레이싱 처리를 하는 하이브리드입니다.
SSGI는 스크린 스페이스를 기준으로 GI를 처리합니다.
루멘 GI는 레이트레이싱을 제대로 하여 루멘씬을 기준으로 처리하기 때문에 반사 처리를 하면 화면 밖에 오브젝트가 있더라도 잘 처리를 합니다.
스크린 스페이스는 보고 있는 화면을 기준으로 처리를 하기 때문에 화면 밖에 있는 경우는 잘 처리를 하지 않습니다.
그래서 반사 처리 방식은 GI의 성격에 따라 많이 달라집니다.
GI 쪽은 그냥 값이 높으면 좋고 비용을 많이 잡아먹고, 낮으면 퀄리티는 낮아지는데 흐린 눈으로 보면 괜찮고 연산에는 좋구나 이렇게 생각하면 된다고 합니다.
| 항목 | SSGI | 루멘 GI |
|---|---|---|
| 계산 범위/방식 | 스크린 스페이스(뷰 내부) 기반 GI | 하이브리드: Screen Trace + Lumen Scene(서피스 캐시/RT 등) |
| 화면 밖 오브젝트 영향 | 기본적으로 미반영(뷰 밖 정보 없음) | 대체로 반영(씬 기반), 단 Screen Trace 섞이면 뷰 의존성 케이스 존재 |
| 멀티 바운스(디퓨즈) | 제한적(보조용 성격) | 다중 바운스 지향(동적 GI 시스템) |
| 권장 사용 | Lightmass 베이크 간접광 보강 | 동적 GI의 메인 솔루션 |
| 성능 성격 | 보통 루멘보다 가벼움(대신 제약/아티팩트가 본질적) | 비용 큼(콘솔 30/60fps 예산 기준으로 스케일링 가이드 제공) |
| 상태 | Screen Space (Beta)로 노출 | 실사용/디폴트 동적 GI 시스템(UE5 기본) |
엠비어트 오클루전을 수정해도 루멘에는 변화가 없습니다. 전용 뷰로 보면 그냥 하얗게만 나타납니다. 포스트 프로세스 볼륨에 있는 Ambient Occulsion은 SSGI를 위한 기능이라고 생각하면 된다고 합니다.
모션 블러도 설정할 수 있으나 역시나 루멘에서는 변화가 없습니다.
SSGI를 해놓고 조절을 해야 변화가 있습니다. 야외 맵에서는 그 변화가 미미하다고 합니다. 주변 빛이 많아서 일까요?
반투명 처리도 레이트레이스으로 할건지, 레스터(Raster)로 할지 정하는 옵션도 있는데 VFX를 사용할 때는 Raster로 설정한다고 합니다.
PBR이 중요하다면 레이트레이스로 사용하지만 그게 아니면 레스터로 쓴다고 합니다.
포스트 프로세스 머티리얼 항목에서 생성한 포스트 프로세스 머티리얼들을 추가할 수가 있습니다. 이 머티리얼들은 순차적으로 처리된다고 합니다.
포스트프로세스 볼륨의 렌즈 탭에서는 카메라 렌즈와 같은 여러 기능들이 모여있습니다.
Bloom
Chromatic Aberration
Dirt Mask
Lens Flares
Image Effects
Depth of Field(DoF)
Mobile DoF
포스트 프로세스 머티리얼을 통한 라이트 처리
포스트 프로세스 생성
Details -> Post Process Material -> Blendable Location = Scene Color After DOF
기존 머티리얼로는 멀티라이트 처리가 안 되었습니다.
라이트 정보를 가져오는 노드는 Sky AtmoshpereLight Direction인데, 월드에 존재하는 DirectionalLight의 빛 백터를 가져와주는 것이기에 다른 라이트들의 정보를 처리하지 못하는 것입니다.
지오메트리 쉐이더 단계에서 구동한다고 하는데, 이 시점에서 다른 라이팅 정보를 가져오는 것은 어려운 것 같습니다.
포스트 프로세스는 우리가 바라보는 최종적인 화면인 SceneTexture를 가져와서 작업하기에 모든 조명이 이미 계산된 이후라 멀티 라이트가 문제 없이 동작한다고 합니다.
SceneTexture 노드
Desaturation
BaseColor 버퍼는 모든 BaseColor들을 모은 뒤 라이팅 처리해서 저장한 것
PostProcess Input -> Desaturation = 조명 처리된 색들을 회색조로 변경
BaseColor(for lighting) -> Desaturation = 조명 정보가 없는 색상정보를 회색조로 변경
정보량은 조명 정보를 포함하는 PostProcessInput이 더 많음.
for lighting - lighting 처리 시 사용하라는 의미