SlideShare a Scribd company logo
Hierarchical Z Map Occlusion
           Culling
          유영천
         KASA Study
Occlusion Culling
• 가려진 물체를 그리지 말자.
• Occluder가 Occludee를 가림
Occluder

 Occludee




Occludee
Simple Occlusion Culling
• 디자이너가 맵에 Plane(판대기) 배치
• 런타임에 카메라의 Eye포인트와 판대기를
  연결한 뷰프러스텀 계산-Near Plane은
  Occlusion면이 되어야함.
• 이 뷰프러스텀에 들어가는 오브젝트는 렌
  더링 안함.
• 은근 실제 게임에 많이 쓰인다.
장점
• 구현이 쉽다.(프로그래머한테 쉽다)
• 효과는 매우 확실!
단점
• 구현하기 귀찮다어렵다.(디자이너한테 어
  렵다)
• Occlusion을 정밀한 단위로 만들 수 없다.
H/W Occlusion Culling

• Occluder가 렌더링 된 상태에서 (Z-Buffer
  를 유지한 상태에서) Occludee를 렌더링 g
  하여 정말 그려지나 테스트.
• D3D9에서부터 표준적으로 지원.
• 물론 D3D9 디바이스에서도 지원 안하는 놈
  이 있다.
• D3D11 API에서도 D3D9 API와 비슷한 형
  태로 지원함.
원리
• Occluder(raw맵 데이타나 거의 꼭 맞는 바
  운딩매쉬)를 그려서 Z-Buffer를 구성한다.
• Occludee(아마도 캐릭터나 맵데이타,기타
  배치 가능한 오브젝트)를 그리되 pixel은
  write하지 않고 z-test만 한다.
• 그려지는 픽셀 수를 GPU측 메모리에 기록
  해둔다.
• 나중에 GPU로부터 픽셀수를 얻어온다.
HW Occlusion Query @D3D9
•   // Initialize
•   LPDIRECT3DQUERY9 Query
•   pDevice->CreateQuery(D3DQUERYTYPE_OCCLUSION, &pQuery);


•   // Begin Test
•   pQuery->Issue(D3DISSUE_BEGIN);

•   //
•   // Drawing
•   //

•   // End Test
•   pQuery->Issue(D3DISSUE_END);


•   // 실제로 렌더링된 픽셀 수가 dwPixelCount로 저장되어 나옴.
•   DWORD dwPixelCount = 0;
•   pQuery->GetData(&dwPixelCount,sizeof(DWORD), D3DGETDATA_FLUSH);
장점
• 구현이 쉽다.(프로그래머한테 쉽다.)
• 구현이 쉽다.(디자이너는 할 일이 아예 없
  다.)
단점
• 성능이 별로다.

•심지어 더 느려지기
 도 한다!!!
왜 성능이 안나올까?
• DrawCall 회수를 줄이지 못한다.(멀티패스
  로 오브젝트를 그리는 경우는 제외)
• 두번 그려야 하므로 쉐이더에서 엄청나게
  부하가 걸리지 않는 이상 더 빨라질리가 없
  다. 더 느려진다.
• Occludee의 크기가 커질수록 Z-Test 회수
  도 많아진다. Z-Test
• 픽셀 수를 받아올때 PCI버스를 타고 GPU
  Memory-> System Memory로 가져온다.
Hierarchical Z Map Occlusion
              Culling
• 정말 그려지는지 테스트-기본 아이디어는 같다.
• Occluder와 Occludee가 꼭 정밀해야하는가? 간단한 매
  쉬(경계구)로 대치하자.
• 그렇다면 Z-Buffer의 해상도도 정밀할 필요가 없다.
• 낮은 해상도의 Z-Buffer를 사용하면 Z-Buffer의 읽기/쓰
  기 시간을 줄일 수 있다.
• 경계구 가지고 테스트할건데 실제 그려볼 필요나 있을
  까? 아예 그리지도 말고 구의 한 점만 프로젝션 해서
  depth값을 비교하자.
