Rhea's Package

소실편 하루히 100개를 그리라고 했더니 이런 꽁수를 썼음.
픽셀단위까지 작업하지 못한 죄를 추궁하려 했으나 이 정도로 용서.

내년 2월 6일엔 교토로 가서 성지순례를 하고와야 하는데... 흐음...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지금으로부터 까마득한 과거, 티라노가 풀뜯어먹던 시절에 그래픽하는 선배랑 룸메를 하고 있었다.
당시 다양한 그래픽툴들을 구경할 수 있었고 배울수 있었는데,
그중 개발자로써 관심이 많이 갔던 것이 브라이스(Bryce)라는 툴이었다.


브라이스는 독특하게도 지형 모델링 + 렌더링에 특화된 전문툴로써 MAX처럼 폴리곤이 아닌 2D 이미지를 그려대면 그것을 기초로 멋진 3D 지형을 만들어 주었다. 기본적인 텍스쳐까지 말이다!
브라이스는 스스로를 Fractal 어쩌구 하면서 자랑을 하는 툴이었고,
한눈에 봐도 엄청나보이는 알고리즘과 무지막지할 수학 공식이 엿보였으므로,

"난 평생 이런거 짤일 없을꺼야~"

라는 부끄러운 자위를 하며 분석과 흉내란 도전에서 도망쳤었다.

그러나 시간은 흘러 게임에서 지형은 삼각형 양탄자에서 쿼드트리를 거쳐 높이맵, 라이트맵이 나오고 지형엔진이란 말까지 오래 전에 나와버렸다. Rhea君의 경우, MMORPG보다는 MO를 더 좋아하기에 솔직히 지형에 대한 공부는 별로 하지 않았다. Seamless 월드보단 메탈기어솔리드2같이 한정된 공간 사이사이에서 뛰어노는 게임이 더 좋았고 콘솔게임에 익숙하다보니 월드를 이동할때 생기는 로딩과 연출, 거기에서 나오는 게임의 성격을 자연스레 받아들인 탓이었다.

아뭏든 그래도 직업이 직업이다보니 공부는 계속 하게될수 밖에 없고 실전(=상용) 프로젝트에서 사용하든 접히든(- -;;;;) 계속 삽질을 해야하는게 개발자의 사명이거니 했다. 물론 그 과정 속에서 브라이스가 보여준 독특한 지형 제작 방식이 높이맵(Heghtmap)이란 것도 저절로 알게되었다.

모르는 사람들을 위한 높이맵 이야기
산, 바다, 언덕, 계곡...등과 같이 높낮이가 있는 지형을 만드는 것이 높이맵이다. 상식적으로 모든 3D는 삼각형들로 이루어져 있으며 지형 역시 삼각형 덩어리이다. 이 삼각형들이 같은 높이로 깔려있으면 그야말로 평지일 것이고 높이 방향에 대해 튀어 나오고 들어가면 산이 되고 바다가 된다.


그럼 튀어나오게 하고 들어가게 하는 정의가 필요한데 주로 사용되는 것이 256 단계를 지닌 Gray Scale 비트맵 이미지가 되겠다. 알다시피 컴퓨터에서 채도가 없는 회색은 0~255의 단계를 지니고 있기에 256 그레이 스케일 이미지는 높낮이 편집에 아주 유용한 데이터 정의가 된다. 바로 브라이스가 이걸 보여줬었던 것이다. 0이면 솟아오르고 255면 꺼지면 된다.


이 이미지를 바탕으로 정점들을 올리고 내리자. 그냥 작업하면 너무 밋밋하니까 잔디 무늬가 있는 텍스쳐도 하나 같이 올리자.



포스트 공간도 부족하고, 높이맵 따라하기~ 스터디용이 아니니까,
이 싯점에서 굳히 소스까지 뿌려가며 설명할 필요는 없으리라 생각한다.

아뭏든 여기서 중요한 것은, 이제 LOD를 구현하고 원금감을 위해 포그(fog)를 넣어야 한다
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 스트리밍을 제외하면 플래시가 앞으로도 우위를 지킬 것 같다.

...또 말이 꽤나 빗나갔군. 모션 포트레이트, 다시 한번 더 봅니다.

우리 단장님.

역시 이게 만들자~ 식의 강좌는 아니고 포스트 길이의 압박으로 과정과 소스 분석은 생략하고... 지난 회에서 역컴파일 했을 때, 회색으로 나온 높이맵 이미지를 일단 올려보았다.  

원본 높이맵 소스

 

