📌RayCasting

광선 Ray : 어떠한 원점과 방향을 갖는 것

광선 투사법 RayCasting : 광선을 정해진 방향으로 쏘아 어떤 물체와 충돌하게 만드는 것

• 두 점 사이: 광선 투사법으로 두 점 사이에 무언가가 가로막고 있는지 확인 가능
• 두 면 사이: 광선 투사법으로 두 면 사이에 무언가가 가로막고 있는지 확인 가능
  • Ex) A에서부터 빛이 나간다고 할 때, 중간에 무언가가 막고 있어 B 표면에 그림자가 졌는지, 아니면 제대로 빛이 전달되는지 여부 등 확인

📌RayTracing

: RayCasting을 사용해서 이미지 생성하는 렌더링 방식

• 카메라 앞에 모니터를 두고, 카메라에서 모니터의 각 픽셀마다 광선을 쏜다고 가정
• 광선이 3D 공간에서 어떤 한 물체와 충돌했을 때,
• 충돌 지점에서 또다른 광선을 투사시켜 그림자 유무를 확인하는 방식으로 색을 계산

📌RayCasting vs RayTracing

: 광선 투사법과 광선 추적법은 다름

[RayCasting] View point로부터 나와 Scene 내의 Object에 도달하는 광선을 추적

• semi-3D 기술: 2차원 맵에서 3차원의 원근감을 만드는 렌더링 기술
• 빠른 속도: 스크린의 모든 수직선에 대해 계산만 하면 됨
  • 과거 컴퓨터의 퍼포먼스 문제로 3D 엔진을 실시간으로 실행할 수 없던 시절 사용

[RayTracing] Object에서 나오는 빛의 광선을 추적해 렌더링

• 3D 장면의 반사, 그림자를 지원하는 현실감있는 렌더링 기술
• 높은 해상도와 복잡한 장면 실시간 처리

📒Ray-Triangle Intersection

: 광선 충돌 판단을 위해선 장면 내의 모든 물체의, 각 삼각메쉬마다, 광선과 충돌했는지 판단해야 함

• Moller-Trumbore 알고리즘 등을 통해 검출 가능

📌1. 평면과 광선의 교차점 찾기

📌2. 삼각형 안의 점인지 판단하기

• 외적
  • 들어오는 벡터의 방향에 따라 외적의 위치가 바뀜
  • 이를 이용해 내외부 판별
  • 삼각형의 한 점 v0에서 다른 점 v1을 향하는 벡터 (변 표현)와, v0에서 교차점 p를 향하는 벡터를 외적
  • 외적의 결과를 Normal 벡터와 내적시켜 방향 판단
• 내적
  • 대상 벡터가 90도를 넘을 때 내적의 값이 음수가 됨
  • 내적을 이용하면 간단하게 내외부 판별
• 삼각형의 모든 점에 대해 내부로 판별된다면 삼각형 안의 점임

📒Mouse Picking

: 카메라가 보는 화면 상에서 마우스를 클릭했을 때, 해당 픽셀의 3D World 좌표 구하기

📌Ray Setting

카메라에서 마우스의 위치로 향하는 Ray

• Start Point: Camera Pos
• Dir: Mouse의 Screen 좌표(ScreenSpace)를 World 좌표로 이동
  1. NDC 좌표계 변환 (ScreenSpace: uv좌표계 --> NDC좌표계)
  2. ViewSpace에서 광선의 방향정보 구해줌
  3. ViewSpace ➡️ WorldSpace 전환 (View inv matrix)

📌RayCasting

카메라에서 마우스의 위치로 향하는 World Ray를 마우스 피킹할 오브젝트의 로컬로 보냄

• 오브젝트와 광선의 교차점 구함
• 충돌 검사: 마우스 피킹할 오브젝트를 대상으로, 메쉬의 모든 면마다 Ray와 충돌했는지 검사

References [1] RayTracing: 🔗github [2] RayCasting: 🔗github [3] Ray-Triangle Intersection: https://www.slideshare.net/wraithkim/1-249173329 [4] 삼각형 내부판단 : https://hwanggoon.tistory.com/114

📌What is Level Of Detail?

: 메시 모델링 데이터의 정밀도를 단계별로 조정하는 기술

• 가까우면 메시를 세밀하게, 멀면 단순하게 표현
• 렌더링 속도(Speed)와 질(Quality)의 밸런싱
  • 실시간 렌더링 기술은 어느정도 퀄리티를 타협하더라도 빠른 렌더링이 중요함
  • 가능한 좋은 퀄리티로(즉 타협을 덜 하면서) 빠르게 렌더링하기 위함

[LOD 타입]

• Static LOD
• Dynamic LOD
  • 메시 분할
  • 메시 간략화

📌Static LOD

: 여러개의 메시를 준비해 사용

• 카메라와 물체 간 거리를 측정해서 카메라와 가까운 거리에 있는 물체는 정밀한메시를 사용하고, 거리가 멀어질수록 낮은 단계의 메시를 사용
• 처음부터 메시의 정밀도가 정해져 있고, 이를 카메라와의 거리에 따라서 단계별로 바꿔가며 사용하는 것
• 장단
  • 장: 간단하므로 속도가 빠름
  • 단: 메모리 낭비, 거리에 따라서 메시가 급격히 변할 때 튀는 현상(popping) 발생

📌Dynamic LOD

: 카메라와 물체의 거리에 따라서 실시간으로 메시의 정밀도를 변화시킴

• 메시 분할과 메시 간략화 두 타입으로 나뉨
• 장단
  • 장: 거리에 따라 LOD가 이루어지므로 튀는 현상(popping) 적음, 메모리 낭비 없음
  • 단:
    • 느린 속도: 메시 분할, 간략화 등에 추가 연산이 필요
    • 잦은 Lock-Unlock: 레벨이 바뀌거나 정점데이터를 갱신할 때 정점 계산을 동적으로 수행

DirectX11과 Tesellation DirectX 11 버전부터는 GPU가 LOD를 처리해줘서, 따로 구현하지 않아도 된다.

📒Dynamic LOD

📌LOD 계산

(1) 거리기반 LOD : 시점 위치와 오브젝트의 거리를 이용해 단계 값을 구하는 방법

• 구현이 간단하고 부하가 적음
• 필요없는 부분이 세밀하게 보이거나 세밀하게 보여야 하는 부분이 단순하게 보일 수 있음

*(2) 면적기반 LOD * : 오브젝트의 투영 면적에 따른 단계값을 구하는 방법

• 자연스럽게 표현됨
• 많은 CPU 연산량: 투영 면적이 달라질 때마다 다시 계산

📌(방법1) 메시 간략화

: 폴리곤의 수를 줄이는 방법

• 간략화할 기준을 세우고 모양을 최대한 유지한 상태에서 폴리곤의 수 제거
• 간략화 기준: 어느 폴리곤의 어느 꼭지점을 먼저 제거할 것인가 등
• 간략화 방법:
  • 점 제거(Vertex Decimation)
  • 점 합치기(Vertex Clustering)
  • 면 줄이기(Edege Colapse)

📌(방법2) 메시 분할

: 하나 폴리곤을 여러 개의 폴리곤으로 분할하는 방법

📌균열 현상 (Crack)

하나의 단일 메시 속에 여러 단계의 패치가 존재할 때, 인접한 패치 간 분할 단계의 차이가 존재하는 경우 발생

• 패치 단위로 분할 level을 잡는다면 level이 변하는 경계면에선 틈이 생김 (들림)

[Crack이 생기지 않게 하기]

• 방법1: 인접한 두 패치 가 서로 level이 다르더라도, 더 낮은 level의 패치쪽에선 맞닿는 면의 레벨을 높여줘야(맞춰줘야) 함
• 방법2: 패치 단위가 아닌, 거리에 따라 분할 level을 잡으면 자연스럽게 mapping 가능

[발생한 Crack을 매꾸기] : 추가 삼각형을 발생한 Crack에 끼워넣기

• 뗌질 삼각형을 LOD단계가 달라지는 모든 노드에 해서 상하좌우 네 가지 방향으로 만들어줌

📌poppiong 현상

: 거리에 따라 폴리곤 수가 갑작스럽게 줄어들거나 늘어나면 그래픽이 튀어보이는 현상

• 정적LOD사용시 급격한 레벨의 차이로 모양이 바뀌어 튀어보이는 현상
• 해결: 보간
  • 낮은 레벨에서 높은 레벨로 갈 때 사라지는 정점의 위치값을 level 간 차이에 대한 보간값 t를 구해 보간
  • 정적LOD에서의 해결 : 실시간으로 데이터를 계산할때 t값을 구하고, 그에 따라 보간
  • 동적LOD에서의 해결 : 두 level에서의 버텍스 버퍼를 모두 stream source로 보내고, t값을 세팅하여 버텍스 셰이더에서 두 버텍스를 보간

[보간 예시] : level0 (0, 0), (10, 15), (20, 5)과 level1(0, 0), (20, 5)으로 구성된 직선이 있을 때 level1에서 존재하지 않는 점 (10, 15)를 level1에서의 가상의점 (10, 2.5)와 보간해야 함

현재 level이 0이고 보간값 t가 0.5라면 중간점은 0.5 * (10, 15) + 0.5 * (10, 2.5) = (10, 8.75)

📒Tesellation과 Height map

: Height map을 참고해서 추가적으로 만든 정점들의 높이를 변경

• ex 지형텍스처가 표현하려고 했던 고해상도 지형 적용

📌Displacement Mapping

• nomal mapping: 근본적으로 geometry를 조작하지 못함
• tesellation: surfaces를 쪼개 만든 정점의 위치를 조작할 수 있음

📌Setting

[Mesh] : Tesellation level의 차이를 주려면 patch를 필요한 값으로 세팅해줘야 함 즉, mesh를 새로 만들어 써야 함

• Face: 기본적으로 mesh를 쪼개는(patch) 줄 수

• UV

  • Mesh의 사각형 하나(patch 2개) 당 0~1
  • 전체를 0~1로 보지 않음 주의
  • 즉 왼쪽 위가 0,0, 오른쪽 아래가 Face,Face

• 렌더링 시점: deferred rendering

[height map]

• 픽셀 포맷: R32
  • r: height
  • 흑백으로만 표현됨
• shader
  • UV: 전체 기준
  • normal: shader에서 재계산 필요

📌normal 재계산

: height map을 그대로 적용시키면 height는 적용되지만, 모든 vertex의 normal은 여전히 같은 방향이므로 명암의 차이가 존재하지 않음

[Normal 구하기]

• 바로 주변 정점의 높이를 통해 현재 접하는 면의 Tangent와 Binormal을 도출 가능
• 이를 통해 Normal 구함

[변화량 도출]

• 정점 간 간격 변화량
  • Inside Level로 정점 간 이동 간격 추측
  • 정점 간 간격 변화량 = 1 / pathLevel.Inside
• 정점 간 UV 변화량
  • UV 간 변화량 = 1 / FaceXY * 정점 간 간격
• 계산 좌표계
  • world에서 scale이 적용되면 높이가 변하므로, world 좌표계에서 계산해야 함
  • (주의) 계산 후 WV matrix 곱하는 것과 결과 다름!!

📌LandScape

: height map으로 적용시킬 texture를 실시간으로 수정해서, 지형을 만드는 것

• height tex 수정
• albedo tex 수정

References [1] LOD: https://blog.naver.com/ssod015/220272372528 [2] Height Map: https://victorbush.com/2015/01/tessellated-terrain/ [3] LandScape: https://victorbush.com/2015/01/tessellated-terrain/

• 평면의 방정식 기법 사용

📒평면의 방정식

