Graphics Programming

도대체 언제적 상태인지 내 블로그를 뒤져보니 2016년 1월이었다. 갓 대학교 4학년 된 때구먼 -_-; 이 때 보더랜드 2를 그렇게 열심히 했는데. 취업하고 손을 놓았다. 집에서 게임을 하도 해서 게임이 질릴 때만 코딩했더니 3년간 만든 게 톤 매핑, 스켈레탈 애니메이션, 뎁스 오브 필드 뿐이다. 이건 올해 시작한 CPU 레이트레이서인데 OpenGL 프로젝트가 눈에 밟혀서 얼마 못 만들고 우선순위에서 밀렸다. 그래도 만들어보니 "OpenGL이나 DirectX로 리얼 타임 렌더링을 해야지 무슨 요즘 시대에 CPU 레이트레이서임?" 은 정말 잘못된 생각이었다. 훨씬 적은 코드로도 품질이 그럭저럭 나오며 PBR이나 라이팅 이론을 이해하기 훨씬 좋은 환경이라고 생각한다. 코드 막 뜯어고치는 중인 지금의 결과물..

멀티쓰레딩한다고 기존의 모든 gl 호출에 커맨드 리스트를 붙이다가 진이 빠져서 잠시 외도를 하고 있다. 메인 쓰레드와 렌더 쓰레드에서 쓸 데이터를 분리하는 작업이 남아있지만, 리팩토링의 문제점은 아무리 해도 화면에 보이는 결과물이 같다는 것이다. 그게 리팩토링의 목적이기도 하지만. 다행히 씬에 대한 렌더 프록시를 만드는 작업은 나중에 해도 렌더러 내부를 크게 건드릴 게 없어보여서 조금 미뤄도 큰 작업으로 번지지는 않을 것 같다. 먼저 엔비디아 FXAA를 붙여보기로 했다. 소스코드를 찾아보니 NVIDIAGameWorks 샘플에 들어있었다. https://github.com/NVIDIAGameWorks/GraphicsSamples FXAA 코드를 너무 잘 짜놔서 내 플랫폼에 맞게 #define 몇 개 넣고 ..

종이책에 무슨 미련이 그렇게 있었는지 차곡차곡 쌓다가 드디어 버릴 결심을 했다. 컴퓨터 책상 옆에 보조 책상을 놔뒀는데 금방 책으로 가득 차서 뭘 하지 못하게 된 것도 있고, 몇 년째 펼치지 않은 책도 허다하고, 더이상 내 인생과 상관이 없을 것 같은 책들도 있다. 무엇보다 이사할 때 힘들어 죽겠다. 가구나 전자제품 같은 보편적인 이삿짐은 적은데 책 싸느라 항상 고생이 이만저만 아니었다. 막상 그대로 내다버리기는 또 미련이 남아서 빠르게 훑어보고 컴퓨터에 정리한 다음 버리는 책도 있다. 교양서, 소설, 쓸모 없는 전공서적, 이제는 관심 없는 프로그래밍 서적 등을 버리고 있다. 대학교에서 배운 무선이동통신. 큐잉 이론에 관한 수학은 재밌었는데 그 외에는 별로 재미 없었다. 예전에는 셜록 홈즈, 애거서 크리..