일단 3D 높낮이가 만들어졌다.

  흠좀무... 텍스쳐를 그대로 사용했더니 마치 화성의 안면암이 떠오른다. - -;;;;;;;;;;;;; (보통 책에서는 텍스쳐를 없애버리고 음영만 준다.)  

......ㅎㄷㄷ;;;;

무섭다. ㅠㅠ
솔직히 나는 정교한 MAX 모델링(예컨데 얼굴 + 눈알이 있는)을 보고도 ㅎㄷㄷ;;; 거린다.
텍스쳐 이미지를 보면 인간의 살가죽을 벚겨놓은 듯해 코딩하면서도 조낸 무서워한다. ㅠㅠ;;;;
카메라에 대한 멀미도 하는데... 어찌보면 게임 프로그래머로써 최악의 조건을 지닌 셈이다.

우선 매핑을 더 올려보았다.

코가 아주 못생겨졌는데 이는 아직 전체에 대한 원근감이 남아있기 때문에 색이 두드러져 보이기 때문이다.
이제 노말 적용, 직교행렬을 이용한 카메라 설정, 커서 위치 판단...등등이 남았다.

시간 관계상, 오늘은 일단 여기까지 적용해본다.
워낙 텍스쳐가 뛰어나니 높낮이를 없애고 직교행렬만 적용시키면 정말 상기의 모션포트레이트처럼 나오리라 확신한다.

이것으로 한동안 화제였던 모션포트레이트의 기본적인 비밀을 밝혔다.
(원래 생각은 한꺼번에 다 구현해볼 생각이었는데 먹고 사는 문제 때문에... ㅠㅠ)


모션포트레이트도 보다 모에하도록 구현을 해볼 것이고 위에 느낀 감정을 기억하며 하나의 기법으로 새로운 효과를 만들어내는 습관을 지녀야 할 것같다.

보다 모에해지고, 쓸만한 효과가 나올떄 모션포트레이트를 다시 포스팅하겠다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

몇년을 기다렸던가!
쿄애니 만세!!!!!!!!!!




 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

소니(Sony-Kihara Research Center)에서 개발한 모션 포트레이트(motion portrait)는 이제 꽤나 알려진 기술이 되었다.



또다른 데모들은 모션 포트레이트 사의 홈페이지에서도 볼수 있다.
http://www.motionportrait.com/about/demo_others_01.html

하지만 실제 게임에서 적용된 것은 반다이-남코의 "스즈미야 하루히의 약속"과 "토라도라 P"일 것이다.
(홈페이지를 보면 실제 모션 포트레이트는 모션 포트레이트 사에서 가져온 기술이라고 적혀있다.)

SWF로 약간의 데모가 공개되어 있어서, 염치불구하고 이곳으로 모셔보았다.

  이런 모션 포트레이트 기술이 루리웹등을 통해 알려진 것은 "1장의 이미지로 만드는 2D 기술"이란 설명 때문이었다. 결론부터 먼저 이야기하면 이것은 2D 기술이 아니었다. 완벽한 3D 기술이었다.   처음에 Rhea君 역시 그 말을 보고 다음과 같은 상상을 했었다.  

1) 움직이는 부분들은 각각의 2D 이미지이다. 2) 이미지는 각각 개체와 되어 움직이다. 와타나베 연구소의 Glove On Fight처럼.

Glove On Fight

3) 얼굴을 돌리는 것은 영역별로 픽셀을 줄이거나 늘리거나 해서 돌아가는 것처럼 보인다.

  그러나 3)의 경우, 아무리 생각해도 결코 쉽지않은, 노가다^노가다^노가다^노가다 스러운 부분이라 호기심이 발동하지 않을 수가 없었다. 그리하여, 플래시 디컴파일러를 동원하여 살펴보기로 하였다.  

디컴파일 중~

  아 그런데 SWF 속에는 원하는 이미지 따위는 존재하지 않았다. (눈썹이나 입 모양을 위해 PNG 파일을 로딩하는 부분은 발견했다. 따지고 보면 하드코딩한 부분이라 할수 있다.)   혹시나 하는 마음에 Fiddler를 통해 살펴보니, 역시나 예상대로 비트맵 이미지를 모아둔 SWF를 따로 로딩하는 것을 확인할수 있었고 해당 SWF도 까...보았다.   

리소스 전용 SWF를 다운받는 것, 발각!

   

단장님의 얼굴이시다...그런데?

  윗 짤방은 리소스들을 보여주는데 일단 조각난 얼굴이 공포스럽게 해주신다. 그리고 image10 과 image 13 처럼 알파값처럼 나타나는 부분은 아주 중요한 부분이 될 것 같다는 느낌이 든다.   이 때 마침, Rhea君 옆을 우연히 지나던 우연君과 태완성, 이 모습을 보고 한마디씩 하신다.  