1. 어떤 벡터와 평면의 노말벡터의 내적이 0이라면 두 벡터는 수직임

• 수직하는 두 벡터 간의 내적값은 0

  (복습) 내적 Inner Product : 투영

  • 각 성분의 합

• 평면 위의 벡터와 평면의 노말벡터는 수직임
  • 평면 위의 벡터: 평면 위의 두 점 사이에 존재하는 방향벡터
• 평면 위의 아무 점들 간 방향벡터와 평면의 노말벡터는 수직임
  • 즉 평면의 방향벡터와 노말벡터의 내적값은 항상 0으로 같음
  • 즉 어떤 벡터와 평면의 노말벡터의 내적이 0이라면 두 벡터는 수직임

2. 원점이 아닌 곳에 존재하는 평면

• Normal 판단
  • 평면 위의 방향벡터 V1과, V1의 Tangent vector인 V2까지 두 벡터가 필요함
  • 즉 평면 위의 점 3개가 필요함
• 원점 O로부터 떨어진 거리 D
  • 평면 위의 점을 노멀벡터로 내적하면(투영하면) D의 길이를 구할 수 있음
• 평면의 위치 판단
  • D = 0: 평면이 원점에 위치함
  • D > 0 or D < 0: 평면이 원점에 위치하지 않음
• 평면의 방정식: Ax + By + Cz + D

3. 임의의 정점과 평면

• 임의의 점과 원점 사이의 거리
  • 임의의 점과 평면의 노말벡터를 내적한 값 (자료상 SD)
• 원점으로부터 거리 비교
  • 평면: D
  • 임의의 점: SD
  • 즉, D와 SD를 비교하면 임의의 점이 평면으로부터 떨어진 방향을 구할 수 있음
• 점과 평면의 관계
  • SD > D : 평면 밖
  • SD = D : 평면 위
  • SD < D : 평면 안
• 점과 평면의 방정식
  • 즉, 평면의 방정식을 알고 있다면 대입해서 쉽게 연산 가능
    • 평면의 방정식의 계수를 알고 있다면 내적해서 값 얻을 수 있음
    • 내적: 각 성분의 곱
  • 대입값(내적 + D) > 0 : 평면 밖
  • 대입값(내적 + D) = 0 : 평면 위
  • 대입값(내적 + D) < 0 : 평면 안

📒Frustum Culling

: 카메라 시야 범위 즉, 절두체 안에 들어오지 않으면 rendering을 걸지 않는 최적화 방식

• CPU 차원에서 검사

📌절두체 검사

: 절두체의 각 면마다 평면의 방적식 안밖검사, 총 6번 (6면) 검사

• 한 면이라도 통과하지 못하는 경우 카메라에 들어오지 않음
  • 즉 렌더링 않음

📌평면의 방정식 판단

: 평면과 현재 좌표(점)의 관계 연산

• D > P·N : 원점과 평면 사이에 있음
• D = P·N : 평면에 있음
• D < P·N : 원점과 평면 외부에 있음

📌Bounding Box

: 시야각에서 중심은 벗어났지만, 부피가 커서 시야 안에 들어오는 경우

• 문제: 오브젝트의 중심좌표만 체크하는 경우
• 해결: 물체마다 제일 큰 동작 기반으로 벗어남 인정해주는 값 지정

References. [1] 평면의 방정식: https://m.blog.naver.com/ldj1725/220062476672 [2] Frustum Culling: https://learnopengl.com/Guest-Articles/2021/Scene/Frustum-Culling [3] Frustum Culling: https://sanghoon23.tistory.com/86

: Hull & Domain Shader

• DX11부터 추가된 pipeline 단계
• 정점을 추가해 폴리곤을 세분화하고 쪼갬

📌Setting

• Topology
  • Vtx를 분석하는 위상
  • Tesselation 전용 Topology 사용
  • D3D11_PRIMITIVE_TOPOLOGY_N_CONTROL_POINT_PATCHLISHT
    • ex, N==3 이라면 제어점 3개짜리 patch list
• edge
  • edge idx: idxed Vtx가 마주보는 변
• mesh: 대칭구조 필요

📌Control Point & Patch

[Control Point] : 삼각형을 넘겨준다고 가정할 때, 각 정점에 해당하는 점

• 내부를 제어하는 점
• 제어점은 중간의 다른 정점을 생성하기 위한 기준점임

[Patch] : 삼각형을 넘겨준다고 가정할 때, Control Point 세 개가 모인 set 자체

• control point의 그룹

📒PipeLine

📌Tesellation Pipeline

[Vertex Shader] : 원본 Vertex의 input - output

• Tesellation에서는 Domain Shader가 진짜 vertex 처리
  • 즉 VS는 딱히 하는 일 없음
• ex, 사각형 그리기위해 2개 삼각형 구성하는 상황) : 6개 output

[Hull Shader] : 원본 Vertex를 n개씩 묶어 patch라는 하나의 조각으로 묶음

• n: 사용자가 설정, 대체로 3(삼각형) 사용
• ex, 사각형 그리기위해 2개 삼각형 구성하는 상황) : 2개 output

[Tesellation Stage] : 추가적인 정점 생성함

• DX 내부적으로 수행, 직접 건드릴 수 없음
• patch constant function만 정의 가능
• patch constant function:
  • 패치당 한 번씩 호출되는 함수
  • 원하는 정점 개수 세팅

[Domian Shader] : 새로 생긴 Vtx까지 포함해서, 모든 Vtx에 대해 호출 후 전처리

• 원래 VS에서 하던 일 담당

📌Tesellation vs Geometry

[(복습) Geometry Shader] : 추가적인 분할 진행

: Tesellation과 Geometry 모두 정점을 분할하는 기능을 가지므로, 보통 함께 사용하진 않음

• 정점 대량 생산의 경우: Tesellation 활용
  • ex, 지형생성
• 정점 소량 생산의 경우: Geometry Shader 활용
  • ex, billboard 효과

📒Hull Shader State

: 각 입력 패치(사각형, 삼각형 또는 선)에 해당하는 기하 도형 패치(및 패치 상수)를 생성하는 단계

• 각 패치(SV_PrimitiveID)에 대해 출력 제어점(SV_OutputControlPointID) 당 한 번 호출

📌HullShader 실행단계

: 크게 두 단계로 나뉨

• 제어점 단계
  • 각 제어점에 대해 한 번 작동
  • 패치를 위한 제어점을 읽고, 하나의 출력 제어점 생성
    • 출력 제어점은 ControlPointID로 식별됨
• 패치 상수 단계
  • 패치당 한 번씩 작동
  • 가장자리 공간 분할 요인 및 기타 패치별 상수 생성

📌HullShader Func Define

[description] : 컴파일에 필요한 description 필요

• https://learn.microsoft.com/en-us/windows/win32/direct3d11/direct3d-11-advanced-stages-hull-shader-design
• 대표적인 description
  • patch constant func: 컴파일할 함수
  • outputtopology
  • outputcontrolpoints
  • domain
  • partioning: 분할 자료형
    • float형을 쓰면 더 세밀한 분할 가능

[paramater] : 같이 소속된 patch의 정점들이 함께 들어옴

• InputPatch: patch의 원본 정점들 (VS return type)
• SV_OutputControlPointID: patch 내 호출된 idx

[TIP] Sementics SV_Position은 rasterizer에서 사용하는 sementic이기 때문에, HS에선 사용 불가능함

📌patch constant function

: 어떻게 분할할지 설정하는 함수

• 실행: Tesselation Stage
  • Hull Shader > Tesselation Stage > Domain Shader
• 패치 당 한 번씩 호출
  • 즉 Vtx의 idx가 필요하지 않음

[paramater]

• InputPatch: patch의 원본 정점들 (VS return type)
• SV_PrimitiveID: patch의 ID

[retun type] : patch의 분할 레벨

• SV_TessFactor: edge당 control 갯수
• SV_InsideTessFactor: 내부 control 갯수

📒Tesselation State

: 더 세밀한 표현을 위해 공간 분할 요소를 사용하여 각 패치를 세분화하는 단계

• 패치당 한 번 작동
• 프로그래밍 불가

📒Domain Shader

: 원본 정점 포함 모든 정점에 대해 호출해 세분화된 위치 계산하는 단계

• 출력 지점당 한 번 실행

📌보간

: 보간된 값이 들어오지 않고, 대신 가중치값이 들어오므로 직접 보간해서 값 구해야 함

• 원본 정점: 패치의 원본 정점 먼저 들어옴
• 가중치: 보간된 값이 아닌, 원본 정점에 대한 가중치 값이 들어옴
  • 가중치를 사용해서 정점 계산해야 함

(복습) Pixel Shader : 호출된 픽셀의 값이 알아서 보간되어 들어왔음

📌DomainShader Func Define

[description] : 컴파일에 필요한 description 필요

• domain : 들어오는 단위
  • ex, 3개 정점을 가진 삼각형을 단위로 들어옴 명시

[paramater]

• patch Level: HullShader에서 설계한 각 패치의 분할 레벨
• OutputPach : 원본 정점들
• SV_DomainLocation : 해당 Vtx에서 사용할 가중치

📒Tesellation의 이점

📌성능 개선

• GPU를 통해 low-detail subdivision surface를 high-detail subdivision surface로 변환
• CPU에서 high-resolution 모델을 올리는 방식: 엄청난 부하 발생

📌Displacement Mapping

• nomal mapping: 근본적으로 geometry를 조작하지 못함
• tesellation: surfaces를 쪼개 만든 정점의 위치를 조작할 수 있음

References [1] Hull Shader MS Doc: https://learn.microsoft.com/en-us/windows/uwp/graphics-concepts/hull-shader-stage--hs- [2] Domain Shader MS Doc: https://learn.microsoft.com/en-us/windows/uwp/graphics-concepts/domain-shader-stage--ds- [3] Tessellation: https://develop-4-art.tistory.com/11 [4] Tessellation: https://song-ift.tistory.com/450

📌개념적 흐름

1. Depth Map 생성
   • 광원 기준 샷 따로 찍음 : 깊이 저장
2. Depth Map 투영
   • 메인카메라가 보는 월드를 다시 전역광원 깊이샷에 투영시켜봄
   • 광원에서 볼 수 있는지, 즉 그림자지는 부분인지 아닌지 판단

(복습) scene 찍기

• tick: shader domain의 obj들을 따로 모아둠
• render: 모은 그룹의 각 obj마다 render 호출
• shader:
  • 세팅한 RT & DST에다가,
  • 각 VS에서 들어온 Vtx의 local 값을 ➡️ WVP 행렬 연산해 Screen 좌표로 보내 얻은
  • 본인의 위치에 값 연산해 그림
  • 그룹의 모든 obj마다 반복
• 해당 shader domain 그룹의 texture 완성!
  • 모든 그룹마다 위 과정 수행

    : 즉, 그림자를 생성하는 obj를 모아 shader depth map을 그리는 render 호출하면, 각 obj마다 shadow depth shader를 통해 light에서 바라보는 모습을 그려, shadow depth texture를 완성함

📌Setting

[ShadowDepth MRT]

• ShadowDepth Tex (RT)
  • Texture 해상도:
    • 화면에 그리는 용도가 아닌 Shader용으로 제작하기 때문에 화면크기와 달라도 됨
      • Texture의 최대크기: 8192
    • Directinal Light: 월드 전체를 그려야 하므로 해상도가 커야 함
    • Point Light: 정해진 range 안의 물체만 그리므로 작아도 괜찮음(512~1024)
• DepthStencil Tex
  • RT와 같은 해상도의 DS용 Tex 따로 생성

📌Shadow Drawing

