Genshin impact Rendering pipeline flow
https://blog.kelu.org/japanese/2021/07/26/mhy.html
Mobile은 아니고 PC/console쪽으로 보임.
1. Genshin impact Rendering Process
multiple light를 사용하는 deferred Rendering을 기반으로 하고 Forward Rendering이 혼합된(반투명 처리등을 위한) 대규모 맵 렌더링 파이프라인으로 AAA에서 흔히 볼수 있는 Hi-Z Culling, SSR, Temporal AA, Cluster Lighting이 모두 가능하다.
2. Genshin Impact의 Key Steps and special effects
2.1 Genshin impact scene rendering
Genshin Impact의 scene 렌더링은 매우 전통적인 PBS 프로세스를 사용하며 대부분의 scene 모델은 디퍼드 렌더링으로 이루어짐. 이 scene은 GPU 컬링을 위해 Hi-Z를 사용하는 장면으로, 시야가 매우 과장되어 있으며, Qingyun 정상에 서면 몇 킬로미터 떨어진 Monde 시가 어렴풋이 보이게 된다.
건물과 일부 터레인에서 Genshin Impact는 parallax map을 사용하여 보다 3차원적으로 보임.
Genshin Impact는 PS3의 The Last Survivor에서 사용한 것과 유사한 ellipsoid directional shading을 사용하여 캐릭터의 indirect shadowing을 구현.이 방법은 기존 SSAO와 비교하여 side perspective에서 더 나은 결과를 얻을 수 있다.
원신의 땅에 드리워진 구름 그림자는 일종의 데칼 같은 접근으로 땅에 드리운 구름 그림자가 하늘의 구름과 일치하지 않는다는 것을 쉽게 발견할 수 있다.
원신에서 반사를 표현하는 방법은 크게 두 가지가 있는데, 첫 번째는 건물과 같은 물리적인 씬에 SSR과 Cubemap을 혼합하는 방식이며, SSR은 이전 프레임의 렌더링 결과를 반사된 오브젝트로 읽어서 빛의 다중 반사 효과를 얻는다. 큐브맵이 매 프레임 업데이트 되는 것 같지는 않지만1 캐릭터의 위치 변경과 관련이 있는데, SSR에서 큐브맵으로 전환하는 과정을 몬드시티 교회에서 잘 볼 수 있다.
물의 표면은 평면 SSR을 사용하지만, 오브젝트와 수면 사이의 인터페이스가 잘 처리되지 않고 명백한 렌더링 오류가 있다.
또한 Spherical harmonics 기반 스카이 라이팅도 사용되며 SSR과 혼합되어 특정 GI 효과를 얻는다.
2.2 Genshin impact Character Rendering
원신의 캐릭터 렌더링은 G-Buffer에서 캐릭터의 최종 음영을 Diffuse로 렌더링하기 위해 직접 포워드 렌더링을 사용. 즉, 캐릭터의 조명은 LDR에서 계산되며 캐릭터의 조명 알고리즘은 Honkai Impact 3의 조명 알고리즘과 거의 동일
캐릭터의 주변 조명 노출은 이전 프레임의 ambient sensor texture를 읽어서 계산. 어떤 이유로 캐릭터의 빛 노출이 보간되지 않아 캐릭터가 그림자 가장자리에 있을 때 빛이 점프하고 캐릭터가 고속으로 이동할 때 눈에 보이는 지연이 있음.
2.3 Genshin impact Rendering
Genshin Impact의 PC 버전은 특수 효과 측면에서 그다지 언급할 것이 없지만, 모바일 측의 Genshin Impact는 특수 효과를 위해 반해상도 최적화를 사용하고 투명 파티클은 반해상도로 계산되어 Alpha Blending의 오버헤드를 크게 줄인다는 점을 언급할 가치가 있다.
또한, 원신의 구름과 특정 각도의 빛은 레이 마칭을 이용하여 단순한 패치가 아닌 볼륨 효과를 구현.
3. 겐신 모바일 최적화
최적화를 위해 대부분의 Android 기기는 긴 면에서 1280픽셀을 초과하지 않는 3D 해상도로 Genshin을 실행하므로 이미지가 매우 흐릿하게 나타나며 TAA를 사용하면 도움이 되지 않습니다. 이동 단말기에서 Yuanshen에 의한 투명 개체의 절반 해상도 렌더링은 일부 모델의 반투명 RT 와이드 면에서 288픽셀에 불과합니다.
많은 다운 해상도 렌더링을 사용하고 많은 화면 공간 효과를 삭제 한 후에도 Genshin Impact의 성능은 여전히 매우 좋지 않으며 어떤 모바일 SoC도 Genshin Impact를 60FPS에서 오랫동안 안정적으로 실행할 수 없습니다. Yuanshen 모바일 터미널의 최적화가 좋지 않은 이유는 다음과 같습니다.
- 지연된 렌더링을 사용하면 깊이 사전 통과도 수행되며 지형만 그리는 것이 아니라 DC와 대역폭을 낭비하게 됩니다.
- 지연 렌더링은 Frame Buffer Fetch 또는 SubPass를 사용하지 않고 MRT 하드 드로잉을 직접 사용합니다.
- G-Buffer는 저장하지 않으며 대역폭 오버헤드가 너무 큽니다. 계산된 디퓨즈와 스페큘러를 직접 저장하고 노멀은 압축을 하지 않아 최소 32비트 대역폭을 낭비한다.
- 게임 플레이와 무관한 바위나 초목과 같은 지형 부착물의 렌더링이 너무 크고, LoD가 너무 보수적이어서 GPU Culling을 사용하더라도 여전히 DrawCall(수천 번)이 너무 많고, 매우 심각한 쿼드 오버드로.
- 저해상도 렌더링 후 업샘플링에는 추가 성능 오버헤드가 있어 TBR 및 TBDR용 GPU에서 역 최적화가 발생할 수 있습니다.
그 중 1 2 3 5는 그래픽 기술과 관련이 있고 4는 예술 및 기획과 관련이 있습니다.
결론적으로 겐신임팩트의 렌더링 파이프라인은 국내 친구나 사업가들에게 어느 정도 참고할 만한 가치가 있지만 그렇게 가치 있는 것은 아니다. 그래픽 기술은 빼기의 예술인 제품의 예술적 스타일과 일치해야 합니다. Genshin Impact의 PBS 소재와 초대형 시청 거리 렌더링은 이러한 셀룰로이드 만화의 아트 스타일에서 매우 불필요합니다.
그런 점에서 겐신임팩트의 그래픽 기술은 매우 가성비가 좋다.두 가지 측면에서 낮다.첫째, 자본 투자에 비해 최종 영상 효과가 맞추기 어렵다.둘째, 성능 오버헤드가 너무 커서 모바일 장치가 원활하게 실행되기 어렵습니다.
그리고 이 낮은 비용 성능은 서구의 성숙한 대규모 게임 파이프라인과 관련이 있습니다. Yuanshen은 3년 만에 서구에서 15년간의 대규모 게임 산업화를 완료했으며, 반복된 시행착오와 구덩이를 밟는 것은 Yuanshen의 높은 비용을 초래했을 수 있습니다.
친구나 사업가가 겐신과 경쟁하는 군비 경쟁에 참가한다면 겐신의 경험을 흡수하지 못하면 같은 자원으로 겐신보다 잘하기 어려울 것입니다. 친구나 상인들은 미하유처럼 안정적인 사용자 기반이 없고, 이렇게 큰 생산량으로 수익을 내기 어렵습니다.
현지 보스가 Yuanshen의 높은 수익성을보고 Yuanshen과 같은 대형 생산을 따라 현지 보스의 파산을 가속화한다면 "강제 산업을 더욱 세련되게 만드는"과정 일 수도 있습니다.
Unity Unite Seoul 2020 세션 다시보기 - 원신 콘솔 플랫폼 개발 및 렌더링 파이프라인 기술 소개
요건 Recap 방송한거. 이 자료 준비한다고 꽤나 열심히 봤는데 마지막의 PS4에서의 HDR쪽은 많이 부족했다.
https://youtu.be/t0rOOs1701o
CPU나 I/O에 대한 내용은 NDA때문에 다루지 않음.(이부분에서 최적화도 있었을 것으로 추정)
모바일/ 콘솔 : 기본 파이프라인은 동일. 모바일이 먼저였으나 결국 비슷하게 개발 시작.. 모든
24h. 다이나믹 동적 라이팅,
- Time of day
- Dynamic weather
렌더링 1440p. Output 1080p
Compute shader 최대한 활용
아트팀 요구.
We kept these 2 groups of words in mind at all times.
엔진 자체도 모바일 기본이라 수정 필요(커스텀 빌드로 추정)
TRC(Technical Requirement Checklist). Sony build 심사 프로세스.
연구에 많은 시간이 필요한 기능은 제외. 짧은 기간내에 내부에서 검증된 기술을 주로 사용.
PS4 Specification
Main processor : Single-chip custom processor, CPU : x86-64 AMD “Jaguar”, 8 cores
GPU : 1.84 TFLOPS, AMD Radeon™ based graphics engine
Memory : GDDR5 8GB
Networking : Ethernet（10BASE-T, 100BASE-TX, 1000BASE-T）×1, IEEE 802.11 a/b/g/n/ac, Bluetooth®v4.0
Power consumption : Max. 165W
HDMI™ out port (HDR output supported)
Devkit : https://www.techpowerup.com/gpu-specs/sony-playstation-4-pro-devkit-gpu.b6385
Shaders / TMUs / ROPs
PS4 : 1152 / 82 / 32, Devkit : 2034 / 144 / 64(PS4 Pro와 동급)
Tech Details
Shadows
* Shadow quality
* High quality and covering a far distance shadow casting(800m)
* CSM + poisson noise soft shadows.(포아송분포를 사용한 셰도우 처리)
- http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/#aliasing
- Poisson sampling(4번 샘플링해서 PCF와 같이 사용한것과 16번 샘플링으로 처리한 방식 두개에 대한 소개)
- Stratified Poisson sampling(계층화된 포아송 샘플링)원신에서는 계층화된 포아송 샘플링을 Rotated Poisson을 사용해 스크린 공간에서 각각 11번씩 샘플링해서 노이즈 소프트 셰도우를 계산
* 8 cascade shadow map(increase CPU and GPU cost 증가 only PS4)
* 4개는 매 프레임 업데이트, 나머지 4개는 8프레임 마다 업데이트 >> 5번으로 줄임(DP 감소)
* GPU side : Poisson noise soft shadow계산을 GPU 사이드에서 처리. 모든 셰도우에 대해서 이렇게 처리 하지 않고 셰도우 마스크를 생성해 셰도우 가장자리의 셰도우에만 적용.이로 인해 2~2.6ms >> 1.3~1.7ms으로 감소
* Mask texture generation 최적화. ¼ sampling으로 셰도우 마스크 텍스쳐에 블러를 추가하고 셰도우 영역을 확장(0.3ms)
Ambient Occlusion
* 3가지 방법을 상황에 맞게 사용
* HBAO(Horizon Based Ambient Occlusion)
- 2008년 시그라프에서 nvidia가 공개. 뎁스버퍼 샘플링과 적분을 근사화하는 물리기반 알고리즘을 사용해 AO를 표현하는 방법. 무겁기 때문에 보통 절반의 해상도로 렌더링해서 사용함(배틀필드 2, 3의 케이스)
- https://www.nvidia.com/en-us/geforce/technologies/hbao-plus/technology/
- http://guitarjawa.net/?page_id=789(가장자리 깜빡임 예시)
- 향후 HBAO+로 개선. 3배더 빠르고 세부 디테일은 두배로 높아짐.(DX11기반)
* AOVolume
- Tabletop can large AO on the floor
- https://www.gdcvault.com/play/1015320/Ambient-Occlusion-Fields-and-Decals Nathan Reed GDC2012
- AO mesh에 대한 pre-bake 정보 필요(Baked shadow map은 사용하지 않는것으로 보이고 모두 realtime으로 처리하는것으로 보임. 성대님 voxel shadow mapping과 접근은 비슷)
* CapsuleAO
- Realtime contact shadow character within envi.
- The order 1886 시그라프 2015 발표 자료 : https://forum.beyond3d.com/threads/the-order-1886.54378/page-71
- 이를 바탕으로 두가지 ambient occlusion을 계산. Long direction과 occlusion directional approximate direction. 이를 기반으로 블렌딩해 소프트 셰도우 구현
* 모든 AO pass가 ½ ½ 로 계산. 2개의 패스 블러와 1개의 업 스케일링 패스. = 멀티플 AO read and write.
* Complete the compute shader in a single pass
Local Lighting
* 클러스터 디퍼드 라이팅을 구현. 1024개를 한씬에서 표현
* 4K 해상도에서 64x64로 나뉘고 방향에 따라 16개의 클러스터로 구분
* Local lighting shadow
- 약 100개의 그림자 캐스팅이 가능한 라이팅 지원
- 우선순위는 거리에 따라 자동으로 조정.
- Staic 오브젝트와 다이나믹 셰도우가 프레임마다 혼합해서 처리.
- 셰도우 텍스쳐의 경우 BCn으로 압축해서 처리(Block compressed)
- 아티스트가 압축 방식을 결정.
- Bo Li A scalable realtime many shadowed light rendering system - Siggraph 2019
- https://dl.acm.org/doi/10.1145/3306307.3328167
- 정밀도를 높여서 그림자 품질을 높임.
Volumetric Fog
* Project texture를 추가해 볼류메트릭 라이팅의 표현을 늘림(Projection Decal처럼.. IES랑은 다름)
* PS4 Pro(1ms 미만)
* GodRay
- 별도의 패스를 사용해 갓레이 사용(God Ray pass)
- 분리된 패스로 연산. ½ x ½ 로 사용
- 굳이 다른 패스를 사용하는 이유는?
- 복셀 해상도가 부족
- 눈에 잘 띄는 빛줄기를 표현하기에는 볼류메트릭 포그 밀도에 의해 좌우되는데 이는 너무 지저분하고 명확치 않음.(후에 이미지로 설명)
Image Based Lighting
* Reflection probe & Ambient Probes
* Reflection Probe
- 렌더링을 위한 반사 데이터를 제공
- 미니 Gbuffer를 생성해 런타임시 미니 Gbuffer에서 생성
- Relight, convolve, then compress >> based on compute shader
- BC6H로 압축
* Ambient Probe
- 반사 프로브 처리 이후 진행. SH로 저장되며 역시 컴퓨트 셰이더로 생성
* Interior marks(indoor and outdoor 구분)
- 실내외의 GI를 통해 구분이 명확하게 보이도록 설정
* SSR 사용 PS4기준 1.5ms
* Temporal filter 사용
* Hi-z 버퍼를 생성해 SSR패스에서 사용.
HDR Display
* PQ ST 2084.
- SMPTE ST 2084는 HDR 영상을 구현하기 위하여 돌비에서 개발한 EOTF다. 인지 시각 양자화 (Perceptual Quantizer; PQ)라고도 불린다.
- https://namu.wiki/w/SMPTE%20ST%202084
* 대부분의 HDTV에서 지원한는 색역은 Rec. 709 이므로 전체 색공간의 35.9%만을 표현
* RRT+ODT
- RRT(Reference Rendering Transform) : scene-referred-colorimetry(씬 기반의 색측정법)를 display-referred로 변환하고, 전통적인 필름 이미지 렌더링과 유사하게 S자 커브로 변환합니다. 모든 출력 장치(아직 존재하지 않는 장치도 포함)로 렌더링 할 수 있도록 더 넓은 gamut(색역)과 dynamic Range(를 사용할 수 있습니다.
- ODT(Output Device Transform) : 넓은 색역(a large gamut)과 와이드 dynamic Range를 제한된 색역과 dynamic Range로 물리적으로 실현될 출력장치로 렌더링 하기 위한 가이드 라인. ACES 지침에 따라 제조업체에서 생성할 가능성이 있는 ODT가 많이 있음.
* WCG(World Wide Gamut) : 광색역
* OETF(Opto Electronic Transfer Function) : relative-scene(상대적인 씬)의 linear light를 non-linear 신호 값으로 매핑하는 함수.(linear to non-linear)
* OOTF(Opto-Optical Transfer Function) : 광-시각 전달함수(linear to linear)
* EOTF (Electro-Optical Transfer Function; 전기-광학 전달 함수)는 광학적인 밝기 정보와 전기적인 정보 간의 상호변환 관계를 정의한 함수이다. 이미지에 있는 픽셀의 색상 값에 대응되는 밝기 정보를 출력하거나 그 반대로 밝기 정보를 이미지에 있는 픽셀의 색상 값에 저장하기 위하여 사용된다.
- EOTF에서 어떤 것을 사용하느냐에 따라서 SDR (Standard Dynamic Range; 표준 다이나믹 레인지)과 HDR (High Dynamic Range; 높은 다이나믹 레인지)로 갈리게 된다. 디스플레이 및 영상 분야에서 다이나믹 레인지는 명암비보다는 구현 가능한 최대 휘도값을 지칭한다.
- https://namu.wiki/w/EOTF
- SDR이라고 불리는 영상 소스 및 장비는 sRGB이나 BT.1886 함수를 사용하고, HDR이라고 불리는 영상 소스 및 장비는 ST.2084 함수나 HLG 함수를 사용한다
* Hue shift issue
- HDR does not has tone mapping.(orange to orange)
- 다른 게임의 경우 BlackBody를 사용해서 해결.
- 에셋에 대한 수정 필요가 없음
- Shader에서 hue shift 시뮬레이션 방식을 사용해서 해결. 컬러룩업 생성 패스에 결합.
Reference
⭐Poisson sampling http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/#aliasing
⭐AO volume. Nathan Reed GDC2012 https://www.gdcvault.com/play/1015320/Ambient-Occlusion-Fields-and-Decals
⭐Capsule AO. The Order 1886 Siggraph 2015 https://forum.beyond3d.com/threads/the-order-1886.54378/page-71
⭐Bo Li A scalable realtime many shadowed light rendering system - Siggraph 2019 https://dl.acm.org/doi/10.1145/3306307.3328167
⭐ST 2084 https://namu.wiki/w/SMPTE%20ST%202084?from=ST%202084
- frame rate에 따라 script에서 임의로 update 주기를 설정할 수 있다 [본문으로]