Flexible character customizing 1

Flexible character customizing

주제 : 케릭터의 유저 커스터마이징 접근론.

비교대상 : Facegen , Poser , sims , Aion

알려진 이슈 

Poser (비게임류-케릭터 생성 어플리케이션) , Sims , Aion 등을 비롯하여 해외 유수의 게임 중 케릭터 커스터마이징의 수준이 체형 , 두상의 디테일 , 연령대 별 , 인종적 특징까지 잡아 내고 있는 게임들의 커스터마이징 시스템 구조의 골조는 FACEGEN 으로 부터 시작되고 있다.

FACEGANE 의 최신 버젼을 살펴 보면 5대륙 별 인종의 특성을 1차적으로 골격 단위 , 2차적으로 피부의 색으로 세분화 하였으며 이후 세부 디테일은 그 버전이 업그레이드 될수록 세분화 되 가고 있다.

현재 최신 버전에서는 노멀맵 표현이 추가 되어 연령대별 표현을 이전 버전보다 더욱 충실히 표현 하고 있다.

예> 노멀맵을 사용하여 주름의 깊이 등을 표현 함으로서 더욱 커스터마이징의 리얼리티에 충실하며 부가적으로 나이에 따른 피부의 윤기는 스팩큘러맵이나 글로스 맵을 사용하여 디테일하게 잡아 내고 있다.

커스터마이징 시스템 설계를 위해 언급 해야 할 대상.

소구적 측면

포지티브적 측면	아바타 개념적 정의에 대한 충실함. 게임 홍보적 이슈 부분수익화적 측면 리소스적 측면(서로 다른 픽스된 얼굴 데이터를 수십개씩 만들지 않아도 됨. 단, 아이온의 경우 픽스 된 기본 얼굴도 25개 정도 되는 것 참고.)
네거티브적 측면	개발 비용적 측면의 검토. (프로그래밍 기간 측면이 비중이 큼.)

        

기술적 측면

클라이언트

참조.Facezen































그림1. FaceGen SDK for developer







































그림2. FaceGen SDK for Artist

서버

커스터마이징 인포메이션 데이터의 통신 처리.

케릭터 커스터마이징 데이터의 저장 -> User DB.

UserDB 가 관리 할 Data method -> 커스터마이징 하기 위한 Node 의 Parameter data(커스텀 노드의 수가 15개일 경우 약 140바이트)

저장 될 파라메터의 예.

par1=1 par2=10 par3=10 par4=10 par5=10 par6=10 par7=10 par8=10 par9=10 par10=10 par11=10 par12=10 par13=10 par14=10 par15=10

데이터는 정수형 데이터로 파라메터 스냅은 1단위로 1~10까지 10단계 커스터마이징 할 수 있도록 초기에 설계한다.

!위 파라메터는 얼굴 텍스쳐 데칼(문양에 사용되는)이나 컬러 변형(버텍스컬러 혼합을 통한 염색) 정보는 제외 하고 있음.

클라이언트와 서버간의 개념도.














개념적으로 위와 같이 추론 하여 이해 한 상태에서 클라이언트 연산처리 상의 방식의 범주일 것이다.



FaceGen 과 관련 하지 않고 가장 간단하게 개념적인 데이터 제작 및 관리 형태에 대한 추론.

1. 몰프(Morph) 데이터 접근.

변형 할 얼굴 부위 별 노드를 정하고 각 노드 별 변형 데이터를 제작하여 관리.

파라메터의 중간 값은 5 를 기준으로 하여 제작한다.

가장 자연스러운 결과 데이터 리소스 제작이 가능 하다.

개념도.

UserDB 파라메터 저장 정보.

노드에 따른 각 모프 데이터는 변형 해당 영역의 Vertex Set 등을 갖는다.

2. 본(Bone) 처리 방식 접근.




얼굴에 근육의 방향으로 본을 설치 하여 처리 하는 방식이나 자연스럽지 못하다.



디포메이션 클러스터 등을 따로 부가적으로 설정하여 좀 더 자연스럽게 할 수 있으나 컨트롤 데이터의 양이 너무 많아지기 때문에 응용 검토 사항에서 일단 후순위로 두기로 한다.







위와 같이 두가지의 방법에 대한 추론을 해 보았다.



이제 1번 안에 대한 좀 더 세부적이고 명확한 방법을 연구 하고 추론 하도록 하자.











케릭터 정보가 갖게 될 정보는 아래와 같을 것이다.

케릭터 스케일(루트 본 스케일->하위 본은 루트 본 스케일을 상속 받을 것이다.)

헤어 데이터 정보(기존에 정해 진 헤어 모델의 넘버 인덱스 값 과 염색에 사용 된 RGB 값을 갖을 것이다.)

얼굴모양의 변형 정보(기존에 정해 진 얼굴 모델의 넘버 인덱스 값과 디포메이션 된 각 노드에 대한 약속 된 파라메터 정보를 갖을 것이다.)



생각 할 문제.1

데이터 케시화 할 경우.

만약 유저 커스터마이징 상태에서 케릭터 확정을 하였을때 최종적으로 만들어 진 얼굴 데이터를 지오메트리 데이터로 재생성 한다고 가정 했을 경우 그 데이터를 클라이언트가 갖고 있을 순 없을 것이다.

서버에서 데이터를 관리 해야 하는데 이 정보는 유저디비에 보관 될 것인데 바이너리 데이터로 저장 되어 보관 되어 진다면 용량면에서 과연 유저디비에서 관리 할 수 있을까.라는 의문을 일단 갖어 보자.



처리 루틴은 아래와 같겠다.

서버 접속 - > 유저 디비 엑서스 -> 정보 리시브 ->게임접속-> 다른 플레이어들에게 모든 공통 바이너리 데이터 전송

처리 면에서 말이 좀 안될꺼 같다.



추가적인 검토사항.

얼굴 데이터에 대한 바이너리 데이터 또는 아스키 데이터 형태로 저장 할 경우 전송 되는 패킷의 크기 검토.



장점 : 프로세스 적으로 처리 할 부분이 미비 하다.

만약 한번 봤던 유저의 얼굴 커스텀 정보를 내려받아 케시 하고 있다면 데이터를 내려 받는다는 단순한 작업 이외에 만날때 마다

그 데이터가 맞는지 비교를 해야 하는데 이것은 달라진 유저의 유저 디비에 변경 된 정보에 대해서 주고 받을때 함께 주고 받게 될 것이다.

단점 : 네트웍 리소스 부분







생각 할 문제.2

클라이언트 안에서 디폼 된 데이터 셋과 유저 디비에서 파라메터 정보만을 가져 올 경우.



처리 루틴은 아래와 같겠다.

서버 접속 - > 유저 디비 엑서스 - > 정보 리시브 - > 게임접속 -> 다른 플레이어들에게 유저 인포메이션 정보 센드. 타 유저들 유저 커스터마이징 파라메터 데이터 리시브 -> 화면에 보여짐.


Game Developer Leegoon copyright all right reserved since 2010.