1. Viewport 설정

   • Viewport 크기와 Render Target 크기:

     • 처음부터 RT 크기가 아닌 Viewport 설정(크기)에 맞춰서 그려짐
     • 즉, Viewport와 Render Target의 크기가 다를 때 늘어나거나 줄어드는 개념이 아니라
     • RenderTarget에서 Viewport만큼의 크기에 렌더링되는 것

   • Viewport 설정 단계: Rasterizer 이전

     • Viewport는 Rasterizer 단계에 영향을 줌
     • MRT가 Viewport Size를 들고 있어야 함

   • Viewport의 크기가 제대로 세팅되지 않는다면

     • Rasterizer: Viewport만큼의 크기에 호출시켜줌
     • RT Copy: 전체 Render Target 영역을 대상으로 호출됨

2. ShadowDepth rendering : 광원 시점에서 물체의 깊이 그림

   • 광원 시점 View & Proj 행렬을 통해 물체의 깊이 그림

     • 카메라 컴포넌트에서 구현해뒀으므로
     • Light3D에서 CamObj를 들고 행렬 계산용으로만 사용하도록 설계

   • Proj Type

     • Directional Light: 직교투영
       • DirLight는 태양광이므로 모두 같은 방향을 가져야 함
       • 태양은 멀리 떨어져 있으므로 월드값 즉, _근소한 값의 차이_에 차이 발생 않음
     • Point Light: 원근투영

   Shadow depth texture의 각 Pixel

   • position : Light가 바라보는 관점 기준
   • 기록정보 :
     • r : depth, Light로부터 떨어진 정도 기록

3. Shadow Shading

   • Light가 추가적으로 필요한 정보 (바인딩)
     • Shadow Depth Tex
     • Light ViewProj mat
   • 그림자 지는 부분 확인 : Pixel Shader에서 현재 픽셀의 위치를 Shadow Depth Tex로 투영해 그림자 지는 부분인지 판단
     • 변환행렬: pixel 위치 * View Inv mat * Light ViewProj mat
   • 판단
     • Shadow Depth Tex로 투영해 추출한 값(Depth)이 예상한 값보다 더 앞이라면, 즉 추출값이 계산값보다 더 작다면
     • 앞에 빛을 가리는 물체가 있었음
     • 즉 그림자지는 부분
     • 보정값(Magic Number): 실수계산이라 작은 오차가 존재할 수 있으므로 값 보정해서 인정

📌Alising

: Directional Light의 경우 깨짐현상 발생

• 이유
  • 이유1: Directional Light가 멀리서 찍기 때문에, 확대했을 때 깨짐
  • 이유2: deferred라서 Anti-Alising 처리가 안됨
• 해결: 별도의 단계
  • 그림자만 처리하는 단계 분리해야 함
  • 이후 blur 등으로 직접 처리

📌광원의 범위를 벗어나는 경우

: 광원의 범위를 벗어나서 그림자가 갑자기 사라지면 어색해 보임

• 방법1: 그림자 그리지 않기
• 방법2: follow (dynamic의 경우)
  • dynamic light는 main cam을 따라다님
• 방법3: 광원 반복배치 (static의 경우)
  • 광원을 반복적으로 배치해서 연속적으로 그림자 그려줌

📌애니메이션 그림자

• 광원은 TPose를 받지만 애니메이션을 플레이하는 경우
• 그림자를 찍을 때 Skinning작업을 해줘야 함

📒 Point Light Shadow

: Dir Light와는 달리 그림자가 육면체형태로 6번 판정 및 렌더링 돌아야 함

• 최적화: Geometry 셰이더
  • 하나의 시점에서 여러방향 뽑을 수 있음

📒 최적화

📌Static Object vs Dynamic Object

[Object Type]

• static: 처음 1회 그림자 그려 사용
• dynamic: 매 틱 그림자 그려 사용

[Object Shadow Option]

• enable: 그림자 생기는 오브젝트
• disable: 그림자 생기지 않는 오브젝트

[Light Shadow Option]

• enable: 그림자 만드는 빛
• disable: 그림자 만들지 않는 빛

📌최적화

: 그림자를 그리기 위해선 결국 렌더링 횟수가 증가하니 프레임드랍 발생함

• 움직이지 않는 것, static한 물체들은 미리 (한 번) 그려놓고 다시 그리지 않음
• 변형이 있는 물체, dynamic한 물체들만 계속 다시 그림

: VolumeMesh가 교차하는 다른 Object에 Texture 투영

• Deffered Rendering 사용
• ex) 발자국 자국, 총알 자국, 문신

📌Setting

• Shader domain : Decal domain 추가
  • 렌더링 시점: Deffered 이후, Lighting 이전
• Render Target (MRT): Decal MRT 생성
• DepthStencil State: NoTest NoWrite
• culling: CULL-FRONT
  • VolumeMesh 안으로 카메라가 들어갔을 때도 렌더링되어야 함
  • Lighting을 CULL-FRONT한 것과 같은 이유

📌Shading

: VolumeMesh와 교차하는 면의 PixelShader만 호출되어야 함

• PointLight의 Shading 접근법과 유사
• VolumeMesh의 내부 판단
  1. Texture Sampling 값 보정
     • -0.5 ~ +0.5 ➡️ ~ -1.0 ~ +1.0
  2. 보정한 값으로 UV sampling
     • 표면의 normal이 Y축을 향하도록 바닥에 깔려있으므로 XZ축 사용

📒Additional Decal MRT Op

📌Emissive Texture

: 자체적으로 발광하는 텍스처

• Blend State
  • 상황:
    • Color는 AlphaBlend 필요
    • Light(Emissive Tex)는 OneOneBlend 필요
  • Decal 전용 Blend State 생성
    • BLEND_DESC.IndependentBlend = Enable
    • Render Target마다 독립적으로 Blend State 설정하는 플래그
• Emissive Tex 처리: Merge

📌Normal Map

: Normal Map 등을 사용해서 표면 거칠기 덮어씌우기 가능

: 지연 렌더링

• Deferred: 연기된, 지연된

📌Foward Rendering

Straight Forward Shading. 렌더링 파이프라인을 1번만 거쳐서 GPU Back Buffer(GBuffer)에 바로 렌더링

• Mesh 하나를 그릴 때마다 모든 계산을 시행
• 라이팅 계산: Mesh의 수에 비례
  • 불필요한 연산 발생: 빛의 영향을 받지 않은 Mesh에 대해서도 연산

📌Deferred Rendering

: 렌더링 파이프라인을 크게 2번 거쳐 렌더링 (Two Pass Algorithm)

• Foward Rendering의 단점을 보완한 렌더링 기법으로, 멀티 렌더 타겟 사용

• Two Pass

  • First Pass : Gbuffer라고 칭하는 여러개의 버퍼에 오브젝트 정보 렌더링
    • Diffuse, Screen Space Normal, Specular, Smoothness, Screen Space Depth등의 정보를 기록해 사용함
  • Second Pass : 기록된 정보들을 토대로 셰이딩 연산 (라이팅 연산)
    • 모든 오브젝트들의 GBuffer을 렌더링한 후(Deffered) 라이팅 계산함
    • 즉, 한 번에 렌더링이 완료되지 않고
    • 기록된 오브젝트의 정보들을 사용해 렌더링 완료함

[장점]

• 특정 정보만 따로 분리해 다룰 수 있으므로
• 특정 영역에 관한 추가적인 연산, 효과 적용 가능
• 광원을 많이 사용하는 경우 Forward보다 빠를 수 있음
  • 겹친 픽셀을 포함해 모든 픽셀마다 Light 연산을 하는 대신 Light마다 한 번의 연산만 진행

[단점]

• 광원을 적게 사용하는 경우 Forward보다 느림
  • 더 많은 렌더링 횟수
  • 더 많은 메모리 사용 (Texture)
• 반투명한 물체 처리가 어려움
  • PASS1에서 한 오브젝트의 값으로 모든 데이터를 결정하므로 겹쳐있는 오브젝트 처리가 어려움
• Anti-Aliasing 성능 하락
  • MSAA같은 anti-aliasing은 하드웨어 Rasterization 단계에서 수행됨
  • Deferred Shading에서는 Frist Pass에서만 Rasterization 수행
  • Second Pass는 GBuffer결과물을 사용하기만 하므로 Rasterization 수행되지 않으므로 AA 적용 불가능
  • 이러한 이유로 Deferred Shading은 Light계산이 이루어지기 전에 AA을 적용하므로 최종 결과물이 예상한 값과 다르게 나올 수 있음

📒Deferred에서의 Lighting

: Deferred rendering을 적용하면 광원에 대한 연산만을 따로 다룰 수 있음

• 라이트가 미치는 영향을 따로 기록
• 빛 번짐, Bloom 등과 같은 기능을 사용하기 쉬워짐

📌Forward Lighting과의 연산흐름 차이

: (Deferred) 화면 결정 후 -> 라이팅 연산

• Forward Shading: 한 pixel위치에 존재하는 여러개의 pixel값들에 모두 Lighting 연산 후 depth값 비교해 하나의 pixel만 그림

• Deferred Shading: First Pass를 통해 한 pixel 위치에서 'Light 계산하게될 pixel값'을 선정, Second Pass에서 해당 pixel값만 Light연산 후 그림
  • 즉, 한 픽셀에 여러개의 Object가 겹쳐있을수록 Deferred Shading의 성능이득 증가

📌Light MRT

: 전용 Texture에 빛의 영향 기록

• 연산시점: Deferred 물체가 그려진 이후

  • Deferred: Lighting 연산 받음
  • Forward: (따로 처리 않는 이상) Lighting 처리 않음

• 렌더링 요청 주체: Light

  • Forward: 모든 Mesh마다 Lighting 연산 적용
  • Deferred: 각 Light Object가 렌더링 요청

• 빛의 영향 범위 판단: Position 정보를 기록해둔 Texture 사용

  • 예를 들어, Position Texture에 기록이 없다면 물체가 존재하지 않는 부분 ➡️ 빛 기록 안함
  • 예를 들어, (Point Light rendering 시) Position Texture에 기록이 있다면 Point Light의 범위 안으로 들어오는지 판단

📌Setting

[Texture] : 2개의 CBuffer 사용

• Diffuse: 세기
• Specular: 반사광

[Setting]

• DepthStencil Type: NO_TEST_NO_WRITE
• Blend State Type: ONE_ONE
  • 기존1 : 신규1 비율로 믹스
• Culling: CULL-FRONT
  • CULL-NONE: Light rendering이 두 번 호출됨
  • CULL-BACK: Light 범위 안으로 카메라가 들어가면 Light 연산하지 않음

📌Volume Mesh Check

: Directional Lihgt가 아닌 경우 빛이 영향을 주는 범위를 알기 위해 Volume Mesh check가 필요함

• VolumeMesh: 광원이 영향을 주는 범위
  • VolumeMesh만큼 호출된 전체 픽셀에 빛을 적용시키면 안 됨
  • VolumeMesh만큼 호출된 곳에서도 빛이 영향을 주는 부분만 적용시켜야 함

📒Volume Mesh Check

[빛의 영향 범위를 확인하는 여러 방법들]

• 방법1: Position Texture 사용
• 방법2: Stencil 사용

📌방법1: Position Texture 사용

: Position Texture를 사용해 Pixel shader에서 한 번에 빛의 영향 범위 판단

• VolumeMesh 안에 들어오는지 판단
  1. 호출된 픽셀 위치를 UV로 환산
  2. 추출한 UV로 Position Texture 샘플링
  3. 얻은 좌표정보로 VolumeMesh와의 거리 측정
     • 역으로 연산 (Screen➡️World➡️LocalSpace of VolumeMesh)
     • 좌표계 역연산: 변환행렬(View Inv * World Inv)을 바인딩해 사용
  4. 거리 측정 결과로 내외부 판단