• 직접 버퍼에 그릴 필요가 없다면 Pixel Shader쓸 필요
  도 없으니 Compute Shader로 경계구 하나마다 스레드
  를 할당해서 depth테스트를 병렬화 시키자.
기본전략
• screen space에서 Occludee를 대표하는 한
  점과 Occludee가 그려질 영역의 depth값을 비
  교.
• Occludee의 크기가 크면 Z-Buffer해상도는 낮
  아도 된다.
• Occludee의 크기가 작으면 Z-Buffer의 해상도
  가 높아야 한다.
• Occludee의 크기에 따라 가능하면 작은 크기
  의 Z-Buffer를 억세스한다.
• 기준은 Occludee가 screen space에서 2x2텍
  셀에 맞아들어가는지.
극단적으로 오브젝트 크기가 이 정도면 Z-Buffer의 해상도는 2x2로 충분



                     Occludee




 Z-Buffer
오브젝트 크기가 이 정도면 Z-Buffer의 해상도가 충분치 않음


                           Occludee




Z-Buffer
오브젝트 크기가 이 정도면 Z-Buffer의 해상도는 4x4가 적당




Z-Buffer              Z-Buffer
왜 2x2?
• screen space 상에서 항상 Occludee가 그려
  지는 영역 전체를 커버할 수 있는 사이즈.
• 1x1일 경우 screen space에서 Occludee가 텍
  셀의 경계에 걸칠 경우 잘못된 depth비교를 하
  게 된다.
• 2x2보다 크면 샘플링 회수가 늘어나서 성능이
  떨어진다.
• Occludee의 경계구가 screen space상에서 반
  드시 1x1 - 2x2가 되도록 공식을 사용한다.
     -> float fLOD = ceil(log2( Width ));
구현전략-초기화
• 적당한 해상도(ex: 512x256)의 렌더타겟을
  만든다.
• 1x1까지 밉체인을 생성한다.
• 512x256 -> 256x128 -> 128x64 -> 64x32 -
  > 32x16…..
구현 - Occluder렌더링

• Mip level 0에서 Occluder를 렌더링. ->
  Depth map을 텍스쳐로 보관.
구현 – Depth map Down sapmling


• Depth map을 level 0부터 마지막 level(1x1)
  맵까지 다운샘플링해서 보관.
Z-buffer Texture
                mip chain




0   1   2   3      4
구현 – Occludee렌더링
• Occludee를 직접 렌더링 하지는 않는다.
• 화면에 렌더링될 Occludee의 경계구 목록
  을 만든다.
• 경계구 목록을 Compute Shader로전달.
구현 – 깊이비교(with Compute
         Shader)
• screen space에서 Occludee의 경계구 목록이 렌더링
  될 영역을 구한다.
• Occludee가 screen space에서 차지할 영역을 계산한
  다.
• screen space에서의 Occludee 가로길이에 따라 깊이
  비교를 할 Z-Map텍스쳐의 Mip레벨을 선택한다.
• 카메라 eye로부터 가장 가까운 경계구위의 한점을 구
  하고 screen space로 변환한다.
• screen space에서 경계구가 위치하는 영역의 2x2텍셀
  을 샘플링한다.
• 경계구를 대표하는 한 점의 Depth값과 2x2텍셀로 얻은
  depth값 비교.
• 경계구의 Depth > 텍셀의 Depth이면 culling.
빨간박스 : screen space에서 Occludee가 그려지는 영역
 녹색 숫자 : Occludee가 z-test에 사용할 밉맵 레벨




미쿠 캐릭터의 경우 mip level 8의 depth map으로 테스트한다.
Lv 0가 512x256일때 미쿠의 박스의 width는 화면 길이의 절반 정도
를 차지하므로 256정도로 볼 수 있다.
log2(256) = 8 이므로 mip level 8의 2x1짜리 depth map을 사용
구현 – 결과 얻어오기
• GPU메모리는 직접 읽기가 불가하다.
• D3D11_USAGE_STAGING ,D3D11_CPU_
  ACCESS_READ 으로 만든 버퍼로 copy,
  CopyResource() 사용.
