Unavailable

RPCGEN 이라는 흥미로운 유닉스 명령어가 있다.

RPC라 함은 Remote procedure call 일꺼다.. -_-;
몇일 전에 외웠는데 까먹었군.. 이놈은 하나의 프로토콜인데 원격 사용자가 서버에 접속하여 명령을 실행하는 것을 말한다..

사실 RPC도 TCP나 UDP를 통해서 원격 사용자 (클라이언트)의 입력값들을 서버측으로 넘겨준다. 결국 TCP/IP 기반의 프로토콜인셈...

하지만 RPCGEN이라는 명령어 때문에 좀 특별해 지는데, 원래 RPC를 사용하려면 클라이언트 측과 서버 측의 stub 를 꼬옥 만들어줘야 한다. (처음에는 걍 하면 안되나 했던 기억이 난다...) 여기서 stub라 함은 하나의 프로그램으로써 사용자에게 각종 잡다한일 예를 들자면 통신 규격으로의 인코딩/디코딩, 각종 입력값의 변환등을 알아서 다 해주는 것이다.

물론 저넘을 사용자가 직접짠다면 골때린다. 우선 RPC를 위한 특별 언어가 따로 존재하여 그 언어를 사용해야만 한다. 아마도 .xdr일 것이다. 고로 언어를 새로 배워야 한다.. 젠장. 물론 C와 매우 매우 유사하기는 해도 짜증이 벌써 밀려온다.

바로 이런 것을 편리하게도 RPCGEN이라는 명령어가 대신해준다. 그저 사용자는 간단한 규칙에 따라서 .x 파일을 작성해 주고 repgen *.x를 해주면 알아서 5개인가 6개의 파일이 만들어진다.

그중에 가장 중요한 파일이 헤더 파일로써 사용자는 그 헤더 파일을 항상 포함시켜서 나머지 사용자 정의 함수를 정의해야 한다.

그러니까 사실 .x 파일은 헤더 파일의 헤더 파일 소스인거다.. -__-;;

암튼, 이렇게 하니까 멀리 떨어진 다른 컴퓨터에서 서버 코드를 실행시켜 놓고 내 컴퓨터에서 클라이언트 프로그램을 수행하면 서버측으로 입력값이 TCP 혹은 UDP를 통해서 날아가는데 이것은 전부 stub라는 놈이 알아서 다 해준다. 사용자는 인터페이스와 규칙만 설정하면 된다.

서버는 들어온 값을 분석하여 서버 컴퓨터의 자원을 이용하여 결과를 다시 리턴하는데 이때도 마찬가지로 리턴되는 모든 것들은 stub를 이용해서 알아서 잘 날아간다...

어찌보면 심히 편하기도 하다. 왜냐면 서로 다른 컴퓨터간의 통신시 가장 문제가 되는 규격을 일치시키는 복잡한 과정이 rpcgen이라는 명령을 통해서 쉽게 이루어 지기 때문인데 단점으로는 세세한 조절을 할 수 없다고 하더라. 당연히 그렇겠지만 그렇다고 새로 언어를 습득하는 것보다는 낫지 않을까?

숙제가 있었다. TCP 커넥션을 만들어서 구성원들끼리 대화를 주고 받는 프로그램인데 특이한 점이라면 서버/클라이언트가 하나의 프로그램에 동시에 존재한다는 점과 한개의 파일로 어디서나 작동하게끔 만들어야 한다는 점이었다.

그닥 어렵지는 않다. 뭐 서버 클라이언트 관계는 못만들 이유가 없고 소켓만 잘 순서대로 연결해주면 아무 탈 없이 돌아갈 줄 알았다. 그런데 문제는 의외에 장소에서 터졌다.

프로그래머라면 당연히 관련된 정보는 하나의 구조체로 묶어서 관리하는 것이 좋다는 것을 안다. 그리고 나도 그대로 했다. 특정한 형태를 유지 시키기 위해서 구조체를 만들어서 각종 정보를 담아 두었다.