태완성 : 니들은 또 미소녀만 갖고 노냐? Rhea君 : 허어~ 형님~ 이건 미소녀이 아니라 그래픽 공부라고요~* 태완성 : ...근데 니들 그래픽 예제는 왜 다들 미소녀만 나와? Rhea君 : 아니 미소녀가 없는데 왜 관심을 가져야 하나요?              .......우연君, 이 알파값으로 픽셀 영역을 줄이거나 늘릴 영역을 지정하는것 아닐까? 우연君 : 흠... 내가 보기엔 이거 알파값이 아니라 깊이(Depth)값 같은데? 

  이때 삥!하고 계시가 내려왔다! 그렇다, 이건 2D 장난이 아니라 깊이맵으로 구현한 것이란 직감이 들었다.

지못미, 하루히

깊이맵과 모션포트레이트 분석은 다음 포스트에서 계속!!!
                                                         http://rhea.pe.kr/261

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

"사수좌의 날에서 나가토가 입력한 프로그램, 그거 진짜 소스 코드래요."

하루히 2기에 대한 이야기를 오덕오덕거리다가 진형군이 이런 멘트를 했습니다.
이미 12화의 기타 코드는 실제 코드로 알려져있었고 쿄토 애니라면 충분히 있을 수 있는 일이죠... .

이 떡밥을 물자마자 당장 하루히 11화, 사수좌의 날(The Day of Sagittarius)을 돌려보았습니다.
그리고 아래는 그 코드를 캡쳐한 것입니다.

본론으로 돌아가봅시다.

우선 이 코드의 대부분은 몇개의 Cmd 콘솔창에서 이뤄집니다.
이것을 보면 "type" 명령어로 텍스트를 뿌렸거나 "copy con" 을 이용하며 Cmd 상에서 소스 파일을 만들고 있는 것으로 추측됩니다.
하지만 실제로 자세히 보면 여러개의 콘솔창의 소스 코드가 같습니다.
아뭏든 이 상황을 짐작해보면, 현재 나가토의 PC에는 컴파일러와 링커는 있으되 IDE가 없다는 사실을 알수 있습니다.
마치 Turbo-C 1.5 나 리눅스 기본 환경같은 상황이군요.


이젠 소스를 볼까요?

이 콘솔창, 아주 건방집니다.
가로 스크롤바도 안보이는 주제에 가로 스크롤이 되어 앞부분이 잘 보이지 않습니다.

소스를 잘보면 대체로 Process를 건드리는 것이라고 추측됩니다.

이런 핸들 선언과

함수가 가장 먼저 눈에 뜁니다.
CreateToolhelp32Snapshot()은 지정한 프로세스들이 사용하고 있는 힙(heap)과 모듈, 그리고 쓰레드의 현재 모습을 얻어오는 API 라고 MSDN께서 말씀해 주십니다. ^^ (http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx)

프로세스 상태를 구하는 것은 후킹과 리버스 엔지니어링의 시작!
이를 통해 나가토는 후킹을 이용해 자신들의 PC에 설치된 (컴연을 검색하는 루틴이 빠진)게임을 수정할려고 하는 것이라고 유추할수 있습니다.

sub_03 콘솔을 봅시다.