• 위의 버퍼에 대해 Map(),UnMap()을 사용해
  서 결과값을 읽어옴.
장점
• Occludee를 직접 그리지 않으니 Raster Operation
  이 없다.
• Occludee의 모든 픽셀이 아닌 대표하는 한 점만으
  로 Z-Test를 하므로 Z-Test회수 자체가 적다.
• 가능한 작은 사이즈의 Z-Buffer Texture를 억세스
  하므로 텍스쳐 캐쉬효율 증가, bandwidth절약.
• 2x2 = 4번만 depth값을 읽어오므로 Depth맵 읽기
  시간 절약.
• GPGPU(Compute Shader)를 이용한 병렬처리 가
  능.
단점
• Occluder 렌더링 시간을 줄여주지는 못한
  다. 이것은 다른 차원의 문제.
• Culling결과를 가져오기 위해 PCI-E버스를
  통해 GPU Memory->System Memory로 전
  송하므로 이 부분은 여전히 느리다.
• 경계구의 한 점으로 depth테스트를 하므로
  약간 부정확하다. 가려진 오브젝트가 렌더
  링 될 수 있다. 단 반대의 경우는 일어나지
  않는다.
성능비교
<입력 오브젝트 대략 700개일때>

No Occulusion Culling
-> 430 FPS, 렌더링된 오브젝트 수 : 376개

D3DQuery Occlusion Culling
-> 561 FPS, 렌더링된 오브젝트 수 : 31개

Hierarchical Z Map Occlusion Culling
-> 713 FPS, 렌더링된 오브젝트 개수 : 31개

테스트하는 Occludee 개수가 많아질수록 격차가 더
커짐
더 생각해보기
Compute Shader에서 Thread개수
          와 Group개수
*Thread 개수는 GPU의 SP(Core)에 연관
*Group은 GPU의 SM에 맵핑
Threads : 256일때
Occludee가 256이면 Group은 1개만 필요.

일반적으로 nVidia의 데스크탑용 GPU라면 SM은 4개 – 16개 장착. 따라서 대부분의 SM이 단 1
개의 SM의 작업이 끝나기를 기다린다.

SM이 16개라면
Threads : 16 , Thread Group : 16 이 적당.

SM이 4개라면
Threads : 64 , Thread Group : 4 이 적당.

Threads per group의 수는 많은 것이 좋지만 SM을 놀지 않도록 하는 것이 더 중요.
자동화된 Occluder생성
1.   삼각형매쉬를 voxelize시킨다.
2.   Voxel들 안에서 가장 밀도가 높은 voxel을 찾는다.
3.   해당 voxel위치에서 박스를 만든다.
4.   외곽에 부딪칠때까지 박스를 확장한다.
5.   3으로 돌아간다. 일정 용적률을 채울때까지 반복

<참고>
http://www.nickdarnell.com/2011/06/hierarchical-z-buffer-occlusion-culling-
generating-occlusion-volumes/

http://www.mpi-inf.mpg.de/~mschwarz/papers/vox-siga10.pdf

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.6993
Hierachical z Map Occlusion Culling
참고문헌
• http://www.nickdarnell.com/2010/06/hierar
  chical-z-buffer-occlusion-culling/
Q/A

More Related Content

PDF
멀티스레드 렌더링 (Multithreaded rendering)
PDF
Ndc2010 전형규 마비노기2 캐릭터 렌더링 기술
PDF
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
PDF
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
PDF
Sw occlusion culling
PPTX
Compute shader DX11
PDF
나만의 엔진 개발하기
PPTX
[Ndc11 박민근] deferred shading
멀티스레드 렌더링 (Multithreaded rendering)
Ndc2010 전형규 마비노기2 캐릭터 렌더링 기술
김혁, <드래곤 하운드>의 PBR과 레이트레이싱 렌더링 기법, NDC2019
NDC2016 프로젝트 A1의 AAA급 캐릭터 렌더링 기술
Sw occlusion culling
Compute shader DX11
나만의 엔진 개발하기
[Ndc11 박민근] deferred shading