이 프로그램은 ssh를 이용해서 다른 컴퓨터에 접속한 다음 거기서 명령을 실행하는 것이 주 목적이다. 근데 이상하게도 바꾸지도 않았는데 구조체의 값들이 지 맘대로 변하는 것이 아닌가?

아무래도 이상해서 이리저리 테스트를 해보아도 도데체 이유를 몰랐다. 그런데... 알고보니...

구조체에 char *IP_addr이라는 멤버가 바로 문제 였다. 이 포인터의 값이 비록 내가 ssh를 이용해 원격 접속을 다른 컴퓨터에 하더라도 같은 값을 가지며 현재 사용중이 컴퓨터의 local memory를 가리킬 것이라고 생각 못했다.

분명히 다른 컴퓨터의 다른 주소에 위치 할 줄 알았는데 그게 아니었다. 그래서 아무리 값을 바꾸려고 해도 그 값들은 오직 같은 값만을 유지했던 것이다. 이런건 책에 나와 있는지 모르겠다. 아무튼 구조체 내에 절대로 포인터를 쓰지 말라는 말은 들어본 적이 없는 것 같다.

아무튼 저놈 때문에 금요일 오후를 홀딱 날렸다. 젠당.. 다음부턴 주의 해야지. 아, 해결법은, 구조체 내에 멤버를 선언할 때 char IP_addr[MAXLEN] 처럼 고정된 주소 공간을 가지는 형태로 바꾸고 strcpy를 이용해서 데이터를 입력해 넣었더니 '무슨 일 있었나요?' 라고 하며 바로 작동이 잘되었음... 젠당...

현재 내가 수행중이 프로젝트는 절묘한 Stencil Buffer 사용을 요구한다.

Framebuffer Object의 Stencil buffer를 사용하려고 하다보니 생각지 못한 문제들에 막힌적이 있었다.

우선 Framebuffer Object 사용시 Stencil Buffer의 세부 규약에 대해서 몰라서 어떻게 세팅하는지 몰랐고

다른 한가지는 Nvidia 그래픽 카드에서는 Nvidia에서만 허용되는 특수한 타입이 있는데 그것을 반드시 써야만 Framebuffer Object의 Stencil Buffer를 아무 에러없이 쓸 수 있다는 점이었다.

이것은 다음에 자세히 알아보도록 하고 오늘은 Stencil Buffer를 어떻게 정하고 또 어떻게 사용하는지만 이야기 해보자.

우선 Stencil Buffer를 정의하는 것부터 시작한다. Stencil Buffer를 어디서 정의해야 하는가 하는 의문부터 해결하자. Stencil Buffer라 함은 사용자가 원하는 부분만 그려내고 싶을때 사용하는 기술이다.

자동차 게임을 예로 들어보면 Need for speed에서 자동차 내부에서 보는 시점이 있다. 그 때에는 차 앞쪽과 측면 유리를 통해서만 외부의 세상이 보여질 뿐이다. 바로 이럴때 Stencil Buffer를 사용한다. Full Screen으로 렌더링 할 필요가 없고 사용자가 원하는 부분만 보여주고 싶을때 이다.

그렇다면 당연히 외부의 세상을 그리기 전에 Stencil Buffer를 정의해야 한다. 외부의 모든 물체를 다 그려놓고 보이지 않는 부분을 삭제하는 것과 보여지지 않는 부분을 빼고 그리는 것 둘중에 어떤것이 더 나을까 라고 스스로에게 질문해보자.

그래서 물체를 그리기 전에 다음과 같은 명령들을 내려줘야 한다.

  glColorMask(0, 0, 0, 0); // 1
  glEnable(GL_STENCIL_TEST); // 2
  glStencilFunc(GL_ALWAYS, 1, 1); // 3
  glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE); // 4
  glDisable(GL_DEPTH_TEST); // 5

  glColor3f(0.0f, 1.0f, 0.0f); // 6
  glPushMatrix(); // 7
  glTranslatef(VP_x, VP_y, -10.0f); // 8
  glCallList(MakeMask); // 9
  glPopMatrix(); // 10
  glDisable(GL_STENCIL_TEST); // 11

