[Shader study] the rendering technology of lords of the fallen - 발표메모(14.06.23)

Post on 05-Jul-2015

194 views 6 download

description

원본 https://www.slideshare.net/philiphammer/the-rendering-technology-of-lords-of-the-fallen

Transcript of [Shader study] the rendering technology of lords of the fallen - 발표메모(14.06.23)

Shader Study 해강

The Rendering Technology of Lords of the Fallen

The Rendering Technology of Lords of the Fallen은

Deck13의 Philip Hammer가 2014년 발표한 자료

스터디 발표를 위해 적어놓은 메모를 같이 올립니다 메모라 안 친절합니다.

틀린 내용이 있을지도 모르지만 적당히!

원본은 여기로 https://www.slideshare.net/philiphammer/the-rendering-technology-of-lords-of-the-fallen

프로모션 영상

http://www.youtube.com/watch?v=bXFAJOQnwJc

Deck13은 독일의 잘나가는 회사랍니다

지금 작업하는 Lord of the Fallen은 3인칭 액션에 ps4, xb1, pc로 나올 거고 CI랑 같이 만들어서 2014년에 출시!

처음에는 PS3/XB360 작업 하다 보니 차세대기로 이동, 컨텐츠 변화 기술적 변화도 있었는데 ○ Light-Prepass방식에서 디퍼드 렌더링으로 지원(Prepass는 라이트버퍼,프레임버퍼 들고 있는거…) ○ DX9 지원 포기는 많은 자유를 줬다! ○ 많은 멀티 스레딩 기능

오늘 볼 내용들은 이렇다 우리가 디퍼드 랜더링에 접근한 방식 디퍼드 물질의 매개 변수 버퍼를 설정한 방법 디퍼드 파티클 라이팅 방법 그리고 투명 그림자, 볼륨 조명, gpu 파티클을 짧게 보자

light-prepass에서 전통적인 deffered rendering으로 변화 이를 통해서 두번째 지오메트리 패스를 제거했다 지오메트리와 api의 오버헤드는 콘솔에서 끔찍했다 메모리 양과 대역폭도 좋아졌다 더 많은 랜더타겟 메모리 여유가 생겼다 (반사, 안개, 그외) 오브젝트별 쉐이더에서 디퍼드 영역으로 많은 효과를 이동했다

우리는 조명을 더 많이 자유롭게 쓰기를 원했다 ○ 앰비언트 스팩큘러를 위한 IBL, 지역 큐브맵 ○ 반투명은 더이상 해키코너 케이스(지글지글한 것?) 안 된다 ○ 투명 개체는 조명과 투명 그림자를 받아야 한다 ○ 동적 글로벌 일루미네이션 우리는 Geomerics Enlighten 미들웨어에 의해 생성 된 동적 방향 조도 라이트 맵을 사용

● 최소한의 G-버퍼 렌더링 (dx10 포멧들 인텔은 리틀엔디안 뒤에서부터 저장abgr, 10:10:10:2 랜더 포멧으로 알파블렌딩, 필터링,멀티샘플링 모두 지원. 24비트 깊이버퍼 8스텐실 총 128비트펄픽셀) ● L-버퍼 렌더링, 별도의 확산 + 반사 조명 ● 디퍼드 반사 랜더링은 여러 환경 프로브 큐브 맵 + 화면 공간 반사 ● 렌더링 패스를 결합 - 복합 알베도, 특별한 색, 조명, 반사 ● 투명한 객체, 디퍼드 안개, 후처리 랜더링

● 가능한 한 여전히 작아야한다 ● 매개 변수 인코딩 ○ 2 채널 법선 ○ 알베도 + 반사 컬러 컴팩트 YCoCg(샘플링방식) [Mavridis12], 크로마(채도) 성분을 추가 ○ 매개 변수 포장 - 하나의 비트를 포장하고 몇 가지 속성에 대한 낮은 정밀도를 사용 ○ 상호 배타적 인 매개 변수에 의한 공유 채널(각각의 변수가 공유하기 위한 채널) 매개변수를 참조하는 메테리얼 id/index 필요, XB1 ESRAM 에도 적합해야 함

