꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알 수 없는 사용자

안녕하세요. 뻔한 이야기만 하는 게임기획자 주민석 입니다.

게임디자이너부터 프로젝트매니저, 프로듀서의 업무까지 다양하게 경험하다 보니 여러 상황에서 다양한 사람들에게 제안을 해왔습니다. 그러다 보니 제안서를 쓰는 나만의 규칙도 생기고 제안이 잘 먹히려면 어떻게 해야 하는지 나름의 요령도 갖추게 되었습니다. 

그래서 오늘 말씀 드리고자 하는 것은 제안서를 쓸 때 생각해야 할 가장 핵심적인 부분, 제안서가 제안 받는 사람들에게 잘 통하기 위한 요령에 대해서 입니다. 제안서의 목차나 기술적인 부분보다는 아주 뻔하고, 귀 따갑게 듣는 정론적인 내용입니다. 게임개발포에버에 필자 참여하고 첫글이니 너그럽게 봐주세요. ^^

 

1.

제안서에서 가장 중요하고 명확하게 표현 되야 할 것은 이 제안을 통해 제안 받는 사람이 무엇을 얻는가, 제안 하는 사람은 무엇을 얻는가 입니다. 만약, 당신의 제안이 

1) 당신이 원하는 것이지만, 제안 받는 사람이 원하는 것이 없다면 : 제안 드롭

2) 당신이 원하는 것도 아니고, 제안 받는 사람이 원하는 것도 아니라면 : 그냥 뻘짓

3) 당신이 원하는 것이 아니지만, 제안 받는 사람이 원하는 것이라면 : 고난 시작

이죠. 1)번의 경우는 별 문제가 없습니다. 다시 제안을 하면 됩니다. 문제가 되는 경우는 3)번 입니다. 이렇게 통과 된 제안이 당신의 프로젝트가 되면 이 것을 진행하는 동안 '도대체 왜 이런 일을 해야 하지?' 하는 고민을 수백번도 더하게 됩니다.

그래서 제안은 당신이 원하는 일을 하면서, 제안 받는 사람이 원하는 것을 충족시켜 주는 것이어야 합니다. 하지만 현실이 언제나 이상적이지만은 않더군요. 우리가 원하는 제안은 항상 제안 받는 사람이 원하는 것과 충돌해서 드롭 되기 일수고 우리가 원하지 않은 제안이 통과 되어 고난이 시작 되는 경우가 많습니다. 저도 그런 경험을 많이 했고, 아마 앞으로도 계속 이런 경험을 하게 되겠지요. (T,.T)

그래서 최선은 내가 원하는 것과 제안 받는 사람이 원하는 것이 일치하는 것이지만 이런 경우가 결코 흔하지 않습니다. 그래서 이 제안이 실행 됨으로 제안 받는 사람도 원하는 것을 달성하고 그 과정을 통해 내가 원하는 것도 달성하는 방법을 찾는 것이 차선입니다. 그렇게 되기 위해 내가 원하는 것과 제안 받는 사람이 원하는 것에 대해 심층적으로 고민해야 합니다.

 

2.

여기 제안이 고난이 되는 아주 많은 오해 중 하나가 있습니다. 제안 받는 사람(주로 경영진)에 대해 '그들은 돈 잘 버는 것에만 관심이 있을거야.' 하는 것이죠. 앞서 말했 듯이 윈윈하려면 상대가 원하는 것에 대한 심층적인 고찰이 필요한데, '경영진 = 돈을 버는 것이 목적인 사람'으로 성급하게 결론 내리는 경우입니다. 비슷한 오해로는 '경영진은 일정 단축해주면 무조건 좋아할꺼야.' 하는 것도 있습니다.

제안을 받는 사람들은 사람마다 각각 다른 사고 과정을 거쳐 제안에 대해 결정을 하게 됩니다. 어떤 경영자는 정말로 '돈을 잘 벌 것 같은가'를 우선해서 평가하기도 하지만, 어떤 경영자는 이 제안을 실행해서 우리 조직이 어떻게 변화할 것인가를 우선해서 고민하기도 합니다. 논리적인 경영자는 제안의 결과에 따른 손익을 분석하고, 충동적인 경영자는 즉흥적인 직관으로 결정을 합니다. 정치적인 경영자는 이 제안이 부서나 직원 간 어떤 이해관계를 가지는지에 대해서 고민하고 결정합니다. 같은 경영자라도 저번에는 논리적으로, 이번에는 충동적으로, 다음에는 정치적으로 결정할지 모릅니다. 이건 일관성의 문제가 아니라 사람이기 때문에 당연히 그렇습니다.

그래서 성공적인 제안이 되려면 제안 받는 사람의 성향, 가치관, 현재 관심사부터 제안을 통해 무엇을 원하는지에 대해 심도 깊은 고민과 이해가 필요합니다. 이를 알아내는 방법은 대화를 하는 것입니다. 혹시라도 제안을 결정하는 대표나 직장상사에게 제안서를 다 쓰기도 전에 제안에 대해 질문을 해도 되는지 걱정하시는 분이 있다면 걱정 말고 대화해보라고 말씀 드리고 싶습니다. 왜냐하면 그들은 당신의 일을 평가하는 것보다 당신이 올바르게 일하는 것이 더 중요한 사람들입니다. 당신이 구체적으로 질문해 오면 아마 거의 대부분 친절하게 대화에 임해줄 것이라고 99% 정도 확신합니다. (간혹 1% 정도 비정상적인 사람들도 있어요...)

당신의 제안을 받는 사람이 유명인이라면 인터넷 검색을 해보세요. 최근 인터뷰 기사는 그 사람이 평소 어떤 생각 혹은 가치관을 가지고 있는지 알아내는데 도움이 됩니다.

 

3.

제안서는 제안을 통해 무엇인가 행동을 하게끔 만드는 것이 목적입니다. 즉, 제안서에는 반드시 제안 받는 사람이 내려야 할 결정이 명확하게 담겨 있어야 합니다.

"추가적인 자금 투입을 승인해 주세요.", "일정이 3개월 더 필요 합니다.", "이런 아이디어를 추가하고자 합니다. 구현해봅시다."

제안의 목적이 분명하고 명확하게 구체적으로 제시 되어야 합니다. 그래서 제안 받는 사람이 어떤 결정을 내리도록 유도 해야 합니다. 명확한 목적이 없는 제안은 '생각해봅시다.' 하고 다른 바쁘고, 중요한 일들에 밀려 잊혀집니다. 제안이 행동으로 이어지게 만들기 위해서 제안 받는 사람에게 시간을 제한하는 것도 좋은 방법입니다. 문서로 제안서를 작성하여 이메일로 보냈다면 전화를 하거나 직접 찾아가 제안에 대해 확인하고 결론을 받아 내는 것도 좋습니다.

제안이 여러 사람을 대상으로 할 때에는 특히 구체적이어야 합니다. 서로 제안에 대한 결정을 미루기 때문입니다. 도움이 필요할 때 군중을 향해 "누가 좀 도와주세요." 하는 것보다 "거기 초록색 옷 입은 아저씨는 119에 전화해 주시고, 노란색 옷 입은 아줌마는 이 사람 좀 부축 해주세요." 하고 구체적으로 요청하는 것이 효과적인 것과 같은 이치입니다. 제안을 받는 그룹에서 정확하게 어떤 사람이 어떤 일을 해야 하는지 그룹의 최종책임자는 어떤 결정을 내려야 하는지 구체적으로 명시해야 합니다.

 

4.

제안서를 잘 쓰는 왕도는 역시 많이 써보고 많이 제안해 보는 것입니다. 그렇게 계속 제안이 쌓이다 보면 나만의 폼? 모듈? 서식 같은 것들이 생겨 납니다. 어떤 논리를 전개할 때 주로 쓰는 도해라든지, 어떤 상황에서 사용하는 슬라이드 마스터라든지, 시장 조사 자료를 수집하는 경로라든지, 어떤 주장을 전개하기 위한 논리적 흐름 같은 것들에 규칙이 생겨 납니다.

제가 요즘 제안서를 쓸 때 가장 고민하는 것은 제안에서 논리 전개의 흐름인데, 제 나름대로는 '제안서의 스토리텔링'이라고 부르고 있습니다. 예를 들어 신규 게임에 대해 사업 제안을 할 때 전통적으로 게임 개요, 콘텐츠 소개, 마케팅 계획, 개발계획 같은 큰 목차를 나누고 그 안에서 세부적인 목차를 나누어 작성하는 경우를 많이 보았습니다. 그런데 제 생각에 이 것은 읽는 사람 입장에서 전혀 흥미롭지가 않습니다. (물론 이런 문서가 필요 합니다. 제안이 아니라 정리 차원에서요.)

