Graphics Programming

패스 트레이싱은 CPU 구현하던 것이 있지만 최근에 하드웨어 가속을 이용해 리얼타임 GPU 패스 트레이싱을 훌륭하게 구현한 사례가 계속 나오고 있고, 사이버펑크 2077의 경우 패스 트레이싱 모드를 출시한 것이 인상깊어서 나도 GPU 구현으로 갈아타기로 했다. 다행히 DXR로 Ray Traced Reflections을, CPU로 패스 트레이싱을 구현했던 적이 있어서 DXR 프로젝트에 CPU 구현을 GPU로 포팅하는 것만으로 기초적인 GPU 패스 트레이싱을 구현할 수 있었다. 모든 표면을 램버트로 강제하여 렌더링한 디퓨즈 글로벌 일루미네이션 마이크로파싯 BRDF를 구현해서 디퓨즈 + 스페큘러 리플렉션을 모두 커버하는 글로벌 일루미네이션 샘플 씬을 렌더링할 수 있을 정도로만 구현했기 때문에 앞으로 다른 샘플..

DX12 토이 프로젝트인 Cyseal에 Dear ImGui를 붙여봤다. Dear ImGui는 렌더링 테크데모, 게임 엔진 등의 분야에서 많이 쓰이는 imgui 라이브러리다. 이전 회사에서 같이 일했던 선임 엔지니어 분이 간단한 엔진 툴을 만들 때 써봤는데 매우 직관적이고 사용하기 편리하다고 추천하셨던 기억이 난다. 나도 Dear ImGui에 편승하기로 했다. 듣던 대로 통합하기도 쉽고 사용법도 간단했다. 내 프로젝트에서 Vulkan 백엔드가 제대로 돌지 않고 있기 때문에 일단은 imgui의 win32 + dx12 백엔드 부분만 통합했다. 처음에 그려보니 글자가 살짝 흐릿하고 마우스 히트 테스트가 어긋나는 문제가 있었는데, 내가 swapchain 이미지들의 크기를 윈도우 client rect와 정확히 일치..

프로그래밍을 플래시 액션스크립트로 처음 배웠으니 내 뿌리는 managed code가 맞지만, C++가 주력 언어가 된 후에는 학교에서 공부할 때도 회사에서 일할 때도 C++만 쓰게 되었다. 액션스크립트만큼은 개인적으로 계속 사용했지만 어도비가 플래시를 버린 이후에는 나도 쓰지 않게 되었다. 예전 기억을 잠시 되살려보면 플래시 런타임의 본질은 JVM을 얇게 감싼 것이고 액션스크립트 초기 문법은 자바스크립트에서 가져온 것이다. 그래서 액션스크립트를 깊게 파다 보니 자연스럽게 자바와 자바스크립트도 배우게 되었다. 액션스크립트의 마지막 버전인 3.0에 와서는 오히려 자바를 닮아갔는데, 그러다보니 클래스 기반 상속과 프로토타입 기반 상속이 공존하는 해괴한 언어가 되었다. 어쨌든 이런 VM 위에서 돌아가는 코드를 ..

https://codeonwort.tistory.com/386 Ray Tracing: The Next Week https://codeonwort.tistory.com/364 1부를 3년 전에 구현했는데 이제서야 2부를 읽고 있다. 맨날 놀다가 질리면 사이드 프로젝트들 중 하나를 골라서 잠깐 하는 것을 반복하니 영 진도가 안 나간다. 모션 codeonwort.tistory.com 이거 이후로 한동안 방치하다가 또 조금씩 깨작거리고 있다. 기가바이트 단위의 렌더링 리서치용 애셋들은 있지만 한 장 그릴 때마다 몇십 분씩 기다리기도 싫고 해서 또다시 McGuire의 간단한 Wavefront OBJ 모델들을 긁어와서 렌더링을 돌려보고 있다. Wavefront OBJ 포맷 자체가 별로 잘 정의되어 있지 않아서 일단..