luma 광도(빛에서 수직 통과하는 양) irradiance 방사조도(무엇에서 나오는 빛의 양) translucency 반투명 컬러 스팩큘러와 투명화는 전용의 상호작용 재질id에 의해서 결정된다

1비트는 mrt1인지 아닌지 알아내는데 사용, 투명 또는 스펙채도 7비트는 메테리얼 파라메터 버퍼 참조 사용

소스를 보시면 인덱스를 가져와서 반환하는 방식

스텐실은 마스킹(일부만 대충 씀) 해서 사용 3비트는 데칼, 반사, 피부 2비트는 라이트볼륨 스텐실

● 단지 몇 개의 개체에 영향을 미치는 다른 특성은 별도의 패스에서 랜더링 ○ 부드러운 알파 테스트에 대한 접선 ○ 개체 별 림라이트, 방사 / 발광 및 기타 FX ○ motionblur에 움직이는 물체의 모션 벡터 스태틱 오브젝트를 위한 벡터는 깊이버퍼 ( "카메라 motionblur")를 다시 투영에 의해 계산한다 ○ 포스트 왜곡에 대한 왜곡 - 벡터

● G-버퍼가 가득 찼을 때 메테리얼 파라메터를 추가하려면 무엇이 필요한가? ○ G-버퍼 사이즈는 항상 옵션에서 증가하는 것은 아니다 ○ 정보는 전체 메테리얼에서 가끔만 필요할 뿐이다, 반드시 모든 픽셀에 필요한건 아니다 ● 예 ○ 반사-매개 변수 (강도, 프레넬) ○ 지하 산란 매개 변수 (왜곡, 색조), 그외 기타 등등

● 우리는 물자 매개 변수 버퍼로 해결 ● CPU에서 모든 프레임 버퍼 생성 및 빛, 반사 쉐이더에 바인딩, 재질 매개 변수에 대한 조회 테이블 ■ DX9 : 복수의 1 차원 RGBA8 텍스처, DX11 : 재료와 구조 버퍼 ○ 메테리얼을 위한 파라메터 저장, 메테리얼 색인에 의해 색인 (G-버퍼) ■ 프레임 당 128개의 서로 다른 재질에 인덱스를 읽을 수 있다, 7 비트, 자료-ID 용으로 예약 1 비트 ■ 매개 변수를 설정해 각각의 드로우콜 결정 ● 스마트 값 양자화 및 인터리빙(복수 분할 접근?), 디퍼드 렌더링을 위한 더 많은 재질 종류 가능

● 서브서피스 산란 / 후방산란 [Brisebois12]에서 영감 ● 디퍼드 랜더링의 일부 문제 ○ 표면당 너무 많은 매개 변수 ○ 빛 마다 다른 파라미터 설정을 둘 수 있지만 융통성발휘(흰색 빛 필터를 쓰거나 오브젝트 색깔을 다르게) ● 우리는 픽셀 당 하나의 스칼라(방향 없고 하나의 수치로) 투명감 값 저장 ● 다른 매개 변수는 (프레넬 매개 변수 및 색조 같은) MP-버퍼에 저장, 메테리얼에 따라 달라질 수 있음

Mrt0의 a에 들어간다 메테리얼id / 룩업테이블 인덱스 / 구조버퍼

소스는 이렇다

● 4 가지 빛 유형 : 방향, 점, 반점, 상자 (지역 광선) ○ 현재 레벨 당 약 500 동적 라이팅 ○ 대부분은 애니메이션 고보 - 텍스처 및 그림자 캐스팅을 갖추고 있다 (gobo 차광판? 원하지 않는 빛 연산을 빼는 특정 재질을 뜻하는 듯) ● L-버퍼에 클래식 라이트 볼륨 축적 ○ 대형 조명에 대해서 양면 스텐실 마스킹 선택, 타일 디퍼드는 현재 개발 중