• 장단
  • 장: 빠름 (PS에서 바로 연산 가능)
  • 단: VolumeMesh의 기하학적인 특징이 있어야 함 - 내외부 판단 위해

📌방법2: Stencil 사용

: VolumeMesh의 BackFace, FrontFace, Stencil에 대해 총 3번 렌더링 결과로 빛의 영향 범위 판단

• VolumeMesh 안에 들어오는지 판단

  1. Volume Mesh용 DepthStencil State 제작

     • BACKFACE용
     • FRONTFACE용
     • STENCIL용

  2. BACKFACE 렌더링 : Light의 뒷부분 관점에서 VolumeMesh의 내부판단

     • DepthFunc: BackFaceCheck
     • DepthStencilType: Greater
       • 더 뒤에 있으면 통과
       • 먼저 그려진 물체들이(Deffered) VolumeMesh의 뒷면보다 앞에 존재한다면
       • 즉, light의 영향 범위 안쪽이라면

  3. FRONTFACE 렌더링 : Light의 앞부분 관점에서 VolumeMesh의 내부판단

     • DepthFunc: FrontFaceCheck
     • DepthStencilType: Less
       • 더 뒤에 있으면 통과
     • FrontFace.StencilFailOp: DECR
       • 두 번 증가하는 현상 방지

  4. STENCILCHECK : 예상하는 Stencil 값인지 확인

     • DepthFunc: NEVER
     • DepthStencilType: Equal
       • 같으면 통과
     • OMSetDepthStencilState: 2번째(idx 1) pram으로 예상하는 Stencil 값 전달
     • StencilEnable = true
       • RenderTarget없이 DepthStencil Texture만 세팅
       • 즉, RenderTarget에 색을 내보내는 Pixel Shader 단계 수행 X
     • StencilPassOp: INCR

• 장단

  • 장: VolumeMesh의 기하학적인 특징이 없어도 가능 - 내외부 판단 위해
  • 단: 느림 (렌더링이 3번 발생)

[Stencil 단계 3~4를 한 단계로 합치기] : 2~3 단계는 한 단계로 수행할 수 있음

• DepthStencilType: CULL_NONE
• 각 구조체마다 세팅

📒Stencil Buffer

: 렌더링해야 할 곳에 특정 값을 설정해, back buffer의 일정 부분만 rendering되도록 함

• off-screen buffer
• 해상도: Backbuffer, depth buffer와 동일함
• ex) 거울, 그림자, 아웃라인

References [1] Deffered Rendering: https://learnopengl.com/Advanced-Lighting/Deferred-Shading [2] Stencil Buffer: https://dis.dankook.ac.kr/lectures/game09/wp-content/uploads/sites/16/1/1171436988.pdf

📌OM Set

DX11 기준 : Render Target과 Depth Stencil Texture를 같이 묶어서 세팅해줌

• Render Target: 최대 8장 지정 가능
• Depth Stencil Texture: 1장만 지정 가능

📒Multi Render Target(MRT) Class 설계

📌MRT Class

: RenderTarget arr와 DS를 모아 관리

• 더이상 Device가 직접 RenderTarget을 관리할 필요 없음

[Code Flow]

• MRT Create & Clear: RenderMgr
  • RenderMgr에서 MRT 생성 후 들고 있는 구조
  • 즉, 모든 MRT는 RenderMgr에서 들고 있음
• OM Set: render 시
  • 사용하는 셰이더에 따라 적절한(정해진) MRT로 OMSet 해줌

📌MRT Type

• MRT는 여러 타입이 있을 수 있음
• 용도에 따라 MRT를 바꿔가며 렌더 찍어 사용

[Texture Format] : MRT에서 Position 등의 정보를 Texture로 저장해 전달하기도 함

• Position 등은 큰 숫자를 저장할 수 있어야 함
• R8G8B8 : 부동소수점을 저장하기에 8bit는 너무 작음
• R32G32B32 : 큰 데이터를 저장하기 위해선 32bit Format으로 설정해야 함

📌대략적인 Rendering 순서

1. Deffered : 정보를 남겨두고 취합하는 렌더링

   • 다른 연산에서 사용하기 위한 정보를 연산하는 렌더링
   • 한 번의 연산으로 완성되지 않음, 다른 곳에서 가져다 사용하는 용
   • ex) DEFFERED, DECAL, LIGHTING ...

2. Merge : Deferred에 기록된 정보를 메인렌더에 병합시켜야 함

3. Forward : 한 번의 연산으로 완성되는 렌더링

   • Forward를 통해 AlphaBlend를 처리할 수 있음

📌SkyBox란

: 가상의 배경을 만들 때 사용되는 wrapper

• 전체 씬을 둘러싸며 지오메트리 너머의 월드의 이미지를 보여줌
• 카메라가 움직이는 동안 고정된 배경 제공

[Skybox 타입]

• Sphere
• Cube

📌Mesh & Material

• Mesh: Cube, Sphere
• Shader: 전용 Shader 제작
  • Rasterizer Type: CULL_FRONT
    • SkyBox는 내부에서만 볼 것
  • DepthStencil Type: LESS_EQUAL
    • skybox는 제일 멀리 있으므로 depth가 1이어야 함 (depth: 0~1)
    • depth texture는 초기화 시 1로 세팅되므로 LESS가 아닌 LESS_EQUAL

📌SkyBox 배치

[SkyBox를 배치하는 방법]

1. 실제 SkyBox의 위치 조작
2. Shader로 렌더 시 합성

[(방법1) 실제 SkyBox 위치 조작]

• Main Camera의 위치로 SkyBox 위치를 계속 업데이트
• Cam이 어디에 있든 SkyBox가 보임

[(방법2) Shader로 SkyBox 강제 렌더] : VS에서 Position과 Depth를 Viewspace에 맞춰 세팅해줌

1. SkyBox가 ViewSpace 상에서 원점에 있다고 가정

   • 즉 카메라에 배치되어 있다고 가정
   • VS로 들어온 Skybox Vtx의 Local 좌표를 ViewSpace 상 좌표라고 봄

2. Camera의 회전정보 적용

3. Depth를 최대값으로 밈

   • depth: 0~1의 값
   • 즉 z를 1로 설정해야 함
   • Rasterizer State를 고려해서 투영행렬 결과의 z 자리에 w값을 넣어줌

Rasterizer State : 투영행렬 곱한 결과는 최종좌표가 아님

• 뷰행렬 결과: vX, vY, vZ, vW
• 투영행렬 결과: pX * vZ, pY * vZ, pZ * vZ, vZ
• Rasterizer State: 투영행렬 결과의 w(vZ)로 나눠줌

📒CubeTex

: DX에서 자체적으로 큐브텍스처 샘플링을 진행함

• 텍스처가 큐브로 배치되어 있는 것처럼 봄
• UV 대신 방향벡터 사용

📌OBB 충돌

: 비용이 너무 커짐 (축 15?개)

• 온라인의 경우 서버 부담 증가로 거의 사용하지 않음
• 대체:
  • 거리계산 (radius check)
  • 시야계산 (부채꼴)
  • 타게팅 (mouse position)

[표면의 거칠기를 표현하는 다양한 방법]

• 고퀄리티 모델링
• Normal Mapping (Bump Mapping)
• Tesselation (Displacement Mapping)
• Nanite Virtualized Geometry (Mesh shader) ???

📌Normal Mapping

: Normal에 값을 매핑시켜서, 마치 다른 면인 것처럼 연산함

• Texture Type
• Vtx의 수를 유지하면서 퀄리티 높게 묘사 가능
  • 실루엣: Vtx 수는 그대로 유지하되 가상의 표면 방향을 사용하는 눈속임 기법이므로, 실루엣은 변하지 않음
  • 즉 큐브를 구처럼 만들거나, 튀어나온 무언가를 표현하기에는 한계가 있음
• Normal Texture: 색상 텍스처 (RGB)
  • RGB를 XYZ로 매핑 (Bump Mapping의 상위호환)

[Bump Mapping]

• Texture Type
• 사용: 스크래치, 모공 등 작은 디테일
• Bump Texture: Grayscale
  • 색상값을 Height로 매핑

📌Tesselation

: 그래픽스 셰이더에서 정점 수 늘리기 (쪼개기)

• Shader Technique
• Hull Shader + Domain Shader
• 정점 쪼개기: 임의의 메쉬를 입력받아 동적으로 여러 기본 요소로 세분화함
  • 실루엣: 실루엣의 변화가 표현됨
• 동적 세분화: 현재 시점을 기준으로 메쉬의 어느 부분을 더 세분화해야 하는지 동적으로 결정한다는 뜻
  • 메시의 일부는 높은 해상도와 디테일을 가짐
  • 다른 부분은 매우 낮은 해상도를 가짐
  • ex, 메시의 쿼드가 카메라에서 얼마나 멀리 떨어져 있는지, 현재 카메라가 볼 수 있는지 등을 판단해 쿼드를 완전히 폐기하고 단지 2개의 삼각형으로 처리하거나, 수천개의 삼각형으로 처리하거나 선택
• 장점: 렌더링 속도가 매우 빠름 (Displacement Mapping의 상위호환)

[Displacement Mapping (& Bump Mapping)] : 정점 수 늘리기 (쪼개기)

• Displacement Mapping은 텍스처를 기반으로 메시 정점을 실제로 변환함 (static)
• static한 변환으로 높은 비용 소모

📌Nanite

: 픽셀 스케일의 디테일 및 다수의 오브젝트를 렌더링하는 가상화 지오메트리 시스템

• Geometry System
• tesellation으로 생성된 Vtx를 포함해, 렌더링되는 Vtx를 결정해 성능을 향상시킴
• 클러스터 컬링과 자동 LOD(Level of detail)를 통해 고품질 모델을 빠르게 렌더링

[Nanite]

• UE5에 새롭게 적용된 핵심 기술

  • amd에서는 primitive shader라는 이름으로 지원
  • nvidia에서는 mesh shader라는 이름으로 지원

• 기술목표

  • 버추얼 텍스처링처럼 지오메트리 버전
  • 뷰에 따라 필요한 디테일 수준의 지오메트리 데이터만 가상화
  • 폴리곤 수나 드로 콜의 제약 없이 하이폴리곤 메시를 바로 사용
  • 로우폴리곤 + 노멀 맵 대신 하이폴리곤 모델을 바로 사용 가능

• 작동방식

  • 로드 시: 메시를 hierachy cluster라는 단위로 묶어줌
  • 렌더링 시
    • 카메라 뷰를 바탕으로 클러스트의 LOD가 자동 결정됨
    • 클러스터는 동일한 오브젝트 내에서 인접한 클러스트와 또다시 묶어 부모 클러스터로 만들어줌

• 장점

  • 수동으로 노멀맵을 굽거나 LOD를 적용할 필요가 없기 때문에 최적화 시간을 줄일 수 있음
  • 카메라에 보이는 클러스터만 렌더링하므로 성능이 좋음
    • Oclusion Curing 비교군, 모든 폴리곤을 렌더링하므로 성능이 나쁨
    • Clustur Curing

📒Normal Mapping

📌Normal Texture 좌표계

• (주의) DX식이 아님!
• Unreal식임

📌Normal Texture Type

• Tangent Space: Local 방식
• Object Space: World 방식

[Object Space] : World 좌표 기준으로 표현된 값 (절대값)

• rgb를 world normal의 xyz로 매핑 (Normal Texture 좌표계 기준)
• 장: 연산이 간단함
• 단:
  • Vtx의 변화에 대응하지 못함
    • ex, 3D Animation 등
    • local space 내에서 Vtx가 움직일 수 있음
    • 그런 경우 Normal의 방향이 틀어짐
  • 대상 모델에만 적용 가능
    • 다른 모델에 적용하면 normal이 틀어져 어색함