(http://msdn.microsoft.com/en-us/library/ms684320(VS.85).aspx)

OpenProcess() 함수가 반겨주네요. OpenProcess()는
아마도 현재 자신들의 게임에 무언가 작업을 걸려고 준비 중인가 봅니다.

짤방에는 나오진 않지만 그전에 살짝

(http://msdn.microsoft.com/en-us/library/ms684834(VS.85).aspx)

이란게 지나가는데 프로세스 스냅샵으로 얻은 현재 프로세스의 핸들을 구해 OpenProcess()로 강제로 열려는가 봅니다.
또한 코드를 아무리 봐도 socket이나 pipe 같은 네트워크 함수는 찾을 수 없었습니다.
순수히 로컬의 프로세스를 변형시켜 TCP 패킷을 짜맞추려는가 봅니다.

이것은 전형적인 프로세스 변형을 통한 온라인 게임 공격방식!! 게임의 TCP 패킷 프로토콜을 몰라도 변형과 서버 공격이 가능하다는 장점이 있고 여전히 서버 개발자를 괴롭히는 악질 해킹기법입니다.

main() 함수가 등장했습니다.
자막에 가려져 잘 안보이지만 상당히 간단합니다.

이제까지 만든 함수는 결국 GetProcessList() 라는 녀석이군요.
함수 이름 참 민망합니다.
프로세스 리스트를 보여줌과 동시에 프로그램 변형을 함께 시도하는군요.

어이, 나가토~ 함수를 둘로 쪼게시게.
나라면,

으로 할 것이네.

그런데 여기서 주목해야 할 것은 MessageBox()가 MB_YESNO 가 아니라 MB_OK란 사실입니다.
리턴값도 체크하지 않아요.
결국 이 프로그램은 쿈의 의사와 관계없이 무조건 실행시켜버리겠다는 나가토의 무서운 의지가 담겨져 있습니다.
ESC를 누르건, Enter를 누르건, 클릭질을 하던 무조건 프로그램은 실행됩니다.
멈출 방법은 오직 작업관리자에서 프로세스 강제로 끝내는 수밖에 없습니다.

실행 모습입니다.
오~~ 고증이 철저하군요. MB_OK 답게 OK 버튼 하나만 떴습니다.
리턴값 체크 없으니 [X] 눌러도 프로그램은 실행될 수 밖에 없습니다.
하지만 애니메이션상에 버그는 보이네요.
이 프로그램은 이미 실행되었으니 콘솔창에 캐릿은 캐리지 리턴 되어야 하는데 그냥 떠있습니다. ^^


MB_OK 인 주제에 뭔 허가를 바랍니까?
쿈이 싫다고 하면 프로세스 강제로 끝낼 건가요?
이거 쿈이 컴맹, 아니 프맹이라는 사실을 이용한 외계 로봇의 농간입니다.
(마치 컴맹 기획자를 농락하는 어떤 개발자의 모습이 연상되는 것은 왜일까요? -_-;;;)
 

점심시간에 SOS단 홈페이지(http://www.haruhi.tv/) 를 뚝딱 만든 쿈이지만,
역시 바이너리 프로그래밍은 전혀 알지 못하는 프맹이란 사실이 만천하에 드러났습니다.

이렇게 아무런 버그없이 클린 실행은 되고

프로세스 인젝션 기법으로 컴연을 이겼고...

단장님과 그 추종자들은 기분이 좋아 덩실덩실 춤을 추십니다. 응?

안돼, 나가토... 미래를 위해 프밍 따윈 잊고 너도 수능 목표를 공대말고 의약대 & 사법고시를 목표로... .

거봐, 프로세스 인젝션을 하던 뭘 하던 앞에 나설수 있는건 개발자가 아니라니까! 흐흐흑

아뭏든 사수좌의 날을 재분석 함으로써 우리는 다음과 같은 사실을 알수 있었습니다.

그리고 추가로 하루히 위키(http://wiki.sos-dan.com/wiki/The_Day_of_Sagittarius)에서 다음과 같은 사실을 알 수 있었습니다.
1) VC++ 이 아닌 볼랜드 C (Borland C)였다는군요.
2) 소스코드를 분석한 덕후가 일본에 있었습니다!!! 아마 블루레이였기에 소스 분석이 더 쉽게 가능했을리라 생각됩니다.
   (http://blog.proj.jp/ituki/data/2006/20060615.SimInject.org.cc)


저도 프로세스 인젝션 소스 분석과 공부를 위해서
                              어쩔수 없이 하루히 블루레이를 사야겠습니다.
  

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이번에 새로 구입한 물건 중, 가격대 성능면에서 가장 발군의 위력을 발휘하는 것은 하루히(2기의 예고) 롤스크린이다.
원래 커튼보다 롤스크린을 더 좋아하기에 이번에도 커튼은 버리고 세개의 창문에 전부 롤스크린을 붙였다.


방 정리 전의 모습이라 좀 지저분한데(사실 별로 차이 나지 않는다.-_-), 그냥 이렇게 평범한 롤스크린이지만
아침에 보면 묘한 분위기를 내어준다.


자동 카메라의 한계로 아침 특유의 그 분위기를 담을수는 없어도 실제 눈으로 보는 모습은 상당히 좋다.
마치 최신 빔프로젝트로 만든 화면을 보는 분위기가 난다.


참고로 이건 반대쪽~!
꾸준히 한 이미지로 밀고 나가는 거다~!


물론 좌우 뿐만 아니라 중앙에도 같은 이미지를!!
3개의 방향에서 같은 이미지로 도배하니 정말 오덕같은오묘한 분위기가 난다.

그나저나 집에 와주신 분들이 전부 하는 말씀이, TV자리랑 책상자리를 서로 바꾸라고 한다.
이게 사실 짐의 85%인데!!!!
그 노가가다를 다시 할 생각을 하니 눈앞이 캄캄하다.

아 그리고 절대로 밝히고 싶은데,

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.