동차 표기법은 무엇인가 많이 검색하고 찾아봤지만 나에게는 다 두루뭉실하게 들렸다ㅠ

내가 정의한 동차 표기법은

"차원을 하나 더 추가하는 표기법" 이다.

하나 더 추가하는 이유는 그 차원의 값을 통하여 여러가지 계산을 쉽게 할 수 있기 때문이다.

실제로 차원이 더 늘어나는게 아님

예를들어 3차원에서 3x3행렬으로도 회전, 스케일링 등의 선형변환을 나타낼 수 있다.

하지만 이동은 3x3행렬로 표현할 수 없다

그래서 한차원을 추가해서 4x4행렬로 만든다면 행렬곱을 통하여 이동 및 여러 변환을 쉽게 시킬수가 있다.

한차원을 추가 : 3차원 (x, y, z) => 4차원 (x, y, z, w)

또 다른 기능이 있는데 방향벡터와 위치벡터를 구분해줄수있다.

벡터에는 위치를 나타내는 위치벡터와 방향을 나타내는 방향벡터가 있다.

근데 방향벡터에 이동이 필요한가?

한다면 정규화된 값이 방향벡터이라 의미가 없다고 생각한다.

그렇기 때문에 방향 벡터는 w의 값을 0, 위치벡터는 w의 값을 1로 사용하여

두 벡터를 구분할 수 있다.

이는 VertexShader에서 확인이 가능한데

다들 Vs를 작성해봤었다면 정점의 위치는 float4, 방향벡터는 float3로 정의하여 값을 옮겼을 것이다.

위치데이터가 float4인 이유는 바로 저 동차표기로 이동을 계산해야하기 때문이다.

그래서 float4로 정의하면 w값에 1이 초기값으로 들어간다.

Normal은 방향벡터로 w가 쓸일이 없으니까 굳이 w값까지 필요 없기에 float3로 받아오는것이다.

또 다른 사용의도가 있는데 이번에는 Pixel Shader에서 화면 비율과 관련된 의도인데

아직 사용을 안해봐서 직접해보고 추가로 작성해야겠다.

https://coding-groot.tistory.com/89

https://enghqii.tistory.com/59?category=206685 

DEFAULT

GPU가 이 리소스를 빠르게 읽기 및 쓰기 권한이 가능하다.

오직 UpdateSubresource만을 사용하여 업데이트 할 수 있다.

렌더타겟에서 사용될때 좋은 후보가 될수있다 =>무슨말?

IMMUTABLE

GPU만이 이 리소스를 빠르게 읽을 수 있다.
일단 생성되면 업데이트할 수 없습니다.
생성 호출 중에 초기 데이터를 전달해야 합니다.
변하지 않는 리소스(정적 텍스처, Vb/Ib)에 좋은 후보가 될 수 있습니다.

Vb/Ib : VertexBuffer, IndexBuffer

모든것을 IMMUTABLE로 만들려 애쓰지 마라

DYNAMIC

빠른 CPU 쓰기 액세스가 필요한 리소스에 사용
(GPU 읽기 액세스 속도가 느려짐)
CPU 읽기 액세스 없음
밑의 두가지 플래그와 Map을 사용하여만 업데이트할 수 있습니다.

• D3D10_MAP_WRITE_DISCARE
• D3D10_MAP_WRITE_DNO_OVERWRITE

동적 텍스처, 동적 VertexBuffer는 좋은 후보입니다.

STAGING

GPU에서 데이터를 다시 읽을 수 있는 유일한 방법입니다.
MAP을 사용해야만 업데이트할 수 있습니다.
단 밑의 플래그와는 매핑할 수 없음

• D3D11_MAP_WRITE_DISCARD
• D3D11_MAP_WRITE_NO_OVERWRITE

gpu가 지연되지 않도록 버퍼를 두 배로 늘릴 수 있습니다.
GPU는 이것들을 직접 사용할 수 없다.

Vertex Buffer의 경우

버텍스 버퍼가 프레임당 한 번 미만의 CPU에 의해 터치됨
=> D3D11_USAGE_DEFAULT로 생성하여 UpdateSubresource를 사용하여 업데이트 해라

정점 버퍼는 동적 지오메트리에 사용되며 CPU에서 프레임당 여러 번 업데이트할 필요가 있는 경우

=> D3D11_USAGE_DYNAMIC으로 생성하여 MAP을 통해 업데이트 해라

사용하면서 내 경험으로 더 알아가면서 추가로 포스팅해야겠다.

https://www.slideshare.net/cagetu/windows-to-reality-getting-the-most-out-of-direct3-d-10-graphics-in-your-games

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=masca140&logNo=220719096462 

Vertex Shader

주 역할은 3D공간 상의 정점들의 위치를 화면좌표로 변환한다.

고로 정점하나당 Vertex Shader가 한번 실행된다.

Rasterizer

정점이 찍힌다면 이제 정점과 정점사이에 선을 그릴것이다.

그 선이 이어져서 삼각형을 만들수있다.

그렇다면 정점과 정점사이에는 몇개의 픽셀이 들어가있을까?

혹은 만들어진 삼각형안에 몇개의 픽셀이 어떻게 있을까?

