[또자랑] 제 셰이더 서적에 대한 너무나 좋은 평

제 블로그의 셰이더 입문강좌 페이지에 실린 댓글입니다. 이 댓글 받고 나서... '아, 책 쓴 보람이 있구나.' 생각이 들어.. 또 제자랑겸 여기다도 올립니다. 이런 기회를 제가 놓칠리가 없죠 -_-;

----------------------------------------------------------------------------------------

정헌 2013년 1월 14일 오후 11:00
안녕하세요~ 다시 와보니 바로 윗글에 글 남긴 사람이네요 ㅎㅎㅎ
Appendix A 까지 다 보고 코드로 적용해본다음 후기 올리려 왔답니다

지금으로부터 한.. 7일 전, 처음 이 책을 서점에서 목차를 봤던 기억이 나네요 ㅎㅎ
처음엔 그냥 셰이더 책 또 하나 나왔구나 라고 생각을 하고 지나쳤더랬죠
그런데 저 개인적으로 프로젝트를 진행하던 중이였습니다, 그동안 수학,물리를 공부해서
실질적으로 뭔가 보려고 했지만, 막상 시간이 지나다보니 셰이더를 넣어야겠다는 생각에
봉착하게 됐습니다, 그런데 2,3년 전 셰이더를 본적이 있긴 하지만 다시 시작해볼려고
하니깐 막상 주변엔 셰이더 관련 책이 있긴 하지만 셰이더 책들 분량이 대부분 많아
다시 보기에도 귀차니즘이 승리할 것 같아 그냥 필요한 부분만 보면서 넘어가자라는 식으로 하려고 했으나 원래 성격이 그렇지 못한지라 결국 다른 방법이 없을까 생각을 했죠
생각을 하던중 셰이더 프로그래밍 입문 책의 목차가 머리속에 사~~악 지나가더군요,
그때 드는 생각이 그래! 이거다! 라는 생각이 들어 바로 서점으로 튀어가서
한권 구입했더랬죠 ㅎㅎ
처음엔 챕터8 정도까지만 본 다음 다시 본래 프로젝트로 돌아가려 했지만
8 장을 vs로 코딩하던 중 드는 생각이
"어.. 이 책 뭔가 다르다" 는 생각이 들게 되더군요
처음 해본다면 오랜 시간 투자해야되는 여러가지 DX 설정들과 셰이더와의 상호
상태와 값과 그 의미들이 간단 명료하고 잘 연결 되어있다는 느낌을 받게 되더군요
결국 한챕터 더 보까? 더보까? 더 보까? 하다가 끝까지 보게 됐습니다

인터넷 뒤져가며 두꺼운 셰이더 책 뒤져가며 찾아 설정해야 되는 것들에 대한 시간
절약과 셰이더 소스코드들의 간략하면서도 이해가 잘가는 설명은
처음 앞뒤 뭐 대락 소개나 이런 저런것 빼면 2백 50~60 페이지 정도 되는 분량이
좀 적은거 아닌가? 조금 비싼거 아닌가? 라는 생각을 완전히 뒤바꿔 주더군요

기본적인 탄탄한 노하우가 담겨져 있는 책이라는 느낌이 들었습니다

게임관련 많은책을 보긴했지만 이렇게 직접 사이트에 찾아와 후기를 남기는건 처음이네요

또 질문 하나 하고싶어서 글을 남기기도 한건데요

Q:
대부분 프로그래머는 자신이 익힌 것을 잘 공개하려는 마인드를 갖고 있진 않다고
생각 하곤 합니다, 그런데..
사이트에 보면 이 책의 일부 챕터가 올라와있는것도 볼 수 있고 책 또한 기본적인
내용들을 담았다곤 했다고 하셨지만 노하우가 많이 묻어나온 책이라는걸 느낄 수가
있었습니다, 책을 보면서 이렇게 까지 이 한권의 책으로 도움을 받아도 되나
라는 생각을 하게 되었는데요, 왜 이리 적지 않은 부분을 공개한것인지 궁금하네요 ㅎㅎ
p.s 렌더몽키를 소스코드로 옮기는 과정은 감탄이 나오더군요 ㅎㅎ
스승으로 모셔도 될까요?? ㅎㅎㅎㅎ

Subversion에서 Private Depot 사용하기(Mercurial을 이용)

Private Depot 얼마나 오랫동안 꿈꾸어 오던 것인지... -_-;

SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;

그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...

'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'

라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;

그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤

"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"

이라는 commit log를 작성하고 싶었다고나 할까....

Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...

하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.

이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ

방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...

모든간에 졸 간단한 방법:

