AMD표 셰이더 저작 도구(shader authoring tool)이다. 프로그래밍 언어를 안 사용하고 만드는 걸 저작(authoring)이라 하는데, 렌더몽키는 DirectX, OpenGL API를 직접 만질 필요가 없어 셰이더 자체에 집중할 수 있게 하는 셰이더 저작 도구다.
맛보기로 Deferred Shading을 구현했다. 확실히 DirectX API에 신경을 안 써도 되니깐 셰이더 자체에 집중이 잘 된다.
Feb 102010
Nov 032009
간략한 shadow volume 소개와 여러 shadow mapping 알고리즘을 소개한 아티클이다. 프로그래머뿐만 아니라 게임에 관심이 있는 사람들도 읽을 수 있도록 쉽게 써서 그림자를 구현하기 전에 살짝 읽기에 좋은 글이다.
용어 정리가 조금 아쉽다. 어떤 말이고 하면 깊이 그림자 기법으로 PSM, LiSPSM 등을 소개하는데, PSM과 LiSPSM은 어떻게 shadow map texture를 그리는지에 대한 알고리즘이다. 사실 그림자 back-projection 신경 안 쓰고 셸프 섀도(self shadow)도 관심 없다면 depth map을 안 쓰고 이런 알고리즘대로 그림자 컬러 값을 그리고 지형에 매핑해도 된다. 하긴 요즘 shadow mapping이라 하면 저장한 깊이 값을 비교해서 그림자인지 아닌지 가리는 depth map test를 사용하는 걸로 고정되어 있어서 젠지씨보고 뭐라 하기도 그렇다. 사실 논문 자체 구현도 depth map을 사용하고 있다.
Oct 092009
Make your tools “bullet-proof”
bullet-proof는 총알을 막는 방탄을 의미한다. 죽지 않고 잘 돌아가는 프로그램을 가리킨다. 이거 당연한 거 아냐? 다만, 여기서 추가로 생각해야 할 게 만약 디자이너가 무사히 익스포트했다면 게임 엔진에서도 알 수 없는 이유로 죽지 않고 잘 돌아가야 한다는 거다. 아티스트가 몇 시간 시도하다가 포기하면서 프로그래머에게 던져주면 디버깅 끝에 “influences가 버텍스당 4개 이하여야 합니다.”라는 대답이 돌아온다면? 쏟아부은 시간을 생각하면 피눈물이 날 것이다. 당연히 죽지 않고 익스포터에서 경고를 해야 한다.
Make the tool, not the artist, do the non-artistic work.
니도 할 수 있는 쿼드를 트라이앵글로 잘라내는 일 따위를 아티스트에게 시키지 마라는 것이다. 이런 건 당연히 툴에서 지원해줘야 한다.
Sep 282009
노멀 매핑(범프 매핑(bump mapping)과 노멀 매핑(normal mapping)은 같은 뜻으로 쓰인다. 좀 더 익숙한 노멀 매핑을 사용.)이 가진 가장 큰 단점은 “니가 어디에서 바라보든지 난 상관하지 않아.”이다. 즉, 시야 정보 없이 노멀맵에 저장된 normal로 per-pixel lighting을 한다. 이렇다 보니 비스듬히 보거나 가까이서 보게 되면 평면에 제발 속아달라고 정성스럽게 음영을 표현한 그대로 보이게 된다.
Sep 272009
[GPU Gems3] Chapter 28. Practical Post Process Depth Of Field 아티클의 결론이다. 결론이 참 인상적이다. 내가 읽은 아티클은 보통 뭐보다 몇 배 빠르고 킹왕짱이다라고 말하거나 PC 사양을 적어놓고 FPS(Frame Per Second)를 비교했었다. 이렇게 수치로 샘플링 횟수와 원본 이미지의 픽셀을 읽어서 몇 번 렌더타겟에 기록하는지를 기록한 건 처음 본다. (내가 본 아티클 개수가 많진 않지… 아님 봤더라도 넘어갔거나)
난 한 번이라도 이런 결론을 내봤을까? 으.. 한 번도 없는 것 같다. 사용한 셰이더 명령어 수와 이전과의 프레임 비교, 렌더타겟 수 정도만으로 결론을 내곤 했다. 이런 수치를 봤을 때 “뭐야 저거.. .무서워”라는 생각이 들고 또는 오버라고 생각할 수 있지만 이런 절대적인 수치를 내는 건 이 알고리즘의 성능을 보는데 매우 중요한 역할을 한다. 또 생각했던 수치와 달라서 해당하는 부분에 뻘짓을 제거하거나 버그를 고칠 확률도 늘어난다.
한 번 해봐야겠다. 이런 거 처음엔 무지 오래 걸리겠지만 몇 번 고생하면 나중에는 빨리 되겠지. “도움이 안 되지 않을까?”라는 생각도 들지만 안 들면 그때부터 안 하면 되는 거다.
Sep 262009
텍스쳐 매핑이 없고 라이팅이 폴리곤 단위로 플랫 셰이딩 시대인 1980년대부터 “이제까지 힘들었지? 내가 반투명 오브젝트를 알아서 처리할께. 소팅하지 말고 넘겨”라는 A-buffer가 들어가니 마니하는 다이렉트X 11 시대까지 다뤘다.(DirectX 11 RTM이 나왔는데, A-buffer 얘기가 없다. 아무래도 논의만 되고 들어가지는 않은 것 같다. 아 아쉬비.)
May 262009
PerfHUD나 DirectX Caps Viewer로 볼 수 있지만, 비디오 메모리 사용량을 렌더링하는 게 그리 힘든 일이 아니라 보통 이 정도는 렌더링해준다. 그건 좋은데 문제는 DirectX9 인터페이스로는 사용 가능한 전용 비디오 메모리를 알 수 없는 거다. 그래서 보통 DirectDraw 인터페이스를 구해서 GetAvailableVidMem()를 호출해서 비디오 메모리를 구한다.
이것만 알고 있었는데, DirectX 샘플을 보던 중 비디오 메모리를 5가지 방법으로 구하는 VideoMemory Sample을 발견해서 살펴봤다. 샘플 자체가 비디오 메모리 구하기 완전 정복 필이다.
이 5가지 중에서 DirectDraw, WMI, DXGI를 사용하면 비디오 로컬 메모리를 구할 수 있다. DXGI는 비스타 이상에서만 사용할 수 있어서 XP 타겟으로 개발하는 게 대부분이라서 탈락이고 DirectDraw와 WMI 둘 중 하나를 고려해야 하는데, 문서에는 XP에서는 WMI, Vista에서는 DXGI 사용을 추천하고 있다.
Jul 252008
역경을 딛고 집에 PerfHUD 6 – NVIDIA를 설치하고 새로 추가된 피쳐들을 살펴봤다. 앞자리 숫자가 바뀐 버전인 만큼 정말 멋진 기능들이 많이 추가됐다. 더 쾌적하게 게임을 하려고 ATI 비디오 카드를 꼽을 수는 있겠는데, 개발용으론 이제 NVIDIA 비디오 카드밖에 못 쓰겠다.
풀 스크린으로 텍스쳐 또는 렌더타겟을 시각화(visualization) 시킬 수 있다.
이제 확대해서 보고 싶을 때, 번거롭게 파일로 저장해서 보지 않아도 된다.
Jul 222008
집에서 NVIDIA PerfHUD 6의 여러 가지 기능들을 테스트하려고 다운받았다.
PerfHUD를 붙여서 실행했는데, 오잉! 처음 보는 메시지다. HW counters are disabled??? 난 지금 7300GT를 사용하고 있고 6600에서도 잘 돌렸는데 이상하다.
Jul 132008
Debugging시 Watch창으로 내부 변수들을 볼 수 있다. 위의 그림은 IDirect3DDevice9를 Watch창으로 본 화면. 어휴! 역시 DirectX 새로운 SDK 나오면 무조건 Document부터 다 훑어봐야 한다. 발견한 지 일주일이 안 됐지만 그전부터 사용 가능한듯하다.