[Tangent Space] : local 기준으로 표현된 값

• rgb를 local normal의 xyz로 매핑 (Normal Texture 좌표계 기준)
  • Normal의 좌표계 = local 좌표계 = 평면좌표계 = Tangent space
• local -> world space로의 연산 필요

📌Tangent Space 연산

[좌표계 변환에 필요한 정보] : Vtx가 향하는 방향, 즉 Normal 방향을 가상으로 바꿔줌

• Normal, Tangent, Binormal 의 방향 조작 (매핑)

[Normal Texture 읽기]

1. 회전행렬 계산

   • Normal Texture 좌표계는 rgb "B"가 "Z"축이며 Normal Vector임
   • 회전행렬 Normal Texture 좌표계를 고려했을 때
     • X 축: tangent vector
     • Y 축: binormal vector
     • Z 축: normal vector

2. 값 매핑

   • 픽셀의 색상정보(RGB)를 벡터 표현 위한 자료형으로 사용
   • RGB는 각각 0255 저장하며, 셰이더에선 정규화해 01로 표현
   • 음수 표현: 표현 범위를 쪼개 음수와 양수 표현
     • 0 ~ 0.5 : 음수
     • 0.5 : 0
     • 0.5 ~ 1 : 양수
   • 치환식: 샘플값 * 2 - 1
     • 연산결과 -1~1로 표현 가능

3. (OpenGL 용 텍스처인 경우) 좌표계 매핑

   • OpenGL은 y축의 방향이 반대임
   • 해결:
     • Normal Texture 좌표계 기준 Y축, 즉 Binormal 부호를 반전시키거나
     • 텍스처를 DX용으로 바꾸기

References. [1] 3D Simulation: Bump Mapping vs Normal Mapping vs Displacement Mapping [2] About Mapping: https://www.pluralsight.com/blog/film-games [3] Nanite Unreal Doc: 언리얼 엔진의 나나이트 가상화 지오메트리 | 언리얼 엔진 5.1 문서 [4] Nanite Introduction: https://devjino.tistory.com/219 [5] Mesh Shader Nvida Doc: Mesh Sahder | Nvida Devloper

[다양한 라이팅 연산 방법]

• Gouraud shading: 정점에서 라이팅 연산하는 방법
• Pong shading: 픽셀단위로 라이팅 연산하는 방법

📌Gouraud shading

: Vtx에서 광원 연산 후 PS에서 보간값 사용

• 장: 연산량 적음
  • 초창기 그래픽스에서 사용하던 방식
  • 그러나 현재 컴퓨터에선 이정도 연산량 큰 차이 없음
• 단: 어색함
  • 버텍스의 연산 결과를 보간한 값이므로,
  • 이를 평면에 발라 구체를 만들면 어색함

📌Pong shading

: 각 픽셀의 Normal을 보간해 픽셀마다 광원 연산

• 보간된 Normal로 각 픽셀마다 적절한 Lighting 연산 가능
  • 평면이지만 곡면처럼 처리 가능

📒Light Reflection

: 반사된 빛이 카메라를 향하면 더 밝아 보임

📌반사벡터 유도

R = P + 2N(-P·N) 반사벡터 = 입사벡터 + 2표면벡터(-입사벡터·표면벡터)

📌좌표계

: View space 사용

• 반사광 연산은 카메라 정보를 얻어 사용해야 함
• 카메라 정보 :
  • view matrix에서 얻어 사용 가능
  • 좌표계를 view space로 둔다면 카메라와 관련한 연산 용이

📌반사광 연산

• 반사된 빛의 크기

  • Reflection Vector와 Camera의 Eye vector 간 각도 연산
  • 내적:
    • 두 벡터가 반대방향으로 교차할 때 반사된 값이 최대
    • (라이팅 연산처럼) cos 사용하기 위해 내적
    • 반대방향 교차이므로 한 벡터는 뒤집어줘야 함

• 그래프 보정

  • cos의 문제: 그래프가 완만함 (로그그래프처럼 급격히 꺾여야 함)
  • 내적 결과값을 pow해서 그래프 곡선 조절
  • cos 그래프
  • 로그그래프

• 연산 결과 빛처리

  • 결과값 * reflection scale(설정한 반사값)
  • 오브젝트 값이 아닌 라이트값만 영향을 받아야 함

References. [1] Reflection Vector derivation: https://novemberfirst.tistory.com/112

📌복습: VB & IB

• 다각형을 그리기 위해서는 중첩된 정점이 발생함
• Index Buffer: 정점을 재활용하므로 같은 정점을 두 번 만들지 않음
  • 메모리적 이점

📌Normal Vector & Tangent Vectors

3D Vertex에는 정점의 방향 정보가 추가됨

• Normal: (정점 표면 방향 벡터) 표면의 수직 방향으로 향함
• Tangent: (접선 벡터) Normal Vector에 수직이며 UV의 U축으로 향하는 벡터
  • DX에서 UV의 U축은 왼손좌표계 기준 우측으로 향하는 벡터임
• Binormal: (종법선 벡터) Normal Vector에 수직이며 UV의 V축으로 향하는 벡터
  • Normal과 Tangent 벡터에 모두 수직한 벡터

[복습] Vertex Struct 변경 시

• Input Layout 변경

📌추가된 벡터(방향정보)의 사용

: 3D Lighting

• 표면의 normal 벡터와 빛의 진입각을 내적해서 빛을 받는 양 계산

  • 내적하는 이유: cos 그래프 사용하려고
  • 빛이 0도로 진입했을땐 1(최대), 90도로 진입했을땐 0(최소)

• 연산 시 사용하는 Light 방향:

  • 90도를 기준으로 연산해야하므로,
  • 광원에서 나온 Light의 반대 방향을 사용해야 함
  • (~표면으로 들어온 Light의 방향)

📒3D Shader

📌Vertex Shader

: Vtx의 방향 계산

• 단위벡터
  1. 확장: 좌표가 아닌 단위벡터이므로 0으로 확장
  2. Rotate에만 영향받아야 함: World Matrix는 Scaling이 이미 적용되어 있으므로 Normalize 필요
• 좌표계: Local -> World 변환
  • Vtx의 정보는 Local 좌표계 기준으로 들어오지만,
  • Light의 World 방향과 연산 등
  • World상에서의 normal 방향을 표기해 사용해야 하므로
  • World좌표계로 옮겨줘야 함

📌Pixel Shader

: 최종 출력 색상 결정

• Obj color * Light color * Light Pow
• + Obj color * Light Amb color

📌Light Pow의 범위

: 0~1

• 음수일 수 없음
• Ambient color 등 빛의 개념을 의도대로 적용하기 위해선 0~1에서 잘라줘야 함

📒3D Debug Shading

📌Inner Glow

• Sphere의 중앙일수록 Normal이 카메라를 보고
• Sphere의 가쪽일수록 Normal이 카메라와 직교함
• 카메라의 시선벡터 (부호반대)와 내적해서 유사도 계산
• alpha = ~유사도

📒3D Mesh

📌Normal, 평면과 곡면

[평면] : 극단적으로 표면의 각이 변화하는 경우

• ex Cube Mesh
• Normal 공유할 수 없음
• 4*6 개의 Vtx 필요

[곡면] : 표면의 각이 부드럽게 변화하는 경우

• ex Sphere
• Normal 중간값으로 둬서 공유해도 됨

📌Culling

: Cull-Back

• 3D Light 연산

  • CW를 가정한 Vtx 세팅의 연산결과이므로
  • 뒷면(CCW)에서 보더라도 CW의 연산결과를 보게됨
  • ➡️ 그냥 뒷면을 그리지 않게 Cull back 사용

• 뒷면을 그리려면

  • 두 면(앞면 + 뒷면)을 합쳐야 함

📌(곡면예시) Sphere Mesh 만들기

• Vtx: 가로/세로 분할해 접근
• Normal: 본인의 좌표가 Normal임
  • 중점에서 바라보는 방향이 표면의 방향이 되므로

언리얼 공식 가이드 QuickStart를 따라하는 중 생긴 오류 해결 https://docs.unrealengine.com/5.2/ko/unreal-engine-cpp-quick-start/

1. Unreal세팅

https://dev.epicgames.com/community/learning/tutorials/XjvJ/unreal-engine-ue-5-1-visual-studio-2022-installation-guide?locale=ko-kr

2. VS 환경 세팅

만약 설치했는데 구성설정에서 인식을 제대로 하지 못한다면, 최신 업데이트를 진행해준다

1. VS 세팅

https://docs.unrealengine.com/5.1/ko/setting-up-visual-studio-development-environment-for-cplusplus-projects-in-unreal-engine/

2. UnrealVS 설치

• 언리얼 설치경로의 UnrealVS를 찾는다 (\Epic Games\UE_5.2\Engine\Extras\UnrealVS\)
• 사용 버전의 VS 폴더로 들어간다
• UnrealVS.vsix를 설치한다

3. VS 구성설정

구성상태 불량

https://raw.githubusercontent.com/microsoft/vc-ue-extensions/main/Source/.editorconfig

• 명명 규칙 검사기 설정
• HLSL 설정

오류 목록

무시한다. 공식문서에서 VS 에러는 무시하고 Unreal의 콘솔창으로 에러를 확인하라는게 이런 말인 듯? 몰?루

4. VS 연결 확인

https://makerejoicegames.tistory.com/297

5. VS로 빌드하기

VS에서 빌드하면 오류가 발생한다

방법1. VS에서 말고 Unreal에서 build한다

방법2. Unreal에서 live coding을 끄고, VS에서 build한다

Dot Product, Inner Product (내적)

내적이란 두 벡터의 같은 성분끼리의 곱의 합으로, 두 벡터의 곱과 유사하다. 예를 들어 vecotr A(x1, y1)와, vector B(x2, y2)가 있을 때, 두 벡터의 내적인 A · B 는 (x1*x2) + (y1*y2)가 된다.

즉 벡터의 내적은 스칼라값이다. 이 값은, 한 벡터의 방향으로 다른 벡터를 projection_투영_ 시킨 후 곱한 값이다.

내적의 정리1

두 벡터의 내적 값은, 두 벡터의 크기와 두 벡터 사이의 각을 곱한 값과 같다. |a| 는 vector A의 크기이고 θ는 두 벡터가 이루는 각이다.

따름정리

따라서 두 벡터 사이의 cosθ는 위와 같은 정리를 만족한다.

응용: 두 벡터 사이의 각도 구하기 (0 ~ 180도)

따라서 벡터의 내적을 활용해 두 벡터가 이루는 각을 구할 수 있다.

• 두 벡터의 내적으로 cosθ 값을 구할 수 있다.
• arccos(cosθ)를 한다면, θ 값을 도출할 수 있다.
• 이 때 normalized된 단위벡터를 활용한다면 arccos에 넣을 값이 간결해지므로 용이하다

❕두 벡터 사이의 값이 180도가 넘눈다면, 외적 등을 활용해 추가적인 연산을 해야함

❕두 벡터 사이의 값은 arctan으로도 구할 수 있음

❕ 응용문제: https://rangsub.tistory.com/15

내적의 정리2

두 벡터의 내적 값으로 두 벡터의 유사도(진행방향 사이의 관계)를 판단할 수 있다. cos의 그래프를 떠올리면 쉽게 연상 가능하다.

• 내적 값이 0이라면, 두 벡터는 수직이다
• 내적 값이 양수라면, 두 벡터 사이의 각은 90도보다 작다
• 내적 값이 음수라면, 두 벡터 사이의 값은 90도보다 크다