● 색상을 위한 L-버퍼 ○ 간접 조명 ○ G-버퍼 단계에서 다 채워 넣는다 ○ 정적 객체에 대한 방향 조도 라이트 맵 ○ 동적 객체에 대한 SH lightprobes ○ 우리는 Geomerics Enlighten을 사용

● 색상을 위한 L-버퍼 ○ 직접 색을 넣고 + 반투명 빛을 축적

○ 반사 빛 누적

○ 스펙큘러 L-버퍼와 공유 ○ 정적 반사 (간접 반사 조명) ○ IBL을 지역화하고 큐브 맵으로 오류 조절[Largarde12] http://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/ ibl 빛행렬에 영향 받아 반사된 이미지(무한반사 환경맵과 차이)

● 환경 프로브 ○ 90 ° FOV와 1:1 화면 비율로 6 "스크린 샷"(원시 RGBA16_F)를 만든다. 후처리, GUI는 건너 뜀 ○ 6 스크린 (256 × 256 × 256 / BC6) 으로 큐브 맵 만든다 ○ ATI CubemapGen API의 밉맵 체인 + 엣지 오류 복구 필터를 사용 ○ BRDF가 완전히 일치하지는 않지만, 그런 곳은 아티스트가 보기 좋게 터치 ● 모든 반사는 하나의 전체 화면 패스 [Drobot12]에서 수행 ○ 8 가장 영향력있는 ENV - 프로브를 수집하고 하나 또는 그 이상은 ENV 프로브의 AABB 내부 확인

● 마지막 프레임 ○ 복합 ○ 부피 광산란 ○ 투명 개체 ○ 후처리

● 우리는 빛나는 파티클을 원한다 ○ 씬에 알맞는 통합 ○ 다른 조명 아래에서 또는 그림자 재사용 입자 효과

● 입자의 일반적인 유형 : 대기, 연기, 먼지 및 안개 효과 ○ 일반적으로, 투명, 밀도 … 그리고 오버가 많이 발생함 ○ 따라서 모든 조각에 빛 연산 할 때는 비용 폭발 ○ 방향이 없는 저주파 정보 사용, 완벽한 정점 라이팅 ● 디퍼드 정점 조명 ○ 영향을 주는 빛과 그림자의 수에 타협할 필요가 없다, 디퍼드 파이프 라인에 완벽하게 적합

● 1 단계 : 비 화면 공간 입자를 랜더링 하는 "G-버퍼" ○ 기본적으로 순차 목록 ○ 점 목록으로 입자의 정점 버퍼를 랜더링 ○ 이후 버퍼에 입자의 래스터를 넣고 뷰스페이스 위치로 레스터라이즈(전환) ■ 현재 보이는 모든 조명 파티클들을 위한 1024x512의 RGBA16F 텍스처 ○ G-버퍼는 현재 정점의 위치만을 포함 ■ 투명 또는 노말을 통해 더 많은 표면 속성 확장이 가능(빌보드 입자를 너무 많이 만들지 않았다)

● Step 1: 비 화면 공간 입자 "G-버퍼"를 렌더링 ○ 버텍스 쉐이더 및 래스터의 다음 리스트 인덱스를 계산 ■ 현재 SV_VertexID을 기반으로 하되 이전에 렌더링 된 입자는 쉐이더 상수 vertexCountPerInstance로 계산 ■ 인스턴스(기존것)화 된 파티클을 사용하는 경우, SV_InstanceID 추가 감안 param_vertexcount 는 정점의 현재 랜더링 번호를 가진 상수