회사 다니면서 내팽겨쳐둔 OpenGL 렌더링 엔진을 다시 꺼내서 손보고 있다. 그래도 엔진 프로그래머랍시고 3년을 굴렀더니 잘못된 게 너무 많이 보여서 아키텍처에 또다시 대규모 공사를 하고 있다. 이 엔진을 바닥부터 다시 만드는 수준으로 갈아엎은 적이 이미 3번은 넘은 것 같은데 볼 때마다 엉망이다. 차라리 DirectX 12나 Vulkan으로 새로 만드는 게 낫겠다고 생각하다가도, 그러면 중간에 그만둘 거 같아서 이미 만든 걸 손보기로 했다. 그리고 이런 API는 쓰기 번거로워서 회사에서 돈 받으면서 코딩해야 한다. (크로스플랫폼 개발도 마찬가지다. 엑스박스 타이틀 개발하는 게 멋진 경험일 줄 알았는데 똑같은 걸 서로 다른 플랫폼들에서 돌아가게 하는 건 노가다일 뿐이다. 회사에서 돈 받고 해야지 집에서..

멀티쓰레딩 하려고 쓰레드 풀 만들다가 또 당했다. // std::vector queue; bool ThreadPool::PopWork(ThreadPoolWork& work){ bool ret = true; queueLock.lock(); if(queue.size() == 0) { ret = false; } else { work = queue[queue.size() - 1]; queue.pop_back(); } queueLock.unlock(); return ret;} 얼핏 아무 문제 없어보였는데 pop_back()을 하면서 queue의 크기가 변하고, reallocate되어버렸다. 쓰레드 엔트리 함수에 work에 대한 포인터를 인자로 넘길 건데, 컨테이너가 재할당돼서 메모리 위치가 바뀌어버렸고 작업 쓰레..

그냥 온라인의 유명한 레이트레이싱 튜토리얼을 그대로 따라했다.토요일에 빌드 환경 만들어놓고 게임만 하다가 일요일에 부랴부랴 완성했다. 어쨌든 주말 안에 끝냄... ㅎㅎ; 광선을 반사시킬 때 난수가 필요한데, 매번 난수를 만드니까 루프가 느려져서 그냥 10000개 정도 생성해놓고 돌려썼다.그랬더니 광선 튕기는 거에 규칙성이 생겨버려서 그림자에도 패턴이 생겼다. 튜토리얼은 난수를 너무 무식하게 생성해서 PBR 13장에서 읽었던 단위 구/원에서의 난수 생성을 가져다 썼다. 램버트 표면하고 메탈 표면을 구현해서 구 3개 붙여놓은 거.난반사하고 앰비언트 오클루전 되는 게 래스터 기반 렌더링보다 때깔이 많이 좋아보인다. 튜토리얼 마지막. 구가 너무 많아서 이미지 생성하는 게 드럽게 오래 걸린다.튜토리얼이 2개 더 ..

옛날에 (2011~2012년 즈음) 어도비 플래시로 음악 시각화를 재밌게 만든 적이 있다. 이름은 음악 시각화라고 붙였지만 딱히 음악의 특성을 잘 표현하는 건 아니었다. 볼륨이 커지면 화면이 더 급격히 변하거나, 파티클들이 더 빠르게 움직이고 간단한 비트 감지를 통해 비주얼을 급격히 변화시키는 정도였다. 이때는 음악의 장르, 정확한 비트 감지, 선율 표현 등을 할 능력도 없었고 어디서 관련 자료를 찾는 지도 몰랐다. 애초에 푸리에 변환이 뭔지도 몰랐고 매 프레임 computeSpectrum()이라는 API 함수를 호출하면 오디오 샘플이 256개 나오는구나, 그런데 pcm이랑 주파수 스펙트럼이 무슨 차이야? 수준이었으니... 작년에(2018년 -.- 벌써 2019년이다) 오랜만에 하나 만들어봤지만 역시 옛..

이 글에서는 서드 파티는 논외로 하고 UI와 UMG를 동의어로 쓴다. 입력 처리하기 골치아프다 UI에서 입력을 받는 방법은 적어도 세 가지가 있다. UMG 블루프린트에서 key down, key up 이벤트를 직접 처리한다. 입력 바인딩(action/axis)을 활용한다. 이 때 input mode의 존재 때문에 두 가지 방법이 있다. player controller에서 입력을 바인딩하고 응답은 UI에 위임한다. UMG에서 owning controller의 input component에 직접 입력을 바인딩하고 응답한다. 일단 key down/up은 안 쓰는 게 나을 것 같은게, 로직 변경이 힘들기 때문이다. 메뉴 여는 걸 P에 바인딩했는데 O로 바꾸려면? 이동이 기본은 WASD인데 조작 키를 바꿀 수 있..