제안서는 누군가의 마음에 들어 실행이 결정 되는 것이 목적인 문서입니다. 무조건 흥미로워야 합니다. 문서 전체를 보았을 때 목차가 아니라 이야기가 보여야 합니다. 제안을 읽는 사람이 '내가 이 제안을 실행하면 이런 결과가 나오겠구나, 이런 이득이 생기겠구나.' 하는 내용이 이야기로 명쾌하게 보여져야 합니다.

PPT로 제안서를 작성했다면 여러 슬라이드 보기를 꼭 해 보세요. 전체적으로 어떤 흐름이 보이는지 확인 해 보세요. 목차에 따른 전개입니까. 하나의 이야기 입니까. 전체적으로 건조합니까. 아니면 흥미롭습니까. 특히 제안이 구두 설명이나 프레젠테이션 없이 이메일이나 문서로만 진행 되는 것이라면 더더욱 중요합니다.

보편적으로 딱딱해 보이는 제안서보다 재미있는 이야기 같아 보이는 제안서가 채택 될 가능성이 높습니다.

 

 요점정리

1) 나도 좋고, 제안 받는 사람도 좋은 제안을 하자.

2) 제안 받는 사람이 결정을 내리는 동기를 파악하자.

3) 제안에 따른 결정, 실행에 대해 구체적으로 요청하자.

4) 제안서도 흥미롭게 읽을 수 있어야 한다.

땡~ 끝!

 

요즘 제가 가장 많이 하고 있는 제안은 '나랑 같이 스마트폰, 태블릿PC로 게임 만들어 보지 않을래요?' 하는 것인데 열번 시도하면 아홉번 정도 실패하고, 그 중에 성공한 한번도 구체적 단계에서 세번 중에 두번은 실패하는 것 같네요. 이런 제안을 같이 일했던 동료들에게 던져 보면서 항상 내가 지금 하고 있는 프로젝트를 어떻게 설명해야 개발자들이 참여하고 싶게끔 매력적으로 보이게 할까 고민을 합니다.

모든 일이 그렇겠지만 경력이 많아지고 직급이 올라갈 수록 업무의 범위가 컨셉추얼 해지고 정형적인 일도 비정형적으로 변해가고, 제안이 필요한 일의 양과 범위가 증가하게 되더군요. 그래서 어느 수준에 이르면 얼마나 성공적인 제안을 계속 할 수 있는가(일단 수행과 결과는 별개로...) 하는 점이 얼마나 좋은 리더인가의 잣대가 되는 것 같습니다.

오늘은 제안에 대한 총론적인 이야기들만 했는데 다음 번에는 제안서에서 많이 쓰이는 도해들을 정리해서 방출하도록 하겠습니다.

 

뻔한 이야기 읽어주셔서 고맙습니다.

 

반응형
,

Wrapped Diffuse

프로그래밍 2012. 4. 3. 17:25
Posted by 알 수 없는 사용자

오랜만이네요. 한 동안 멘탈이 붕괴되어서, 방황하다가 우리 아가랑 신나게 놀다가 정신차리고 돌아왔습니다. ㅎㅎ

슬슬 GDC12의 기술문서들이 올라오네요.. ㅎㅎㅎ.. 비록 GDC는 못 갔지만, 대충 어떤 흐름으로 전개가 되고 있는지는 대충 파악할 수 있겠군요. 공부할 것들이 태산이네요.. 하악 하악... 이 넘의 게임개발자란 직업은 정말이쥐.. ㅎㅎㅎ

하지만, 오늘은 조금 간단한 내용을 다루어 볼까 합니다. 바로 Diffuse 라이팅!!!! 


1. Lambert 라이팅 모델

가장 일반적으로 Diffuse 라이팅에 사용되는 공식이 바로 Lambert 공식입니다. 

float lambert_term = max(0, dot(normal, light_direction));

특별히 설명할 것이 없지만, Lambert 공식에 대한 특징은 "퐁퐁퐁"님의 Oren-Nayar Reflectance Lighting Model 를 보시면 잘 설명이 되어 있으니, 참고하시면 될 듯 합니다.

위의 내용에도 잘 나와 있지만, Lambert 모델은 플라스틱 같은 느낌의 표현이 됩니다. 


2. Half Lambert 라이팅 모델