Projection

두 벡터의 내적은 개념적으로 한 벡터의 방향으로 다른 벡터를 투영시켜 곱한다. 즉, 어떤 vector V를 단위벡터 N에 내적한다면, V의 N의 방향으로의 길이를 구할 수 있다.

내적을 사용하는 이유

두 벡터 사이의 각도를 구하려면 arccos 함수를 사용해야 하는데, 삼각함수를 남발하면 프로그램의 성능이 하락할 수 있으므로 몇 번의 곱셈과 덧셈으로 끝나는 내적을 사용하는 것이 이득이다.

내적의 응용사례

• 3D에서 면이 빛을 받음을 계산할 때 (즉, 명암처리 시)
• 3D에서 면이 카메라를 향하는지 계산할 때 (즉, Normal 판단 시)
• 반사 벡터를 구할 때
• 그림자를 구할 때

References [1] 내적의 정의 : https://m.blog.naver.com/mindo1103/90103350914 [2] 두 벡터의 사이각 구하기 : https://asteriskhun.tistory.com/40 [3] 벡터의 내적 응용문제 : https://rangsub.tistory.com/15 [4] 반사벡터 구하기 : https://novemberfirst.tistory.com/112

처리 방식

culling에는 [Z sroting]과 [ Z buffer] 방식 등이 있다.

• (A) Z sorting:
  • 간단함
  • 물체끼리 교차하는 전후관계를 결정하기 어려울 때 제대로 렌더링되지 않음
  • sorting에 시간이 걸림
• (B) Z buffer: 거리를 픽셀 단위로 기록하기 위한 [ Depth Buffer ] 필요
  • 전후관계를 픽셀단위로 판단할 수 있음
  • 일반적으로는 Z 버퍼 기법을 사용
  • 반투명인 물체가 있으면 depth buffer만으로는 제대로 렌더링할 수 없음
• alpha sorting: Z buffer로 불투명한 물체 렌더링
  • 불투명 물체를 먼저 렌더링해 둠
  • 반투명 물체를 뒤에서부터 sorting하여 렌더링한다
• Stencil Buffer: 여러가지 효과를 표현하는데 쓰이는 [Stencil Buffer ]를 사용하는 경우도 있음
  

DepthStencil Buffer

DirectX 11에서 Depth Buffer와 Stencil Buffer는 1개의 리소스를 공유하므로, [ DepthStnecil Buffer] 라고 묶어서 취급한다.

• [ render target ] 과 조합해서 사용
• 렌더타겟은 동시에 8개까지 설정할 수 있지만 깊이/스텐실 버퍼는 1개 뿐이다.

DirectX 11 의 처리 흐름도는 크게 다음과 같다.

• (1) Device & Swap Chain 생성
• (2) Depth/Stencil Buffer 생성
• (3) render target 설정: SwapChain의 BackBuffer (depth/stencil view 설정)
• (4) 어플리케이션 실행, 필요한 처리 수행
  • 일정간격으로 화면을 렌더링하고 swapChain으로 화면 갱신
  • 윈도우 사이즈의 갱신에 따라 백 버퍼를 리사이징한다
• (5) 종료 처리

header

DirectX 11 library 참조

#include <d3d11.h>
#include <d3dcompiler.h>
#include <DirectXMath.h>
#pragma comment(lib, "d3d11")
#pragma comment(lib, "d3dcompiler")
using namespace DirectX;

Smart Pointer library 참조

#include <wrl.h>
using namespace Microsoft::WRL;

Smart Pointer

DirectX의 Reference Counter는 객체에 대한 이해가 필요하므로 관리가 어렵다. 용이한 관리 위해 MS에서 만든 Smart Pointer 기능을 사용한다.