What's hot (20)

PDF
[Kgc2012] deferred forward 이창희
PDF
Cascade Shadow Mapping
PDF
Ndc11 이창희_hdr
PDF
빠른 렌더링을 위한 오브젝트 제외 기술
PPT
Shadow mapping 정리
PPTX
리플렉션과 가비지 컬렉션
PPTX
PPTX
GPGPU(CUDA)를 이용한 MMOG 캐릭터 충돌처리
PDF
UE4 Garbage Collection
PDF
Brdf기반 사전정의 스킨 셰이더
PDF
[Ndc12] 누구나 알기쉬운 hdr과 톤맵핑 박민근
PPTX
게임프로젝트에 적용하는 GPGPU
PDF
스크린 스페이스 데칼에 대해 자세히 알아보자(워햄머 40,000: 스페이스 마린)
PDF
MMOG Server-Side 충돌 및 이동처리 설계와 구현
PDF
임태현, 게임 서버 디자인 가이드, NDC2013
PPTX
Tips and experience of DX12 Engine development .
PPTX
Implements Cascaded Shadow Maps with using Texture Array
PDF
Motion blur
PPTX
물리 기반 셰이더의 이해
PDF
쉐도우맵을 압축하여 대규모씬에 라이팅을 적용해보자
[Kgc2012] deferred forward 이창희
Cascade Shadow Mapping
Ndc11 이창희_hdr
빠른 렌더링을 위한 오브젝트 제외 기술
Shadow mapping 정리
리플렉션과 가비지 컬렉션
GPGPU(CUDA)를 이용한 MMOG 캐릭터 충돌처리
UE4 Garbage Collection
Brdf기반 사전정의 스킨 셰이더
[Ndc12] 누구나 알기쉬운 hdr과 톤맵핑 박민근
게임프로젝트에 적용하는 GPGPU
스크린 스페이스 데칼에 대해 자세히 알아보자(워햄머 40,000: 스페이스 마린)
MMOG Server-Side 충돌 및 이동처리 설계와 구현
임태현, 게임 서버 디자인 가이드, NDC2013
Tips and experience of DX12 Engine development .
Implements Cascaded Shadow Maps with using Texture Array
Motion blur
물리 기반 셰이더의 이해
쉐도우맵을 압축하여 대규모씬에 라이팅을 적용해보자
Ad

Viewers also liked (10)

PPTX
Porting direct x 11 desktop game to uwp app
PPTX
DirectX + C++을 이용한 WindowsStore App과 Windows Phone용 게임 개발
PDF
전형규, 가성비 좋은 렌더링 테크닉 10선, NDC2012
PPTX
프로그래밍 언어의 F1머신 C++을 타고 Windows 10 UWP 앱 개발의 세계로~
PDF
배정섭, 쉽고 빠르게 매력적인 모션 제작하기 tip, NDC2010
PDF
SQLER on Windows Azure camp - SQL Database
PDF
[NDC 14] '미쿠미쿠하게 해줄게' - MMD MV 제작 사례와 매력적인 캐릭터 애니메이션
PDF
[스마트스터디] 재택근무 잘 하고 있어요
PDF
파이썬 생존 안내서 (자막)
PDF
스타트업에서 기술책임자로 살아가기
Porting direct x 11 desktop game to uwp app
DirectX + C++을 이용한 WindowsStore App과 Windows Phone용 게임 개발
전형규, 가성비 좋은 렌더링 테크닉 10선, NDC2012
프로그래밍 언어의 F1머신 C++을 타고 Windows 10 UWP 앱 개발의 세계로~
배정섭, 쉽고 빠르게 매력적인 모션 제작하기 tip, NDC2010
SQLER on Windows Azure camp - SQL Database
[NDC 14] '미쿠미쿠하게 해줄게' - MMD MV 제작 사례와 매력적인 캐릭터 애니메이션
[스마트스터디] 재택근무 잘 하고 있어요
파이썬 생존 안내서 (자막)
스타트업에서 기술책임자로 살아가기
Ad