Half Lambert 공식은 Value 사에서 Half-Life에서 처음 소개된 방식으로 오브젝트가 너무 어둡게 나오는 것을 방지하기 위한 목적으로 사용되었습니다. (https://developer.valvesoftware.com/wiki/Half_Lambert)








내용은 굉장히 간단합니다.

float halflambert_term = dot(normal, lightdirection) * 0.5f + 0.5f

float halflambert_pow_term = pow(dot(normal, lightdirection) * 0.5f + 0.5f, power);

계수에 의한 변화에 대한 결과는 대마왕J님의 블로그에 실험 결과가 올라와 있네요. (http://chulin28ho.egloos.com/5099713) 참고하면 될 듯 합니다.

Half Lambert는 물리적으로 올바르지는 않지만, 일반적으로 피부와 같이 약간 투과되는 느낌의 질감을 표현할 때, 꽤 효과가 좋습니다. 또 간단하게 셰이딩을 할 때에는 은근히 간접광을 받는 듯한 느낌도 있어서, 비교적 저렴하게 꽤 화사한 느낌을 만들어 낼 수 있습니다. 하지만, 결과적으로 너무 밝은 결과가 나오기 때문에, 사실적인 느낌의 게임 렌더링에서는 잘 맞습니다. 


3. Wrapped Diffuse 라이팅 모델

오늘의 주제인 Wrapped Diffuse 입니다. 제가 처음으로 Wrapped Diffuse 에 대해서 들어본 것은 몇 년 전 Valve에서 출시한 팀포트리스2 라는 게임에 대한 렌더링 기술문서에서 입니다. Diffuse 렌더링을 위해서 Wrapped Diffuse를 사용했다고 하는데, 그 때에는 이것이 무엇인지 정확하게 이해를 하지 못했습니다. 

(참고로 팀포트리스의 Wrapped Function은 Half Lambert를 이용해서, 1D Wrapped Diffuse Texture에서 값을 얻어오는 것이었습니다.)

시간이 지나서, Wrapped Diffuse가 일반적으로 많이 사용되지 않기 때문에, 그냥 잊고 지냈는데, 최근 들어서, 여러가지 기술문서들에서 Wrapped Diffuse 라는 용어가 등장합니다. 그럼 Wrapped Diffuse는 뭐하는 것일까요?


Wrapped Diffuse는 subsurface scattering, area light source, 더 부드러운 reflectance 를 표현하기 위해서 Hemisphere(반구)를 감싸는 셰이딩 모델입니다.

[Lambert(좌)와 Wrapped Diffuse(우) [2]]

Wrapped Diffuse 공식은 다음과 같습니다.

float wrapped_diffuse_term = (dot(normal, lightdirection) + w) / (1+w);

그런데 가만보니까 Half Lambert 정의와 유사하네요? 그렇습니다. Half Lambert 공식도 바로 Wrapped Diffuse 라이팅 공식을 간략화 한 내용입니다. 그러니, Half Lambert 특징과 유사하다고 생각하면 틀리지 않습니다. (W=1이면, Half Lambert 공식이 됩니다.)

Wrapped Diffuse는 Half Lambert와 유사하게 투과되는 느낌을 표현하는데 많이 사용되는데요, 피부, 나뭇잎, 파티클 라이팅에 주로 사용됩니다. 여기 유니티 3D의 SkinShader 샘플을 보시면 사용예를 보실 수 있을 것입니다. (http://unifycommunity.com/wiki/index.php?title=SkinShader)


하지만, Wrapped Diffuse 모델은 너무 밝은 결과를 나타냅니다. 그래서 일반적으로 사용하기는 조금 부담감이 있습니다. 최근 본 내용 중에 이를 해결할 수 있는 좋은 아티클(Energy-Conserving Wrapped Diffuse)이 올라와서 소개합니다.

최근에는 Physically Based Lighting 이 주목을 받고 있습니다. 그 중심에는 "에너지 보존"이 기반이 되는데요. 이 아티클도 "에너지 보존"에 중심을 두고 있습니다. 즉, Lambert Diffuse 모델에 대한 결과를 1로 봤을 때, Wrapped Diffuse 모델의 총 에너지도 1로 만들어 주는 것이지요. 그렇게 되면, 너무 밝지 않은 Wrapped Diffuse 결과를 얻을 수 있습니다.

// w is between 0 and 1
float3 wrappedDiffuse = LightColour * saturate((dot(N, L) + w) / ((1 + w) * (1 + w)));

결과

이 그림을 보고, 뭐가 좋아졌나 싶죠? 하지만, 실제로 적용을 해보시고 테스트를 해보시면, 대충 어떤 느낌이신지 아실 것입니다. w값에 따라서, 전체 에너지량은 그대로이면서, 음영만 조절되는 느낌이거든요. (이전의 Wrappped Diffuse 모델은 그냥 밝아져버리죠!)


4. 결론

Wrapped Diffuse에 대해서 알아보았습니다. 앞에서 "퐁퐁퐁"님의 Oren-Nayar Reflectance Lighting Model 에서도 보셨듯이 Diffuse Lighting 모델은 Lambert Model 하나만 있는 것은 아닙니다(Oren-Nayar 비싸요. ㅜㅜ). Diffuse 라이팅을 할 때에도 표면의 성질에 따라서 라이팅 모델을 선택해서 적절하게 선택해서 사용을 한다면, 좀 더 정밀한 재질 느낌을 낼 수 있을 것입니다. (물론, Diffuse 보다는 Specular가 더 중요하겠죠!? ㅎ)

- 좀 더 거친 표면의 Diffuse 표현 -> Oren-Nayar Model
- 일반적인 표면의 Diffuse 표현 -> Lambert Model
- 좀 더 부드러운 표면의 Diffuse 표현 -> Wrapped Diffuse Model

(Physically Based Lighting의 세계는 재밌어요!!! ㅎㅎㅎ)


5. 참고자료

[1] Wrap Shading : http://www.iro.umontreal.ca/~derek/publication8.html
[2] Energy-Conserving Wrapped Diffuse 
[3] Wrapped Diffuse와 팀포트리스 셰이딩 : http://cagetu.egloos.com/5621806
[4] 팀포트리스 셰이딩 따라해보기 : http://cagetu.egloos.com/4212681 
[5] Energy Conservation in Games : http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/

반응형
,
Posted by 대마왕J

우왕 - 벌써 9강이야 >_< /
라고 말씀드리고 싶지만 사실은
아직도 9강이야 ... 흑흑흑 입니다. 진도 언제나가 흑흑흑... 역시 설명을 쓸데없이 자세히 하는걸까... 흑흑흑...
뭐 어쨌건 게임테크 강연도 잘 끝났겠다. 일정이 빠듯하지만 빨리 다음 강의를 써야겠지요.

자... 그럼 또 오늘은 뭘 할까 얘기해 봅시다.

다들 아시겠지만 지금까지 이미지 합성을 주로 가지고 놀았습니다. 특히 채널을 가지고 놀았지요. 검은색은 0이고 흰색은 1이고 뭐 그런거지요. 그리고 거기서부터 모든게 시작되었다.. 뭐 그런 겁니다.

오늘은 여기에서 좀 더 진화된 내용을 하나 더 배워보도록 하지요. 지루하시다고요? 그래픽 디자이너 분들에게 익숙하지 않은 '색깔을 숫자로 바꾸는' 내용을 완전히 이해시키려면 반복이 최고라고요!

1. Vertex Color 그려보기

일단 배워 볼 것은, Vertex Color 입니다.

Vertex, 일명 '점' 은 많은 정보를 가지고 있습니다. 위치정보, UV 정보, 노말정보...

그리고 거기에 하나 더 해서 , float4의 '색' 도 가지고 있습니다. 오오오 , 자체적으로 RGBA도 가지고 있다는 말입니다 . 텍스쳐도 없이!!! [각주:1]

대충 이렇게 보입니다.

3d 그래픽 디자이너 분들이라면 뭐 쉽게 그리실 수 있으시리라 믿지만, 그렇지 않은 분들을 위해서 매우매우매우매우 귀찮지만, 이 대마왕께서 친히 vertex color를 그리는 법을 알려드려야 겠군요.

캬오

vertex color를 그리는 방법은 크게 두 가지가 있습니다.

우선 첫 번째 방법부터 알려드리지요.

플렌을 하나 만듭니다. 어떻게 만드냐고요? 이것까지는 건너뛸래요. 이젠 이정도는 만드실 수 있으시잖아요. 아닌가? 아니면 할 수 없죠. 옆의 사람한테 물어보세요. 이거 설명하기에는 시간이 아깝습니다. 우후후 [각주:2]

면 수는 조금 많은게 편합니다.

그리셨으면, 오른쪽 클릭하고, Convert To Editable Poly를 선택해서, Poly 오브젝트로 만들어줍니다. [각주:3]

Poly 오브젝트가 되었으면, 이번엔 오른쪽 메뉴에서 vertex 선택 모드를 켜 줍니다.
그럼 vertex들이 파랑색으로 보일겁니다.
화면의 일정 영역을 드래그해서, 원하는 만큼의 vertex를 선택하도록 합시다. [각주:4]

그럼 선택된 vertex는 빨강색이 됩니다.

이제 오른쪽 메뉴의 빈 구석을 마우스로 잘 뒤져보면, 빈 영역에서 마우스 아이콘이 손바닥으로 변하는 것을 볼 수 있습니다. 이 손바닥을 이용해서 메뉴를 위로 끌어 올리면, 'Edit Vertex Colors' 라는 메뉴가 보일겁니다.
color도 있고 alpha도 있네요.

자, 이제 color를 블랙으로 바꿔서, 선택된 vertex의 색을 검은 색으로 바꿔봅시다.

응? 분명히 바꿨는데 아무 일도 일어나지 않습니다???

아무 일도 일어나지 않았다면 정상입니다.

vertexcolor는 평소에 보이는 칼라가 아닙니다. vertex가 꽁꽁 숨겨서 가지고 있다가, 'vertexcolor를 보여줘라' 라는 명령이 있다던가 할 때에야 보여주는 녀석입니다.

믿어주세요.

그렇지만 우리는 지금 vertexcolor를 보고 싶습니다. 그렇다면 임시로 vertexcolor가 보이는 모드로 변환시키면 되지요.
아래 그림처럼, 다시 vertex 모드를 풀고 일반 오브젝트 모드로 돌아옵니다. [각주:5]

그 다음에 오브젝트를 오른쪽 클릭하고, Object Properties를 선택합니다.

Object Properties가 나오면, Vertex Channel Display를 체크해 주고 OK를 누릅니다.

VertexColor가 보입니다!!! 단 아까의 색은 다 없어지고, 지금은 vertexcolor만 보이게 됩니다. [각주:6]

자, 이제 vertex 모드를 켜고, vertex를 선택한 다음에 원하는 색으로 vertex를 물들여 보시기 바랍니다.[각주:7]

vertex color가 아닌, 일반 텍스쳐 혹은 일반 오브젝트의 색을 보고 싶으시면, 다시 Properties에 가셔서 Vertex Channel Display를 꺼주시면 됩니다.

2. vertex color를 shaderFX로 써봅시다.

자, 위에서 vertex color를 그리는 법을 익혔습니다.

즉 vertex는 각각마다 개별의 color를 가질 수 있지만,
그 color는 평소에 보이는 것은 아닙니다. '보이게 해야' 보이는 겁니다.

...라는 얘기였죠.

그리고 Alpha도 있는 것으로 보아, float4 의 데이터를 가지고 있다는 것도 알 수 있습니다.
다시 말해서, 이 vertexcolor도 이전 시간에 배운 내용들과 같이 색상용으로, 혹은 마스킹 채널용으로 사용할 수 있다는 말입니다. 그럼 직접 해보도록 하지요.

자, 뭡니까? 뻔하죠? 지금까지 우리가 수없이 해왔던, Grass.dds 파일을 그냥 Texture로 해서 입혀놨을 뿐입니다!!!
아까 vertexcolor를 그렸던건, 하나도 보이지 않습니다!!!

당연하죠! 아까도 말했잖아요! 그냥은 보이지 않는게 정상이라니까요!! 분명히 vertex는 색상을 가지고 있습니다만, 안보이는게 기본이예요!!! [각주:8]

자, 이제 이걸 보이게 해 봅시다.

일단, vertex 에는 vertex color가 들어 있는 것을 알고 있으므로, 그 값을 입력받아와야 하니까, shaderFX의 빈 화면에서 오른쪽 클릭하고 Inputs / VertexColor를 받아옵시다.

이렇게 VertexColor를 쉽게 받아 왔습니다.

역시나 아이콘 참 좋아요. 점이 세 개 있고, 칼라가 그려져 있습니다. 훌륭하죠. 게다가 RGBA , float4로 이루어져 있는 것도 볼 수 있습니다. 이 녀석을 Texture 대신 연결하면, 당연하게도 이제 Vertex Color가 나옵니다!!!

즉, 텍스쳐와 vertex color를 곱하거나 더하거나 등등 해 주면, 아래와 같이 이제 텍스쳐와 함께도 나올 수 있다는 말입니다. 게임에서도 동일하게 사용 가능하죠.

요것이 대충 그린거긴 합니다만, 이 별거 아닌 기능을 만들어 놓고선 아티스트에게 쥐어주면, 갑자기 아트가 튀어나옵니다. 그게 아티스트들의 종특.

프로그래머들에게는 없는 '제약' 같은 것이 있기 때문에 오히려 '있는 것' 을 가지고 파 들어가는 능력이 특화된 것이 3D 그래픽 디자이너들입니다.

대충 생각해 봐도 이런데 쓸 수 있죠.

- 캐릭터 옷의 염색 등에 쓸 수 있습니다. 실제로 프리스타일이나 마비노기 (맞나..) 에서 사용되었죠
- 지형의 격자 단위가 모두 동일하다면, (동적 LOD가 일어나지 않는다면) 워포그로도 사용할 수 있습니다.
- 저사양을 목표로 하는 게임에서, 지형에 빛이나 그림자가 은은하게 먹은 느낌 등 색감을 풍부하게 주고 싶을 때 사용할 수도 있습니다.

위의 땅 그림에 vertexcolor가 사용되었습니다 물 아래는 녹색으로 칠하고, 나무 아래와 언덕에 음영처럼 보이는 것 모두가 vertex 칼라를 이용한 것입니다. 군데군데 밝은 것도 마찬가지고, 멀리 푸른 빛이 도는 땅도 vertexcolor로 칠한 겁니다.

그 외에도 사실, 안보이는 부분에서도 많이 사용할 수 있습니다.

- 간단한 RPG나 엑션 게임 등에서 지형의 속성을 정할때에도 사용할 수 있겠죠.
- 모바일 프로젝트처럼 가벼워야 하는 프로젝트에서는, 지형 텍스쳐 여러 장을 섞어줄 때 사용할 마스킹 텍스쳐 대신 사용할 수 있습니다.
- 기타 각종 마스킹에서도 응용할 수 있습니다.

그리고 장점 단점은 다음과 같습니다.

장점은, 무척 가격이 싼 기능이라는 겁니다. 텍스쳐가 들어가는 것도 아니고, UV가 필요한 것도 아니니까요.

단점은, vertex 간격이 조밀하지 않으면 매우 거칠게 보이며 , 어쨌건 텍스쳐로 그리는 것보다 덜 정밀하다는 것입니다. 채널 4개를 다 써버리면 더 쓸 수 없다는 것도 단점이구요.

3. 실시간 스플레팅 맵에디터를
만들어 봅시다.

자... 그럼 vertexcolor를 응용해서 실시간으로 동작하는 맵 에디터를 한번 만들어 볼까요?
좀 더 본격적으로 만들기 위해, 텍스쳐를 준비해 봤습니다. 나 잘했죠.

빨리 칭찬해줘요 하악하악


아래 텍스쳐를 받아서 써 보세요. 4개의 타일링 된 텍스쳐입니다.
출처는 무료 텍스쳐 사이트인 http://www.cgtextures.com 에서 가져온 겁니다.

     

이 네개의 타일링된 텍스쳐가 스플레팅으로 동작하는 맵에디터를 만들어 보도록 하겠습니다. vertex color를 그리는 방법은 위에 소개한 방법을 사용하시면 되겠습니다. [각주:9]

자, 일단, 이전에 만들었던 plane은 버리고, 새로 만들기로 하지요.
지금 막 만든 오브젝트니까, vertexcolor는 흰색일겁니다. 알파도 물론 1.0
float4(1.0, 1.0, 1.0, 1.0) 인 상태겠지요.

위에서 배운 방법대로, vertex color를 보이게 한 다음 모두 검은색으로 칠해줍니다.

그리고 다시 오브젝트 모드로 돌아옵니다. 이것이 기본.


역시 겉으로 보이는 것은 그대로입니다. 그렇지만 내부의 vertex color는 , float4(0,0,0, 1) 이 되어 있다는 걸 아실겁니다.[각주:10]

이 부분은 매우 중요합니다. 흰 색으로 해 놓으면, RGB 값이 모두 1,1,1 이 되어서 마스킹 작업이 곤란하기 때문입니다.
...해보시면 알아요.

자 그럼 예제로 올려드린 첫번째 텍스쳐와 두 번째 텍스쳐를 불러 낸 다음, 첫 번째 텍스쳐만 보이게 해 줍니다.
Diffuse Color 에 연결해도 아무 문제 없습니다. 첫 번째 텍스쳐가 잘 나왔습니다.
그런데 두 번째 텍스쳐가 뭔가 뻘쭘해 보이는군요. 나 할 일 업ㅅ엉ㅋ

추가적인 노드가 두 개 더 필요합니다.
하나는 이번 시간에 배운,Input / Vertex Color 이구요
또 하나는 저번시간에 배운 Lerp, 즉 "리니어 인터폴레이션" Math / MaxLinierInterp 입니다.

후후후후 뭘 할지 짐작이 나시나요?
저번 시간 강의가 '조낸 쉽네' 하면서 그냥 슬쩍 읽기만 하신 분은 모르시겠지만,
사실은 지난 시간 강의가 이번 시간 강의를 위한 초석이었습니다!!! 밑밥이었구요!!! 낚시였습니다!!!

나는야 낚시왕


그렇습니다. 지난 강의에 나온 걸 그대로 하려고 하는 겁니다. 리니어 인터폴레이션을 이용한 텍스쳐 블렌딩 말이죠.

자.. 이걸로 이렇게 연결해 줍시다.
Lerp의 A소스와 B 소스는 텍스쳐 1과 2로, 그리고 Blend Value 에는 vertexcolor의 R 채널을 연결시켜 줍시다.
변화가 있습니까?
... 없다고요?

-생각해 보지요. 지금 저 Plane의 모든 버텍스는 무슨 색?
-검은색이죠?
-검은색이면 R채널은 몇?
-0.0 이죠? [각주:11]
-BlendValue에 0.0 이 들어가면 A 이미지가 나올까요 B 이미지가 나올까요? 당연히 A 이미지가 나오죠?

그래서 이렇게 해 놔도 변화가 없습니다. 네 변화가 없는게 당근 맞습니다 .

하지만, vertex를 선택해서, VertexColor를 빨강색으로 바꿔주면 어떨까?

넹, 빨간색이 출동하자, vertex color의 R 채널은 1이 되어 버리면서 두 번째 텍스쳐가 나오기 시작합니다!!! 오오오!!!
Opacity에 따라 서로 블렌딩도 조절할 수 있겠군요!!!

이걸 쉐이더 코드로 써 본다면...
FinalColor = lerp( InputA , InputB, VertexColor.r ) ;
이 한 줄로 처리할 수 있겠군요.. OTL 언제나 코드는 참 짧기도 하지..
언젠가는 유니티 쉐이더를 직접 짜보는 강좌를 할 수 있겠죠?


욕심이 생기니 다른 텍스쳐도 넣어 보고 싶습니다.
추가적인 텍스쳐와 노드를 추가해서 준비해 봅시다. 아래와 같이 말이죠[각주:12]
추가된 것은 lerp 노드와 vertexcolor 노드, 그리고 새로운 추가 텍스쳐입니다.

그럼 이제 아까 나온 최종 결과를 다시 A에 넣고,
B 칼라는 새로 들어갈 풀 텍스쳐를 넣으며,
Blend Value는 vertexcolor의 g 채널을 연결해 놓는 겁니다.

이렇게 해 놓고, vertex color를 녹색으로 바꾸면!!!
그 부분에 풀 텍스쳐가 나오게 됩니다!!! 오오오!!!

그런데 사실, 위의 노드를 보면, 쓸데없이 vertex color를 두 번씩 입력받고 있습니다. 이건 낭비입니다! 비효율 코드예요!!! 만약 쉐이더 코드라면, 쓸 데 없이 vertex color를 두 번 호출하는 코드가 되었을 것입니다!!!

그래서 이렇게 바꿔줬습니다. 아까 한 번 받은게 있으니 거기서 G 값을 받아와서 쓰면 되잖아요.[각주:13]
이렇게 하면 한 번 받은 vertexcolor의 R 값은 첫 번째 블렌딩에, G 값은 두 번째 블렌딩에 쓰게 되는 것을 알 수 있습니다. 조금 복잡해 보이지만 알뜰하죠.

팁 : 퀵 그룹을 써 봅시다.

잠깐 알려드릴 추가 기술이 있습니다.
슬슬 노드가 복잡해지기 시작하시죠? 원래 노드로 짜면 제일 큰 단점이 너무 보기가 힘들어진다는 것입니다.
때문에 좀만 복잡한 코드는 한 번 놓치면 끝장이예요.
그래서 이 복잡한 노드를 좀 더 가볍게 볼 수 있는 방법이 ... 더블클릭하면 노드가 작아지는 법이 일단 있군요.... 그거 말고요, 있습니다. 바로 퀵 그룹 (Quick Group)메뉴인데요.

일단 예를 들어 안건드릴 것 같은 노드들이 있다고 가정하면, 그걸 좌아악 선택합니다.

노드가 선택되었으면, Tools / Quick Group를 선택합니다.

선택한 노드들이 그룹이 되어서, 노드 하나로 압축되어 버립니다.
물론 다시 그룹을 풀 때에는 Quick Group 바로 아래에 있는 Un-Group 으로 풀어주면 됩니다.

덧: 이번 강의엔 별 필요 없습니다람쥐.

자 그럼 말 나온김에 B 채널까지.. 뭐 이젠 쉽겠죠. 결말로 급 전개입니다.
이렇게 만들면 됩니다. 세 번재 vertexcolor lerp입니다. 알아 보시겠죠?

이렇게 하면, vertexcolor를 파랗게 칠한 곳에는 네 번째 텍스쳐가 나오게 됩니다. 후후후후

A 채널까지 사용한다면, 무려 5개의 텍스쳐를 스플레팅으로 블렌딩 할 수 있는 거지요! 그래서 한 번에 처리할 수 있는 스플레팅 텍스쳐의 최대 장수는 5개입니다. [각주:14]

이렇게 해서 스플레팅의 기본은 끝내 봤습니다. 혹시나 원하시는 분을 위해서, 풀 버전의 노드를 다시 한 번 공개해 보도록 하겠습니다.

4. 숙제로 간지나는 텍스쳐 스플레팅 기능을 만들어 보기

강의가 사실 너무 길어져서 -_-;;; 여기서 줄이느라고 나머지는 숙제로 내 드리겠습니다.
오늘의 숙제는 두 개입니다!

첫 번째 숙제 : 위의 지형에서 텍스쳐 타일링 개수를 늘이고, 지형 높낮이를 만드세요.

간단한겁니다. 저 텍스쳐들은 지금 타일링이 가능한 텍스쳐라서 , 좀 더 지형처럼 텍스쳐가 나오게 할 수 있습니다. 입력받은 UV에 일정 숫자를 곱해서 타일링 시키던거 기억나시죠?

대충 노드는 아래 모양처럼 될 테고... 저저저번 시간 강의던가... 그때랑 연결시켜 응용하셔야 해요.

모양은 대충 아래처럼 나오겠죠.
UV를 각각 조절하게 만들면, 스플레팅 텍스쳐마다 개별로 조절할 수도 있겠죠.

두 번째 숙제: vertex paint 기능을 이용해서 진짜 맵에디터처럼 그려 보세요.

vertex paint 기능을 이용하면, 좀 더 그럴듯 하게 그릴 수 있습니다. 정말 부드럽게 브러쉬처럼 조절도 되고, 블렌딩도 훨씬 자연스러워 지며 , 보기에도 멋지게 됩니다.

이 부분은 max이므로 자세히 설명하지 않겠습니다. 이 강의는 그래픽 디자이너 분들을 위한 강의라서, 맥스의 조작방법은 매우 불친절하게 가르쳐 드린다는 것을 잊지 마시길.
어쨌건 모디파이어에서 vertex paint를 꺼낸 후,

그냥 vertexcolor를 그리기만 하면 상용 엔진의 맵에디터와 비슷한 느낌으로 맵을 제작할 수 있습니다. 슥슥슥슥. 타블렛펜을 이용하면 금상첨화.

그럼 뭐 이렇게 되는 겁니다. 해보세요 재밌습니다.

 

자 그럼, 오늘은 vertex color를 이용한 텍스쳐 스플레팅까지 해 보았습니다. 다음 시간엔 뭐할까나.. .뭐하지... 뭐하나...
에이 몰라. 다음 시간껀 다음에 생각할래요. 이미 너무 길어져서 귀찮!

유니티 컨퍼런스랑 NDC 준비도 해야 한단 말야!!!

2012/03/18 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 8강

2012/03/03 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 7강

2012/02/18 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 6강

2012/02/03 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 5강

2012/01/31 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 4강

2012/01/18 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 3강

2012/01/03 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 2강

2011/12/18 - [아트] - ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 1강

 

  1. vertex가 가지고 있는 , 즉 vertex가 가질 수 있는 정보가 뭐냐... 라는 것은 나중에 최적화 할 때 매우 중요한 정보가 됩니다. [본문으로]
  2. 매우 불친절하게 알려드리자면... 오른쪽 메뉴에서 Create 탭에서 Plane을 누르고, 화면에서 드래그 하면 됩니다. [본문으로]
  3. 프로그래머 분들을 위한 여담을 하자면, Poly라고 하는 구조는 맥스에서 만든 구조입니다. 삼각형이 아닌 다각형을 지원하는 구조지요. 물론 게임으로 컨버팅할때는 자동적으로 삼각형으로 다시 분할됩니다만, 맥스에서 모델링 할때에는 매우 편한 구조입니다. [본문으로]
  4. 제 그림의 vertex가 유난히 크게 보이는 이유는, 보시기 쉽도록 설정에서 조정했기 때문입니다. 기본은 이렇게 안커요 ㅋ [본문으로]
  5. 이건 굳이 안해도 되긴 합니다만.. [본문으로]
  6. 우리는 아까 일부 vertex를 잡아서 검은색으로 칠했었습니다. 즉, 아무것도 손대지 않았을때의 기본 vertex color는 흰색이라는 것을 알 수 있습니다 . [본문으로]
  7. 브러쉬로 편하게 그리는 또 하나 방법이 있습니다만, 이 방법도 뭐 그냥저냥 쓸데가 있는 방법입니다. [본문으로]
  8. '왜 꼭 Ambient Color에 연결하냐' 라는 질문을 해주신 분이 계십니다. 이것은 별 이유 없습니다. 거기가 그냥 제일 빛 영향 안받고 텍스쳐가 잘보여서 넣는 것 뿐입니다 :) 여러분은 Diffuse에 넣으셔서 멋있게 보셔도 좋겠습니다. [본문으로]
  9. 타블렛을 소지하신 그래픽 디자이너 분들은, vertexpaint 모디파이를 사용하시는 것도 좋겠습니다. [본문으로]
  10. 마지막 1은 Alpha입니다. 우리는 color만 검은색으로 만들었잖아요? 이번 예제에서는 alpha는 번거러워서 안쓰렵니다 -_-;; [본문으로]
  11. 그냥 0 이라고 해도 되구요. 0.0 이라고 쓰는 이유는 "이게 소숫점을 가질 수 있는 float " 이라는 의미로 주로 쓰는 겁니다. 왔다갔다 하곤 하죠. [본문으로]
  12. 노드를 더블클릭하면 작아집니다! 노드를 선택하고 Ctrl+C 를 하면 노드가 복사됩니다!!! [본문으로]
  13. 자, 슬슬 눈 돌아가시는 분들 생깁니다... [본문으로]
  14. 지형을 만들때 일반적으로 5장까지 블렌딩을 제한하는 이유가 이것입니다. 만약 더 쓰게 되면, 2pass로 넘어가게 되어서 퍼포먼스에 안좋은 영향을 끼치기 때문이지요 [본문으로]
반응형
,
Posted by 김포프

안녕하세요. 이젠 하도 들어서 꽃미남이란 별명이 좀 질릴까 하다가도 여전히 부정할 수 없는 현실임이 안타까운 여전히 꽃미남 게임 프로그래머 포프입니다. (제가 태어나서 써 본 것 중 가장 긴 문장입니다. 뿌듯합니다.... -_-)

이제 본문 입니다... -_-

요즘 나름 바빠졌습니다

개인 블로그에 북미취업 가이드쉐이더 입문 강좌를 연재하고, 게임개발포에버를 시작한 후로 한국에서 이런저런 문의를 해오시는 분들이 상당히 많으십니다. 현직 게임개발자분들도 계시고 게임개발자 지망생분들도 계시지요. 저도 답변해드리면서 배우는 점도 많고 새로 깨닫는 것도 많아서 여태까지 모든 분께 열심히 답을 해드렸습니다만... 


하지만 가끔 당혹스러운 질문이....

사실 가끔 너무나 광범위한 질문을 해오시는 분들에게는 답을 해드리기가 참 어렵습니다. 보통 현직 개발자분들 보다는 지망생 분들이 좀 이런 경항이 강하지요. 예를 들어..


"게임개발자가 되는게 제 인생의 꿈입니다. 어떻게 해야 게임개발자가 될 수 있죠?"


이런 질문을 볼 때마다 솔직히 당혹스럽습니다. 제가 영미권에서도 학생들의 질문도 많이 받는 편인데 이런 질문을 해오는 사람들이 거의 없었거든요. 그래서 첨엔 정말 많이 당혹스러웠죠. (물론 아직도 많이 당혹스럽습니다.) 뭐든간에 이렇게 질문이 시작되면보통 8~90프로는 다음과 같이 마무리 됩니다.


포프: "게임을 만들어는 보셨어요?"

지망생: "아뇨. 아직 만드는 법을 안배웠어요. 아직 대학을 안가서요.(아니면 그와 유사한 이유들...)"

포프: "학교에서 배운다고 게임개발자 되는거 아니에요. 일단 게임부터 만드세요. (그리고 이런저런 리소스들을 알려준다)"


현직 개발자분이시라면 다들 한번 쯤은 지망생들과 이런 대화를 해보셨을거고, 그리고 실력이 너무나 출중하신 많은 분들이 더 이상 이런 질문에 답변을 해주지 않으십니다. 왜 그럴까요? 이런 질문 하시는 분들 중의 상당히 대다수가 결국 게임개발자가 안되고 현직 개발자 분들은 이런 분들의 개인비서가 되서 게임제작 자료나 찾아주는 일을 해주는데 질렸기 때문이지요. 한마디로 더이상 이용당하고 싶지 않으신 겁니다.


게임개발자가 되려면 게임을 만드세요

저도 한 때 게임개발자가 되고 싶어하던 어린이었던 때가 있고, 잠시 게임개발하다가 법대생이 되서 외도한뒤에 다시 게임계로 돌아오려고 나름 고생한 놈으로써 제 경험담을 말하자면.....

제가 "난 게임을 만들꺼야"라고 꿈을 꾸고 살던 때에 만났던 친구들이 꽤 있습니다. 저랑 비슷한 꿈을 가진 친구들이었지요. 하지만 정작 말만하고 이런저런 핑계 실제 허접한 거 하나라도 만들지 않은 친구들, 또는 그냥 관련학과만 가서 졸업한 친구들 중에 게임개발자 된 친구들이 없습니다. 다들 게임을 만드는게 인생의 꿈이라고 했던 친구들인데.... 네... 없습니다.

이건 사실 매우 당연한 이친데 왜 이해를 못하시는 분들이 있으신지 모르겠습니다. 소설가가 되는게 인생의 꿈인데 어릴 때부터 글을 한번도 안써본 학생이 있을까요? 단 남의 소설은 많이 읽었지요. 춤추고 노래하는 가수가 되고 싶은데 어릴 때부터 춤 안추고 노래 안해본 학생이 있을까요? 물론 TV에서 가수들 노래하고 춤추는건 많이 봤지요. 야구선수가 되고 싶은데 어릴 때부터 한번도 농구를 안해본 학생이 있을까요? 물론 프로 야구선수들이 경기하는건 많이 봤지요.

이쯤되면 대충 제가 하려는 말이 무엇인지 아실겁니다. 정말 게임을 만드는 게 인생의 꿈이고 정말 이걸 안하면 죽는다고 믿고 계신데 아직 만들어본 게임(또는 그와 유사한게) 없다면 한 95프로는 그냥 세뇌당하셨거나 자기최면 거신겁니다. (물론 정말 사정이 있어서 못하신 분들이 한 5프로 있다고 해드리지요. 근데 다들 본인이 5프로 안에 든다고 우기시면.... 못써요.....) 뭐가되었든 간에 전 이런 분들에게도 답변을 최대한 한다고 해왔는데 사실 마음이 무거웠습니다.

"이렇게 이렇게.. 게임을 우선 만들어보세요.(또는 그림을 그려보세요. 또는 게임 아이디어를 정리해보세요 등등)" 

라고 제가 드리는 답변은 말은 사실...

"그렇게라도 안하시면 가망성이 좀 많이 없어보여요."

라는 뜻이거든요. 물론 제 판단도 가끔 틀립니다. 틀릴땐 틀렸다고 인정도 하고요. 근데 거의 십중팔구는 제 판단이 맞습니다. 

위에서 영미권 학생들로부터도 질문을 많이 받는다고 말씀을 드렸었습니다. 근데 한가지 다른 점은 영미권 학생들의 질문이 매우 구체적이라는 겁니다. 보통 자기 스스로 뭔가 만들어보려고 깨작여봤고 거기서 막히는 것들에 대한 질문.. 혹은 더 나은 방법이 없는지 조언을 구하는 질문 등이 대부분입니다. (물론 게임업계의 근무여건이 대해 묻는 사람들도 있긴 합니다.) 이런 질문에 대답을 할 때는 정말 그 학생에게 뭔가 큰 힘이 되는거 같아 제 마음도 뿌듯합니다. 한국분들 중에도 이렇게 뿌듯한 질문을 해오시는 분들이 있는데 안그런 분들이 좀 너무 많습니다. 현재론....

게임개발자 지망생님들... 질문하시려면요...

언제나 그렇듯이 또 주저리 주저리 말만 많이 썼습니다. 제가 사실 하고픈 말은 이겁니다.

  1. 전 아직도 게임개발자가 될 꿈을 꾸시는 분들에게 힘이 되고 싶습니다.

  2. 그리고 저도 이런 분들하고 대화하면서 얻는 게 많습니다.하지만 꿈만 꾸시는 분들에게 일일이 답해드리느라, 정말 뭔가 열심히 하시는 분들에게 소홀해지는 게 아쉽습니다.

  3. 따라서 앞으로는 직접 만드신 게임(또는 유사한것.. 예: 그림, 프로그래밍, 게임 아이디어 등등)을 먼저 보여주시지 않는한 진로에 관한 질문에는 답변을 드리지 않겠습니다.

  4. 그리고 혹시나 해서 하는 말인데.... 어떻게든 제 허접한 답변 받아보시겠다고... 남의 작품을 훔쳐서 본인이 만든 것인척 하시는 분들이 계시면 게임업계에 이름을 널리 퍼뜨려 드리겠습니다.

  5. 그리고 질문하시기전에 충분히 리서치(구글에서라도)도 해보시기 바랍니다. 구글에서 쉽게 나오는 질문에도 답변 해드리지 않겠습니다.

  6. 이렇게 하면 질문자 분들께서도 알아서 포트폴리오를 만드는 겪이 되니 본인 인생에도 도움이 되는 거라고 믿습니다.

마지막으로 한마디

제가 한 악담(?)이 틀렸다는걸 보여주기 위해 이 악물고 열심히 해서 멋진 게임개발자 되신 분들이 있다면 디스 쏴주세요. 진심으로 축하해 드리겠습니다.


p.s. 사실 요번엔 게개포 연재 거를려고 했는데 게임개발자지망생 진우님이 글 쓸 거리를 주셨습니다. 감사합니다. 올해 대학들어가신 새내기인데 학교에서 가르쳐 주지도 않는 C/C++을 독학하며 나름 간단한 게임부터 만들어보고 있으십니다. 이런 자세 본받으시길 바랍니다.



반응형
,
Posted by 알 수 없는 사용자

시작하기 전에 - 이 글은 유저가 3ds Max를 사용한다고 가정합니다.

3D 작업자가 사용하는 뷰포트(Viewport)의 종류는 여러 가지가 있는데. Front, Left, Right, Top, Bottom, Back, Orthographic(구 User), Perspective 등입니다. 이 중에서 Perspective 시점과 Orthographic 시점은 비슷하면서도 많은 차이가 있는데 의외로 Perspective 시점을 주력으로 사용하는 3D 작업자가 많지 않은 것 같습니다.

먼저 두 시점이 어떻게 달라보이는지 살펴보죠.

둘 다 입체로 보이긴 하지만 Orthographic 시점은 아주 먼 곳에서 망원렌즈로 보는 듯한 느낌이고 Perspective 시점은 적당한 화각을 가진 렌즈로 가까이서 살펴본 느낌입니다. 어느 쪽이 더 현실적인가 하면 당연히 Perspective 시점입니다.

Perspective 시점은 모델러나 애니메이터에게 좀더 현실적인 화면을 보여주기때문에 작업하는 내내 정확한 공간 감각을 유지하도록 해줍니다. 정확한 공간 감각을 유지한다는 것은 생각보다 큰 효과를 만들어내는데요, 폴리곤을 수정할 때 좀더 빠르고 정확한 수정이 가능해지며 애니메이션 자세를 만들 때에도 더 적은 수의 클릭으로 원하는 자세를 만들 수 있게 됩니다.

별거 아닌 차이같은데 뭐가 그리 대단하게 좋아진다는건지 이해가 안되는 분이 많을거라고 생각됩니다. 하지만 직접 겪어봐야 알게되는 부분이라서 객관적인 설명을 하기가 참 어렵네요.

만약에 여러분이 '한 번 해보지 뭐' 하는 생각으로 Perspective 시점을 사용해보면 자주 사용하던 Orthographic 시점에 비해서 모든 것이 다 불편하다는 느낌을 받게 될 것입니다. Perspective 시점을 사용하기 위해서는 몇 가지 익숙해져야 하는 사항들이 있고 어떻게 해도 개선되지 않는 점도 있습니다. 이 것들에 대해서는 뒤에 다시 설명하겠지만 아무튼 Perspective 시점에서 모델링이나 애니메이션을 처음 시도하는 분들은 다음 그림의 '일시적인 효율 저하' 상황에 빠지게 될 것입니다.

이 글에서 최종적으로 말하고자 하는 핵심은 Perspective 시점을 사용할 때 생기는 '일시적인 효율 저하'를 극복하고 조금 더 노력한다면 더 효율적으로 작업할 수 있다는 것입니다.

그렇다면 Perspective 시점은 도데체 뭐가 불편하길레 효율 저하가 발생하거나 사람들이 작업시에 기피하는 시점이 된 것일까요.

첫 번째로, 작업을 하다 보면 마우스 휠로 줌(Zoom) 기능이 잘 안되는 현상이 종종 발생됩니다. 줌이 너무 큰 단위로 되거나 너무 작은 단위로 되면서 원하는 시점으로 볼 수 없는 상황이 되는데요.

이럴 때에는 다음 그림에서처럼 Zoom Extents Selected 기능을 사용해서 현재 선택된 오브젝트 혹은 현재 선택된 폴리곤에 맞게 시점을 초기화 해줌으로써 해결됩니다.

참고로 Zoom Extents 버튼이 아니라 Zoom Extents Selected 인 점을 조심해야합니다. 커다란 오브젝트의 폴리곤 일부를 작업할 때에 Zoom Extents Selected를 꼭 사용해야 합니다. 개인적으로는 이 기능을 단축키로 등록해줌으로써 불편함을 최소화 했습니다.

두 번째 불편한 점은, Orthographic 시점과 번갈아가면서 작업할 경우 Perspective 시점에서 FOV가 이상하게 변경되는 현상이 생긴다는 점입니다. Orthographic 시점에서 마우스 휠로 줌(Zoom)을 해주면 경우에 따라서 Perspective 시점의 FOV 설정이 변경되기도 합니다.

이런 현상이 발생하면 Viewport Configuragion에서 Perspective User View의 FOV 값을 다시 조정해줘야 합니다.

이런 불편함은 Orthographic 시점을 혼용해서 사용하면서 발생하게 되는데, 필자의 경우에는 Perspective 시점에 익숙해진 뒤에는 Orthographic 시점을 거의 사용하지 않게 되면서 자연스럽게 해결된 문제입니다.

필자가 집필한 '캐릭터 셋업 테크닉'의 동영상 강좌를 보신 분들은 알겠지만 작업 중에 80% 이상을 풀스크린 상태의 Perspective 시점에서 작업을 합니다. 나머지 20% 역시 Front, Left, Right, Top 등의 시점이지 Orthographic 시점을 사용하는 비율은 1%도 안될 것 같습니다.

세 번째로 불편한 점은, Editable Poly의 Insert Vertex 기능이나 Cut 기능을 사용할 때 발생합니다. 엣지의 원화는 위치에 버택스를 생성시킨다거나 할 때에 Perspective 시점에서는 마우스를 클릭한 위치와 실제로 버택스가 생성되는 위치가 미묘하게 다른 오차가 생깁니다. 경우에 따라서는 전혀 엉뚱한 곳에서 버택스가 생성되기도 합니다. 이런 작업에서는 Orthographic 시점을 사용해야만 오차 없이 작업할 수 있습니다.

하지만 폴리곤의 중간을 분할해줘야 하는 거의 대부분의 경우 다소 정확도가 떨어지더라도 크게 문제되지 않는 작업이고 굳이 정확한 작업을 해야겠다면 잠깐 Orthographic 시점을 사용하거나 3D 스냅(Snap) 기능을 활용해서 정확도를 높이기도 합니다.

이처럼 Perspective 시점을 사용하면서 발생하는 불편함은 보완하거나 피해갈 방법들이 있어서 시간이 지나면 얼마든지 익숙해질 수 있는 부분입니다.

그럼에도 불구하고 커다란 씬을 작업해야하는 배경 작업자들에게는 Perspective 시점을 권하고 있진 않는데요, 아무래도 규모가 큰 장면에서는 Orthographic 시점이 더 효과적이라는 느낌입니다. 하지만 필자는 이미 Perspective 시점에 적응해버려서 배경 씬을 살펴볼 때에도 꿋꿋이 Perspective 시점을 고수하고 있긴 합니다. ^^


여기까지의 내용을 종합해서 요약해보면~

  • Perspective 시점은 현실적인 화면을 보여줌으로써 작업자가 효율적으로 공간을 인지하도록 해준다
  • 정확한 공간 지각을 통해 모델링과 애니메이션 작업에서 더 빠르고 효과적인 작업이 가능해진다
  • Perspective 시점은 익숙해지는데 시간이 걸리는 몇 가지 장애 요소들이 있다.
  • 대규모 배경 작업에서는 Perspective 시점이 비효율적일 수 있다.

입니다.



(본문 외 내용~ ^^)

원래 29일에 글을 올렸어야 했는데 이틀 연속 회식 후 떡실신모드여서 날짜를 어기게 되었네요. 이번 달도 제낄까 하다가 늦더라도 글 하나 올립니다.

그나저나 쓸 내용이 고갈되어버렸는데 다음 달에는 어떻게 하나요 T_T


반응형
,
Posted by 알 수 없는 사용자

1편에서 게임 QA에 대해 자세하진 않지만 어떤 일들을 하는 것인지 수박 겉핥기 식으로 확인해 보았습니다.

 

이번에 할 얘기는 많은 게임 QA에 종사하는 분들이 고민할 수 있는 혹은 이미 고민하고 있는 문제입니다.

“게임 QA가 제작 중인 게임의 게임성에 관여해야 하는가?”

잠시 옛날이야기로 돌아가 보겠습니다.

최초로 컴퓨터가 만들어지고 소프트웨어가 만들어졌을 때 그 녀석의 탄생 목적은 하나였습니다.
그건 바로 미사일의 궤도 계산이었습니다.

어떻게 해야 가열차게 저 녹색 돼지 잔당을 몰살시킬 수 있는가?

그 뒤로 컴퓨터와 SW는 누군가의 혹은 어떤 조직의 필요성에 의해 발전해왔습니다. 정말 엄청난 발전을 했죠.

HAL이 정말 손아귀 안에 들어왔습니다.

그런데 이런 누군가의 필요성에 의해 만들어져 나간 컴퓨터와 SW의 역사에 게임은 매우 다른 방향에서 튀어나왔습니다.

흔히 최초의 컴퓨터 게임이라고 알려진 퐁 보다도 이전에 만들어진 오실로스코프로 만들어진 게임 Tennis for two입니다. 만든 이유가 박물관에 오는 손님들이 지루해하길래 지루함을 달래기 위해 만들었다고 합니다. 누군가의 요청이나 필요함에 대한 언급 없이 개발자 스스로 만들어 냈습니다. 더군다나 목적이 여흥을 위해서입니다.

게임은 창의력에서 발전해 왔다. 저는 이것이 게임 SW의 핵심이라고 생각합니다. 고객 혹은 Client의 요구가 정의되어 있지 않고 제작자의 의도가 우선하여 반영되기 때문에 게임은 IT 산업 중 예술에 가까운 산업이 되었다고 생각합니다.

한편 SW가 발전하면서 같은 요구목적을 가진 프로그램이더라도 품질에 차이가 나타나기 시작했습니다. 사람이 기획하고 사람이 만들어낸 코드에서 실행되는 것이니 어쩔 수 없는 일이었겠지요. 하지만 초기엔 이게 잘 만들어진 것인지 못 만들어진 것인지 판단하기도 어려웠습니다.

그래서 사람들은 SW의 품질 평가를 할 수 있는 모델을 만들자고 생각했습니다.

그래서 나온 것이 ISO 9126 입니다. 실은 이런 연구가 몇 가지 더 있는데 그중에서 유명한 게 ISO 9126입니다. 그리고 국제 표준화 기구에서 심사 단계의 최종에 다다른 모양입니다.

어쨌든 ISO 9126에서 다루는 SW의 품질 모델은 다음과 같습니다.

 
주특성
주특성 내용
부특성
품질 특성
기능성
소프트웨어가 특정 조건에서 사용될 때명시된 요구와 내재된 요구를 만족하는 기능을 만족하는 기능을 제공하는 소프트웨어 제품의 능력
적절성
적밀성
상호 운용성
준수성
보안성
신뢰성
소프트웨어가 규정된 조건에서 사용될 때 규정된 성능수준을 유지하거나 사용자로 하여금 오류를 방지할 수 있도록 하는 소프트웨어 제품의 능력
성숙성
결함허용성
회복성
유용성
사용성
소프트웨어가 규정된 조건에서 사용될 때사용자에 의해 이해되고학습되며 선호될 수 있게 하는 소프트웨어 제품의 능력
이해성
학습성
운용성
효율성
규정된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력
시간행동
자원이용
유지보수성
소프트웨어 제품을 변경할 수 잇는 능력변경에는 운영환경과 요구사항 및 기능적 사양에 따름 소프트웨어의 수정개선혹은 개작 등이 포함된다.
분석성
변경성
안정성
시험성
이식성
다양한 환경에서 운영될 수 있는 소프트웨어 제품의 능력
적응성
설치성
병행 존재성
적합성
대체성

[출처] ISO9126 품질속성|작성자 인생은쇼

 

QA는 위와 같은 품질모델에 맞게 SW가 제작되었다는 것을 증명하기 위해 테스트를 하는 것입니다.

SW가 품질모델을 준수하여 만들어졌다면 정말 잘 만든 것이라고 볼 수 있을 것입니다. 좋은 프로그램은 팔리기도 잘 팔리겠죠.

하지만 게임은요? 위의 품질모델을 준수하여 만들었다고 게임이 흥행하지는 못합니다.

왜일까요? 묻는 것조차 쑥스러울 정도입니다. 게임 SW의 품질이 좋을지언정 위의 모델이 게임성(재미)을 보장하지는 않거든요.

일반 SW는 고객의 요구가 중시 됩니다.

ATM 소프트웨어는 은행의 요구가 수술기기 혹은 병 진단기는 병원(의사)의 요구 그리고 회계 프로그램은 회계사의 요구가 중시 됩니다. 사용자의 요구가 중요시되는 것이 당연합니다.

게임 SW는 누가 고객인가요?

과거에는 프로그래머가 자신이 기획도 하고 제작도 하고 했습니다. 하지만 현대의 게임을 설계하는 것은 거진 기획자들입니다. 기획자들의 요구가 프로그래머에게 전달되어 구현됩니다. 그런데 그 기획자들이 하려고 게임을 만드는 것은 아닙니다. 기획자는 자신들이 생각한 이용자들이 어떻게 하면 재미있을지 만족할 수 있을지를 생각하여 게임을 설계합니다. 그렇다면 이용자들이 고객인가요?

그런데 게임의 이용자들은 게임이 자신에게 전달되기 전까지는 요구사항을 전달하지 않습니다. 패키지 게임은 물론이거니와 온라인 게임도 CBT를 하기 전까지 제작자들은 이용자의 요구사항을 알기 어렵습니다.

더구나 요구사항을 안다고 하더라도 모든 것을 수용할 수는 없습니다. 게임은 그 고유의 게임성을 유지해야 하는데 이용자들의 요청사항 중에는 고유의 게임성을 벗어나는 요청도 있거든요.

SW는 쓰기 쉽고 이해하기 쉬우며(UI와 UX가 좋아야 하며) 버그가 없으면 좋은 소프트웨어라고 할 수 있습니다.

게임은 쓰기 쉽고 이해하기 쉬운 것도 중요하지만, 재미 혹은 게임성을 갖추고 있어야 좋은 게임이라고 할 수 있습니다.

계속 다른 얘기를 늘어놓은 것 같지만 모두 한가지 화두를 위해 얘기했습니다.

게임 QA는 게임성에 관여해야 하는가?

QA는 품질을 관리하며 이용자들에게 만족감을 줄 수 있다는 보증을 해야 하는 파트입니다.

그렇다면 게임 QA는 게임성과 재미가 있어야만 이용자들에게 만족감을 줄 수 있다는 보증을 할 수 있을 것입니다.

그런데 안타깝게도 재미라는 것은 주관이 개입되기 쉬운 요소입니다.

세계에서 제일 잘 팔렸다는 슈퍼마리오라는 게임도 어떤 성향의 이용자들에게는 재미없는 게임 일 수 있는 것입니다.

으아아아아아아아아아아아악!!!!!!!!!

저는 게임성도 게임 품질의 한 요소지만 게임 QA가 무작정 관여해서는 안 된다고 생각합니다.

2가지의 경우를 예로 들어서 설명해 드리겠습니다.

A. 포스터 와우를 만들고 싶어하는 개발팀의 QA

- 다행히도 게임의 컨셉이 명확합니다. 최대한 WOW의 게임성을 가져오고 싶어합니다.

- WOW 경험이 많은 QA팀의 당신은 QA를 하던 중 자사 게임이 어떤 요소가 WOW와 맞지 않는 성향을 가지고 있는 것을 느낍니다.

- WOW의 해당 요소를 열심히 벤치마킹해 자사 게임과 비교 리뷰를 작성해 건의 합니다.

- 포스트 와우를 만드는 게 목적이기 때문에 당신의 리뷰는 정당한 평가를 받을 수 있을 것 같습니다. (아직까진 QA팀의 게임성 건의는 많은 시련을 겪어야 힘들게 받아들여진다는 걸 기억하세요.)

B. 차세대 MMORPG를 만들고 싶어하는 개발팀의 QA

- 차세대인 만큼 새로운 게임컨셉을 가지고 있습니다. 이때까지 어떤 MMORPG에도 없던 독창성을 가지고 있습니다.

- WOW 경험이 많은 QA팀의 당신은 QA를 하던 중 자사 게임의 어떤 요소가 WOW를 벤치마킹하여 만들면 더 재미있을 텐데 라는 생각을 하게 됩니다.

- 당신은 열심히 WOW의 해당 요소와 자사 게임의 비교 리뷰를 작성하여 건의 합니다.

- 기획자는 우리 게임은 WOW와 다른 게임성을 가지고 있기 때문에 건의 사항과 같이 튜닝하면 다른 요소들을 모두 변경해야 하며 그러면 초기 컨셉과 다른 게임이 된다는 얘기를 합니다.

 

 A와 B의 차이를 아시겠나요? 가장 큰 차이는 초기컨셉의 이해입니다. A는 QA팀이 이미 자사 게임이 WOW의 많은 부분을 따르려 한다는 것을 알고 있습니다. B는 물론 내부적인 초기컨셉이 있었겠지요. 그러나 자신이 생각한 재미요소를 건의했고 해당 내용이 WOW를 따르지 않는 새로운 게임성을 만든다는 점에서 배제된 것입니다.


위에서 계속 게임성(재미)에 관한 이야기를 언급했습니다만 게임성의 품질은 보증하기가 어려운 업무입니다.

왜냐면 그건 창의적인 작업이니까요. 이를테면 이런 겁니다.

화가에게 “제가 앤디 워홀 작품을 봤는데요. 그걸 그렇게 그리면 안 돼요. 앤디 워홀 그림 비싸게 팔리시는거 알죠? 이렇게 작업하셔야 잘 팔려요.”

혹은

박진영에게 “아니 저렇게 볼 빵빵한 애하고 아줌마 같은 애를 걸그룹에 넣어두고 성공하겠다고!? 소녀시대를 봐봐! 다들 이쁘고 귀엽고 다리도 좍 빠졌잖아. 그런 애들을 넣어야지!!” (절대 전 원더걸스 안티는 아닙니다!!)

하는 겁니다.

앤디 워홀을 모작 중인 작가에게는 위와 같은 소리 해도 됩니다. 소녀시대 같은 걸그룹을 가지고 싶어하는 박진영에게도 위와 같은 소리 해도 됩니다.

하지만 그들이 원하는 건 그것이 아니기 때문에 안되는 것입니다.

그런데 위에 예로 써드린 A, B외의 정말 이도 저도 아닌 게임을 제작 중인 스튜디오에서 일할 수도 있습니다.

이건 분명 건의해야 한다! 그래서 고쳐야 한다!

 

그런 분들은 
http://wp.me/p1VNqt-X  글을 참고 해보시면 어떨까요?
마지막으로 3줄 요약해보도록 하겠습니다.

1. QA는 품질보증을 해야 하는 업무이기 때문에 게임성에 대해서도 시장성이 있는지 보증을 해야 한다.

2. 하지만 게임성은 게임 SW가 SW에는 없는 고유의 특성이며 제작자의 창조적인 작업이므로 무작정적인 게임성 건의는 옮지 않다.

3. 될 수 있으면 초기 컨셉 및 리뷰하고자 하는 대상의 컨셉을 이해하고 의견을 전달할 수 있도록 하자.


반응형
,