1. SVN checkout이 되어있는 root folder로 간다. SVN 버전이 1.7 미만이라면 1.7이상으로 업글한 뒤 현재 checkout 되어있는 소스트리를 최신버전으로 업데이트 해줘야 한다.
2. 빈공간에 오른쪽 버튼을 누르고 TortoiseHg > Create Repository Here를 해준다.
   
   
3. Init 대화창이 나오면. 뭐 다른 거 손 볼 필요 없다. 그냥 Create를 눌러준다.
4. 이제 모든 파일이 제대로 보인다....
   
   
5. 이제 private depot에 체크인 할때는 Hg Commit을... 중앙 depot에 체크인할때는 SVN Commit을 해주면 된다.

아, 정말 단순하고.. 깔끔한 방법이다.... 맘에 들어.. ㅠ_ㅠ

이 방법의 단점은 mercurial로 private depot에 체크인 했던 것은 changelist description을 자동으로 복사해올 방법이 없다는건데... 음.... 난 차라리 이 방법이 낫다. 매일 일하며 체크인 해 놨던 내용들을 쭈욱 살펴보면서 요약해서 적을 수 있으니까. 중앙서버까지 mercurial로 만들어 놓으면 local depot에 체크인 했던 changelist들이 전부다 개별적으로 submit된다. 맘에 안든다.... 뭐 collapse 익스텐션을 쓰면 이것도 해결 된다지만.. 역시 기본기능이 아닌 건 사람들이 그닥 많이 사용안하니 제대로 검증되지 않아서... 골치아픈 일이 많기 마련.... 따라서 extension은 그닥 쓰고 싶지 않아.....

어쨌든 이 방법 좋다... 만세~

XNA의 몰락. 그리고 대안

XNA가 처음 나왔을 때부터 열심히 사용했었다. 첨에는 PC와 Xbox 360용으로 돌 수 있는 게임을 만들 수 있다는게 맘에 들어서였고, 또 Xbox 360에 올리면 수익모델이 있다는 것도 맘에 들었었다. 하지만 불행히도 엑박에서 XNA 게임이 차지하는 비중이 매우 미미한 수준에서 그친 이후 XNA는 여러번 변화를 겪게 된다. XNA 4.0부터던가... 윈폰 7.0용으로 게임을 만들려면 XNA를 써야 했다. 모바일 플랫폼을 지원하려고 노력을 퍼붓다 보니 당연 PC나 엑박용 지원은 미미해졌고 그로 인해 XNA의 입지가 조금씩 애매해져갔다.

물론 그럼에도 난 XNA를 자주 사용했는데... 스크린 스페이스 데칼 프리젠테이션에 사용한 데모 프로그램도 XNA로 만든 거였다. XNA가 가지고 있는 컨텐츠 파이프라인이라던가 C#으로 쉽게 DirectX 기능을 사용할 수 있다는 사실이 프로토타입을 만드는데는 아주 적합했다고 할까...?

하지만 이제 윈폰 8이 XNA 지원을 중지한다고 한다. 그 대신 WinRT를 사용한다고... Visual Studio 2012도 XNA를 지원하지 않는다.. (뭐 어떻게 사용할 수 있는 꼼수는 있다.) 물론 Visual Studio 2010을 사용하며 XNA 4.0을 계속 사용할 수는 있지만 XNA에는 다음과 같은 제약이 있다.

• 64비트를 지원하지 않음
• DirectX 9기능까지만 지원함. (즉 DX11 기능을 쓸 수가 없음)

이제 대안을 찾을 때... 결국 XNA가 좋았던 이유는 다음의 두가지였다.

• C#지원
• 컨텐츠 파이프라인

그러니 이것만 어떻게 해결할 수 있는 대안을 찾으면 되는게 아닌가...?

C# 지원

C#을 지원하는(정확히 말하면 어떤 .NET 언어 라도 지원하는) DirectX 로는 SharpDX와 SlimDX가 있다. 둘다 API도 매우 비슷하고 사용법도 거의 같다. 그리고 둘다 64비트를 지원한다. 최근에 64비트용 프로토타입을 만들 일이 있어서 둘다 사용해봤는데... 사용해본 바로는 SharDX가 SlimDX보다 낫다. 이유는 다음의 2개:

• SharpDX가 속도가 더 빠름 (API 호출의 부하가 적음)
• SharpDX가 설치가 더 쉬움(그냥 DLL파일만 복사해놓으면 끝)

고로 SharpDX를 사용하면 C# 지원문제는 해결..

컨텐츠 파이프라인

사실 이 부분은 딱히 방법이 안보인다. 아직... 물론 C#자체 또는 SharpDX자체에서 텍스처 파일 로딩기능은 거의 다 구현해놨으니 이건 큰문제가 아닌데... 오디오 라던가 메쉬 같은건 여전히 좀 문제다.

