Work In Progress
-
2024/05/11 Render Graph
렌더 그래프는 사전에 주어진 렌더링 작업(렌더 패스)간의 리소스 의존성 관계를 통해, 렌더 패스간의 관계를 DAG(Directed Acyclic Graph, 유향 비순환 그래프)의 형태로 해석하여 , 렌더 패스의 순서를 정하고 텍스처가 특정 단계에서 어떤 레이아웃으로 변환되어야 하는지, 그리고 어떤 렌더 패스들이 병렬적으로 실행 될 수 있는지 그리고 이종(Heterogenous) 큐 간의 동기화는 어느 시점에 이뤄져야하는지에 대한 결정을 특정 알고리즘에 의해 자동적으로 이뤄 질 수 있도록 해줍니다.기본적으로 Ubisoft가 GDC 2017 에서 발표한 FrameGraph와 동일하게 Setup->Compile->Execute 단계를 거치고, Setup 단계에서는 실제 리소스가 아닌 가상 리소스, 즉 가상..
-
Little Tokyo
간단히 텍스처링 + 모델 임포트
-
2024/04/13 WIP
ImGui 테마 Texture 미리 보기 확장 ImGui 위젯 2종 추가
-
2024/04/09 Asset Management/System/Framework
전반적인 Asset 관리/시스템/프레임워크를 완성하였습니다. 물론 비효율적인 방식이라 생각하지만.. 좀 더 효율적이고 깔끔한 방식은 앞으로 더 공부해 나가고 개선해 나가야 할 사항인 것 같습니다.
Pot of Thoughts
-
높은 폴링레이트의 마우스와 PeekMessage 그리고 Raw Input Device
본격적으로 화면에 뭔가를 렌더링 하고, 렌더링되는 장면을 이리저리 돌아다니면서 뭔가 이상한 현상을 발견하게 되었다. 마우스의 이동이 많을 수록 그리고 더 갑작스럽게 할 때 마다, 프레임 처리 시간이 확 늘어나서 스터터링이 발생한다는 것 이다. 어느 부분이 문제일까 싶어서 프로파일링을 해보니 윈도우 메시지 펌프에 있는 PeekMessage을 처리하는데 사용되는 시간이 압도적으로 높다는 것이다. 또한 마우스를 갑작스럽게 움직일 때, PeekMessage의 호출 횟수 또한 늘어나고 그로 인해서 자연스럽게 프레임 처리 시간은 더 길어졌다. 어떻게 보면 당연한 현상이다, 마우스가 움직일 때 마다 그에 따른 메시지(이벤트)가 발생 할 것이고 메인 스레드의 메시지 큐에 그 만큼 많은 이벤트가 쌓이고, PeekMess..
2024.05.13 13:19 -
D3D12 래퍼 설계에 대하여 #2
기존 설계로는, Wrapper::Ctor(Device, params...) 와 같은 식으로 객체를 생성했다만, 내부적으로 결국 Device의 네이티브 인터페이스인 ID3D12Device~을 GetNative로 받아와서 내부 객체를 생성해주는 방식이였다. 다만 이렇게 되면 API 설계에 대한 사견 #2, API 설계에 대한 사견 #3 에서의 2가지 아이디어를 위반한다. 변경할 설계, Device 래퍼가, 기존 ID3D12Device의 책임을 그대로 이어 받도록 할 것. 즉 Device 래퍼 클래스가 명령어 할당자, 명령 목록, 명령 큐, 리소스 등등.. 을 생성/할당하는데 직접적으로 사용되도록 한다. 예컨데, Device::CreateFence(...) 와 같이. 기존 ID3D12Device와의 차별점은 ..
2024.02.08 20:46 -
API 설계에 대한 사견 #3
래퍼 클래스는 래핑된 클래스의 'responsibility'를 이어 받아야 한다. 리팩토링은 '방법'보다는 '필요성'을 깨닳고, 필요성에 따라 시행하여야 한다. Fine-Grained Warning Management -> 프로젝트의 경고 단계를 W4로 설정 한 다음, 경고를 오류로 취급하게 할 것. 컴파일러의 경고는 잘못 경고를 발생시키는 경우도 있지만, 대다수의 경우에 작동했을 때 문제를 일이킬 수 있는 행동을 미연에 방지할 수 있다. 외부 라이브러리의 경고는 선택적으로 비활성화 하되, 자신의 프로젝트에서 만큼은 경고가 하나도 없도록 만드는 것이 좋다. 최적의 경우로는 전체 빌드시, 자신의 프로젝트에서 경고가 하나도 없어야 한다.
2024.02.08 20:34