DirectX 12, RTX 그래픽카드, 하드웨어 레이트레이싱 가속 등이 처음으로 거론되던 시절에 레포지토리를 파놓고 4년 간 방치하다 이제서야 DXR 코딩을 시작했다. 처음으로 뭘 구현할까 고민하다 간접 스페큘러 리플렉션을 선택했다. 리얼타임 렌더링에서 래스터와 레이트레이싱을 섞어 쓰는 하이브리드 렌더링을 할 때 흔히 레이트레이싱으로는 RT Shadow, RTAO, RTGI(Diffuse GI), RTR(Specular GI) 등을 구현하는데 경험상 처음 3개는 레이트레이싱으로 인해 증가하는 비용에 비해 극적인 차이를 낸다고는 느끼지 못했다. 반면 RTR은 SSR + 리플렉션 큐브맵에서 아쉬웠던 문제점들을 깔끔히 해결한다. 프로젝트를 워낙에 방치했던 터여서 RTR 구현에 앞서 여러가지 선행작업이 필요했..

최근에 티스토리 서비스가 한동안 먹통이 되는 사고가 발생한 후에 내 블로그 기록을 잃을 수도 있겠다는 생각이 들었다. 그렇다고 집에서 설치형 블로그를 직접 호스팅할 생각까지는 없어서, 백업 및 복구가 편리한 플랫폼을 찾아보다 github.io에 정착하게 되었다. 다들 github.io를 Hugo나 Jekyll 같은 정적 사이트 생성기와 함께 쓰는 모양이지만 이것저것 세팅하기도 귀찮아서 베어본 HTML과 마크다운만으로 글을 쓰는 단순한 환경을 구축했다. Notepad++에서 마크다운으로 글을 쓰면 HTML 파일이 자동 생성되게 만들고, 그렇게 생성된 포스트들을 index.html에 링크한다. 글 원본이 마크다운 포맷이므로 컨텐츠 손상될 일 없이 백업할 수 있고 혹여나 다른 플랫폼으로 옮기게 될 경우 HTM..

렌더링 챌린지 일지 1 을 작성한 것이 벌써 2년 전이다. 이 데모 씬(이하 RC1)를 내버려두고 다른 렌더링 테크닉만 구현해왔는데, 마무리를 짓고 다른 챌린지 월드를 만들어야겠다 싶어서 손질에 들어갔다. 리워크 중간 결과물 가장 최근에 작성한 일지인 AMD FSR1 통합 이후로 GLTF 로더, TAA 구현, 톤 매퍼 변경(Reinhard → ACES), CPU 프로파일러 개선, SSR 개선 등의 작업을 했고, 그 이후 RC1 손질을 시작했다. 타워 모델 벽돌 텍스처를 바르기 위해 triplanar mapping을 썼는데 노멀맵 계산이 틀려서 라이팅이 이상했었다. GPU Gems 3 - Generating Complex Procedural Terrains Using the GPU 을 참고해서 고쳤다. 번..

CUDA 공부를 시작했다. 레퍼런스로는 마침 올해 개정판이 나온 "Programming Massively Parallel Processors" 4판을 쓰고 있다. 예제 코드를 몇 개 따라해보니 그래픽스 API에서 컴퓨트 셰이더를 쓰는 것과 모델이 크게 다르지 않다. 호스트(CPU+RAM)에서 디바이스(GPU+VRAM)로 데이터를 업로드하고 커널을 실행한다. 실행 결과를 다시 호스트 메모리로 가져온다. 그래픽스 API에서 셰이더 리소스 바인딩 → 컴퓨트 셰이더 실행 → CPU readback하는 것에 그대로 대응된다. 산술 연산과 메모리 액세스의 비율, 블록 사이즈, 레지스터 등을 고려한 최적화는 GPU 프로파일러를 돌려서 occupancy, VGPR, VMEM/VDATA throughput 등을 따지는 ..