1번은 Color Buffer(화면에 보여질 모습이 저장되는 버퍼)에 어떠한 색깔도 그리지 말라는 의미인데 이것을 하는 이유는 현재 우리는 Stencil Buffer에 그림을 그리고자 하는 것이지 Color Buffer에 그림을 그리고자 하는 것이 아니기 때문이다. Stencil Buffer에 그리고자 하는 그림이 화면에 그대로 보인다면 당연히 이상한 그림이 나올것이다.

2번과 5번 11번은 굳이 설명하지 않아도 알것이다. Stencil 기능을 켜고 끄며 혹은 Depth test를 끄는 기능들을 한다.

이제 3번과 4번이 중요한데 이거 상당히 복잡해서 나도 처음에 볼때는 많이 애먹었다. 3번 함수는 Stencil Buffer에 값을 쓸때 어떤 경우에 쓰고 또 어떤 값을 쓸것인가를 설정하는 함수다. 아시다시피 Stencil buffer는 단순히 생각해서 0과 1로 이루어진 bitplane이다. 즉 1이면 통과 0이면 통과 실패이다. 여기서 이해하고 넘어가야 할것은 stencil buffer를 정의할 때는 일일이 각각의 화소 위치에 대해서 1과 0을 세팅하는 것이 아니고 내가 원하는 위치에 물체를 그려 넣음으로써 그 부분은 1로 채워지게 만드는 것이다. 원래 Stencil Buffer는 모두 0으로 가득 차 있는데 내가 보여주고 싶은 부분에만 그림을 그려 넣으면 3번과 4번 함수에 의해서 그 부분의 Stencil buffer 값은 모두 1로 바뀌게 되는 것이다.

의미적으로만 설명을 했는데 3번과 4번 함수는 인터넷에서 man page를 찾아보면 금방 이해할 수 있을 것이다. 중요한 것은 이 단계에서는 Stencil buffer에 우리가 보여주고 싶은 부분만 그린다는 것이다.

6,7,8,9,10은 모두 물체를 그리는 명령이다. 다 설명하자면 너무 길고 어쨌든 줄여서 저 명령들은 내가 원하는 위치에 내가 원하는 물체를 그리는 것이다. 고로 그 위치의 Stencil Buffer 값은 모두 1로 변하게 된다. 자, 여기까지 하면 이제 비로서 Stencil Buffer를 사용할 수 있는 단계에 온것이다. 이제 고작 사용할 수 있는 단계에 온것이다. 그렇다면 어떻게 사용하느냐? 오히려 사용하는 것이 더 쉽다.

    glEnable(GL_STENCIL_TEST);
    glColorMask(1,1,1,1);
    glStencilFunc(GL_EQUAL, 1, 1);
    glStencilOp(GL_KEEP, GL_KEEP, GL_KEEP);
 
    glPushMatrix();
    glCallList(MakeSpaceShip);
    glPopMatrix();
 
    glDisable(GL_STENCIL_TEST);

위의 일련의 명령이 사용하는 법이다. 우선 Stencil Test를 Enable한다음 glColorMask()함수를 이용해서 지금부터 그리는 물체를 color buffer에 넣으라는 명령을 내린다. 당연히 그래야 한다. 왜? 지금부터는 사용자에게 보여줄 화면을 그리는 것이기 때문이다. 그런다음 설정함수인 glStencilFunc와 glStencilOp가 나오는데 이것은 아까 본것과 조금 다를뿐 거의 같다. 함수에 대한 설명은 여기서 다 하기 힘드니 함수 설명을 찾아보고 읽으면 금방 이해가 갈것이다. 저 두함수가 하는 역활은 들어오는 각각의 화소에 대한 값을 stencil buffer의 해당 위치의 값과 비교해서 1이면 통과 0이면 통과 실패를 시키는 것이고 추가적으로 stencil buffer에 저장되어 있는 값은 변경하지 말라는 의미이다. 당연히 stencill buffer를 변경해서는 안된다.

그리고 그 다음 좌악 나오는 명령들은 이제 진짜 그림을 그리자는 명령들이다.