하지만 비주얼 스튜디오 2012에 FBX를 이용하는 예제가 이미 포함되어있고, MS에서 WinRT를 더 제대로 지원하려면 컨텐츠 파이프라인을 좀더 낫게 만들어 주지 않을까? 하는 기대만 한다...

아니면 내가 시간이 좀 나면 짬짬이 이런걸 만들어서 공개하고 싶기도 한데... 현재 내 스케줄을 봤을때 그건 거의 불가능할듯...

결론 - SharpDX

난 일단 SharpDX로 갈아타기로 했다. 프로토타입이나 툴에서 필요한 메모리가 32비트에서 지원할수 있는 용량을 이미 넘어섰기때문이다. 컨텐츠 파이프라인은 텍스처나 메쉬정도는 이미 지원되니.. 나머지거야 어떻게든 닥칠때마다 해결하면 되겠지.

새해 첫 팬레터 겸 사랑고백....

오늘 집에 와보니.. 어라 우편함에.. 뭔가 심상치 않은 놈이 꼽혀있었습니다...열어보니... 20대초의 어여뿐 여대생이 보낸 새해인사 겸 사랑고백 엽서가 있었습니다... 이뻐요...

앞에는 이렇게 이쁘게 귀엽게 생겼고... ^_^

뒤에는 이렇게 사랑고백이.....

역시 사람은 잘 생기고 볼일입니다.. 아이 설레라 ~ -_-;

쓸모없는 회의

정확히 기억은 안나는데 아마도 애플사의 일 진행법을 소개하는 프리젠테이션이었던거 같다. 거기서 한 말중에 기억에 남는 게...

• 모든 회의의 끝에는 결정(액션 플랜)을 내릴 것
• 결정을 내리지 않을 회의는 하지도 말 것
• 결정을 내릴 권한이 없는 직원은 회의에 포함시키지 말 것

원래부터 쓸모없는 회의에 들어가서 시간낭비하는 걸 싫어했던 나에게 참 괜찮게 들리는 이야기였다. 

그 후, 어떤 회의에 초대되어 들어갔다. 한두시간에 끝나는 회의가 아니라 한 3일간에 걸쳐서 하는 회의였고 참여자만도 20명정도 되었는데  회의의 주제는 '차세대 그래픽'이었다.

정확히 회의가 어떻게 진행는지 아무도 내게 말해준 적이 없어서... 

'대체 무슨 회의지?'

하는 생각에 들어갔는데... 이런 저런 새로운 그래픽 기법들이 있는데 자기 팀에서는 어떤 시도를 해봤는지 그리고 앞으로 어떻게 사용할건지 등을 공유하는 거였다. 뭐 결과적으론 시그래프 등에서 볼 수 있는 내용들을 그냥 반복하는 정도랄까... 차이점이라면 

"우린 이거 시도해봤는데 너무 느려서 실제 게임에선 못쓰겠어요."

라고 (주로) 실패한 경험을 공유하는 정도... 이쯤 이야기하면

"아, 대단히 값진 회의였군요."

라고 말할 사람들이 있을지도 모르겠다. 솔직히 말하면 시간낭비였다. 게임쪽에서 차세대 그래픽이 그리 엄청난 도약을 하지 않을 것이라는 건 이제 누구나 아는 이야기이다. 전세대에서 현세대로 넘어올 때 처럼의 엄청난 도약은 없을거란 말...

근데 회의를 마치는 날에 회의 진행자가 갑자기 말하더라. 이 회의의 끝에는 액션 플랜을 만들어야 한다고... 

'아, 이 사람도 그 프리젠테이션을 봤구나.'

라는 생각이 들었는데 사실 유쾌하기 보다는 좀 실망스러웠다고 할까? 왜냐면 그 프리젠테이션에서 전하고자 하는 의미를 제대로 이해 못한 채, 어설프게 흉내내며 시간만 더 낭비하는 느낌이었다.

우리가 만든 액션플랜은 한 대 여섯개 되었는데 이건 사실 다음과 같이 한 줄로 요약이 가능했다. 

"이런 이런 기법이 있다. 하지만 게임에서 사용하기엔 너무 느림. 도구와 파이프라인의 효율성을 높이는데 더 주력해야 할 것"

이건 회의를 들어가기 전에 회의 세부일정을 보고 이미 생각한 거였다. 나 뿐 아니라 회의 참가자들 모두가 같은 생각을 했을 거라 생각한다. (아니라면 그놈들 실력을 심각히 의심해봐야할 듯...).어차피 뻔히 알고 있는 내용으로 결론을 내릴 것을 20명이나 되는 시니어 그래픽 프로그래머들의 시간을 3일이나 낭비시킬 이유가 있는건지....

위의 프리젠테이션에 다음 내용을 추가해야만 이런 쓸모없는 시간낭비를 막을 수 있을 거 같다.

• 이미 알고 있는 결정을 내릴 회의는 하지도 말 것