04. 캐릭터와 언리얼 쉐이더의 구조, 그리고 반투명에 대해

01 플레이어 캐릭터의 일반 속성

가장 기본적이고 다양한 형태를 가지고 있다.

 

퀄리티에 가장 중요한 요소는 애니메이션.

언리얼에서는 스켈레톤을 공유하고 매쉬만 변경하는걸 권장하긴 하지만

성별이나 체형이 달라서 어려울 수도 있다.

 

가능하면 많은 것을 공유할 수 있는 대상을 만들거나 그룹을 지워놔야 한다.

남자와 여자는 모션적인 특성이 매우 다르다.

-

 

언리얼에서는 리타게팅이라는 개념을 제공한다.

 

리타게팅은 크게 두가지 형태가 있는데

 

스켈레톤을 완전히 공유하는 것 특정 모션(칼을 든 캐릭터, 활을 든 캐릭터)이 사용하도록 하거나

스켈레톤에 귀속된 애니메이션들을 다른 스켈레톤에서 사용할 수 있도록 형태를 복사해주는 것이 있다.

 

일반적으로 언리얼 도큐먼트를 찾으면 후자가 나을것인데

보통의 게임개발에서는 큰 도움이 되진 않는다.

(여러가지 형태를 가질 때 말이다)

 

리타게팅된 애니메이션들은 고유한 새로운 애니메이션이 된다.

(스태틱데이터로 완전히 분리가 된다)

 

동일한 모션을 편집하더라도 기존의 원본에 데이터를 상속시키기 어렵다.

관리해야할 애니메이션 수량 자체도 늘어나기 때문에 메모리에 올라갈때도 다른 모션으로 인식하고 비용도 늘어난다.

 

-

 

장르에 따라서 방법이 달라지기 때문에 항상 어떤식으로 해야할까 고민을 해야만한다.

 

##

 

쉐이더 제작 측면에서 본다면

캐릭터를 보통은 쪼개지 않는다.

 

분할 포인트가 있을 수는 있는데 (옷을 갈아입거나, 파츠를 교환하는 둥)

렌더링 퍼포먼스 비용이 많이 든다.

 

보통 하나의 매쉬를 그릴 때 한번의 드로우콜이 발생하고 하나의 고유 머터리얼 쉐이더를 그릴 때 또 한번의 드로우 콜이 발생한다.

점점 그림자나 다른 것들을 그릴 때 마다 점점 불어나는데

 

캐릭터가 하나라고 해도 교체가능한 독립적인 오브젝트로 만든다면 아주 많은 비용이 발생한다.

드로우콜은 그렇다고 해도 리소스 갯수가 많아지고 관리해야할 리소스 종류도 많아지기에 효율적으로 관리해야할 방법을 또 만들어야 한다.

 

캐릭터 구조설계라는 것은 이런 여러가지 형태를 보았을때

게임 자체의 대한 이해도를 포함해 아트 리소스에 대한 이해가 없으면 아주 어려울 수 있는 단계다.

 

 

 

 

02 NPC와 몬스터의 일반 속성

나머지들은 경우의 수를 따져보았을 때 플레이어블 캐릭터에 비해 하위호환이다.

변수가 적다라는 부분에서 상대적으로 개발하기 쉬운 편

트리플A 게임에서는 이런 각기 다른 NPC가 다른 형태를 가져야하는 형태를 가져야만 할때도 있는데

제일 많이 해결하는 방법은 커스터마이즈 방법이다.

 

주인공 캐릭터같은 경우는 대체로 규격화된 형태로 만들기 매우 어렵다.

(각자 주인공다운 포인트를 넣어야하기 때문에 그렇다)

 

하지만 NPC나 적을 만들 때에는 아주 훌륭한 방법이라고 할 수 있겠다.

 

캐릭터도 프시시졀 텍스쳐로 표현 할 수 있다는 얘기이다.

 

-

 

NPC인데 주인공 캐릭터처럼 다양한 변수나 움직임이 필요한 상황이 있는데

그런 경우는 그냥 주인공 스켈레톤 데이터를 가져와서 사용하는게 나을 수도 있다.

 

 

 

 

03 보스 몬스터의 일반 속성

보스는 주로 인간형이 아닌 경우가 매우 많다

게임에 따라서 다르지만 보스는 바리에이션의 대상이 아닌 경우가 많다.

 

아주 독립적인 특성을 가진 특수 NPC 혹은 바리에이션이 전혀 없는 플레이어블 캐릭터라고 생각하면 좋다.

보통 이 보스에 따라서 전체 프로젝트 제작난이도 편차가 큰 편이다.

 

 

 

04 머터리얼 제작 관리 개념 배우기

CG 툴 같은 경우는 하나에 다 넣는 형태로 되어있지만

엔진에서는 안쓰는건 빼는 등으로 사용된다.

 

어떠한 쉐이더 모델은 PC에서 적용하기 힘들만큼 무거울 수도 있다 그렇기 때문에 최대한 기술적으로 쉐이더를 만들어야 한다.

결국 엔진 쉐이더는 실물의 BRDF를 흉내내는 것이 때문에 크게 다르지 않다.

 

-

 

언리얼을 이용해 노드를 짜서 쉐이더를 만들면 hlsl으로도 생성이 된다.

노드 쉐이더는 제작이 쉬운 반면에 코드화 시켰을 때 상당히 해독하기 난해하게 생성이된다.

변수화를 많이 시키기 때문에 추상화 시키기가 어렵다.

 

특정 수식을 예를 들었을 때 한줄이면 정리가 되는 것을 노드는 10줄을 이용해서 하는 등 난해해진다.

10줄로 적으면 무거워지는거 아니냐? 싶지만 전혀 그렇지 않다.

 

어차피 우리가 쓰는 노드든 hlsl이든 엔진에서 실제로 사용하는 것은 컴파일 된 것만 사용한다.

이걸 뭐로 제공하든 하드웨어가 알아들을 수 있는 언어로 컴파일하기 때문에 이 부분에 대한 최적화는 신경하지 않아도 된다.

 

그것보단 노드기반에서는 계산 자체가 무거울 수록 문제가 된다.

 

hlsl을 아는 것은 각 수식에 따른 비용을 안다는 뜻이 될 수 있는데

노드로만 만들면 비용을 잘 모를 수도 있다.

 

 

05 실무로 보는 불투명과 투명의 사용

투명은 다른 무엇보다 많은 변수를 낳는 어려운 친구들이다.

 

영상이라면 상관이 없는데 실시간 렌더링에서는 정말 필요한 경우가 아닌 경우는 지양하는 편이고

트리플A 급 게임회사들도 최대한 반투명을 피해가려고 노력하고 있다. (하드웨어가 널널해도 말이다)

 

정렬문제는 커스텀뎁스로 해결이 가능하긴 하지만 완벽하게 해결할 수는 없는 노릇이다.