목차
- 서론
- 왜 노말맵을 쓰는가?
- 노말맵의 역사(?) : 범프맵과 디스플레이스먼트 맵, 그리고 노말맵
- 여담: 애니메이션으로 메쉬와 머터리얼을 컨트롤하면 되지 않나요
서론
게임개발에 대한 개념과 유니티를 공부하면서, 텍스쳐를 배울 땐 특히 의문 투성이었습니다. 왜 노말맵이라는 개념을 쓰는지, 머터리얼을 다루기 위한 요소가 뭐 이리 많은지, 또 쉐이더는 뭐 이리 복잡한지.. 다시 그때로 돌아간다면 기초적인 배경을 알고 공부했더라면 조금 더 뇌리에 박히게 공부할 수 있었지 않나 싶습니다. 그래서 혹시나 제가 가졌던 몇 가지 의문에 대한 이야기를 풀어보려고 합니다.
왜 노말맵을 쓰는가?
이 질문은 정말 말 그대로입니다. 유니티의 머터리얼을 다루시다 보면 노말맵이라는 개념을 보시게 될 텐데, 왜 굳이 노말맵을 쓰는지가 너무나 궁금하지않으신가요? 지브러시나 여러 DCC를 써봤던 저 입장에서는, 메쉬를 수정해서 디테일을 표현하면 될 텐데 굳이 표면에다가 작업을 하고 디테일을 표현한다는 것이 좀 와닿지가 않았습니다. 즉 불필요한 과정이 하나 추가되었다는 생각을 한 것이지요.
이 의문에 대해부연설명하기 앞서, 결론부터 말하자면 노말맵을 쓰는 이유는 최적화 때문입니다. 물론 노말맵을 사용해서 얻는 여러 가지 장점이야 더 있습니다. 유연성이라던가, 시각적 품질 향상이라던가.. 이것저것 있겠지만 제일 중요한 장점과 배경 또한 최적화라는 단어로 정리할 수 있습니다.
최적화랑 무슨 관련이 있지? 싶은 분들을 위해 예시를 하나 준비했습니다. 도넛모양을 하나 만들고, 표면에 거친 질감을 넣고 싶다고 예시를 들어보겠습니다. 유니티에서 직접적으로 모델링을 하는 일이 많지는 않기에, 마야를 예시로 들어보겠습니다. 아래처럼 이런 도넛모양이 하나 있다고 할게요.
자 이제 여기서 누군가가 여러분에게, "진짜 도넛처럼 보이게, 표면에 빵 같은 질감 좀 넣어주세요"라고 했다고 가정합니다.
그래서 한분은 노말맵으로 작업했고, 한 분은 메쉬를 컨트롤해서 작업했습니다.
예시를 위해 좀 억지스럽게 작업하긴 했으나.. 쩄든, 왼쪽에 있는 것 (좌표계가 있고, 메쉬개수가 엄청 많은 것)이 메쉬를 직접적으로 컨트롤해서 만든 결과물이고, 오른쪽은 메쉬작업 후, 범프맵에다가 질감을 그림 그리듯 그린 것입니다. (마야는 노말맵과 비슷한 개념으로 노말맵 대신 범프맵을 기본적으로 지원합니다. 플러그인을 통해 바로 노말맵으로 그릴 수 있기는 하나.. 일반적인지는 잘 모르겠습니다.)
어쨌든 이렇게 도넛질감을 부탁하신 분이 두 가지 도넛 모두 맘에 들었다고 합시다. 근데 최적화 입장에서 차이가 느껴지시나요? 왼쪽의 빵은 표면작업을 하기 위해 메쉬를 추가했고, 추가한 곳에다가 스컬핑작업을(조각작업)을 한 것입니다. 메쉬수가 적으면 울퉁불퉁하면서도 부드러운 질감표현이 어렵기 때문에 메쉬를 부득이하게 추가하게 됩니다.
하지만 반면, 오른쪽 메쉬는 어떤가요? 처음 만들었을 때 도넛모양 메쉬 이외에 추가한 게 없습니다. 당연하게도 메쉬가 많으면 렌더링 할 때 성능에 좋은 영향을 끼칠 수 없겠죠. 이게 바로 노말맵 즉 표면의 질감을 나타내는 것의 장점이자 핵심이라고 할 수 있습니다.
다시 말해서, 메쉬는 성능 때문에 추가하기는 싫지만, 디테일은 표현하고은경우 노말맵을 씁니다.
그리고 메쉬를 추가하지않아도 노말맵, 즉 맵의 픽셀단위까지 디테일을 표현할 수 있는 퀄리티가 생기게 됩니다. 물론 조각하듯이 높낮이가 큰 부분을 노말맵으로 다 묘사하는 건 사실상 어렵긴합니다.
- 노말맵의 역사(?) : 범프맵과 디스플레이스먼트 맵, 그리고 노말맵
노말맵의 아버지는 범프맵이라고 할 수 있습니다. 게임그래픽에 있어서 적은 비용으로 고품질의 작업물을 원하는 건 어느 때나 있던 고민일 것입니다. 이에 1970년부터 범프맵이 사용되기 시작했습니다. 참고로 이 범프맵을 최초로 논문으로 작성하신 분은 블린퐁 머터리얼로 유명한 Jim Blin이라는 사람입니다. (이분 위키피디아 링크입니다: 블린퐁이랑 퐁 차이도 재밌으니 봐보세요)
이렇게 범프맵이 탄생하고, 점점 고도화되면서 나타난 것들이 디스플레이스먼트 맵과 노말맵입니다. 유니티에서도 노말맵이 쓰이고 있습니다. 그리고 마야나 맥스에서 쓰이는 디스플레이스먼트맵도, 맥락은 살짝 다르지 유니티에서 하이트맵(Height Map)으로 비슷하게 사용되고 있습니다. 참고로 맥락이 다르다는 것은, 디스플레이스먼트 맵은 실제로 버텍스를 이동시키는 역할을 하지만 하이트맵은 지형에 관한 높낮이 정보입니다. 물론 이 정보로 지형의 높낮이를 컨트롤하기에 개념이 매우 유사한 건 맞습니다.
- 여담: 애니메이션으로 메쉬와 머터리얼을 컨트롤하면 되지 않나요
이건 좀 다른 분들이 듣기에 황당한 질문일 수 도 있고, 노말맵이랑 뭔 상관인가 싶으실 겁니다. 그냥 여담 같은 거라 위에 내용이 잘 이해 가셨다면 그냥 건너뛰셔도 될 것 같습니다.
쉐이더를 공부하면서 노말맵을 게임 환경에 맞게 실시간으로 바꾸면서 연출을 하는 걸 보았습니다. 이때 제가 가졌던 의문인데요, 질문은 이겁니다: "캐릭터 애니메이션처럼 각종 머터리얼이나 그래픽이 상호작용하는 것도, 애니메이션으로 가져다 쓰면 되는 게 아닌가? 왜 굳이 머리 아프게 쉐이더 작성해서 논리적으로 처리해야 하지?"라는 의문이 들었습니다.
이것도 사실 이미 대부분 아시겠지만 결론은 단순합니다. 두 가지 방식이 사실상 목적이 다릅니다. 특히나 게임에서요.
예를 들어 애니메이션으로만 대처하는 상황을 생각해 보시면 좀 더 이해가 가실 겁니다.
"게임에서 유저가 마우스를 클릭하는 빈도에 따라서 불꽃의 세기가 바뀌고, 불꽃의 세기에 따라서 옆에 있는 환경과 주인공이 받는 광량이 달라지는 애니메이션을 만들고 싶다고" 가정합시다.
간단해 보일진 모르지만, 이런 변수끼리 상호작용하는 경우의 수는 엄청나게 많을뿐더러, 제일중요한 건 유저가 주는 모든 인풋에 대해서 설계한다는 건 만만치 않은 일입니다. 즉 애니메이션은 미리 정의가 가능한 패턴을 토대로 설계하는 부분인데, 이러한 경우의 수를 모조리 설계한다는 건 사실상 불가능하고, 한다고 하더라도 쉐이더를 쓰는 것만큼의 효율이 날 수는 없습니다.
즉 쉐이더는 변수와 상호작용을 어느 정도 수학적이고 논리적으로 표현한 '알고리즘'적인 방식인데 비해, 애니메이션은 '이미 정의된 요소를 설계하고 재현' 하는 역할에 충실한 것이죠. 즉 결과물만 봤을 땐 몰랐지만, 너무나 당연하게도 쉐이더를 사용해서 메쉬나 머터리얼을 동적으로 컨트롤하는 것과, 애니메이션을 쓰는 것은 목적 자체가 너무나 달랐던 것입니다.