Similar to Hierachical z Map Occlusion Culling (20)

PDF
Voxel based game_optimazation_relelase
PDF
[IGC2018] 유영천 개발자 - Voxel기반 네트워크 게임 최적화기법
PPTX
[박민근] 3 d렌더링 옵티마이징_2
PPTX
실전프로젝트 정서경 양현찬
PDF
[Kgc2013] 모바일 엔진 개발기
PPTX
[0326 박민근] deferred shading
PPTX
크게, 아름답게,빠르게, 일관되게 만들기: Just Cause 2 개발에서 배운 교훈들 (GPU Pro)
PDF
2017 12 09_데브루키_리얼타임 렌더링_입문편(3차원 그래픽스[저자 : 한정현] 참조)
PPT
Rendering realistic Ice objects
PPTX
[Unite2015 박민근] 유니티 최적화 테크닉 총정리
PPTX
SGL : 소프트웨어 3D 렌더링 엔진
PPTX
Cocos2d x a to z (상)
PPTX
포인트 셰도우
PDF
Introduction to DirectX 12 Programming , Ver 1.5
PDF
Voxelizaition with GPU
PDF
[shaderx6] 3.7 Robust Order-Independent Transparency via Reverse Depth Peelin...
PDF
Deferred Shading
PPTX
니시카와젠지의 3 d 게임 팬을 위한 ps4
PDF
[KGC2014] 울프나이츠 엔진 프로그래밍 기록
PPTX
Kgc2014 jplee allegorithmic
Voxel based game_optimazation_relelase
[IGC2018] 유영천 개발자 - Voxel기반 네트워크 게임 최적화기법
[박민근] 3 d렌더링 옵티마이징_2
실전프로젝트 정서경 양현찬
[Kgc2013] 모바일 엔진 개발기
[0326 박민근] deferred shading
크게, 아름답게,빠르게, 일관되게 만들기: Just Cause 2 개발에서 배운 교훈들 (GPU Pro)
2017 12 09_데브루키_리얼타임 렌더링_입문편(3차원 그래픽스[저자 : 한정현] 참조)
Rendering realistic Ice objects
[Unite2015 박민근] 유니티 최적화 테크닉 총정리
SGL : 소프트웨어 3D 렌더링 엔진
Cocos2d x a to z (상)
포인트 셰도우
Introduction to DirectX 12 Programming , Ver 1.5
Voxelizaition with GPU
[shaderx6] 3.7 Robust Order-Independent Transparency via Reverse Depth Peelin...
Deferred Shading
니시카와젠지의 3 d 게임 팬을 위한 ps4
[KGC2014] 울프나이츠 엔진 프로그래밍 기록
Kgc2014 jplee allegorithmic

More from YEONG-CHEON YOU (14)

PDF
DirectStroage프로그래밍소개
PDF
CUDA Raytracing을 이용한 Voxel오브젝트 가시성 테스트
PDF
Visual Studio를 이용한 어셈블리어 학습 part 2
PDF
Visual Studio를 이용한 어셈블리어 학습 part 1
PDF
XDK없이 XBOX게임 개발하기(UWP on XBOX)
PDF
실시간 게임 서버 최적화 전략
PPTX
CUDA를 게임 프로젝트에 적용하기
PPTX
서버와 클라이언트 같은 엔진 사용하기
PPT
프레임레이트 향상을 위한 공간분할 및 오브젝트 컬링 기법
PPTX
win32 app에서 UWP API호출하기
PPTX
Azure로 MMO게임 서비스하기
PPTX
Development AR App with C++ and Windows Holographic API
PDF
빌드관리 및 디버깅 (2010년 자료)
PPTX
Tips and experience_of_dx12_engine_development._ver_1.2
DirectStroage프로그래밍소개
CUDA Raytracing을 이용한 Voxel오브젝트 가시성 테스트
Visual Studio를 이용한 어셈블리어 학습 part 2
Visual Studio를 이용한 어셈블리어 학습 part 1
XDK없이 XBOX게임 개발하기(UWP on XBOX)
실시간 게임 서버 최적화 전략
CUDA를 게임 프로젝트에 적용하기
서버와 클라이언트 같은 엔진 사용하기
프레임레이트 향상을 위한 공간분할 및 오브젝트 컬링 기법
win32 app에서 UWP API호출하기
Azure로 MMO게임 서비스하기
Development AR App with C++ and Windows Holographic API
빌드관리 및 디버깅 (2010년 자료)
Tips and experience_of_dx12_engine_development._ver_1.2

