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
클라이언트 안에서 디폼 된 데이터 셋과 유저 디비에서 파라메터 정보만을 가져 올 경우.
처리 루틴은 아래와 같겠다.
서버 접속 - > 유저 디비 엑서스 - > 정보 리시브 - > 게임접속 -> 다른 플레이어들에게 유저 인포메이션 정보 센드. 타 유저들 유저 커스터마이징 파라메터 데이터 리시브 -> 화면에 보여짐.
출처 :
http://universeonlinedev.blogspot.com/2010/02/flexible-character-customizing-1.html