쉽게 쉽게 그리고 간단하게만 썼는데 나중에 내가 참고하려고 할때 다시 보면 이해가 잘 될지 모르겠다.ㅋㅋ
팍팍 줄여서 단계별로 설명하자면,
1. 스텐실 버퍼에 내가 보여주고자 하는 부분만 그린다.
2. 실제로 물체를 그리고자 할때에는 스텐실 버퍼 설정함수를 조작하여 스텐실 버퍼가 1의 값을 가지는 곳만 그림이 그려지도록 한다.

아주 간단하게 써보았다. :)

아놔 첨에 이거 보고 뭐가 문제야 라고 했다는.. ㅋㅋㅋ 한 3초쯤 보니까 빅 웃음 나오네..

제목이 너무 도전적이지 않나 하는 걱정이 앞선다.

게임이라는 것이 내 인생에 그만큼의 큰 영향을 준다고 해도 과언이 아니라는 의미다.

게임 폐인이라고는 말 못하지만 정상이었다고도 말 못하는 수준이랄까. :)

사실 이런 내 모습을 부정해 본적도 많다. 현실을 부정하고 게임이라는 세상에 자꾸 몰입한다는 것이 어쩌면 나의 현실 도피를 위한 수단이 아닌가 하는 생각까지 해봤다.

하지만 결국 내가 깨닳은 것은, 나는 게임 그 자체를 좋아했던 것이 아니라 내가 좋아하는 친구들과 함께 무엇인가를 즐긴다는 것이 더 큰 의미 였던것 같다.

멀리와서 나의 절친(절친한 친구)이 없는 곳에서 혼자서 게임을 해보니 이건 단순한 클릭질일 뿐이었다. 물론 시간때우기에는 좋지만 게임을 하다보면 시간을 낭비했다는 생각이 심하게 많이 든다. 그런 생각은 예전에는 단 한번도 한 적이 없다. -_-

그런 의미에서 나에게 게임은 '좋아하는 것을 친구와 함께 한다' 라는 의미로서 내 인생에 큰 영향을 주었던 것임에 틀림이 없다.

아직도 그 생각에는 변함이 없고 나이가 들더라도 그 생각에는 변함이 없을 것 같다.

OpenGL... 처음 들었을때는 심히 막연했던 단어가 아닌가 싶다.

프로그래밍에 대해 그닥 자신이 없는지라 더더욱 그랬다. 처음에는 OpenGL이 단순히 프로그래밍 언어라고 생각했었다. 하지만 알고보니 Library 였던 것이다. -_-

하지만... 차라리 프로그래밍 언어였으면 좋겠다라고 생각한 적이 있을 정도로 갑갑한 적도 있었다. 아예 프로그래밍 언어라면 여러가지 면에서 설명이나 구현이 더 일관성이 있어 질 것이라고 생각했기 때문이다.

뭐 지금은 그럴 필요가 왜 없는지 대충 감이 오긴 오지만 아직 공부를 더 해야....

오픈GL 입문서라 불리는 Red book을 읽다보니 제법 재미있다는 것을 알았다. '오 이거 신기한데~' 랄까..

나처럼 영상 분야를 공부하는 사람이라면 OpenGL이야 말로 나의 상상을 펼치게 만들어주는 날개와도 같다는 생각이 든다.

이론과 광학 장비로는 절대 풀수 없는 문제를 OpenGL을 통해 구현해 내는 것을 보면 신기하기 그지 없다.

그래서~ OpenGL 목록을 만들었고 내가 사용했던 혹은 사용할 유용한 프로그램 Tip이라든가 조그만 도움말정도의 글을 적어둘까 한다.

이제 겨우 시작이긴 하지만 재미있다고 느끼는 일이 생겨서 다행이다. :)

푸헐헐...

얼씨구나 좋구나~ :) 나도 이제 제대로된 블로그 하나 열었구나~

처음에 회원 인증하라는 메일 받고 가짜 메일인줄 알았는데 진짜였구나. 감격...

왜 회원 초대를 받게 되었는지 아직도 이유를 모르지만 아마도 나의 절친 삽수가 초대한게 아닌가 하는 생각이 든다.

땡큐 삽수 :) 이제부터 나도 열심히 블로그를 꾸며 나가야지.