시작하며…

OGRE는 Object-Oriented Graphics Rendering Engine의 약자로써, 이미 아시는 분들은 저보다 훨씬 잘아시리라 믿습니다. 3D를 주 테마로 잡고 있는 개인이 운영하는 사이트를 보면 OGRE를 강한 열정을 가지고 분석하고 있는 분들이 많더군요. 하지만 저는 단지 수개월전에 OGRE를 공개소스로써 3D 그래픽 엔진 중 인기순위 1위를 차지하는 라이브러리 정도로만 알고 있었고, 그 당시 한번 컴파일이나 해보자는 마음으로 소스코드를 다운로드 받아 컴파일을 시도했지만, 실패하고 말았었습니다. 왜 실패했는지 그 이유는 모르겠습니다. 아마도 제 마음속에 별.. 그다지 OGRE에 대한 관심이 별로 없었지 않았나 싶습니다. 하지만 다행이 이미 컴파일된 데모들을 실행해 볼 수는 있었고, 단지 “좋군..”이 전부였습니다.


하지만 최근 우연이 Direct3D를 전문으로 다루는 어느 개인 블로그에 방문했데, 그 곳에 OGRE를 다루더군요. 또 다시 호기심이 발동한 저는 다시한번 컴파일이나 해볼 요량으로  OGRE의 공식 사이트인 www.ogre3d.org에 방문해 차근 차근 시도를 해보았습니다. 그런데 이번엔 왠일인지 쉽게 컴파일이 되더군요. 이상하게도 컴파일이 되니 제 마음속에서 이 놈을 깊이 있게 분석해보리라는 강한 욕심이 생겼습니다. 정말입니다. 컴파일 성공이라는 첫걸음이 성공하는 순간, 저도 전혀 예상하지 못했던 흥분과 욕심이 생기는겁니다!

제가 OGRE에서 얻고자 하는 바는 다음과 같습니다.

  • 많은 3D 그래픽 개발자로부터 찬사를 받고 있는 OGRE를 직접 사용해보고…
  • 최고 수준의 Object-Oriented를 지향한다는 Ogre의 개발자의 이 엔진으로부터 설계방법을  배우며…
  • OpenGL이나 DirectX보다 상위 수준의 API 통해 최신 그래픽 기술을 직접 코딩해 느껴보고, 점차 하위 수준으로 접근해 나간다.

위의 3가지 목적중에 2번째인 설계방법이 가장 큰 목표입니다. OGRE의 첫자인 “O”가 Object-Oriented인 만큼, 또한 OS 독립적이며 OpenGL과 Direct3D를 실행중에 유연하게 선택할 수 있는 설계방식이 무척 궁금합니다. 물론 제 나름대로의 이러저러하게 하면 되지 않을까 하는 다소 어설픈 아이디어는 있지만, 다른 개발자의 아이디어는 어떨까, 배우고 싶습니다.
위는 Ogre의 핵심 클래스의 관계도입니다. 간단해 보이기는 하지만 다른 부수적인 것들이 붙으면 매우 복잡하겠지요. Ogre를 분석하는 방법은 Ogre 사이트에서 제공하는 Tutorial과 Demo 소스를 분석하는 방식으로 하려 합니다. 제 스스로에게 건투를 빕니다.

Memory Leak 검출해 주는 오픈소스

예전에 VC6.0을 사용할때 코딩하고 Debug로 컴파일하면 어느 지점에서 메모리 누수(Leak)가 발생하는지 IDE의 출력창에서 알려주었다. 원래 VC6.0이 그랬는지, 아니면 나도 모르게 뭔가를 설치해서 그랬는지는 기억나지 않지만 말이다. 그런데 VS2003 이후로는 메모리 누수에 대한 보고를 해주지 않는 것이다. 난 한동안 아.. 메모리 누수가 발생하지 않게 잘했나보다 했는데.. 그게 아니란것을 알고 난후, 메모리 누수를 검출해주는 툴을 찾다가 괜찬은 녀석 둘을 만났다.

http://www.codeproject.com/tools/visualleakdetector.asp
http://www.codeproject.com/tools/leakfinder.asp

간단히 소개를 하면, 첫번째는 라이브러리를 Link해주고 vld.h라는 헤더파일 하면 include 해주면 메모리 누수 검출의 준비가 끝난다. 누수의 결과는 IDE 창에서 해주게 되는데 아래의 코드를 작성하고 컴파일하면 IDE의 출력창에 누수의 지점과 내용을 출력해준다.

#include "vld.h"

int main()
{
    char *pChar = new char[100];

    return 0;
}

