복셀 회전시키는게 뭔 대수인가..하겠지만.
이게 생각보다 빡신 이유는 다음과 같다.
- 복셀 오브젝트는 변환매트릭스를 항시 들고 있어 손쉽게 변환되는 동적 오브젝트가 아니다. 완전히 정적이다.
- 따라서 변환이라고 하지만 구조물을 깨고 다시 만드는 작업이다.
- 부수고 다시 만드는 작업이기에 OK를 누르면 되돌리기 어렵다. 따라서 유저에게 반드시 프리뷰를 제공해야한다. 여기서 작업량이 대폭 증가한다.
- 서버 및 다른 클라이언트와 동기화 되어야 하므로 부수고 다시 만드는 작업의 성능이 중요하다. 어쨌든 서버에서 작업이 완료되고 나서 클라이언트에 적용되어야 한다.
- 2가지 선택이 있다.
- 클라에서 회전하고 복셀 오브젝트를 제거하고 새로 생성하는 패킷을 만들어서(이하 복셀 업로드 기능이라 부름) 서버로 보낼것인가. 이 경우 기존에 작성한 복셀 업로드 기능고 완전히 같다. 서버는 패킷을 받아서 서버측 메모리를 갱신하고 그 내용 그대로 다른 클라이언트에 브로드캐스팅 한다.
- 프리뷰로 확인 후 파라미터(회전축,회전각,피봇점)만 서버에 보내면 서버에서 회전을 처리하고 복셀 업로드 기능을 이용해서 클라이언트에 브로드캐스팅한다.
- 클라이언트에서 회전을 시키고 이를 복셀 업로드 패킷으로 만들어서 서버에 보내면 회전작업 자체의 부하는 문제가 되지 않는다. 반면 클라측에서 패킷을 조작할 해킹 취약점으로 작용한다. 압축을 풀고 서버에 복셀 오브젝트를 생성/삭제할때 서버 메모리를 손상시킬 수 있다. 사실 이는 기존 복셀 업로드 기능도 마찬가지인데 이 부분의 검증을 미뤄두고 있었다.
- 따라서 복셀 업로드 패킷에 대해 데이터가 무결한지 검사하는 코드를 추가해야 한다. 검증하는 비용은 서버에서 직접 회전처리를 하는 비용보다 저렴한가?(더 빠른가?)
- 서버에서 직접 회전을 처리할 경우 처리 시간에 오래 걸리면 게임 전체의 응답성(이동/전투처리)이 떨어진다. 복셀 오브젝트 회전에 얼마만큼의 시간이 소요되는가? 서버에서 처리하기에 충분히 빠른가? 이를 검증해야한다.
- 결국 해야할 일이 다음과 같다.
a. 복셀 오브젝트 회전 기능에 대한 프리뷰 기능 제공.
b. 복셀 회전 코드를 클라/서버 양쪽에서 모두 사용할 수 있는 형태로 가공.
c. 복셀 오브젝트 회전에 대한 프리뷰 상태를 복셀 업로드 패킷으로 만드는 기능.
d. 복셀 업로드 패킷에 대한 검증 코드 구현.
e. 복셀 오브젝트 회전/업로드 패킷에 대한 검증 에 걸리는 비용 측정.
f. 비용이 생각보다 클 경우 최적화 가능한지 여부 확인. 가능하다면 최적화.
e. 최종적으로 서버에서 회전처리를 직접할지, 클라에서 변환하고 서버에 복셀업로드 패킷으로 보낼지 결정.
이거 다 하느라 오래 걸렸다. 현재 마지막 e단계.
현재 복셀 오브젝트 변환에 걸리는 시간은 release빌드 기준 0.08ms수준.
서버에서 회전처리르 직접 하는 방향으로 60%쯤 기울었다.
yuchi's development 