Hierachical z Map Occlusion Culling

  • 1. Hierarchical Z Map Occlusion Culling 유영천 KASA Study
  • 2. Occlusion Culling • 가려진 물체를 그리지 말자. • Occluder가 Occludee를 가림
  • 4. Simple Occlusion Culling • 디자이너가 맵에 Plane(판대기) 배치 • 런타임에 카메라의 Eye포인트와 판대기를 연결한 뷰프러스텀 계산-Near Plane은 Occlusion면이 되어야함. • 이 뷰프러스텀에 들어가는 오브젝트는 렌 더링 안함. • 은근 실제 게임에 많이 쓰인다.
  • 5. 장점 • 구현이 쉽다.(프로그래머한테 쉽다) • 효과는 매우 확실!
  • 6. 단점 • 구현하기 귀찮다어렵다.(디자이너한테 어 렵다) • Occlusion을 정밀한 단위로 만들 수 없다.
  • 7. H/W Occlusion Culling • Occluder가 렌더링 된 상태에서 (Z-Buffer 를 유지한 상태에서) Occludee를 렌더링 g 하여 정말 그려지나 테스트. • D3D9에서부터 표준적으로 지원. • 물론 D3D9 디바이스에서도 지원 안하는 놈 이 있다. • D3D11 API에서도 D3D9 API와 비슷한 형 태로 지원함.
  • 8. 원리 • Occluder(raw맵 데이타나 거의 꼭 맞는 바 운딩매쉬)를 그려서 Z-Buffer를 구성한다. • Occludee(아마도 캐릭터나 맵데이타,기타 배치 가능한 오브젝트)를 그리되 pixel은 write하지 않고 z-test만 한다. • 그려지는 픽셀 수를 GPU측 메모리에 기록 해둔다. • 나중에 GPU로부터 픽셀수를 얻어온다.
  • 9. HW Occlusion Query @D3D9 • // Initialize • LPDIRECT3DQUERY9 Query • pDevice->CreateQuery(D3DQUERYTYPE_OCCLUSION, &pQuery); • // Begin Test • pQuery->Issue(D3DISSUE_BEGIN); • // • // Drawing • // • // End Test • pQuery->Issue(D3DISSUE_END); • // 실제로 렌더링된 픽셀 수가 dwPixelCount로 저장되어 나옴. • DWORD dwPixelCount = 0; • pQuery->GetData(&dwPixelCount,sizeof(DWORD), D3DGETDATA_FLUSH);
  • 10. 장점 • 구현이 쉽다.(프로그래머한테 쉽다.) • 구현이 쉽다.(디자이너는 할 일이 아예 없 다.)
  • 11. 단점 • 성능이 별로다. •심지어 더 느려지기 도 한다!!!
  • 12. 왜 성능이 안나올까? • DrawCall 회수를 줄이지 못한다.(멀티패스 로 오브젝트를 그리는 경우는 제외) • 두번 그려야 하므로 쉐이더에서 엄청나게 부하가 걸리지 않는 이상 더 빨라질리가 없 다. 더 느려진다. • Occludee의 크기가 커질수록 Z-Test 회수 도 많아진다. Z-Test • 픽셀 수를 받아올때 PCI버스를 타고 GPU Memory-> System Memory로 가져온다.
  • 13. Hierarchical Z Map Occlusion Culling • 정말 그려지는지 테스트-기본 아이디어는 같다. • Occluder와 Occludee가 꼭 정밀해야하는가? 간단한 매 쉬(경계구)로 대치하자. • 그렇다면 Z-Buffer의 해상도도 정밀할 필요가 없다. • 낮은 해상도의 Z-Buffer를 사용하면 Z-Buffer의 읽기/쓰 기 시간을 줄일 수 있다. • 경계구 가지고 테스트할건데 실제 그려볼 필요나 있을 까? 아예 그리지도 말고 구의 한 점만 프로젝션 해서 depth값을 비교하자. • 직접 버퍼에 그릴 필요가 없다면 Pixel Shader쓸 필요 도 없으니 Compute Shader로 경계구 하나마다 스레드 를 할당해서 depth테스트를 병렬화 시키자.
  • 14. 기본전략 • screen space에서 Occludee를 대표하는 한 점과 Occludee가 그려질 영역의 depth값을 비 교. • Occludee의 크기가 크면 Z-Buffer해상도는 낮 아도 된다. • Occludee의 크기가 작으면 Z-Buffer의 해상도 가 높아야 한다. • Occludee의 크기에 따라 가능하면 작은 크기 의 Z-Buffer를 억세스한다. • 기준은 Occludee가 screen space에서 2x2텍 셀에 맞아들어가는지.
  • 15. 극단적으로 오브젝트 크기가 이 정도면 Z-Buffer의 해상도는 2x2로 충분 Occludee Z-Buffer
  • 16. 오브젝트 크기가 이 정도면 Z-Buffer의 해상도가 충분치 않음 Occludee Z-Buffer
  • 17. 오브젝트 크기가 이 정도면 Z-Buffer의 해상도는 4x4가 적당 Z-Buffer Z-Buffer
  • 18. 왜 2x2? • screen space 상에서 항상 Occludee가 그려 지는 영역 전체를 커버할 수 있는 사이즈. • 1x1일 경우 screen space에서 Occludee가 텍 셀의 경계에 걸칠 경우 잘못된 depth비교를 하 게 된다. • 2x2보다 크면 샘플링 회수가 늘어나서 성능이 떨어진다. • Occludee의 경계구가 screen space상에서 반 드시 1x1 - 2x2가 되도록 공식을 사용한다. -> float fLOD = ceil(log2( Width ));
  • 19. 구현전략-초기화 • 적당한 해상도(ex: 512x256)의 렌더타겟을 만든다. • 1x1까지 밉체인을 생성한다. • 512x256 -> 256x128 -> 128x64 -> 64x32 - > 32x16…..
  • 20. 구현 - Occluder렌더링 • Mip level 0에서 Occluder를 렌더링. -> Depth map을 텍스쳐로 보관.
  • 21. 구현 – Depth map Down sapmling • Depth map을 level 0부터 마지막 level(1x1) 맵까지 다운샘플링해서 보관.
  • 22. Z-buffer Texture mip chain 0 1 2 3 4
  • 23. 구현 – Occludee렌더링 • Occludee를 직접 렌더링 하지는 않는다. • 화면에 렌더링될 Occludee의 경계구 목록 을 만든다. • 경계구 목록을 Compute Shader로전달.
  • 24. 구현 – 깊이비교(with Compute Shader) • screen space에서 Occludee의 경계구 목록이 렌더링 될 영역을 구한다. • Occludee가 screen space에서 차지할 영역을 계산한 다. • screen space에서의 Occludee 가로길이에 따라 깊이 비교를 할 Z-Map텍스쳐의 Mip레벨을 선택한다. • 카메라 eye로부터 가장 가까운 경계구위의 한점을 구 하고 screen space로 변환한다. • screen space에서 경계구가 위치하는 영역의 2x2텍셀 을 샘플링한다. • 경계구를 대표하는 한 점의 Depth값과 2x2텍셀로 얻은 depth값 비교. • 경계구의 Depth > 텍셀의 Depth이면 culling.
  • 25. 빨간박스 : screen space에서 Occludee가 그려지는 영역 녹색 숫자 : Occludee가 z-test에 사용할 밉맵 레벨 미쿠 캐릭터의 경우 mip level 8의 depth map으로 테스트한다. Lv 0가 512x256일때 미쿠의 박스의 width는 화면 길이의 절반 정도 를 차지하므로 256정도로 볼 수 있다. log2(256) = 8 이므로 mip level 8의 2x1짜리 depth map을 사용
  • 26. 구현 – 결과 얻어오기 • GPU메모리는 직접 읽기가 불가하다. • D3D11_USAGE_STAGING ,D3D11_CPU_ ACCESS_READ 으로 만든 버퍼로 copy, CopyResource() 사용. • 위의 버퍼에 대해 Map(),UnMap()을 사용해 서 결과값을 읽어옴.
  • 27. 장점 • Occludee를 직접 그리지 않으니 Raster Operation 이 없다. • Occludee의 모든 픽셀이 아닌 대표하는 한 점만으 로 Z-Test를 하므로 Z-Test회수 자체가 적다. • 가능한 작은 사이즈의 Z-Buffer Texture를 억세스 하므로 텍스쳐 캐쉬효율 증가, bandwidth절약. • 2x2 = 4번만 depth값을 읽어오므로 Depth맵 읽기 시간 절약. • GPGPU(Compute Shader)를 이용한 병렬처리 가 능.
  • 28. 단점 • Occluder 렌더링 시간을 줄여주지는 못한 다. 이것은 다른 차원의 문제. • Culling결과를 가져오기 위해 PCI-E버스를 통해 GPU Memory->System Memory로 전 송하므로 이 부분은 여전히 느리다. • 경계구의 한 점으로 depth테스트를 하므로 약간 부정확하다. 가려진 오브젝트가 렌더 링 될 수 있다. 단 반대의 경우는 일어나지 않는다.
  • 29. 성능비교 <입력 오브젝트 대략 700개일때> No Occulusion Culling -> 430 FPS, 렌더링된 오브젝트 수 : 376개 D3DQuery Occlusion Culling -> 561 FPS, 렌더링된 오브젝트 수 : 31개 Hierarchical Z Map Occlusion Culling -> 713 FPS, 렌더링된 오브젝트 개수 : 31개 테스트하는 Occludee 개수가 많아질수록 격차가 더 커짐
  • 31. Compute Shader에서 Thread개수 와 Group개수 *Thread 개수는 GPU의 SP(Core)에 연관 *Group은 GPU의 SM에 맵핑 Threads : 256일때 Occludee가 256이면 Group은 1개만 필요. 일반적으로 nVidia의 데스크탑용 GPU라면 SM은 4개 – 16개 장착. 따라서 대부분의 SM이 단 1 개의 SM의 작업이 끝나기를 기다린다. SM이 16개라면 Threads : 16 , Thread Group : 16 이 적당. SM이 4개라면 Threads : 64 , Thread Group : 4 이 적당. Threads per group의 수는 많은 것이 좋지만 SM을 놀지 않도록 하는 것이 더 중요.
  • 32. 자동화된 Occluder생성 1. 삼각형매쉬를 voxelize시킨다. 2. Voxel들 안에서 가장 밀도가 높은 voxel을 찾는다. 3. 해당 voxel위치에서 박스를 만든다. 4. 외곽에 부딪칠때까지 박스를 확장한다. 5. 3으로 돌아간다. 일정 용적률을 채울때까지 반복 <참고> http://www.nickdarnell.com/2011/06/hierarchical-z-buffer-occlusion-culling- generating-occlusion-volumes/ http://www.mpi-inf.mpg.de/~mschwarz/papers/vox-siga10.pdf http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.6993
  • 35. Q/A