이것은 필자가 VS6.0에서 경험했던 바로 그것이였다. 그러나 단점은 프로젝트의 코드생성이 다중스레드DLL이냐, 그냥 다중스레드냐에 따라 다른 라이브러리를 링크해줘야 한다는 것과 CRT 메모리에 대한 누수만을 검출해주며 COM 메모리 누수는 검출해주지 못한다. 즉, COM군의 함수중에 메모리를 할당해주는 CoTaskMemAlloc 함수에 대한 메모리 누수는 검출해주지 못하는 것이다. 그러나 IDE와 연동되어 IDE의 출력창에서 누수에 대한 정보를 더블클릭하면 누수지점의 코드로 커서가 이동하는 기능은 상당히 매력적이다.

끝으로 두번째는. 하나의 헤더파일과 그에 대한 하나의 소스파일로 구성되는 간단한 구조인데, StackWalker.h 파일을 include 해주고 누수검출 시작과 끝을 지정하는 함수를 호출해줌으로써 메모리 누수 검출의 준비가 끝나게 되어 무척 사용하기가 쉽다. 게다가 CRT 메모리 뿐아니라 COM 메모리에 대한 누수검출까지 가능하다. 또한 메모리 누수에 대한 정보는 3가지로 구분되는데, 간단한 SImple 모드, 좀더 자세한 Advanced 모드, XML 모드이다. 모두 외부 파일을 통해 누수 정보를 개발자에게 Report한다. 하지만 첫번째 소개했던 누수툴과는 달리 IDE와 연동을 지원해주지 않는다는 단점이 있다.

플렛폼이 Windows라는 범위에만 초점을 맞춰볼적에 비록, 최근의 추세가 Garbage Collection에 의한 자동 메모리 정리 기능이 있어, 메모리 누수에 대한 염려가 많이 줄기는 하였지만, .NET에서 지원하는 C++/CLI는 CLR 메모리만이 아니라, CRT, CLR, Stack 메모리에 까지 접근이 가능하므로 메모리 누수에 대해 주의를 요한다는 점에서 아직까지 이러한 메모리 누수 검출 도구는 유용하다고 하겠다.

[참고] 아래 글의 “줘도 못먹는”에 해당하는 오프소스가 아닙니다.

놀고 있는 비디오 메모리 활용

비디오 카드의 메모리의 용량은 적게는 32M에서 256M 정도 된다. 흔히 128M 정도의 카드가 많이 사용된다. 이 많은 비디오 카드의 메모리는 렌더링의 속도를 향상 시키기 위해서 3차원 그래픽 프로그램에서 사용된다. 하지만 3차원 그래픽 프로그램이 구동되지 않을 경우 대부분의 비디오 카드 메모리는 사용되지 않고 낭비된다. 예를들어 필자의 경우 해상도 1280×1024에서 32비트 색상을 사용하고 비디오 카드의 메모리는 128M이므로 128M에서 약 5M를 뺀 약 120M 정도의 비디오 메모리가 놀고 있는 셈이다.

그렇다면 이렇게 낭비되는 비디오 카드의 메모리를 3D 그래픽의 사용 목적이 아닌 일반 메모리처럼 사용할 수는 없을까? 게다가 비디오 카드의 메모리는 일반 메모리에 비해서 그 속도가 훨씬더 빠르다는 장점이 있지 않은가?

비디오 메모리를 사용하기 위해서는 당연히 비디오 메모리에 접근할 수 있어야 한다. 비디오 메모리에 접근하기 위한 API가 필요한데, 접근을 위한 특별한 API 라이브러리를 사용하는게 아니라 OpenGL과 DirectX의 API를 사용하면 되겠다. 여기서 필자에게 익숙한 OpenGL API를 사용하도록 하겠다.

비디오 메모리와 관련된 OpenGL API는 다음과 같다.

– glBindBuffer
– glBufferData
– glBufferSubData
– glDeleteBuffers
– glGenBuffers
– glMapBuffer
– glUnmapBuffer

위의 API는 ARB 군에 속해 있다가 OpenGL 1.5부터는 표준으로 안착되었다. 즉, OpenGL 1.5 이전에는 위의 함수명에다 접미사격으로 ARB를 붙여 사용해야 한다. 예를 들어서 glBindBuffer의 경우 glBindBufferARB 처럼 말이다. 물론 ARB의 경우는 Extension이므로 지원하는지의 여부를 먼저 확인해야 할 것이다. 확인을 위한 문자값은 GL_ARB_vertex_buffer_object이다.