이러한 정점 사이에 있는 픽셀들을 어디에 몇개나 그려야 하는지 알아내는 단계가 레스터라이저에서 이루어진다.

Pixel Shader

Vertex shader는 정점하나당 실행된다.

그렇다면 Pixel Shader는?

래스터라이저에서 계산된 픽셀 수 만큼 실행된다.

역할은 그 픽셀의 최종색상을 계산하는것

Shader

고로 셰이더란 화면에 존재하는 각 픽셀의 위치와 색상을 계산하는 함수이다.

셰이더에서 사용할 수 있는 입력 값으로는 전역변수와 정점데이터가 있다.

한 물체를 구성하는 모든 정점이 동일한 값을 사용한다면 전역변수가 될수있고

한 물체를 구성하는 모든 정점 : 예를들어 한 캐릭터를 그리기 위한 모든 정점

각 정점마다 다른 값을 사용하면 정점 하나하나의 데이터로 받아들여야한다.

https://kblog.popekim.com/2011/11/01-part-1.html

https://gasbebe.github.io/shader/

Device & Device Context

이 두 인터페이스는 Dx의 주된 인터페이스로 물리적인 그래픽 장치 하드웨어에 대한 제어기다.

ID3D11Device, ID3D11DeviceContext 의 맨 앞이 모두 ' I ' 이므로 인터페이스인걸 확인 알 수 있다.

가장 주요한 인터페이스기에 Direct3D 초기화의 시작은 Device와 Device Context의 생성으로 시작 된다.

생성의 함수는

D3D11CreateDevice ( 혹은 D3D11CreateDeviceAndSwapChain사용 )

HRESULT D3D11CreateDevice(

     IDXGIAdapter *pAdapter,

     D3D_DRIVER_TYPE DriverType,

     HMODULE Software,

     UINT Flags,

     const D3D_FEATURE_LEVEL *pFeatureLevels,

     UINT FeatureLevels,

     UINT SDKVersion,

     ID3D11Device **ppDevice,

     D3D_FEATURE_LEVEL *pFeatureLevel,

     ID3D11DeviceContext **ppImmediateContext

);

주요 매개변수만 보자면

pAdapter : 디스플레이 어댑터를 지정한다

디스플레이 어댑터 : 그래픽 카드

ID3D11Device **ppDevice : 생성된 Device를 돌려줌

ID3D11DeviceContext **ppImmediateContext : 생성된 DeviceContext를 돌려줌

이러한 매개변수를 받는다는게

이 함수에서 그래픽 카드를 연결해준다는걸 추리해볼수있다.

ID3D11Device의 함수를 보면 거의 다 함수 앞에 Create가 붙어있었다.

셰이더를 만들고(Create)

텍스처의 배열을 만들고(Create)

버퍼를 만들고(Craete)

이런걸로 봤을때 Device의 역할은 그래픽을 그리는 자원들을 생성하고 준비하게끔 도와주는 역할이라 생각한다.

ID3D11DeviceContext의 함수는 대부분 Set과 Get이 많이 들어가 보였다.

버퍼를 세팅하고, 가져오고(Set, Get)

셰이더를 세팅하고(Set)

각 파이프라인 단계를 세팅하고(Set)

이런걸로 봤을때 Device로 생성된 자원들을 디스플레이 어댑터에 세팅하고 세팅되었던걸 가져오고 이러한 역할같다.

+DeviceContext는 주 쓰레드와 그외의 쓰레드일때 다른 문맥을 생성해야한다고 한다.

주 쓰레드면 위의 방식으로 생성, 즉시문맥이 생성되고( immediate context )

멀티 쓰레딩 환경에서 그 외의 쓰레드(일꾼쓰레드)이면 ID3D11Device::CreateDeferredContext으로

지연문맥을 생성한다 ( deferred context )

그래서 일꾼쓰레드가 ID3D11CommandList에 그리기 명령을 기록한다.

주쓰레드에서 그 기록들을 실행한다고 한다.

COM 객체 (Component Object Model)

COM객체또한 액터가 아닌 언어의 독립성과 호환성을 가능하게 하는 기술이라고 한다.

언어의 독립성 : 극단적 예시로 A라는 COM객체를 c++ 에서도 사용하고 java에서도 사용하고 python에서도 사용한다

갑자기 왜 나왔냐면 Device & Device Context가 COM객체이기 때문이다.

이유는 모든 COM객체는 IUnknown이라는 COM 인터페이스 기능을 상속받기 때문이다.

IUKnown을 상속받는 이유는 모든 COM객체가 같은 고유한 방식으로 메모리를 관리하기때문

일단 언리얼에서 컴포넌트를 다뤘다면 대강 그림이 그려진다.

컴포넌트의 이유가 어느 액터이던간에 땟다 붙엿다 하려고 컴포넌트를 생성했었는데

이러한 COM객체는 인터페이스형태로 우리에게 보여지며

New처럼 객체를 생성하지 못하고 특별한 함수나 다른 COM인터페이스의 메서드를 이용하여 얻어야한다.

맨위 사진의 맨 첫줄 MIDL_INTERFACE("db6f6ddb-ac77-4e88-8253-819df9bbf140") 는

uuid라는걸 뜻하는데 개념이 아직 너무 막연하고 아직 필요성은 없는거 같아 나중에 필요해질때 다시 찾아보자