쉐이더 강좌 올려놓은거에 달린 너무나 진지한 댓글에 내가 단 답변...
2012년 2월 29일 수요일
2012년 2월 28일 화요일
꽃미남 게임개발자로 널리 알려진 포프입니다
얼마 전에 게임개발포에버에 글을 쓸 때 처음 여는 인사가 이거였습니다.
'안녕하세요. 꽃미남 게임개발자로 널리 알려진 포프입니다.'
이거 때문에 저의 외모를 시기하는 분들이 좀 계시던데.....(절대 강산아 님이 아님) 이건 절대 제가 날조해서 유표하는 유언비어가 아닙니다. 여기에 그 증거를 제출합니다....
감사합니다. 앞으론 외모보단 실력을 시기해주세요.... -_-;
'안녕하세요. 꽃미남 게임개발자로 널리 알려진 포프입니다.'
이거 때문에 저의 외모를 시기하는 분들이 좀 계시던데.....
감사합니다. 앞으론 외모보단 실력을 시기해주세요.... -_-;
2012년 2월 27일 월요일
오스카 시상식을 보다가... 나에겐 어떤 미래가 있을까?
어쩌다 티비를 틀었더니 오스카 시상식을 하길래 처음부터 끝까지 쭈욱 봤다.. 이미 역사가 84년이란다.
이걸 보면서 느낀점은 과연 게임개발자가 저런 규모로 상을 받는게 가능할까..? 상을 받은 사람 중 한 명의 소감이 인상깊었던게... 초기 오스카는 15분 길이였단다. 즉, 작품도 많지 않았고 사람들 인지도도 높지 않았단 거겠지.. 영화란 매체가...
게임 수상식을 한 지 몇년이나 되었지..? 10년? 20년? 요새 길이로는 1시간정도 하는거 같은데.. 과연 게임 수상식을 보는 보는 사람들이 몇이나 될까... 우리도 한 64년 정도 더해먹으면 오늘날의 오스카처럼 뭔가 널리 인정받는 직종이 될까..?
내 생각은.. .아닐듯 싶다.. 영화는 아무래도 실제 인간인 배우들이 나오고.. 그 배우들과 사랑에 빠져서 팬들은 수상식을 본다.. 그러다 보면 거기서 껴서 상을 받는 영화제작자들 까지도 알게 되는 건데... 게임에 등장하는 건 가상의 캐릭터... 인간이 아니니까... 게임속의 캐릭터와 사랑을 빠지게 되도, 그 캐릭터가 직접 나와서 수상을 할 수 없으니... 수상식을 보려는 사람들도 적을거고... 그럼 그 게임을 만든 개발자들을 알게되는 계기도 적을거고... 결국엔 정말 뛰어난 극소수의 사람들만이 유명해진다는거지....
사람이란게 한번 태어났으면 뭔가 자취를 남기고 가야 하는건데... 난 과연 어떤 흔적이라도 남기고 갈런지 궁금하다.
이걸 보면서 느낀점은 과연 게임개발자가 저런 규모로 상을 받는게 가능할까..? 상을 받은 사람 중 한 명의 소감이 인상깊었던게... 초기 오스카는 15분 길이였단다. 즉, 작품도 많지 않았고 사람들 인지도도 높지 않았단 거겠지.. 영화란 매체가...
게임 수상식을 한 지 몇년이나 되었지..? 10년? 20년? 요새 길이로는 1시간정도 하는거 같은데.. 과연 게임 수상식을 보는 보는 사람들이 몇이나 될까... 우리도 한 64년 정도 더해먹으면 오늘날의 오스카처럼 뭔가 널리 인정받는 직종이 될까..?
내 생각은.. .아닐듯 싶다.. 영화는 아무래도 실제 인간인 배우들이 나오고.. 그 배우들과 사랑에 빠져서 팬들은 수상식을 본다.. 그러다 보면 거기서 껴서 상을 받는 영화제작자들 까지도 알게 되는 건데... 게임에 등장하는 건 가상의 캐릭터... 인간이 아니니까... 게임속의 캐릭터와 사랑을 빠지게 되도, 그 캐릭터가 직접 나와서 수상을 할 수 없으니... 수상식을 보려는 사람들도 적을거고... 그럼 그 게임을 만든 개발자들을 알게되는 계기도 적을거고... 결국엔 정말 뛰어난 극소수의 사람들만이 유명해진다는거지....
사람이란게 한번 태어났으면 뭔가 자취를 남기고 가야 하는건데... 난 과연 어떤 흔적이라도 남기고 갈런지 궁금하다.
P4SandBox 쓸만해 보이는걸...?
게임개발용 버전 컨트롤 시스템으로는 Perforce만한게 없다. 바이너리 지원도 짱~ 문제는 언제나 서버에 연결되어있어야 한다는 거였는데..그래서 원격으로 작업하면 좀 느렸는데.. P4SandBox란 놈이 조만간 나온단다.. 이게 나오면 그 문제도 해결될듯 하다.
P4Sandbox는 GIT처럼 private local branching을 가능하게 해주는 것 (단 Distributed Version Control Syste 은 아니다.. 여전히 중앙관리..)
자세한 내용은 여기참조: http://www.perforce.com/blog/110826/p4sandbox-private-local-branching-distributed-dev
P4Sandbox는 GIT처럼 private local branching을 가능하게 해주는 것 (단 Distributed Version Control Syste 은 아니다.. 여전히 중앙관리..)
자세한 내용은 여기참조: http://www.perforce.com/blog/110826/p4sandbox-private-local-branching-distributed-dev
2012년 2월 13일 월요일
청소년 게임문제는 권위를 잃은 부모의 문제이다.
한참 번역일을 할 때였던 2006년에 "PC와 비디오 게임: 친구인가 적인가?(PC and Video Games: Friends or Foes?)"란 제목의 컨퍼런스 회의록을 번역한 적이 있었는데 거기서 나왔던 내용 중에 아직까지도 뇌리에 강하게 남아있는 내용이 있었죠. 근데 요즘 한국에서 일어나는 게임규제에 대한 꼴갑과 관련이 있다는 생각이 들어 제 블로그에 짧게 올려봅니다.
대충 번역:
원문:
이미 해외에서는 5~6년전에 이렇게 올바른 논의가 진행되었었는데... 대체 너넨 뭐하는거니?
대충 번역:
권위(authority)라는 단어의 기원은 라틴어로 ‘저술하다(author)’란 뜻에서 유래했습니다. 오늘날 부모들은 더 이상 이 세계에 대한 설명을 저술할 능력이 없습니다. 즉 부모들이 현 세계를 마땅히 설명할 능력이 없으므로 권위에 도전을 느끼는 것입니다. 현세계에 대한 개념조차 없는 부모들이 자녀들의 뉴미디어 사용을 적절히 제한할 수 있을 턱이 없죠. 부모들은 아이들이 미지의 가상세계에 빠지는 것을 두려워합니다. 오히려 아이들이 이로부터 영감을 받을 수 있다는 사실을 아직 깨닫지 못하고 있죠. 그래서 부모들은 가상 기술을 거부하기 위해서 필사적으로 아이들의 시간을 컨트롤하려 하죠. 부모들이 가장 두려워하는 것이 중독입니다. 그저 언론매체에서 마땅한 단어가 없어 중독이란 단어를 사용했을 뿐인데 부모들이 이걸 마약중독처럼 엄청 무시무시한거라 생각해버리는 어이없는 일이 발생했죠.
원문:
As you may know, authority comes from Latin “author”, and today, parents are no longer able to author an explanation of the world. So it means that they have a problem of authority because it is impossible for them—they lack the concepts, the words—to author a good explanation of the world. So it means that they have a problem of authority because it is impossible for them—they lack the concepts, the words—to author a good explanation of the world. No wonder we have some problems with authority! It is impossible for parents to forbid the use of new media because they know that it could be closing off the future of their kids: while scared to see their kids being aspirated by this unknown virtuality, they are not yet able to realize that their kids could be inspired by it. So, in a desperate effort, parents today try to control time, refusing virtual technologies. They are afraid above all by addiction. It is a media term: addiction. And they are afraid by this word “addiction” because it conjures up pictures related to drug experiences.
이미 해외에서는 5~6년전에 이렇게 올바른 논의가 진행되었었는데... 대체 너넨 뭐하는거니?
2012년 2월 10일 금요일
[작업중] 음악: Out of Reach 도입부
오늘밤 쓴 곡... 아직 도입부 뿐이지만 꽤 맘에 든다.. 일단 Out of Reach라고 제목을 붙였다... 꽤 맘에 드는 도입부이므로... 언젠간 끝낼 가능성이 높지 않을까... 하고 생각만 한다...
피드백은 내 페이스북 (원맨) 밴드 페이지로.... 고고고?
피드백은 내 페이스북 (원맨) 밴드 페이지로.... 고고고?
구글 플러스 프로필(한국어)을 만들었습니다.
사실 예전부터 영어로 구글 플러스를 써오긴 했었는데... 요즘들어 점점 절 추가하시는 분들이 많아지고 해서... 그냥 한국어 계정으로 구글 플러스를 하나 더 열었습니다. (제가 언어를 섞는걸 별로 안좋아해요.. 아무래도 이쪽에 있는 친구들이 제 트위터나 구글 플러스를 구독하는데.. 거기에 알아듣지 못하는 언어가 절반이면 좀 그래서.. -_-)
자 뭐든간에:
포프의 구글+ 프로필
자 뭐든간에:
포프의 구글+ 프로필
2012년 2월 8일 수요일
거짓말로 버티고 사는 개발자...
최근에 회사를
이미지 출처: http://images.wikia.com/lotr/images/9/9e/Smeagol.jpg |
뭐, 굳이 그놈이 한 모든 거짓말들을 들추어 낼 생각은 없다. 어차피 이 업계에서 머무르려면 그놈은 그런 거짓말을 해야만 할테니까... 그냥 조만간 이놈이 밴쿠버 밖에서 직장을 찾아야 할 꺼라고만 추측한다. 이미 이 도시에서 꽤 유명하더군.... ㅎㅎ... 그 외에도 괜히 여기 까발려서 명예훼손죄로 고소 받는 것도 좀 귀찮고... 뭐 실제 고소 들어오면 어차피 내가 이길 게 뻔하니 그것도 꽤 재밌을 거 같긴 하다. 내가 하는 말은 모두 사실이거든.... (괜히 법대 나온게 아니라니까? -_-) 그냥 아무것도 모르는 똘아이하고 상대하는 게 골치아프니 귀찮은 것일뿐.... 그래도 개인적으로 물어오는 사람이 있다면 당연히 주저하지 않고 말해줄거다. 뭐든간에 난 솔직하고 직설적인 놈이어서.. 절대 거짓말도.. 숨기지도 않으니까...
거짓말 이야기가 나왔으니 말인데... 난 의견/판단 <--> 사실을 구분하는 법을 매우 잘 알고 있다. 법대 괜히 나온게 아니라니까.....? -_- 마찬가지 이유로 내가 그놈을 거짓말쟁이라 부르는 이유도 그놈이 허위사실을 유포하기 때문이지 그놈의 말도안되는 판단이나 의견 때문이 아니다. 그래도 정말 스스로 자기주장이 사실이라 믿고 있다면.... 그놈은 엔지니어가 될 최소한의 자질조차 갖추지 못했다는 증거일 뿐... 아니면 여기가 그놈의 새 전세방이 될지도....
게임개발자 북미취업 가이드 부록 B: 아티스트 포트폴리오 모음
드디어 전자책이 나왔습니다. 전자책 구매 방법은 연두미디어의 홈피를 참조해주세요.
게임개발자 북미취업 가이드 시리즈 목차
- 1편: 소개 및 저술방침
- 2편: 북미 게임개발 근무환경/취업시장
- 3편: 취업을 위한 필수/선택요건 - 면접절차
- 4편: 실전 가이드
- 5편: 실제 취업사례 - 포프
- 6편: 실제 취업사례 - 다른 사람들
- 7편: 질문/답변
- 부록 A: 원화 아티스트 포트폴리오 모음
- 부록 B: 아티스트 포트폴리오 모음
예전에 원화 아티스트들 포트폴리오를 올리고 난 뒤, 다른 아티스트들의 포트폴리오도 링크걸어달란 요청이 좀 있었는데 게을러서 이제서야 올립니다. (실은 책 작업하면서 이걸 좀 모아야 했다는... -_-) 렐릭 뿐만 아니라 그냥 제가 같이 일해봤었던 아티스트들의 포폴을 모두 긁어왔습니다. -_-; 학교졸업 포폴부터 실제 경력 포폴까지 다양하군요.
저번가 마찬가지로 이 사람들 포폴 웹사이트 보시고 동기부여가 되시거나 '이 정도면 뭐 나도 할 수 있겠군~' 정도의 거만함(?)을 키우시기 바랍니다. ^^
3D 아티스트
애니메이터
기타 아티스트(FX & UI)
2012년 2월 7일 화요일
그래픽 프로그래밍 팀장이 될 뻔 했었다....
난 매우 직선적인 성격이다.. 특히 회사에서 일할 땐.... 말도 안되는 개소리는 개소리라고 말해주고... 실력이 없는 놈이 정치를 하려고하면 쌍욕도 잘해준다... 사실 주변에서는 이러면 적만 만들다가 회사 짤리니 조심하란 이야길 하는데... 내 자세는 언제나..
'그러던가?'
였다. 실력 하나로 믿고 살아온 인생.... 괜히 누구에게나 착한 척 가식떨며 내 자리 지키고 싶은 마음은 한번도 없었으니까...
이렇게 말하면 내가 누구에게나 개판으로 대하는 인간처럼 보일지도 모르겠지만 사실 그건 아니다. 난 대우 받을 가치가 있다고 생각하는 개발자들에게는 정말 잘해준다. 한마디로 직급/연차 상관없이 실력좋고 책임감있고 인간되었으면(가식이 아닌 진짜 인간) 존경해준다.
사실 얼마 전까지는 이런 성격때문에 난 적이 꽤 많다고 생각해왔다. 그런데 최근 들어 그보다 아군(?)들이 더 많다는 사실을 깨닫게 되는 계기가 있었다. 다음은 그 이야기... (내 잘난 척 할거니... 보기 싫음 닫으삼.... 경고했음..... -_-)
이번에 렐릭에서 pre-production에 들어가는 프로젝트가 하나 있다. 그 팀에서 그래픽 쪽 일이 좀 많아서 그래픽 팀 리드가 필요하단다. 원래 그 일을 맡기려고 채용했던 놈이 하나 있었는데 실력이 너무 형편없고 구라만 까고 정치만 하는 개늠... -_- 그래서 오늘부로 퇴사... 따라서 저번주부터 새로운 그래픽 팀 리드를 찾으려고 했단다. 윗선에서는 새로운 사람을 채용하려고 구인공고를 낸다 했다지... 근데 그 이야기들을 팀원들 중에 4명(내가 아는 것만)이 나를 그자리에 추천했단다. (현재 그 팀 규모는 15명정도? pre-production이니까 아직 팀 크기가 좀 작다) 여기서 더 재밌는 사실은 그 4명이 합심해서 날 추천한게 아니라... 한 명씩 따로 자기 생각에 내가 좋을거 같아서 추천했단다. 다른 사람들이 날 추천하는 것도 모른 채.... 다들 나랑 스페이스마린 팀에서 같이 일했던 동료들이었고... 하는 일들도 테크니컬 아티스트 감독부터 원화 아티스트, 그리고 내가 그래픽 팀 팀장이 되면 내 밑에서 일하게 될 쥬니어 그래픽 프로그래머까지 다양....
이렇게 산발적으로 여러명이 추천을 하니 그제서야 나의 가치(?)를 알아본 윗선들이 급하게 나를 현재 팀(다크사이더 2 팀)에서 빼가서 그 팀의 그래픽 리드로 앉히려고 했지만... (민주주의의 승리....?) 다크사이더 2 게임의 출시가 6월달이라 그쪽에서 날 놔줄수 없다고, 나 빼가면 울 모회사 THQ에게 이르겠다고(?) 해서 어쩔수 없이 못빼간단다... -_- (민주주의는 개뿔...?)
솔직히 팀장이 안된건 좀 아쉽다. 오랜만(한 15년? 아니 학교에서 한거 따지면 7년인가...)에 팀장질을 다시 해보고 싶은 욕심도 있었지만... 더 큰 이유는 나를 팀장으로 모시고(?) 싶어하는 사람들이 눈에 밟힌다고 할까? 특히 내 밑에서 일하게 될 그 쥬니어 그래픽 프로그래머는 실력에 비해 몸값이 저평가된 경우라, 팀장이 되면 곧바로 내 직급 정도까지 승진(3단계 승진해서 선임으로 -_-... 연차는 안되는데 실력은 거의 나랑 삐까하다고 생각.. 나보다 나을지도?)을 시켜주고 싶었거든...
어쨋든 날 추천했던 놈들에게 이런 이런 이유로 그래픽 팀장이 안된다는 사실을 알려주니 말도 안된다며 화내는 놈도 있었고... 그냥 아쉬워 하는 놈도 있었고... '그래서 이번 게임 6월에 끝나면 뭐할건데?'라고 물어보는 놈들도 있었다. '뭐, 딱히 갈 팀이 없으면 짤리지 않겠어?'라고 하니 혹시라도 그런 일 생기면 자기도 그 날 사표낸다는 놈들까지 -_-;
참, 고맙단 생각이 들었다. 나와 같은 가치 -- 실력위주, 정직함 그리고 integrity(한국어로 뭔지 모름 -_-) -- 를 가지고 개발을 하는 사람들이 있다는 게... 그리고 그 사람들이 내 리더쉽을 믿어 준다는게...
나는 언제나 상향식 변화(bottom-up change)를 선호한다.
였다. 실력 하나로 믿고 살아온 인생.... 괜히 누구에게나 착한 척 가식떨며 내 자리 지키고 싶은 마음은 한번도 없었으니까...
이렇게 말하면 내가 누구에게나 개판으로 대하는 인간처럼 보일지도 모르겠지만 사실 그건 아니다. 난 대우 받을 가치가 있다고 생각하는 개발자들에게는 정말 잘해준다. 한마디로 직급/연차 상관없이 실력좋고 책임감있고 인간되었으면(가식이 아닌 진짜 인간) 존경해준다.
사실 얼마 전까지는 이런 성격때문에 난 적이 꽤 많다고 생각해왔다. 그런데 최근 들어 그보다 아군(?)들이 더 많다는 사실을 깨닫게 되는 계기가 있었다. 다음은 그 이야기... (내 잘난 척 할거니... 보기 싫음 닫으삼.... 경고했음..... -_-)
이번에 렐릭에서 pre-production에 들어가는 프로젝트가 하나 있다. 그 팀에서 그래픽 쪽 일이 좀 많아서 그래픽 팀 리드가 필요하단다. 원래 그 일을 맡기려고 채용했던 놈이 하나 있었는데 실력이 너무 형편없고 구라만 까고 정치만 하는 개늠... -_- 그래서 오늘부로 퇴사... 따라서 저번주부터 새로운 그래픽 팀 리드를 찾으려고 했단다. 윗선에서는 새로운 사람을 채용하려고 구인공고를 낸다 했다지... 근데 그 이야기들을 팀원들 중에 4명(내가 아는 것만)이 나를 그자리에 추천했단다. (현재 그 팀 규모는 15명정도? pre-production이니까 아직 팀 크기가 좀 작다) 여기서 더 재밌는 사실은 그 4명이 합심해서 날 추천한게 아니라... 한 명씩 따로 자기 생각에 내가 좋을거 같아서 추천했단다. 다른 사람들이 날 추천하는 것도 모른 채.... 다들 나랑 스페이스마린 팀에서 같이 일했던 동료들이었고... 하는 일들도 테크니컬 아티스트 감독부터 원화 아티스트, 그리고 내가 그래픽 팀 팀장이 되면 내 밑에서 일하게 될 쥬니어 그래픽 프로그래머까지 다양....
이렇게 산발적으로 여러명이 추천을 하니 그제서야 나의 가치(?)를 알아본 윗선들이 급하게 나를 현재 팀(다크사이더 2 팀)에서 빼가서 그 팀의 그래픽 리드로 앉히려고 했지만... (민주주의의 승리....?) 다크사이더 2 게임의 출시가 6월달이라 그쪽에서 날 놔줄수 없다고, 나 빼가면 울 모회사 THQ에게 이르겠다고(?) 해서 어쩔수 없이 못빼간단다... -_- (민주주의는 개뿔...?)
솔직히 팀장이 안된건 좀 아쉽다. 오랜만(한 15년? 아니 학교에서 한거 따지면 7년인가...)에 팀장질을 다시 해보고 싶은 욕심도 있었지만... 더 큰 이유는 나를 팀장으로 모시고(?) 싶어하는 사람들이 눈에 밟힌다고 할까? 특히 내 밑에서 일하게 될 그 쥬니어 그래픽 프로그래머는 실력에 비해 몸값이 저평가된 경우라, 팀장이 되면 곧바로 내 직급 정도까지 승진(3단계 승진해서 선임으로 -_-... 연차는 안되는데 실력은 거의 나랑 삐까하다고 생각.. 나보다 나을지도?)을 시켜주고 싶었거든...
어쨋든 날 추천했던 놈들에게 이런 이런 이유로 그래픽 팀장이 안된다는 사실을 알려주니 말도 안된다며 화내는 놈도 있었고... 그냥 아쉬워 하는 놈도 있었고... '그래서 이번 게임 6월에 끝나면 뭐할건데?'라고 물어보는 놈들도 있었다. '뭐, 딱히 갈 팀이 없으면 짤리지 않겠어?'라고 하니 혹시라도 그런 일 생기면 자기도 그 날 사표낸다는 놈들까지 -_-;
참, 고맙단 생각이 들었다. 나와 같은 가치 -- 실력위주, 정직함 그리고 integrity(한국어로 뭔지 모름 -_-) -- 를 가지고 개발을 하는 사람들이 있다는 게... 그리고 그 사람들이 내 리더쉽을 믿어 준다는게...
나는 언제나 상향식 변화(bottom-up change)를 선호한다.
2012년 2월 6일 월요일
유니티에서 topology가 같은 캐릭터간에 애니메이션 공유하기...
이미지 출처: http://answers.unity3d.com/questions/191282/sharing-animations-between-models.html |
본(bone)의 길이가 다른 캐릭터들 사이에서 애니메이션을 공유하려고 한다고 생각해 보죠. 물론 각 캐릭터마다 애니메이션을 따로 만들어주면 좋겠지만 인력이 부족한다던가... 그런데 이렇게 본의 길이가 다른 캐릭터터들 사이에서 애니메이션을 공유할 수 있을까요? 뭐 되니까 이글을 쓰는거죠... -_-; 평행이동과 확대/축소를 사용하지 않으면 가능합니다. 달리 말하면 회전만 이용하면 된다는거죠. 이렇게 생각해보면 이해가 쉬워요. 본인의 오른쪽 팔꿈치를 안쪽으로 90도만큼 회전시켜 보세요. 이제 본인보다 키가 작은 친구에게 똑같이 오른쪽 팔꿈치를 90도만큼 회전시키라고 하는거죠. 그러면 둘의 포즈가 똑같죠? 바로 이 원리 입니다. 이해 되죠?
결국 3DS Max가 뱉어내는 데이터가 어쨌던간에 애니메이션에서 회전만 적용시킬 수 있는 방법만 있으면 되는건데... 유니티에서 이런 걸 공식적으로 지원해주는 찾으려고 포럼을 뒤졌지만 그런것 같진 않더군요. 그러면 파이프라인 어딘가에서 회전 이외의 키프레임 정보를 지워버리는 방법이 없을까 찾아봤지요. 불행히도 딱히 대답을 찾을 순 없었습니다.
뭐든간에 좋은소식은...... 제가 그 꼼수를 찾아냈다는 거지요. 무핫핫..... :D
이렇게 했답니다. (코드는 조 밑에~)
- Asset/Editor 폴더 안에 ConvertToRotationOnlyAnim.cs 라는 스크립트 파일을 만듭니다.
- 이 스크립트를 호출하는 메뉴 항목을 만듭니다.
- Unity에 애니메이션을 import 해옵니다. (Unity가 애니메이션 파일이라고 생각하는 한 어디서 이 애니메이션을 만들었는지는 상관없습니다.)
- import해온 애니메이션 애셋에 마우스 오른쪽 버튼을 누르고, 단계 #2에서 추가했던 메뉴 아이템을 선택합니다.
- 이제 스트립트 안에서 propertyName 필드 중에 "m_LocalRotation"이란 이름을 포함한 놈만 복사합니다.
- 이제 _rot 애니메이션 클립을 게임오브젝트의 애니메이션 컴포넌트에 대입합니다.
- 시작 버튼을 누르고..... 즐거워 해봅시다.. 얼씨구나.. 지화자~ -_-
그리고 이게 위에서 말씀드린 스크립트의 전체 소스코드. 주석을 잘 달아놨으니 영어공부할겸..... 대충 보고 이해하세요. ㄱ ㄱ ㅑ ~ -_-
using UnityEditor;
using UnityEngine;
using System.IO;
public class ConvertToRotationOnlyAnim
{
[MenuItem("Assets/Convert To Rotation Animation")]
static void ConvertToRotationAnimation()
{
// Get Selected Animation Clip
AnimationClip sourceClip = Selection.activeObject as AnimationClip;
if (sourceClip == null)
{
Debug.Log("Please select an animation clip");
return;
}
// Rotation only anim clip will have "_rot" post fix at the end
const string destPostfix = "_rot";
string sourcePath = AssetDatabase.GetAssetPath(sourceClip);
string destPath = Path.Combine(Path.GetDirectoryName(sourcePath), sourceClip.name) + destPostfix + ".anim";
// first try to open existing clip to avoid losing reference to this animation from other meshes that are already using it.
AnimationClip destClip = AssetDatabase.LoadAssetAtPath(destPath, typeof(AnimationClip)) as AnimationClip;
if (destClip == null)
{
// existing clip not found. Let's create a new one
Debug.Log("creating a new rotation only animation at " + destPath);
destClip = new AnimationClip();
destClip.name = sourceClip.name + destPostfix;
AssetDatabase.CreateAsset(destClip, destPath);
AssetDatabase.Refresh();
// and let's load it back, just to make sure it's created?
destClip = AssetDatabase.LoadAssetAtPath(destPath, typeof(AnimationClip)) as AnimationClip;
}
if (destClip == null)
{
Debug.Log("cannot create/open the rotation only anim at " + destPath);
return;
}
// clear all the existing curves from destination.
destClip.ClearCurves();
// Now copy only rotation curves
AnimationClipCurveData[] curveDatas = AnimationUtility.GetAllCurves(sourceClip, true);
foreach (AnimationClipCurveData curveData in curveDatas)
{
if (curveData.propertyName.Contains("m_LocalRotation"))
{
AnimationUtility.SetEditorCurve(
destClip,
curveData.path,
curveData.type,
curveData.propertyName,
curveData.curve
);
}
}
Debug.Log("Hooray! Coverting to rotation-only anim to " + destClip.name + " is done");
}
}
2012년 2월 2일 목요일
포토샵 CS3가 실행중이면 ESC 키가 작동하지 않는 버그 고치기
포토샵 CS3를 열어두면 윈도우 전역적으로 ESC 키가 먹히지 않는 문제가 있었다. 한마디로 짜증이었던 게지 -_-;;; CS5는 이 문제를 고쳤던데... CS5로 업그레이드 해달라고 회사에 부탁해도 현재 프로젝트에서 쓰는 버전이 CS3이니 그럴수 없단다...
뭐 그래서 그냥 몇년 이렇게 쓰다가 더이상 못참아서....드디어 오늘 이걸 고쳐버렸다.. 생각보다 해결책은 간단했음... 작업 관리자를 열어서 ccc.exe라고 된 프로세스를 그냥 죽여버리면 된다. (ATI 그래픽 카드 컨트롤 패널이니 사실 별 필요도 없음..) 이제 CS3를 다시 열면... ESC 키가 제대로 작동함....
그리고 위도우즈 키 + 실행을 눌러 시작 프로그램에서 CCC를 제거했다. 이제 CCC를 쓸 일이 있으면 그냥 손수 실행해주면 되겠지... 뭐 어차피 1년에 한 번 열어볼까 말까한 놈이니 별 문제 없을듯....
2012년 2월 1일 수요일
새로운 기법 != 새 장난감
게임데브포에버에 무슨 글을 올릴까 고민을 좀 해봤는데... 그래픽 전문자료들은 이미 다른 필자분들이 열심히 올리고 계셔서 요번에는 그냥 제 경험담을 올리도록 하지요.. (이런 글을 원하시는 분들도 꽤 계실듯...?)
제가 이리도 오래 쉰내나도록(?) 게임 업계에 머무르는 이유 중 하나가 언제나 새로운 것들을 시도해 볼 기회가 충분하기 때문입니다. 특히나 그래픽 프로그래밍 쪽은 하루가 멀다하고 계속 발전하는 분야라서 마약처럼 매우 짜릿하죠. (마약이라고 좀 언급해두면 한국 정부에서 게임개발 셧다운제를 해주지 않을까하는 생각에...그럼 한국 게임개발자 분들도 정시퇴근 하실 수 있습니다. 회사 매출이 높으면 일찍 퇴근!)
근데 가끔은 이런 짜릿함에 눈이 멀어 게임을 망치는 경우도 좀 있습니다. 아직 검증되지 않은 새로운 기법을 동원할 때 그에 부수하는 단점들을 간과하는 경우가 허다하거든요. 심지어는 그런 단점들이 이미 잘 알려져 있더라도 장점보다 단점을 더 크다고 착각하는 경우도 문제입니다. (보통 이미 그 기법을 사용해서 게임을 출시한 개발자들이 하는 이야길 듣는게 검증인데.... 그 개발자들이 컨퍼런스에서 발표를 할 때는 당연히 단점보단 장점을 부각시키는게 일반적이라지요.)
디퍼드 라이팅
제가 요번에 적어드릴 경험담은 디퍼드(deferred) 렌더링에 대해서 입니다. 이미 아시는 분들은 아시겠지만 스페이스마린은 자체 개발한 디퍼드 라이팅(deferred lighting) 엔진을 씁니다. 뭐 찾아보면 좀 더 있겠지만 제가 당장 생각하는 퍼드 라이팅 렌더러의 장단점은 다음과 같습니다. (제가 생각하는 중요도 순서로...)
장점:
그리고 스페이스마린을 출시한 뒤, 다른 회사의 게임을 좀 도와줬습니다. 몇 년전에 출시했던 게임의 후속작인데요. 따라서 그래픽 쪽으로는 특별히 손봐줄게 없겠다고 생각했죠. 어차피 컨텐츠만 좀 바꾸면 되니까. 그래픽 쪽은 좀 빠르게 만들어주거나 눈사탕 몇 개만 슬쩍 추가...?
제가 이리도 오래 쉰내나도록(?) 게임 업계에 머무르는 이유 중 하나가 언제나 새로운 것들을 시도해 볼 기회가 충분하기 때문입니다. 특히나 그래픽 프로그래밍 쪽은 하루가 멀다하고 계속 발전하는 분야라서 마약처럼 매우 짜릿하죠. (마약이라고 좀 언급해두면 한국 정부에서 게임개발 셧다운제를 해주지 않을까하는 생각에...그럼 한국 게임개발자 분들도 정시퇴근 하실 수 있습니다. 회사 매출이 높으면 일찍 퇴근!)
근데 가끔은 이런 짜릿함에 눈이 멀어 게임을 망치는 경우도 좀 있습니다. 아직 검증되지 않은 새로운 기법을 동원할 때 그에 부수하는 단점들을 간과하는 경우가 허다하거든요. 심지어는 그런 단점들이 이미 잘 알려져 있더라도 장점보다 단점을 더 크다고 착각하는 경우도 문제입니다. (보통 이미 그 기법을 사용해서 게임을 출시한 개발자들이 하는 이야길 듣는게 검증인데.... 그 개발자들이 컨퍼런스에서 발표를 할 때는 당연히 단점보단 장점을 부각시키는게 일반적이라지요.)
디퍼드 라이팅
제가 요번에 적어드릴 경험담은 디퍼드(deferred) 렌더링에 대해서 입니다. 이미 아시는 분들은 아시겠지만 스페이스마린은 자체 개발한 디퍼드 라이팅(deferred lighting) 엔진을 씁니다. 뭐 찾아보면 좀 더 있겠지만 제가 당장 생각하는 퍼드 라이팅 렌더러의 장단점은 다음과 같습니다. (제가 생각하는 중요도 순서로...)
장점:
- 포워드(forward) 렌더링에 비해 사용할 수 있는 광원의 수가 많다. (예, '물체당 광원 3개' 라는 제한이 없어짐)
- 대부분의 조명을 동적으로 처리함으로 아티스트들의 작업시간이 빨라진다.
- 화면공간에서 행하는 후처리(post-processing) 기법들을 사용하기 쉽다. (예, SSAO, Screen Space Decal 등)
단점:
- (반)투명한 물체 처리가 골아프다.
- 하드웨어 자체적으로 앤티에일리어싱(anti-aliansing)을 처리하기 힘들다.
- 메모리를 좀 더 많이 잡아먹는다. (화면 해상도 크기의 렌더타겟들이 여러 개 필요)
스페이스 마린에서 디퍼드를 사용한 이유
원래 시작은...
스페이스 마린에서 디퍼드 렌더링을 사용한 이유는 사실 역사적인 이유가 강합니다. 스페이스 마린을 만들기 전에 Grand Theft Auto 류의 오픈월드 게임을 제작하고 있었는데 이 때 (2008년 중순) 다음과 같이 디퍼드 라이팅 엔진을 판단했었습니다.
- 오픈월드 게임이니 광원의 수가 꽤 많겠군? 디퍼드가 좋겠어. (장점 #1)
- 아무래도 밤낮이 바뀌는 효과가 있어야 하니 동적 조명이 좋겠는걸? (장점 #2)
- 근데 배경이 도시니까 투명한 물체가 꽤 필요하겠는데? (단점 #1).... 으음... 뭐 투명한 물체는 디퍼드 말고 따로 포워드로 그려줘야겠군.. (
어쩔수 없는그럴듯한 해결책) - 근데 앤티에일리어싱은 어쩌지? (단점 #2) 아직 1~2년 남았으니 나중에 고민해보지 뭐...(대충 책임 회피 -_-)
근데 이 게임이 한 6개월 만에 취소됩니다. 게임 자체에 문제는 아니었고 THQ가 구조 조정을 하면서 그 당시 스페이스 마린 게임을 개발중이던 THQ 호주 스튜디오를 문을 닫았죠. 워낙 렐릭이 워햄머 40,000 게임을 잘 만드는 회사로 유명했던지라 저희쪽에서 대신 해달라고....
그래서 처음부터 다시 스페이스마린을 만들었습니다. -_- (THQ 호주에서 만들어 놨던건 하나도 안썼죠.. 저희가 원하는 방향과 너무나 달라서...)
그리고 다시 결정을 내리기엔...
자, 그럼 이번엔 스페이스마린을 만들기로 했으니 다시 한 번 렌더링 엔진에 대해 고민해볼 차례인데... 이 때 (2009년) 저희의 생각은 이랬습니다.
- 과연 광원의 수가 많을까? (장점 #1이 시들해짐)
- 밤낮이 바뀌는 효과도 없는데? (장점 #2도 시들해짐)
- 그런데... 아티스트들이 이미 디퍼드 라이팅에 맛을 들여서(iteration 시간이 매우 빨라졌어요... 모든게 동적 조명이니) 매우 원함... (장점 #2가 다시 살아남)
- 또한 디퍼드에 기반해서 구현한 Screen Space Decal을 역시 아티스트들이 너무 좋아함 (장점 #3)
- 서기 40,000년엔 투명한 유리창 따윈 이미 다 뽀개지고 없으니.. 투명한 물체는 그닥 문제가 안될 거야.. (단점 #1이 좀 완화됨)
- 근데 앤티에일리어싱은 어쩌지? (단점 #2)요즘들어 이 분야에 대한 좀 발전이 있으니(Kill Zone 2가 SSAA를 대충 사용할 때..) 좀더 기다려보지.. (여전히 책임 회피... -_-)
- 그럼 딱히 디퍼드를 할 이유가 없지 않아?..... 응... 없지.... 근데 이미 만들어 놓은거 다시 포워드로 돌리는 데 드는 시간과 비용이 과연 값어치가 있을까?......... 없군......
그래서 결국 디퍼드로 그냥 가기로 했죠. 최소한 아티스트들이 작업을 빨리할 수 있으니까 비주얼 품질이 높아질거라 생각했거든요. 그리고 그건 현실이 되었죠. 아티스트들이 여러번 손 대니까 확실히 스페이스마린의 비주얼 퀄리티도 상승.
그래서 단점은 어케 극복을?
그리고 시간은 흐르고 흘러서 2011년 9월 스페이스 마린을 출시했죠. 그렇다면 저 단점들은 어떻게 극복 했을까요?
투명한 물체
"서기 4만년엔 모든 유리들이 뽀작나서 더이상 투명한 물체가 없습니다 -_-;" 는 저희가 장난처럼 한 말이었는데... 사실 저희 게임에서 투명한 물체가 거의 없습니다. 종류따라 다음과 같이 처리했어요.
- 알파테스트: 반투명 블렌딩을 하기 보다 대부분의 물체는 완전투명 아니면 완전 안투명의 두가지로 처리했습니다. 이러면 디퍼드를 사용할 수 있죠.
- Screen Space Decal(SSD): 다른 물체의 표면에 찰싹 붙은 반투명한 물체는 SSD로 처리했습니다. SSD에 대한 자세한 내용은 위에 링크 걸어드린 발표자료를 참조하시길. 역시 깊이버퍼를 업데이트할 필요가 없는 놈들이라 디퍼드에 무난히 사용가능
- 특수 쉐이더: 머리카락에만 쓴 쉐이더인데 딱히 깊이 버퍼를 업데이트 하지 않고 머리통에 있는 법선 조명 정보를 대충 가져다가 씁니다. 즉 디퍼드도 포워드도 아닌 이상한 꼼수를 썼죠.
- 파티클: 파티클은 여전히 포워드로 했습니다. 워낙 투명하니... 저희 파티클 시스템은 또 워낙 빨라놔서.. (파티클 질을 저렇게 해도 콘솔에서 2.75 ms 밖에 안걸림)
이래서 투명한 물체는 해결... 사실 이걸 해결할 수 있던 가장 큰 원인은 아티스트들의 워크플로우를 뚜렷하게 정했다는 거에요. 뭐는 안되고 뭐는 되고를 확실히 알려줬고.. 안되는게 있으면 그걸 성취할 수 있는 다른 방법을 제시했고요.
앤티에일리어싱
그럼 앤티에일리어싱은 어떻게 해결을 했을까요? 사실 운이 좋았죠... -_-
다행히도 게임을 출시할 때쯤 해서 MLAA(God of War 3, The Saboteur)와 FXAA라는 기법들이 이미 개발되었었고... 저희도 FXAA에서 영감을 받아서 그것보다 한 0.1ms 정도 빠른 자체 기법을 개발했습니다. 한 0.8ms 걸렸죠. FXAA라고 해봐야 화면의 색상(또는 조도)을 대충 분석해서 갑자기 픽셀값이 변하는 부분을 적당히 블렌딩 해주는 기법이거든요.
콘솔에서 사용하는 FXAA 기법은 사실 좀 화면에 흐릿해진다는 단점이 있습니다. (PC버전과 달라요) 그래도 스페이스 마린의 비주얼은 만화스럽기보단 사실적에 좀 더 가까워서... 약간 흐릿해져도 큰 문제가 없었죠. (만화처럼 색이 강렬하고 짜잘한 디테일들이 막 들어가있으면 이렇게 흐릿해지는게 문제가 많아요.) 그래서 운좋게 대충 무사히 해결...
지금와서 생각하는데 타사의 개발자들이 이런 기법들을 개발해 놓지 않았다면, 거기에서 영감을 받지도 못했을거고... 그러면 스페이스마린은 앨리어싱 때문에 꽤 타격을 받았을 거 같아요. 그렇다고 Gears of Wars 3처럼 아예 앤티 엘리어싱을 꺼버릴수도 없는거고... 운이 좋았죠. 책임회피는 했지만 운이 좋은.... -_-v
그렇다고 다 우리처럼 운이 좋을리는 없지?
근데 ... 아.뿔.사... -_- 소스코드를 열어보니... 포워드로 잘돌던 그래픽 엔진을 디퍼드로 바꿔버렸더군요..... 과연 왜 그랬는지 마땅히 말해주는 개발자들이 없어서.. 혼자 장단점을 따져봤습니다.
- 광원의 수가 전 게임에 비해 늘었니? 아니... 거의 똑같은데... (장점 #1 실패 -_-)
- 그럼 아티스트들의 작업시간은? 그림자를 오프라인에서 baking 하지 않으니 빨라짐... (장점 #2).... 근데 그림자 품질이 오프라인 처리할 때보다 저하되서 다시 baking을 시작하고 있음.. (결국 장점 #2 실패 -_-)
- 화면공간에서 하는 후처리 기법은? 저번 게임하고 그닥 달라진게 없음... SSAO 정도 추가했나? (미약한 장점 #3)
- 반투명한 물체는? 화면의 절반... -_- 여전히 포워드로 처리함... 한 10 ms 걸림... 쿨럭 -_- (심각한 단점 #1)
- 앤티에일리어싱은? 아직 구현 안했었음... 스페이스마린에서 사용한 AA를 구현해줬으니 게임자체의 색상이 화려한 편이라 흐릿함이 눈에 거슬림.... 이걸 제대로 고치려면 PC버전에서 쓰는 FXAA를 써서 3ms낭비하거나... 아니면 깊이 및 법선 비교까지 해야함. 이러면 2.6 ms 정도 걸림.... (단점 #2)
아무리 생각해도 디퍼드로 갈 이유가 없는 게임이더군요. 아직도 정확한 이유는 모릅니다. 왜 디퍼드로 가기로 결정했는지.... '이론상으로' 포워드보다 낫다고 생각했고... 새로운 기법에 대한 짜릿함 때문에 그렇게 결정해버린 게 아닌지.. 생각만 할뿐..... 처음 게임이 더 비주얼이 좋을 거 같아요......버럭!
대충 정리
글만 주저리주저리 길게 쓰는 놈이라.. 대충 이 일화의 교훈(?)을 정리.
- 새로운 기법을 도입하기 전에는 반드시 장/단점을 반드시 따져볼 것. 특히 단점을 위주로...
- 그 기법을 이용해서 게임을 출시한 사람들이 발표하는 장/단점은 언제나 장점에 치우쳐 있음. 단점의 심각함을 2배로 곱해서 생각할 것...
- 그 기법을 이용해 컨텐츠를 제작할 아티스트 및 디자이너들을 프로토타입 과정에 포함시킬 것. 그 개발자들의 피드백이 좋지 않으면 그 보다 큰 단점이 없음.
- measure, measure and measure!: 언제나 실제로 성능을 측정해볼 것....
피드 구독하기:
글 (Atom)