각 함수의 내용에 대한 설명은 생략하고 사용하는 방법에 대해서만 살펴보겠다. 먼저 OpenGL을 초기화하고 현재 그래픽 카드가 지원하고 있는 OpenGL의 버전이 1.5 이상인지를 확인해야 한다. 여기서 한가지 문제점이 있는데, 그것은 바로 OpenGL의 초기화이다. OpenGL을 초기화하지 않으면 해당 API의 진입점을 찾지 못한다. 하지만 3D 기능을 사용하지도 않을 것인데, OpenGL을 초기화하해야한다는 것은 어쩌면 큰 부담이다. 특히 Console 프로그래밍과 같은 경우 렌더링 창에 대한 DC를 얻어와야 OpenGL을 초기화할 수 있는데, 이런 경우에 필자는 바탕화면의 DC를 사용하였다. 초기화를 위해 바탕화면의 DC를 사용하였을뿐, 실제로 무엇인가 렌더링하지는 않았기때문에 별 문제는 없으리라 본다.

어찌되었든 OpenGL을 초기화하고 OpenGL의 버전이 1.5 이상인 경우 위의 API의 진입점 포인트를 성공적으로 얻어왔다면 이제 사용하는 일만 남았다.

사용하는 방법은 정말 간단하다. 일반 메모리의 포인터를 얻어와 사용하는 방법과 유사하기 때문이다.

GLuint bufferID;

glGenBuffers(1, &bufferID);
glBindBuffer(GL_ARRAY_BUFFER, bufferID);
glBufferData(GL_ARRAY_BUFFER, sizeof(BYTE)*allocMemSize, NULL, GL_STATIC_DRAW);
BYTE *pBuffer = (BYTE *)glMapBuffer(GL_ARRAY_BUFFER, GL_READ_WRITE);

먼저 glGenBuffers를 사용하여 비디오 카드 메모리 버퍼의 ID를 생성하고 이 메모리 버퍼를 GL_ARRAY_BUFFER와 묶기 위해 glBindBuffer 함수를 사용한다. 그 후에 glBufferData를 사용하여 실제 비디오 메모리를 원하는 크기만큼 할당하는데 이 경우 가장 빠른 속도를 위해 GL_STATIC_DRAW를 사용하였다. 할당할 메모리의 크기는 자신이 사용하는 비디오 카드의 메모리의 크기를 잘 고려해서 지정하기 바란다. 여기까지 성공하였다면 할당 받은 비디오 카드의 메모리를 일반 메모리의 포인터처럼 사용하기 위해 메모리 주소값으로 Mapping 시키기 위해 glMapBuffer함수를 사용하여 포인터 주소를 얻어 온다. 바로 이 포인터 주소를 사용해서 일반 메모리와 똑같이 사용할 수 있는 것이다.

