TAD는 사실, 좀 애매한 직종이다. 이것도 하고 저것도 하는 직종이라…
원래 TAD라면, 어떤 효과나 어떤 분위기를 어떤 기술로 내는 것이 가장 효율적이다 … 그러므로 우리 프로젝트에서는 어느어느 기술을 사용하겠다…. 라고 정하고, 테스트 하는 것이 임무이다. 물론 그거에 한정되지 않고, 프로그램쪽 입장도 듣고 그래픽쪽 입장도 들어서 문제가 생겼을 때 서로 어느 부분이 양보할 것인가, 혹은 어느 기술로 돌려서 타협할 것인가를 결정해 주기도 한다.
또 자주 일어나는 소소한 일 중 하나가 그래픽적인 입장과 프로그램 적 입장에서의 ‘통역’ 의 임무인데 …
그런 에피소드 중 하나가 갑자기 생겨서 적어 놓는다.
염색 기능을 프로그래머와 협의해서 만들어 놓았는데, 그걸 적용시킬 타이밍이 되었다.
A 기획자가 그 기술에 대해 물어보러 왔다.
일단 염색 기능의 기술적 기반은 텍스쳐 한 장의 각각의 8비트 채널에서 그 값을 받아와서 지정된 RGB와 텍스쳐의 RGB를 곱해주는 방식인데,
기획자: 염색은 몇 개 쓸 수 있죠?
프로그램: 3개 쓸 수 있죠. 채널당 쓰면 되니까요
기획자: 색을 3가지 밖에 못쓴다고요? 그럼 너무 제약이 심하네요..
프로그램: 네? 3가지면 되잖아요?
여기서 이미지의 단절 발생. 중간에서 통역 필요
- 프로그램 : 한 갑옷에 3가지 색을 염색하면 많지 않냐
- 기획 : 쓸 수 있는 색이 단지 빨강 파랑 노랑처럼 3가지 뿐이라는 거냐
TA: 아니아니 그런 얘기가 아니고, ‘동시에’ 3가지를 쓸 수 있단 말이예요. 실제로는 24비트의 RGB를 쓰니까 색은 무한이라고 봐도 되지요. 중요한건 한 텍스쳐 안에 몇 가지의 색을 쓸 수 있냐는 것인데요. 최대 3개지만, 3개 다 쓰는건 허락하지 않겠어요. 분명 그 조합이 두 개만 되어도 기획자들 차원에서는 매우 귀찮은 고려사항이 될 거예요
R채널과 G 채널 2개만 쓰세요. 분명히 나중에 그래픽 팀에서 갑옷에 드러난 피부를 제어하고 싶어할 거예요.(ㅎㅎ) 그때를 대비해서 B 채널은 쓰지 않기로 하죠.
기획자: 염색한걸 미리 볼 수는 없나요?
프로그램: 클라이언트를 돌려서 볼 수 있는데요. 원하시면 툴을 만들어야 하는데…그건 좀 힘들어요
기획자 : 그래도 색을 미리 봐야 뭘 정하거나 할 수 있지 않겠어요?
다시 중간에 끼어듬.
- 프로그램: 염색을 미리 보기 위해서는 클라이언트 렌더러를 거쳐서 보는 방법밖에 모름
- 기획자 : 색상 넣고 게임실행해서 보고, 다시 색상 좀 수정하고 다시 실행해서 보는건 너무 힘듬.
TA: 알겠는데 간단한 법을 알려줄께요. 포토샵을 열어서 멀티모드로 한 장 올려서 색을 섞어보세요. RGB 곱셈 맞죠? 그렇다면 기본적으로 포토샵의 멀티와 같게 동작할거예요. 물론 쉐이딩을 거치고 라이팅을 거치면 미묘하게 달라지겠지만 그건 텍스쳐도 마찬가지이므로 무시할 수 있는 수준이 될 거예요. 굳이 이걸로 툴을 만들게는 안할게요. 지금 프로그램 자원을 거기에 집중할 수는 없어요.
기획자: 염색에 오파시티는 먹을 수 있나요?
프로그램: 오파시티요? 아니, 그건 염색과 상관 없잖아요. 이건 색만 바꾸는 거지 알파를 안건드려요
다시 중간에 끼어듬
- 프로그램 : 프로그래머의 오파시티 개념은 알파채널에 의한 진짜 투명도.
- 기획 : 포토샵의 브러쉬 오파시티 개념을 말하고 있다.
TA : 기획자가 말하는 오파시티는 그 얘기가 아니예요. 염색 텍스쳐의 각 채널당 8비트를 쓰죠? 즉 256 단계의 염색 블렌딩이 가능하냐고 물어보는 얘기예요. 알파 채널이 아니라고요. 기획자는 그래픽 디자이너에게 그냥 알파 채널처럼 생각하면 된다고 말해주세요. 즉, 생각하는 오파시티는 분명 ‘먹어요’
업계가 커지고 복잡해질수록 한 분야의 ‘전문가’ 가 많이 필요하다고 하는데,
그것은 당연하고 동의하지만
그만큼 그 ‘중간자’ 의 필요성도 높아지고 있다고 할까.
별 것도 아닌 일로 팀 전체의 커뮤니케이션이 틀어져 버리는 일을 너무 많이 봐왔다.
결국은 서로 다 잘 되자고 하는 소리였는데 말이지.
뭐? 이도저도 아닌 박쥐의 변명이라고?
으,음 - 뭐 그럴지도.