● 2 단계 : 일반 디퍼드 조명과 유사한 조명을 적용 ○ 라이트 볼륨 대신 전체 화면 네개, 조각이 공간적인 관계가 없기 때문에, (비 화면 공간 조각 -리스트) ○ 다른 빛 유형, 그림자, 투영 텍스처 등은 "그냥 작품" 생노가다란거지 ○ 매우 간단한 "조명 모델" ○ 섀도잉 : 큰 커널 폭 PCF 그림자 / 라이트 전환 깜박 거림이 감소 ○ 최적화 : 당 정점 G-버퍼에있는 각 조각을 스텐실 마스크

다음은 메테리얼 ● 3 단계 : 적용 조명 입자를 랜더링 ○ (G-버퍼 단계와 동일) 정확한 랜더링 순서를 부탁해 ○ 샘플 입자 L-버퍼 vertexshader ○ 라이팅보간은 플래그먼트 쉐이더와 모듈에서 파티클 텍스쳐로 쉐이더를 조각화 및 입자 질감으로 조절하는 조명 보간

결론적으로다가 ● 그레이트하게 많은 종류의 파티클, 저렴하고 효과적으로! ● 모든 정점 당 기술의 문제를 상속, 낮은 공간 해상도 ● 작은 파티클은 짱짱 ● 입자의 한 모서리가 갑자기 불이 되는 경우 매우 작고 밝은 빛이 깜박 거림을 초래할 수 있다 ● 많은 빛나는 파티클이 가져오는 버퍼 오버 플로우 주의

● PSSM을 위한 Shadowmask ○ 화면 공간에 있는 누적 cascades, 깊이 보존한 가우스 블러, 4 가지 단색 그림자 소스 축적 가능 ● 각 빛은 색의 투명한 그림자를 캐스팅 할 수 있다 ■ 어떤 객체를 알파블렌드 랜더링 할 때 그림자맵 사이즈를 특정 객체에게 렌더링 shadowmap 크기 RGBA8 버퍼에 알파 혼합 ■ 깊이 버퍼로 shadowmap 사용, 라이팅을 곱해 RGBA8 버퍼 샘플, 볼륨, 파티클 라이팅 원활 ○ 문제 : 쉐도우 마스크는 쉐도우 소스를 하나 줄임, 셀프 쉐이더가 정확하지 않지만 큰 이슈는 아니다

● 모든 라이트는 투명그림자에 대해 깊이 테스트를 캐스팅 할 수 있다 (그림자가 자연스러워지게)

볼륨 조명이나 투명 파티클, 기타등등 마찬가지

● 자세한 내용은, 어제 Benjamin Glatzels 이야기를 참조 ● Raymarching이 빛의 뷰 공간에서 shadowmap을 평가하는 동안 (레이트레이싱은 레이와 프리미티브가 교차한다고 가정, 이게 불가능할 때 Raymarching 개체와 가장 가까운 거리를 추정해서 계수에 따라 반복 장점은 엠비언트 오클루전 같은게 거의 무료 ○ 또한 프로젝터와 질감을 평가, 투명 그림자, IES 라이트 - 프로필, 잡음 볼륨 텍스처 등 ● [Toth09]가 제시 한 기술을 바탕

짱이지?

그래 우리는 gpu 파티클 엄청 잘해 컴퓨트 쉐이더는 큰 규모의 파티클도 처리해줘 화면공간 충돌은 깊이버퍼로 테스트해 (파티클이)서로 다른 속성의 타입이 많아 미리 만들어놓은 3d 벡터 필드와 다른 유형의 필드 타입을 드리븐해서 써

이거 영상은 구할 수가 없네…

○ 우리는 이미 PBR의 renderpath을 가지고 있지만, 이미 많이 만들어서 LotF에 포함되지 않았다 ● 순수 Z-prepass을 다시 소개 ○ G-버퍼, 오버드로우를 감소하고 함축적으로 알파 테스트를 전체 깊이 테스트 = 동일 ○ 데칼의 도움 ● 도구, 도구, 도구 ○ 최적화 된 워크 플로우, 더 나은 툴로 반복 작업 시간은 꺼져~ 그래픽 효과보다 더 중요