for(size_t i=0; i

위의 코드는 실제로 비디오 카드의 메모리를 마치 일반 포인터의 개념처럼 사용하는 예를 든 것이다.

이제는 이렇게 사용한 비디오 카드의 메모리를 해제시키는 방법은 다음 코드와 같다.

glUnmapBuffer(GL_ARRAY_BUFFER);
glDeleteBuffers(1, &bufferID);

필자가 시험삼아 10M의 메모리를 비디오 카드에 할당해 사용하는 방법과 일반 메모리에 new 연산자를 이용해 힙에 할당해서 사용하는 방법의 속도 차이를 비교해본 결과 약 3배정도의 속도 향상이 있음을 발견했다.

끝으로 이런 비디오 카드의 메모리의 속도의 장점을 잘활용한다면 빠른 속도를 요구하는 코드에 더욱 좋은 성능 향상을 꾀할 수 있을 것이다. 또한 비디오 메모리의 경우 일반 메모리에 비해 외부의 어플리케이션으로부터의 메모리 해킹이 어렵기 때문에 보안적인 면에서도 좋은 이점이 있을 것으로 생각된다.

뿱스런 나의 GDI+ 사용기

이번에 상당히 황당스런, 하지만 결과를 알고보니 그럴것도 같다는 문제성 코드 때문에 또 하루의 수십%에 해당하는 시간을 소비해 버렸다.

Need는 OpenGL의 텍스쳐맵핑 소스로 BMP, JPG, PNG, GIF등 다양한 이미지 포멧을 사용하기 위해 GDI+의 Bitmap 클래스를 사용하게 되었는데, 이상하게도 Bitmap 클래스를 new 연산자를 통해 Heap에 할당하고 당연이 소멸자에서 delete를 하면 메모리 충돌이 나는 것이였다. delete를 어디선가 두번해 주는 것이 아닌가 하는 의문이 들었으나 그런 부분은 없는 듯 하였다. 또한 분명히 delete 하기전에 클래스의 참조 포인터가 NULL인지를 확인하는 조건까지 따져 코딩했었고….. 오늘은 포기하고 낼 맑은 머리로 해야지 싶어 포기할때쯤, 그 원인이 잡혔다.

프로그램이 시작되면 GDI+ 초기화가 일어나고 종료되면 GDI+ 정리가 일어난다. 문제는 Bitmap 클래스의 해제가 GDI+ 정리 이후에 호출되어져 메모리 충돌이 일어나는 것이였다. 즉, GID+ 관련 클래스들의 생성과 해제는 반드시 GDI+의 초기화와 정리의 중간에 발생해야 한다는 것..! 알고보니 당연한듯도 하다.

하지만 정말 당연한 것일까? 혹시 이런 것은 아닌가..

일단 한번 GDI+ 관련 클래스가 만들어지면 GDI+는 자신의 Namespace의 클래스 중, 생성된 인스턴스를 모두 관리하고 있다는 것. .NET 프레임워크에서 GDI+는 기존의 GDI를 완전이 새롭게 대체하는 요소이다. .NET 하면 GC, 즉 가비지 컬렉션이라는 개념이 존재하는데, 개발자가 생성한 객체를 따로 delete와 같이 직접 메모리에서 해제하지 않아도 알아서 해제를 해주는 참으로 편리한 개념이다. 혹시 이러한 .NET의 중요한 일부를 차지하는 GDI+가 GC를 위해 자신의 Namespace 하의 모든 클래스의 생성을 알고 있기 때문이 아닐까?

이것이 사실이라면 GDI+의 클래스들을 생성하고 직접 해제하지 않아도 GDI+의 정리코드를 호출하면 자동으로 해제된다는 개념이다. 그런데 실제로 GDI+ 클래스를 직접 delete하지 않아도 메모리의 누수가 발견되지 않았고, GDI+를 해제하는 즉시, GDI+ 클래스의 인스턴스의 아무리 사소한 맴버변수나 함수의 호출에 실패한다. 즉, GDI+의 해제시 GDI+의 클래스들의 모든 인스턴스는 무효화 되며 자동적으로 delete 되는 것 같다. Managed가 아닌 개발 환경에서도 말이다.

오전 시간 전부와 오후 시간 조금을 갉아 먹은 코드.

퇴근하기전에 해결하지 못한 코드를 다음 날로 미루고 퇴근한 바로 그 다음날인 오늘, 다시 문제의 코드를 살펴보는데, 도무지 모르겠더라.. 여차저차 해서 문제가 발생하는 방향과 문제가 발생하지 않은 방향은 알게 되었는데.. 그 원인이 무엇인지는 여전히 모르겠더라..

Need는 3DS 파일을 로딩하여 화면상에 표시하는 어느 외국(DigiBen, digiben@gametutorials.com)인 잘만들어 공개해 놓은 소스 코드를 사용하려고 하는데.. 핵심적인 사용은 클래스 하나와 구조체 하나를 조합하여 사용하는 것이었다.

문제는 시험차원에서 만들어 놓은 코드는 잘작동을 하는데, 실제 프로젝트에 적용을 해보면 프로그램이 뻗어 버렸다. 여차저차해서 겨우 문제가 발생하는 경우와 발생하지 않는 경우를 알게되었는데..

문제가 발생하지 않는 경우는 제공되는 클래스 하나와 구조체 하나를 전역으로 선언해 놓고 사용하는 경우고, 문제가 발생하는 경우는 지역이나 힙에 할당해서 사용하는 경우였다.

OOP의 규칙중에 최대한 전역적인 요소를 제거해야 하는 바 절대 전역으로 선언해서 사용해서는 않되었기에 new에 의한 힙 할당으로 사용하려고 했지만 계속 뻗어 버리고.. 뭐가 원인인지도 모르고, 나중에는 제작자의 불순한 의도가 아니겠는가하는 의심까지 들고… 역시 세상에 꽁짜가 없다느니하는 생각이 들더랬다.

제작자의 불순한 의도로 방향을 몰고 가던중에, 소스 코드까지 제공했다면 그 불순한 의도 역시 소스 코드 어디엔가 나를 비웃고 있겠지 하는 생각에.. 반듯이 잡아 족치리라 생각하고 코드 한줄 한줄 디버깅 해 들어갔다. 문제를 발생시키는 함수는 asm 소스로 된 memcpy라는 Ansi C 함수였다. 다시 memcpy가 받은 인자의 값을 살펴보니 웬 쓰레기값?

불현듯… 몽롱한 과거 까까머리로 C/C++을 학습하던 시절에 전역 변수는 자동으로 초기화가 되지만 그외의 경우는 자동으로 초기화가 되지 않는다는 성경말씀이 생각나.. 이것이구나! 라는 생각에 제공되는 클래스와 구조체 중에 구조체의 맴버 변수의 값들을 모두 0으로 설정하고 다시 돌려보니 잘되더라는…. 원인을 알고보니 참으로 어처구니가 없더라는… 하지만 원이 무엇이듯 잘해결이 되니 참으로 감격스러웠다..

이런 감격에 오늘의 교훈을 잊지 않고자 기록에 남긴다. 역시 90%의 오류는 오직 내 안에 있다는 것을… 또한 다른 이의 선행을 확실한 근거 없이 오해하지 말자라고….