자체 제작 물리적 기초 렌더링 프레임워크
이번에 제가 만든 렌더링 엔진U22 프로그래밍 대회 2018이 경제산업대신상을 받았습니다!
발표회에서도 발표했지만 주변에서 어렵다거나 잘 모르겠다고 해 해설 기사를 썼다.
자화자찬은 그만하고 바로 해설합시다.
↓ 클릭하여 프레젠테이션 영상 보기
개요
Lightn Renderer Engine은 엔진이라고 쓰여 있지만 실제로는 프레임 레벨입니다.너무 과장했어.(본 보도에서 혼란을 피하기 위해 이름대로 엔진을 부르는 것을 허락해 주십시오.)
모형을 불러오기, 심지어 계산 라이브러리까지 모두 자작한 것이다.
지금까지 Unity와 UnrealEngine을 사용했기 때문에 그래픽 API에 대한 지식은 거의 없다.
한편, 후효과, 면도기와 경량화에 대한 지식은 비즈니스 게임 엔진을 사용하는 토대에서 각종 조사와 실제 사용을 실시한 것으로 모두 지식으로 존재한다.
이번 목적은 비즈니스 게임 엔진이 실시하는 기능을 자기 앞에서 실시하는 것이다.
Direct3D11
OpenGL은 고사하고 Direct 3D 9도 써본 적이 없어 어떤 그래픽 API를 쓸지 고민이지만 가장 주류인 Direct 3D 11을 선택했다.
학습 목적이라서 Direct 3D 12를 해보고 싶었는데 그때 바로 포기했어요.
렌더링 엔진 자체가 단일한 빨간색으로 실행되는 게임 업데이트 → Render는 흔히 볼 수 있는 아쉬움의 실현이다.
컴퓨터 면도기, 기하학 면도기, DrawIndirect 등 Direct 3D 11세대 명령을 많이 활용했다.
렌더링 경로
GPU 메시지 렌더링(GPU 구동 렌더링)
이 렌더링 엔진의 특징 중 하나는 GPU 드라이버 렌더링 부분입니다.
이것은 전통적인 수업에서 그림을 그리는 절차이다.
위의 이미지는 모두 GPU로 처리되며 GPU 제어 렌더링입니다.
일련의 절차
컴퓨터 화면에서 수업을 계산하다.
그리려는 세계 행렬을 쌓을 수 있는 배열AppendStructuredBuffer에 드로잉 목록으로 저장합니다.
그런 다음 ByteAddressBuffer에 각 드로잉이 호출할 때 그려진 메쉬의 수와 색인 버퍼의 오프셋 등을 기록합니다.
왜 세계 행렬을 그림 목록으로 사용합니까? 사실은 인스타그램에 정점 버퍼로 올리고 싶어서요.정점 캐시 효율의 관계로, 비교적 긴 그림 목록을 상수 버퍼로 전송하는 것보다 빠르다.
그러나 AppendStructuredBuffer의 버퍼 형식은 DXGI입니다.FORMAT_R32_UNKNOWN을 지정해야 합니다.
교점 버퍼 생성에 필요한 D3D11BIND_VERTEX_BUFER와 공존할 수 없기 때문에 울면서 GPU 버퍼의 차폐 자원 보기로 건네주었다.
마지막으로DrawindexedInstancedIndirect 명령을 사용하여 그린 메쉬 수 등을 기록한 ByteAddresssBuffer를 매개변수에 전달하여 그립니다.
정점 그림자에서 그림자 자원 보기로 얻은 그리기 목록의 세계 행렬을 SV로 설정합니다InstanceID 인덱스에 따라 정점 변환이 수행됩니다.
이 절차에 따라 CPU가 하는 일은 컴퓨터 스크레이퍼의 시작과 Dr a windexed Instanced Indirect 명령만 부르는 것이다.
For 문에서 메쉬 수를 순환할 필요가 없으므로 동작이 매우 빠릅니다.
복제 처리
모형의 AABB와 시추대의 6평면 판정이 진행되어 카메라에서 보이지 않는다고 판정되었다.
U-22 프로그래밍 대회 지원 때는 아직 시행되지 않았지만, 이후 GPU 아욱 수업도 시행됐다.
구현 방법으로는 먼저 프레임 앞의 깊이 텍스처의 블렌드를 생성한 다음 깊이 값과 AABB를 비교하여 완전히 숨겨지지 않도록 합니다.
UnrealEngine에서도 시행하는 부탄값 교수법이다.여기서 일본어로 이해하기 쉬운 해설을 발견했다.http://darakemonodarake.hatenablog.jp/entry/2014/12/17/000422
다음은 물량을 얼마나 처리할 수 있는지를 보여주는 시연으로 100만 대상을 실시간으로 복제한다.(그림을 클릭하여 프레젠테이션 영상을 재생)
Depth Pre Pass
DepthPrePass는 픽셀의 과도한 그리기를 방지하는 데 자주 사용되지만 GPU 드라이브 렌더링에서는 GPU에서 그리는 순서를 제어할 수 없기 때문에 과도한 그리기가 더욱 현저하게 나타난다.
일부 내부에서 제조된 엔진은 앞에서 어느 정도만 Depth를 그렸고 이번 렌더링 엔진은 전폭으로 Depth를 그렸다.
GBuffer 그리기
Gbuffer의 레이아웃은 다음과 같습니다.
기본 색상은 Bloom 등에 맞게 HDR64비트 형식입니다.
PC에서 시연할 예정이어서 R11G11B10 포맷은 시도하지 않았다.
법선은 사실 R16G16으로 압축하려고 하지만 시간은 (ry)이다
천등
IBL을 사용하여 작성 중입니다.
설치는 UnrealEngine을 참조합니다.
반사광
더 일반적인 평행 광원 조명.
아쉬운 섀도우(USM)도 이뤄졌다.(떡잡어)
Tile Based Culling & 스포트라이트 켜기
천공등과 표시등은 전체 화면에서 진행되지만 점광원과 스포트라이트는 교육 처리를 포함한 불빛이다.
이 일련의 절차도 GPU로 구동되어 많은 불빛을 그릴 수 있다.
먼저 컴퓨터 면도기로 16pxX16px마다 타일을 만들어 그 타일에 몇 개의 등불이 함유되어 있는지 계산한다.
타일을 둘러싼 6개의 평면을 계산한 후 그 평면과 불빛이 교차하는지 여부로 조정한다.
빛을 찍으면 평면의 법선과 반경의 내적이 정이면 교차한다.스포트라이트라면 이 기초 위에서 각도 조건을 더하면 정확하게 처리할 수 있지만 이번 스포트라이트와 점광은 모두 같은 교육 처리...
조금 상상하기 어렵지만 평면과 반경의 내적이어서 실제로는 원형 타일이 아닌 원을 둘러싼 듯한 사각형이다.
자세한 내용은 아래 영상을 보시면 쉽게 알 수 있습니다.
16비트마다 32비트의 배열로 이동한 다음 쓰기 결과를 저장한 다음, 후처리 단계에서 렌더링 대상에 그립니다.
다음은 조명 1000개 정도를 그린 그림이다.(그림을 클릭하여 프레젠테이션 영상을 재생)
후효과
이후 효과는 다음과 같다.
- Bloom
- SSAO
- Vignette
- ToneMapping
블룸은 거리 제곱으로 감쇠하는 축소 버퍼 메모리를 생성했다.
SSIO는 표본 점과 대상 픽셀 높이의 평균 차이를 사용합니다.
ToneMapping은 반대칭 알고리즘을 사용했습니다.http://filmicworlds.com/blog/filmic-tonemapping-operators/
최종 후효과는 1회로 진행된다.
기타
지도 데이터는 Unity 설정으로 Transform 정보를 장면 데이터로 내보냅니다.
모델 데이터는 FBXSDK를 사용하여 별도의 바이너리 형식으로 변환한 후 사용합니다.
제작 기간은 약 7개월.
Reference
이 문제에 관하여(자체 제작 물리적 기초 렌더링 프레임워크), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/LightnGames/items/2d82d90fc09de07e13ee텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)