지금으로부터 까마득한 과거, 티라노가 풀뜯어먹던 시절에 그래픽하는 선배랑 룸메를 하고 있었다.
당시 다양한 그래픽툴들을 구경할 수 있었고 배울수 있었는데,
그중 개발자로써 관심이 많이 갔던 것이 브라이스(Bryce)라는 툴이었다.
브라이스는 독특하게도 지형 모델링 + 렌더링에 특화된 전문툴로써 MAX처럼 폴리곤이 아닌 2D 이미지를 그려대면 그것을 기초로 멋진 3D 지형을 만들어 주었다. 기본적인 텍스쳐까지 말이다!
브라이스는 스스로를 Fractal 어쩌구 하면서 자랑을 하는 툴이었고,
한눈에 봐도 엄청나보이는 알고리즘과 무지막지할 수학 공식이 엿보였으므로,
"난 평생 이런거 짤일 없을꺼야~"
라는 부끄러운 자위를 하며 분석과 흉내란 도전에서 도망쳤었다.
그러나 시간은 흘러 게임에서 지형은 삼각형 양탄자에서 쿼드트리를 거쳐 높이맵, 라이트맵이 나오고 지형엔진이란 말까지 오래 전에 나와버렸다. Rhea君의 경우, MMORPG보다는 MO를 더 좋아하기에 솔직히 지형에 대한 공부는 별로 하지 않았다. Seamless 월드보단 메탈기어솔리드2같이 한정된 공간 사이사이에서 뛰어노는 게임이 더 좋았고 콘솔게임에 익숙하다보니 월드를 이동할때 생기는 로딩과 연출, 거기에서 나오는 게임의 성격을 자연스레 받아들인 탓이었다.
아뭏든 그래도 직업이 직업이다보니 공부는 계속 하게될수 밖에 없고 실전(=상용) 프로젝트에서 사용하든 접히든(- -;;;;) 계속 삽질을 해야하는게 개발자의 사명이거니 했다. 물론 그 과정 속에서 브라이스가 보여준 독특한 지형 제작 방식이 높이맵(Heghtmap)이란 것도 저절로 알게되었다.
모르는 사람들을 위한 높이맵 이야기
산, 바다, 언덕, 계곡...등과 같이 높낮이가 있는 지형을 만드는 것이 높이맵이다. 상식적으로 모든 3D는 삼각형들로 이루어져 있으며 지형 역시 삼각형 덩어리이다. 이 삼각형들이 같은 높이로 깔려있으면 그야말로 평지일 것이고 높이 방향에 대해 튀어 나오고 들어가면 산이 되고 바다가 된다.
그럼 튀어나오게 하고 들어가게 하는 정의가 필요한데 주로 사용되는 것이 256 단계를 지닌 Gray Scale 비트맵 이미지가 되겠다. 알다시피 컴퓨터에서 채도가 없는 회색은 0~255의 단계를 지니고 있기에 256 그레이 스케일 이미지는 높낮이 편집에 아주 유용한 데이터 정의가 된다. 바로 브라이스가 이걸 보여줬었던 것이다. 0이면 솟아오르고 255면 꺼지면 된다.
이 이미지를 바탕으로 정점들을 올리고 내리자. 그냥 작업하면 너무 밋밋하니까 잔디 무늬가 있는 텍스쳐도 하나 같이 올리자.
포스트 공간도 부족하고, 높이맵 따라하기~ 스터디용이 아니니까,
이 싯점에서 굳히 소스까지 뿌려가며 설명할 필요는 없으리라 생각한다.
아뭏든 여기서 중요한 것은,
3D 모델링이 원래 높낮이가 있다는 것이 아니라 읽어들인 한장의 이미지에 의해 높낮이가 만들어졌다는 사실이다.
더 정확히 말하자면 높낮이를 위해서 1장, 텍스쳐 세장, 그리고 텍스쳐의 경계선을 만들기 위해 1장, 총 5장의 이미지가 사용되었다. 그러나 가장 중요한 3D를 만들기 위해서는 정말 1장이 쓰여졌다.
높이맵은 모션포트레이트가 핵심으로 내걸고 있는 "한장의 이미지로 방향을 갖고 움직이게 한다"라는 사실과 일치한다.
모션포트레이트
액션스크립트 3.0에서 flash.geom 네임스페이스가 추가되었다.
(http://help.adobe.com/ko_KR/AS3LCR/Flash_10.0/flash/geom/package-detail.html)
아, 정말 플래시 너무하는구나. 이것으로 본격 3D 개발툴이 되었다. GPU까지 직접 쓸수 있게 되면... 우~~ 놀라워라~~!
현재로는 소프트웨어 렌더러라고 생각되지만 아뭏든 플래시의 행보는 무섭다.
비단 플래시 뿐만 아니라 포토샵 CS4 역시 Dimension이 번들되면서 GPU 지원까지 하고 있는데 플래시도 조만간 GPU를 적극 활용할 것 같다.
WPF도 Direct3D를 불러쓰고있지만 WPF가 보여주는 아웃풋은 플래시의 그것과는 자뭇 달라서 실망감이 컸던게 사실이었다. 물론 가장 필요한 킬러 타이틀이 없어서 그렇기도 하지만, 현재로 보기에 WPF는 처량해보이는게 사실이다. 차라리 Silverlight에게 희망을 걸어보고 싶지만... 수많은 디자이너들이 액션스크립트에서 C#으로 넘어가는 것도 결코 쉽지 않을 것이라 HD 스트리밍을 제외하면 플래시가 앞으로도 우위를 지킬 것 같다.
...또 말이 꽤나 빗나갔군. 모션 포트레이트, 다시 한번 더 봅니다.
우리 단장님.
무섭다. ㅠㅠ
솔직히 나는 정교한 MAX 모델링(예컨데 얼굴 + 눈알이 있는)을 보고도 ㅎㄷㄷ;;; 거린다.
텍스쳐 이미지를 보면 인간의 살가죽을 벚겨놓은 듯해 코딩하면서도 조낸 무서워한다. ㅠㅠ;;;;
카메라에 대한 멀미도 하는데... 어찌보면 게임 프로그래머로써 최악의 조건을 지닌 셈이다.
우선 매핑을 더 올려보았다.
코가 아주 못생겨졌는데 이는 아직 전체에 대한 원근감이 남아있기 때문에 색이 두드러져 보이기 때문이다.
이제 노말 적용, 직교행렬을 이용한 카메라 설정, 커서 위치 판단...등등이 남았다.
시간 관계상, 오늘은 일단 여기까지 적용해본다.
워낙 텍스쳐가 뛰어나니 높낮이를 없애고 직교행렬만 적용시키면 정말 상기의 모션포트레이트처럼 나오리라 확신한다.
이것으로 한동안 화제였던 모션포트레이트의 기본적인 비밀을 밝혔다.
(원래 생각은 한꺼번에 다 구현해볼 생각이었는데 먹고 사는 문제 때문에... ㅠㅠ)
"높이맵 = 외부 지형, 라이트맵 = 내부 지형"이란 선입견의 제약으로
조금만 더 아이디어를 올리면 무언가를 해볼수 있는 기회를 우리는 그냥 놓아버리게 되는 것이 아닐까 한다.
모션포트레이트도 보다 모에하도록 구현을 해볼 것이고 위에 느낀 감정을 기억하며 하나의 기법으로 새로운 효과를 만들어내는 습관을 지녀야 할 것같다.
보다 모에해지고, 쓸만한 효과가 나올떄 모션포트레이트를 다시 포스팅하겠다.