• 원리: template class로 생성, 소멸자에서 해제될 때 release하는 식

  • ``` template class ComPtr { private: T* m_Ptr; public: void* GetAddressOf(){return &m_Ptr;} T* Get(){return m_Ptr;} public: ComPtr() :m_Ptr(nullptr){} ~ComPtr(){ if(m_Ptr) Release(m_Ptr); } }

  • 기본생성자 호출되므로 직접 초기화할 필요 X
  • 직접 해제 관리할 필요 X
• Caution
  • 접근지점을 명확히 정해야 함
  • GetAdressOf() : 멤버포인터의 주소를 넘김 (doublePointer)
  • Get() : 멤버포인트가 가진 주소를 넘김 (Pointer)
    

Step0. Feature Level 결정

Feature Level

DirectX 11에서는 6단계의 Feature Level을 정의하여 이전 버전의 디바이스여도(DirectX 9/10/10.1) 호환 가능하다. 어플리케이션은 Feature Level에 따라 DirectX 11의 기능을 사용해 실행된다. 이 전 포스팅에서도 설명하였지만 DirectX 11의 기능은 피처 레벨에 의해 6단계로 나누어져있다

• feature level: GPU가 서포트하는 기능셋의 엄밀한 정의
• 기본적으로는 level은 하위 level의 기능 포함함
• 디바이스를 생성할 때 낮은 기능 레벨을 지정하면 DirectX 9, DirectX 10 하드웨어에서도 DirectX 11을 사용 가능

about D3D_FEATURE_LEVEL

// array of feature levels
 D3D_FEATURE_LEVEL featureLevels[] =                             
{
    D3D_FEATURE_LEVEL_11_0,
    D3D_FEATURE_LEVEL_10_1,
    D3D_FEATURE_LEVEL_10_0,
};
>
// array size
UINT numFeatureLevels = ARRAYSIZE( featureLevels );
>
// device 생성 시 넘길 feature level 변수
D3D_FEATURE_LEVEL       g_featureLevel = D3D_FEATURE_LEVEL_11_0;    

Step1. Device & SwapChain 생성

DirectX 11을 사용하려면 [ Device ] [ Device Context ] [ SwapChain(DXGI) ] 인터페이스를 얻어야 한다. D3D11CreateDeviceAndSwapChain 함수를 사용하면 위에서 언급한 3개의 인터페이스를 한번에 얻을 수 있다.

interface 변수 선언

// interface
ComPtr<ID3D11Device> pDevice;
ComPtr<ID3D11DeviceContext> pImmediateContext;
ComPtr<IDXGISwapChain> pSwapChain;

Device flag 설정 debug version에서는 D3D11_CREATE_DEVICE_DEBUG를, release version에선 0으로 설정한다.

• D3D11_CREATE_DEVICE_DEBUG: 세팅하는 경우 GPU의 log 출력됨

  UINT createDeviceFlags = 0;
  #ifdef _DEBUG
    createDeviceFlags |= D3D11_CREATE_DEVICE_DEBUG;
  #endif

Swap Cahin 설정 DXGI_SWAP_CHAIN_DESC 구조체를 사용해 설정할 수 있으며 백버퍼 설정, SwapChain과 관련할 윈도우 멀티샘플 설정, 화면모드 설정 등을 지정한다.

• 해당 멤버들은 디폴트 동작이 0으로 설정되어 있는 경우가 많으므로 모든 멤버를 설정하지 않을 경우에는 ::ZeroMemory 함수로 초기화하는 것이 편리함
• 1600*900 resolution의 backBuffer 1개 SwapChain을 설정하는 예

  DXGI_SWAP_CHAIN_DESC sd;
  ZeroMemory( &sd, sizeof( sd ) );                    // 구조체 초기화  
  >
  sd.BufferCount = 1;                                    // backBuffer Count                                               
  sd.BufferDesc.Width = 1600;                            // backBuffer Resolution
  sd.BufferDesc.Height = 900;                                                 
  sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;  // backBuffer Format
  sd.BufferDesc.RefreshRate.Numerator = 60;           // 화면 주사율 (기본적으로 60/1)
  sd.BufferDesc.RefreshRate.Denominator = 1;
  sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;    // backBuffer 용도
  sd.OutputWindow = g_hWnd;                           // buffuer output window
  sd.SampleDesc.Count = 1;                            // multi sampling count
  sd.SampleDesc.Quality = 0;                          // multi sampling quality
  sd.Windowed = TRUE;                                 // window mod

D3D11CreateDeviceAndSwapChain 호출

• D3D11CreateDevice, CreateSwapChain으로 나누어 호출해도 됨
• CreateSwapChain: Factory가 호출
  • SwapChain 생성 과정: Device -> Adapter -> Factory -> Swapchain

    hr = D3D11CreateDeviceAndSwapChain( NULL,                //사용할 IDXGIAdapter 인터페이스
                                    D3D_DRIVER_TYPE_HARDWARE, //DirectX 11 디바이스 종류
                                    NULL,               //보통  NULL
                                    createDeviceFlags,  //디바이스 플래그
                                    featureLevels,      //featureLevel 사용할 배열
                                    numFeatureLevels,   //featureLevel arr count
                                    D3D11_SDK_VERSION,    //DirectX SDK 버전
                                    &sd,                //스왑체인 구조체
                                    pSwapChain.GetAddressOf(),
                                        //할당할 SwapChain 인터페이스 포인터
                                    pDevice.GetAddress(), //할당할 Device 인터페이스 포인터
                                    &g_featureLevel,    //featureLevel 얻어낼 포인터
                                    pImmediateContext.GetAddressOf() );
                                        //할당할 Device Context 인터페이스 포인터

Step2. BackBuffer & DepthStencilBuffer 설정

swapChain의 backBuffer는 render target으로 설정되어 있지 않다. swapChain으로부터 backBuffer를 얻어 Device의 renderTarget으로 설정해야 한다.

Get BackBuffer SwapChain으로부터 BackBuffer를 얻어온다.

• IDXGISwapChain::GetBuffer 함수: backBuffer의 포인터 얻음

  ComPtr<ID3D11Texture2D> pBackBuffer;
  hr = pSwapChain->GetBuffer( 0, __uuidof( ID3D11Texture2D ), ( LPVOID* )pBackBuffer.GetAddress() );
  >
  if( FAILED( hr ) )
    return hr;

Create Render Target View texture는 view를 통해 pipeline과 access한다. render target view는 D3D11_RENDER_TARGET_VIEW_DESC 구조체로 설정하며, 디폴트 설정으로 NULL을 넘긴다.

hr = g_pd3dDevice->CreateRenderTargetView( pBackBuffer.Get()
                                    //access할 resource
                                , NULL
                                , &pRenderTargetView.GetAddressOf() );
                                    //render target view를 받아올 변수 ptr
if( FAILED( hr ) )
    return hr;

Create Depth Stencil Texture D3D11_TEXTURE2D_DESC 구조체로 설정한다.

• DepthStencil Buffer: https://velog.io/@howru_dv/Culling

  D3D11_TEXTURE2D_DESC Desc = {};
  ZeroMemory( &descDepth, sizeof(descDepth) );    //초기화
  Desc.Format = DXGI_FORMAT_D24_UNORM_S8_UINT;     // depth 24bit + stencil 8bit
  Desc.Width = (UINT)m_vRenderResolution.x;         // render target texture 해상도와 같아야 함
  Desc.Height = (UINT)m_vRenderResolution.y;
  Desc.BindFlags = D3D11_BIND_DEPTH_STENCIL;         // 용도
  Desc.CPUAccessFlags = 0;                         // CPU 접근 불가
  Desc.Usage = D3D11_USAGE_DEFAULT;
  Desc.SampleDesc.Count = 1;                         // multi sampling
  Desc.SampleDesc.Quality = 0;
  Desc.MipLevels = 1;                             // 저퀄리티 버전 사본 생성여부
  Desc.MiscFlags = 0;                                // 그 외 설정 없음
  Desc.ArraySize = 1;
  >
  hr = m_Device->CreateTexture2D(&Desc, nullptr, m_DSTex.GetAddressOf());
  if (FAILED( hr ))
    return hr;

Get Depth Stencil View

• ID3D11DepthStencilView 인터페이스 사용
• ID3D11Device::CreateDepthStencilView 함수로 생성

  m_Device->CreateDepthStencilView(m_DSTex.Get(), nullptr, m_DSView.GetAddressOf());

Set RenderTarget Output Merger(OM)에서 render target을 설정한다. 렌더타겟은 동시에 8개까지 설정할 수 있지만 깊이/스텐실 버퍼는 1개 뿐이다.

• ID3D11DeviceContext::OMSetRenderTargets() 함수를 통해 설정한다

  g_pImmediateContext->OMSetRenderTargets( 1                    //renderTarget count
                                       , pRenderTargetView.GetAddressOf()
                                                               //renderTargetView arr pp
                                       , m_DSTex.Get() );    //DepthStencil

Step3. Viewport 설정

viewport는 render target의 rendering 영역에 대한 설정이다. render target에 rendering하려면 각 render target마다 viewport를 설정해야 한다.

• ID3D11DeviceContext::RSSetViewports() 함수로 viewport 설정
• D3D11_VIEWPORT 구조체로 수행하며, float 형으로 사용
  

Position

geometry shader, 또는 vertex shader로부터 출력되는 vertex의 위치좌표(3D)는 투영변환 후 투영좌표계의 값이 된다 (x,y = -1 1, z = 01) rasterizer는 뷰포트변환을 수행해 3D 투영좌표계로부터 2D 스크린 좌표(x,y = 0~1)을 계산한다

• 스크린 좌표: 왼쪽 상단이 0,0 으로 Y축이 아래를 향하는 좌표계
  • (0,0): backBuffer의 왼쪽 상단
  • (1,1): bakcBuffer의 오른쪽 하단
• viewport 변환식:
  • X = (Y+1) * ViewPort.Width * 0.5 + ViewPort.TopLeftX
  • Y = (1-Y) * ViewPort.Height * 0.5 + ViewPort.TopLeftY
  • Z = ViewPort.MinDepth + Z * (ViewPort.MaxDepth - ViewPort.MinDepth)

Viewport 설정

D3D11_VIEWPORT vp;
>
vp.Width =1900.f;
vp.Height = 600.f;
vp.MinDepth = 0.0f;
vp.MaxDepth = 1.0f;
vp.TopLeftX = 0;
vp.TopLeftY = 0;
g_pImmediateContext->RSSetViewports( 1, &vp );  // rasterizer viewport setting

References [1] DirectX Tutorial: https://blog.naver.com/sorkelf/40161126408

DirectX

DirectX는 Windows 프로그램에 고성능 하드웨어 가속 멀티미디어 지원을 제공하는 low-level의 응용 프로그래밍 인터페이스(APl) 집합이다.

[그래픽 하드웨어 연결]

• DirectX는 응용 프로그램과 그래픽 하드웨어를 연결함
• 사용자는 해당 그래픽 하드웨어가 DirectX 대응장치이기만 한다면, 하드웨어의 세부사항을 알 필요 없음
• DirectX API를 이용해 그래픽 하드웨어에 접근하고, 물체를 렌더링하는 등의 작업 가능
  

[응용 분야 - 게임 개발]

• 윈도우, 세가, 드림캐스트, 마이크로소프트 엑스박스 및 엑스박스 360 등을 위한 비디오 게임 개발에 많이 사용

Features of DirectX 11

Compute Shader

Compute Shader를 지원함으로써 *(1)그래픽스 처리* 이외에도 *(2)데이터를 병렬처리*할 수 있는 범용적인 프로세서로써 GPU를 활용할 수 있다.

• Compute Shader는 DirectX Device를 통해 그래픽스 계열 shader와 resource를 공유하지만, 다른 shader와 직접 연결되진 않음
• CPU: OS나 일반 어플리케이션 등을 실행하는 범용 프로세서
• GPU: 그래픽스 처리에 특화된 전용 프로세서

//

DirectXGI

Direct3D 11은 기초적인 그래픽스 기능을 제공하는 DirectXGI 상에 구축되어 있다.

DirectXGI는 여러 그래픽 API에 공통인 그래픽 관련 작업들을 묶은 것으로, 커널 모드 드라이버 및 시스템 하드웨어와 통신한다. DXGI가 담당하는 영역에는 페이지 전환(스왑체인), 어댑터, 모니터, 디스플레이 모드 등의 그래픽 시스템 정보 등이 있다.

• 간접 조작: DXGI 기능은 Direct3D 11로 접근하므로 어플리케이션 측에서 직접 조작하는 경우는 거의 없음
• 직접 조작: gamma collection이나 출력 디스플레이 선택하는 등의 컨트롤이 필요할 경우

//

Swap Chain

스왑 체인은 프론트버퍼, 백 버퍼를 포함한 복수의 버퍼의 집합과 이들 사이의 전환 방식의 집합이다. double buffering의 일종으로, 화면에 그려질 때 깜빡임(flicking)이나 찢어짐(tearing) 현상을 막기 위한 트릭이다.

DirectXGI의 기능으로써 제공된다.

• 메모리 영역: 거의 항상 디스플레이 하위시스템의 메모리에 만들어짐 (대부분 그래픽 카드이지만, 마더보드에도 구현 가능)
• Presenting: 페이지를 전환하는 것, 즉 프론트 버퍼와 백 버퍼를 교환해서 화면 상에 백 버퍼를 그리는 행위
  

[복수의 버퍼 집합] DirectX에서는 화면표시, 렌더링을 위해 Front Buffer와 Back Buffer를 사용한다.

• Front Buffer: 디스플레이에 표시되는 화면 데이터를 가진 버퍼
• Back Buffer : 다음 업데이트 내용 씀
  

[버퍼 전환] 렌더링이 끝났을 때 Front Buffer의 내용을 갱신한다.

• 갱신 작업 중에는 back buffer에도 렌더링할 수 없음
• 렌더링 퍼포먼스의 저하를 막기 위해 3개 이상의 버퍼를 준비하는 것도 가능

//

Device

DirectX 11 에서는 멀티 스레드 호환이 강화되었다. DirectX 10의 Device가 11에서는 Device와 DeivceContext로 분할됐다.

• Device: GPU 메모리 관리 & 리소스 생성
• Device Context: GPU 렌더링 명령
  

[Device] 리소스 생성에 주로 사용한다. (렌더 타겟 뷰, 상태 변수의 생성 등등에 사용) 각 응용 프로그램에는 하나 이상의 장치가 필요하다. 대부분은 하나의 장치만 만든다.

• ID3D11Device 인터페이스로 표시
• D3D11CreateDevice로 디바이스를 생성하거나, D3D11CreateDeviceAndSwapChain으로 device와 swap chain을 동시에 생성
  

[Device Context] device의 설정을 담당한다. device에서 소유하는 resource를 사용해 파이프라인 상태를 설정하고, 렌더링 명령을 생성할 수 있다.

• 생성된 자원들을 실제로 사용
• 파이프라인 자체를 조작

예시로 상태 변수가 있다. DepthStencilState 같은 상태 변수를 만들었다면 장치 컨텍스트에 적용시켜줘야 한다.

• ID3D11DeviceContext 인터페이스로 표시
• Imediate Context: device에 직접 렌더링, device에 1개만 존재
• Deferred Context: main render thread 이외 worker thread에서 사용

//

Tessellation

Tessellation은 정밀도가 낮은 primitive data를 분할해, 보다 정밀한 primitive를 생성해 출력하는 기능이다.

[Tessellation OFF]

[Tessellation ON]

DirectX 11의 graphics pipeline에는 tessellation을 수행하는 1개 stage와 2개 shader(hull shader, domain shader)가 추가돼 realtime으로 tessellation을 수행할 수 있다.

• primitive: DirectX에서 렌더링하는 도형의 최소단위 (ex 점, 선, 삼각형 ...)
  

//

Dynamic Shader Link

shader를 pipeline에 할당할때 shader code를 드라이버에 최적화할 수 있다.

• 다양한 기능의 셰이더를 사용하기 위해 모든 기능을 갖춘 셰이더를 만들거나, 필요한 조합의 셰이더를 모두 만들 필요가 없어짐
• 퍼포먼스, 리소스 관리 측면에서 이점

Basic Concept

Texture & Format

DirectX에서는 *특정한 형식을 따르는 자료를 텍스처*로 저장한다.

• GPU 필터링, 다중표본화 등의 연산을 텍스쳐에 적용할 수 있음
• format: 특정 포맷을 따르는 자료만 저장 가능
  

[DXGI_FORMAT 예시들] 텍스처의 자료형들은 DXGI_FORMAT이라는 열거형으로 저장된다.

DXGI_FORMAT_R32G32B32_FLOAT     // red,green,blue 32bit float
DXGI_FORMAT_R16G16B16A16_UNORM     // red,green,blue,alpha 16bit로 0~1사이 Normalized 값
DXGI_FORMAT_R32G32_UINT         // red, green 32bit 정수
DXGI_FORMAT_R8G8B8A8_UNORM         // red,green,blue,alpha 8 bit로 0~1값
DXGI_FORMAT_R8G8B8A8_SNORM         // red,green,blue,alpha 8 bit로 -1~1 값
DXGI_FORMAT_R8G8B8A8_SINT         // red,green,blue,alpha 8 bit로 -128~127 값
DXGI_FORMAT_R8G8B8A8_UINT         // red,green,blue,alpha 8 bit로 0~255 값

• 자료형에는 색상 정보 외에도 3차원 벡터와 같은 다양한 값을 담을 수 있음

DXGI_FORMAT_R8G8B8A8_TYPELESS     // TYPELESS형

• Typeless: 메모리만 확보해두고 해석 방식은 텍스쳐를 파이프라인에 묶을 때 결정

//

Resource

GPU가 어떤 일을 하기 위해선 shader 프로그램이 필요한데, *shader에 넘겨주는 데이터를 Resource*라고 한다. Scene을 구성하는 기하 도형, 텍스처, 쉐이더 데이터가 모두 resource다. resource는 buffer와 texture로 구성된다.

• buffer resource: 1차원 배열(vertex buffer, index buffer 등)
• texture resource: 이미지 형태 데이터

생명주기: 생성 -> 바인딩 -> 해지

• Device가 생성
• Device Context에 의해 pipeline binding
• 다 쓰고 나서 Release() 함수로 resource 할당 해제
  

//

Resource View

resource view는 *resource를 rendering pipeline에 binding*해줄 수 있는 객체이다. 하나 이상의 graphics pipeline 단계에서 같은 resource에 접근할 때 resource view로 접근한다.

• 여러 단계의 pipeline은 모두 하나의 같은 resource에 접근
• 파이프라인 단계마다 resource를 할당하고 복사하지 않기 위해 view 사용
  

[예외] resource는 view를 통해 pipeline에 binding하지만, view 없이 binding 가능한 resource도 있다.

• Vertex Buffer
• Index Buffer
• Constant Buffer
• Stream Output Buffer
  

[Resource view list]

• Render Target View
• Depth Stencil View
• Shader Resource View
• unordered access view (DirectX 11에서 추가)
  

//

Render Target View

resource view의 일종으로, Device의 back buffer에 binding되며 생성된다. rendering pipeline의 출력 중 색상 값을 담는다.

[render target] render target은 rendering 대상이다. 예를 들어, texture에 그린다면 texture가, window에 그린다면 back buffer가 render target이다.

[pipeline binding] back buffer에 장면을 출력하려고 할 때 render target view를 파이프라인의 마지막 단계인 Output Merget State (OM)에 binding해야 한다.

• back buffer를 pipeline에 직접 binding할 수 없음
• 즉, pipeline에서 주는 정보가 back buffer로 바로 연결될 수 없음
• pipeline -> render target view -> render target -> graphic device
  

[render target 설정] render target 설정 render target을 설정할 때는 우선 render target view를 만들어준 후, Device Context에서 설정한다.

// backBuffer의 포인터로 render target view 생성
result = m_device->CreateRenderTargetView(backBufferPtr, NULL, &m_renderTargetView);

// device context 설정
result = D3D11CreateDeviceAndSwapChain(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, 0, &featureLevel, 1,
        D3D11_SDK_VERSION, &swapChainDesc, &m_swapChain, &m_device, NULL, &m_deviceContext);

// device context에 render target 설정
m_deviceContext->OMSetRenderTargets(1, &m_renderTargetView, m_depthStencilView);

//

Depth Stencil View

rendering pipeline의 출력 중 depth와 stencil 값을 담는다.

OM에서 쓰이며, depth와 stencil 모두 output test에 쓰이므로 하나의 view로 묶는다.

[stencil] 스텐실 값은 두 개 이상 오브젝트가 겹쳤을 때 뭘 표시할지 나타낸다. depth test와는 달리 앞-뒤 값으로 결정짓는 것이 아니라, 상황에 따른 stencil 값의 대소를 따져 앞-뒤를 계산한다

[code]

// OM setting 시 render target view와 depth stencil buffer를 함께 binding한다
m_deviceContext->OMSetRenderTargets(1, &m_renderTargetView, m_depthStencilView);

//

Basic Matrix

• Perspective Projection Matrix 원근 투영 행렬: 3D 화면을 2D viewport space으로 변환
• Orthographic Projection Matrix 직교 투영 행렬: UI와 같은 2D의 요소를 그리기 위해 사용
• World Matrix: 오브젝트의 좌표를 3D 세계의 좌표로 변환, 3차원 공간에서의 회전/이동/크기 변환
• View Matrix: 현재 장면에서 카메라 위치, 방향 계산

Graphics Pipeline

• 📢필수📢 Input-Assembler (IA) : Vertext Shader에 필요한 데이터 전달 리소스로부터 데이터를 읽어 들여 파이프라인에 데이터를 제공
  • Vertex Buffer 와 Index Buffer : 각 프리미티브 정보는 [ 버텍스 버퍼 ] 와 [ 인덱스 버퍼 ] 에 저장하여 파이프라인에 넘김
• 📢필수📢 Vertext Shader : 정점의 월드 변환과 뷰 변환 등 필요한 처리
• 🔈선택🔈Hull Shader : Tesselation 기능 구성 shader. 132 개의 [ 컨트롤 포인트 ] 를 입력받아, 132개의 [컨트롤 포인트] [배치 정수] [테셀레이션 계수] 를 출력
• 🔈선택🔈Tessellator : Tesselation 기능 구성 stage. [ 쿼드 배치 ] [ 삼각형 배치 ] [ 선 ]을 입력받아, 보다 정밀한 다수의 [삼각형] [선] [점]을 출력
• 🔈선택🔈Domain Shader : Tesselation 기능 구성 shader. [ Hull Shader ] 와 Tessellator의 출력을 입력받아, 배치 내의 각 vertex 좌표를 출력
• 🔈선택🔈Geometry Shader : primitive data 1개를 입력받아, primitive의 변형이나 새로운 primitive의 생성을 수행한 후, 0개 또는 1개 이상의 primitive data 출력
  • Stream Output : GS 나 VS 로부터 출력을 리소스 내의 버퍼에 씀
• 📢디폴트📢 Rasterizer : 각 정점을 보간해 pixel shader에서 사용할 pregment(픽셀별 정보) 생성
• 📢필수📢 Pixel Shader : 픽셀 데이터 1개를 입력받아, 텍스처 처리나 라이팅등을 수행한 후, 픽셀 데이터 1개 출력
  • GPU 사용하는 주요 원인
  • 연산 횟수가 가장 많음 (단순 반복 작업)
• 📢디폴트📢 Output-Merge(OM) 출력 병합기 : pixel shader에서 들어온 색상을 가지고 render target, depth, stencil 등을 고려해, 어떤 걸 표시하고 표시하지 않을지 + 최종 렌더링 색 결정함
  • OM에서 계산된 픽셀 색상이 백 버퍼에 그려져서 화면에 보임

References [1] DX11 Feature: https://blog.naver.com/sorkelf/40160740465 [2] DX Basic Concept: https://dev-nicitis.tistory.com/46 [3] Graphics Pipeline: https://learn.microsoft.com/ko-kr/windows/uwp/graphics-concepts/graphics-pipeline

Library란? c언어에서 library는 모듈화를 지원하는 개념이다.

• 목적: 특정한 기능을, 반복적인 코드 작성을 하지 않고 필요한 곳에서 재사용하기 위함
• 형태: 프로그램이 연결할 수 있는 패키징된 object 파일들의 모음
• 컴파일된 형태인 object code로 존재하므로(미리 컴파일 되어있으므로) 컴파일 시간 단축됨
  기본적으로 C Programming은 소스 파일을 컴파일하고 그 결과물을 실행한다. 코드가 많아지면 소스파일을 여러 파일로 나누어 격리하고, 목적에 맞는 코드들을 모아 Library를 만든다. Library는 각각 컴파일되며 링크 단계에서 execute file에 라이브러리(object code)가 연결된다.

특징 header와 구현부가 분리된다.

• 배포하기 쉬움
• 구현부를 binary code로(.lib 등) 감출 수 있음

예시 게임엔진에서 sound를 처리하기 위해 FMOD를 사용함

• sound 기능을 이미 잘 구현된 library 활용해 처리
• library만 참고해도 내부 함수 사용 가능

Types of Library

Library Type object code가 Linking되는 방법에 따라 나뉜다.

• Static Library
• Dynamic Linking Library (DLL)
  기능이 추가되면 library의 코드도 많아지고, 각 역할에 맞는 library도 많아져 실행 바이너리의 크기는 점점 증가한다. 한 번만 실행하면 괜찮을 수 있겠지만, 여러번 실행되면 많은 메모리 영역을 차지하고, 그러면 더 많은 메모리가 필요하다.
  따라서 메모리 관리 측면에서, 단일 실행에 적합한 Static Library와 다중 실행에 적합한 Dynamic (Linking) Library 로 library 형태를 구분지을 수 있다.

Library Type과 메모리 영역

• Static Library: Text Segment (execute file에 포함됨)
• Dynamic Linking Library: Memory Mapping Segment (library process 공유)

Static Library

concept compile time에 library가 link된다.

• object code(*.lib)가 실행 바이너리에 포함됨
• 각 프로세스는 자체 코드 및 데이터 복사본을 얻음

장점

• runtime 추가 loading 비용 없음: library code는 compile time에 연결되므로 최종 execute file은 runtime 시 library에 종속되지 않음
• 빠른 속도: 동적 쿼리 등 추가작업 없이 독립적으로(실행 바이너리만으로) library functions 사용 가능
• 실행 안정성: 한번 execute file을 생성하면, 추후 static library가 제거되더라도 이미 생성된 실행파일을 실행하는 데는 문제 없음

단점

• 바이너리 파일 크기 & 메모리 공간: binary file의 크기가 커지므로 더 많은 공간 필요
• update: library를 update할 경우 메인 프로그램을 다시 컴파일해야 함

사용

#include <*.h>
#pragma comment(lib, "*.lib")

Dynamic Linking Library (DLL)

Concept runtime에 library가 link된다

• object code(*.lib)가 실행 바이너리에 포함되지 않음
• 라이브러리 프로세스(DLL)는 별도로 존재하며, 각 (실행파일)프로세스는 이를 공유해 사용
• 특정 시점에 연결하거나, 연결을 끊을 수도 있음

Output File

*.Lib: DLL의 "Implict Linking" 위한 링크 정보

• DLL이 제공하고자 하는 함수 정보(함수명)을 가지는 object file
• 프로그램 실행될 때 어떤 DLL을 쓰겠다는 정보 저장

*.DLL: 구현부(binary부)

• lib의 모든 코드 구현
• DLL은 OS에서 두 개 이상 실행되지 않음
• execute file 위치에 함께 존재해야 함

장점

• 바이너리 파일 크기 & 메모리 공간: 더 작게 사용
• update: library를 update하더라도, 이전 버전과 바이너리가 호환되면 다시 컴파일하지 않아도 됨

단점

• 실행 시간: 매번 library 주소에 접근해야 하므로 static library보다 느림
• 호환성 문제: library가 이미 메모리에 올라가 있지만 변경된 경우, 두 버전의 바이너리가 호환되지 않으면 호환성 문제가 생길 수도 있음(다시 링크해야 함)

Types of Linking (DLL)

• Implicit Linking 암시적 링킹
• Explicit Linking 명시적 링킹

Implicit Linking execute file 자체에 어떤 DLL의 어떤 함수를 사용하겠다는 정보를 포함시킨 링크 방식.

• DLL의 *.lib 파일 사용
• 링크 단계: 실행 바이너리의 *.obj 파일들과 DLL의 *.lib 파일을 함께 링크
• 실행 단계: OS가 프로그램 실행 시(runtime) DLL의 함수 코드를 참조

Explicit linking 프로그램이 실행 중일 때 API를 이용하여 DLL 파일이 있는지 검사하고 동적으로 원하는 함수만 불러와서 사용하는 링크 방식.

• *.lib 파일 필요 없음
• 실행 단계: DLL이 필요한 시점에서 로딩하고, 불필요해지면 반환

특징

• 메모리 절약
• 프로그램 실행 중 DLL 교체 및 선택 가능
• 필요한 순간에 하나씩 DLL을 로딩할 수 있으므로 DLL 로딩에 걸리는 시간 분산 가능

예시: Unreal Engine

• 사용자 코드를 DLL로 만듦
• 코드가 Update되는 경우 이전 버전과 메모리 연결 끊고 다시 빌드, 연결

예시: 언어 설정 등의 분기 경우

• DLL을 사용해서 코드 분기하는 케이스
• 같은 함수를 찾아 호출하지만, ~한 경우에는 A, ~한 경우에는 B

Usage

<library header>

• export & import

  #define DLL_EXPORT extern "C" __declspec(dllexport)
  #define DLL_IMPORT extern "C" __declspec(dllimport)

• 하나의 헤더로 묶어 처리

  #ifdef DYNAMICLIB_EXPORTS
  #define MY_DLL extern "C" __declspec(dllexport)
  #else
  #define MY_DLL extern "C" __declspec(dllimport)
  #endif

• library 내에서 사용할 함수, 외부로 공개할 함수 구분 가능

  • export 선언이 있어야 외부로 나감
  • import 선언이 있어야 참조함

<Source.cpp>

# include <*.h>

• Implict Linking

  # pragma comment(lib, *.Lib)

• Explict Linking

  // Load DLL
  HMODULE hDllHandle = LoadLibrary(L"LibName.dll");
  if (!hDllHandle)
    return 0;
  >
  // Call DLL Function
  // - Funtion Pointer
  typedef int(*FUNC_TYPE)(int);
  FUNC_TYPE pFunc = nullptr;
  pFunc = (FUNC_TYPE)GetProcAddress(hDllHandle, "FuncName");
  if (pFunc)
    int data = pFunc(87);

• LoadLibrary : 필요한 DLL을 프로세스 가상 메모리에 맵핑

• GetProcAddress : DLL 함수의 포인터 획득

• FreeLibrary : 프로세스 가상 메모리에서 DLL 반환