일단은 버전2로 올라오면서 용량 최적화가 많이 됐습니다. 이전 구조에 공간데이터를 넣었으면 좌절할만한 용량이-_-;;
일단 기본설명은 버전1에서 설명했으니 생략하도록 하겠습니다..;
데이터가 같은 셀들을 묶어서 용량최적화를 했고.. 공간의 데이터를 가지고 있을 수 있도록 내용을 추가했습니다. 알고리즘은 V1에서 높이만 뽑던걸 Pair로 뽑도록 변경한거라 별다른 내용은 없습니다.
렌더링 되고 있는 화면은 닫힌 공간(실제 공간을 차지하고 있는)을 렌더링 하고 있지만 실제 데이터는 열린 공간을 가지고 있습니다. 닫힌 공간으로는 충돌처리를 할수가 없게 되어 버리더군요;; 이유는 캐릭터가 점..; 이라면 닫힌공간에 부딪히나..를 검사하면 되지만 캐릭터가 세로부피가 있기 때문에(머 대략2m라고 치고) 이 공간에 내가 들어갈 수 있나..를 검사하도록 만들어야 합니다. 다리가 있다고 쳤을때 다리하고 지면이 1미터 간격밖에 안되는데 지나가 버리면 이상하겠죠;;
거창하게 공간데이터 이긴 하지만 실제 사용은 높이만 가지고 있던 내용이랑 큰차이가 없어서 3D상의 공간 충돌뿐만이 아니라 공간상의 길찾기도 내용만 약간 수정해서 그대로 넣어도 사용하는데 지장은 없습니다. 속도적인 부분도 가만할수 있을정도일듯 싶습니다.
잠수나 날아다니거나 하는경우는 사실 1인칭형으로 이동이 될거기 때문에 3D길찾기가 필요한 경우는 없겠지만 혹시나 수중전투-_-같은 경우는 필요하겠죠..; 혹시 몹이 하늘을 날아다니거나..하는 경우도 써먹을수도 있을거고..;;
그리고 걸을수 있는 데이터...의 경우에는 공간데이터와는 따로 가지고 있습니다. 공간데이터쪽에 플래그 같은걸 넣어도 되지만 길찾기 할 때 속도를 높이려고 그냥 중복해서 가지고 있습니다.;;
전과 달라진 내용은 지면데이터 쪽에도 지면에 대한 공간으로 가지고 있습니다. 혹시 캐릭터나 몬스터 이동시 높이에 대한 부피체크(위에서 설명한)가 들어갈 일이 있을까봐 같이 넣었습니다. ( 사실은 따로 만들기 귀찮아서;; )
머 그외에는 버전1에 비해 특별한 내용은 없군요..;
용량을 궁금해 하실까봐 용량을 캡쳐했습니다. dat파일이 실제 서버에서 사용하는 파일입니다.
메모리 구조와 파일구조가 거의 비슷해서 실제 셀데이터 올릴때 vector에 공간차지하는거 약간 1~2메가 정도 말고는 실제 메모리에 올라가는 용량 그대로입니다.
4020*4020 1미터 단위 4개..와 2040*2040 1미터 단위 2개..맵이 185메가 정도군요..; 원래는 좀 더되야 하는데 내부에서 중복셀을 줄이기 위해 16분할로 데이터를 가지고 있습니다. 용량의 대부분이 셀데이터와 실제 지형을 연결시켜주는 인덱스 데이터이기 때문에 중복셀이 많으면 4바이트를 쓰고 적으면 1, 2바이트를 사용하기 때문에 분할하는것과 안하는것이 차이가 꽤 납니다. ( 많게는 2배까지 )
사실 실제 서버는 존서버 방식이라 한서버에 몇개의 존만 올라가서 그냥 써도 상관은 없지만 나중에 테스트 서버같은데는 모든존을 다 올려버리게 될거 같아서 가능한 다이어트를 했습니다.
_ST가 붙은 파일들은 클라이언트용 패킹파일입니다. 파일 내용자체는 100%같습니다.
안에는 대략 이런 모냥이죠;;
서버파일은 그냥 파일을 줄줄줄 붙여논거 밖에 없습니다. 파일 합치는 방식만 다르고 실제파일은 같습니다.
클라이언트용 패킹파일샷은 압축했을때 얼마나 압축이 되나.. 참고하시라고 올렸습니다. 185메가 짜리가 72메가 가량이 되었군요.. 실제 클라이언트에서 그대로 쓰는 구조라 압축률이 낮은걸 쓰고 있어서 저정도 용량입니다. zip방식으로 걍 압축하면 50메가 정도입니다.
대충 내용은 이정도입니다.. 소스를 만들어서 배포를 하거나 할 예정은 없습니다..;;;; ( 이 내용외의 기본 내용들을 만들어서 붙이기도 귀찮고 같이 딸려있는 다른 모듈들;; 덕분에;; )
알고리즘은 내용에 설명을 다 해놨으니 공간개념이 있는 프로그래머분들은 아마 내용만 보고 만드시는데 별 지장은 없을듯 싶습니다.
실제 소스도 공간데이터 만드는 부분 200라인 정도 데이터 구조랑, 로드, 세이브가 500라인정도밖에 안됩니다.
2. SVN 저장소의 hooks디렉토리에 다음에 나오는 배치 명령이 들어있는 post commit hook 파일 생성(C:\Repository\hooks\post-commit.bat). SVN이 commit되는 동안에 Mantis에 이슈노트로 추가될 내용들을 넣습니다. REM Post-commit hook for MantisBT integration SET REPOS=%1 SET REV=%2 SET DETAILS_FILE=C:\Repository\GNIS4M\svnfile_%REV% SET LOG_FILE=C:\Repository\GNIS4M\svnfile_%REV%_Log
스피드 트리의 dll과 OpenAL및 ogg관련 dll들이 보인다. 98계열의 유니코드를 위한 uncows.dll도 보이고 vc관련 dll들을 봤을때 vc2003으로 개발되었다는 걸 알 수 있다. freetype은 찾을 수 없는걸 봐서는 일반 텍스트는 dx출력을 사용하고 캐릭터 이름의 경우 별도의 이미지 프로세싱을 거치는것 같다.
- 폰트구성
꽤 많은 양의 폰트가 보인다. 돈이 많은 회사이니 구매를 했다고 해도 이상하지 않긴 하지만.. 폰트가 한 회사의 것이 아니라 여러회사의 폰트들로 구성되있는건 의문이 간다.
- 패치 시스템
패치시스템으로 RTPatch를 사용하고 있다. 메틴2이후로는 오랜만에 보는것 같다.
- 스크립트 시스템
자세히 보면 <USERNAME>과 같은 형태로 키워드 대치가 가능하다. 그리고 텍스트의 중간에 칼라등을 지정하는 기능도 보인다.
Q라고 되어있는건 퀘스트 관련으로 보인다. 처음엔 질문형 스크립트라고 생각했는데.. 퀘스트외의 형태는 보이지 않는걸 봐선느 퀘스트용으로만 사용하는것 같다. 실제로 처음에 위치안내를 해주는 부분이 스크립트 구성이 안보이는걸 봐서는 일반 질문지는 따로 처리하는것 같다. <Q index="1368" value="받아다 준다." quest="2"/> 같은 형태로 되어있는데 value는 출력되는 내용이고 index는 선택했을때 나올 다음 스크립트 번호이다. quest는 퀘스트 번호와 연결되는것 같다.
위에서 내용을 선택하면 다음과 같이 다음 스크립트로 연결되는것 같다.
- 쉐이더
쉐이더는 cg와 hlsl이 보인다. cgc.exe로 된 컴파일러가 같이 있다. 실제 파일을 열어보면 컴파일 되어 있지 않는 소스형태로 구성되어 있다. cg와 hlsl 두개가 있는건 각각 다른 개발자가 개발했거나.. 언리얼엔진에서 cg형태로 제공된걸 사용하고 hlsl만 따로 개발한것일지도 모르겠다.
- 스크린샷
스크린샷은 bmp형태로 제공된다. 처음에 스크린샷 폴더를 한참 찾았는데 안보이길래 안쪽을 뒤져보니 시스템 파일이 있는 폴더에 들어가 있었다..;; 다..당황스러운 내용이다..; 참 성의 없다..;;;
- ui
ui이미지 파일들이 그냥 있어서 쉽게 볼 수 있다. tga에 bmp를 사용하고 있고 아이콘들은 dds를 사용하고 있다.
ui구성은 xml파일로 되어 있다.
대략 이런 형태이다. 창하나가 하나의 파일로 구성되는 듯 하다. 파일에 주석들이 있는걸로 봐서는 별도의 에디터같은 형태는 없고 수작업을 하는 모양이다..; 별도의 이벤트 관련 내용이 보이지 않는다. 이벤트 설치는 소스에서 하던가 클릭에 대한 이벤트만 처리가 되는걸지도 모르겠다.
- 그래픽 분석
- 물표현
물은 일반 애니텍스쳐와 파도가 밀려오는 이펙트로 구성되어 있다.
보이는 것처럼 물가쪽은 투명한 걸 알 수 있다. 카메라 시점 깊이값 체크는 아니고 지형과의 높이차로 투명도를 계산하고 있다.
그 결과로 위 스샷같은 현상이 생긴다. 지형이 안보이면 물이 보이는게 아니라 그냥 비어있게 된다. 물의 시야거리와 지형의 시야거리가 달라서 생기는 현상이다.
- 물속환경
물속에 들어갔을때 fog의 색을 조절해주는 기능이 있다. 하지만 카메라가 물안에 있을때가 아닌 캐릭터가 일정 깊이에 있을때로 구현되어 있어서 버그처럼 보인다.
- 지형체크
이정도의 경사도 가뿐하게 올라간다.
- 그림자
그림자의 경우 high로 놔도 퀄리티가 높은편이 아니며 다른 크리쳐의 경우 상당히 거리가 짧다. 그림자 텍스쳐를 너무 아끼는 것 같다.
- 그래픽 옵션
대략 이런 내용들로 구성되어 있다.
- 배경사물 표현
두 스샷의 차이로 봤을때는 풀외에는 변화가 없다. 풀의 경우 별도의 풀엔진이 있는것 같지 않고 오브젝트 속성에 옵션처리여부가 들어있는것 같다.
- 지형오브젝트 처리
보이는것처럼 오브젝트위에 올라갈 수 있는데. 테스트 결과 밟을수 있는 속성이 따로 있지 않고 폴리곤이 있으면 아무데나 올라가진다.
- IK
보이는것처럼 IK는 구현되어 있지 않다..;
- 캐릭터 폴리곤
옷 안쪽의 피부가 보인다. 보통은 옷 안의 피부는 만들지 않는데.. 분절방식이 몸과 옷이 분리되어 있거나 아니면? 흐음..
- 오브젝트 출현 연출
위의 스샷과 같이 포그색으로 변하면서 사라지거나 나타난다. 하지만 지형과 오브젝트의 시야거리가 따로 처리되서 좀 이상해 보이기도 한다.
- 오브젝트 시야처리
카메라를 돌릴때 가운데의 나무가 사라졌다 보였다 한다. 하지만 다음 스샷들을 살펴보면 이상한걸 알 수 있다.
자세히 보면 눈치챘겠지만 카메라거리를 조절해도 오브젝트에는 영향이 없다. 이걸로 봤을때 카메라의 위치가 아닌 캐릭터의 위치를 기준으로 판단함을 알 수 있다. 하지만 위에서는 카메라를 회전했을때 오브젝트가 보였다 안보였다 한걸 생각해서는 캐릭터위치를 기준으로 반경이 아닌 평면거리값으로 거리 계산을 한다..라는 이상한 결론이 나온다.
- 지형표현
기본적인 스플래팅형태로 보이고 텍스쳐의 퀄리티는 보통수준이다. 지형에 스페큘러 효과는 보이지 않았다.
- 라이트맵
보이는것처럼 라이트맵의 퀄리티는 꽤 높은 편이다. 하지만 마을 안쪽에만이고 필드쪽에는 라이트맵이 보이지 않는다.
- 카메라 충돌
카메라충돌은 와우형태의 일반오브젝트도 모두 충돌한다. 저위에 레벨오브젝트에서도 말했지만 일반 오브젝트와 레벨오브젝트의 구분이 없기 때문일 수도 있다.
- 플레어 아쉽게도 스샷이 없다. 밤에 달이 보일때 빛이 번지는 형태의 플레어 이펙트를 출력해주는데. 오브젝트에 가리면 출력되지 않는 기능이 구현되있다. 다만 보간이 되지 않아서 깜빡거리는것처럼 보이기도 한다.
머 전체적으로는 특별히 눈에 띄는 내용은 수영과 점프로 아무데나 올라갈 수 있다와 다양한 페이셜 연출... 말고는 특별한건 보이지 않았다. 다만 생각보다 메모리 사용량이 많지 않았다.
파일이 패킹되어 있지 않아서 분석하기는 좋았지만... 혹시 오베까지 저렇게 내용이 오픈되어있는 상태로 가면 좀 문제가 있겠다..;
평가는 첫 클베치고는 괜찮았다..라고도 생각되지만 개발기간과 언리얼2.x를 생각할때는 생각보다 별로.. 라고도 생각된다.
우선 Win32 API 의 경우 CloseHandle() 을 이용해서 파일 핸들을 닫았다고 해서 실제로 disk 에 write 되는것은 아니다. CloseHandle() 이 flush 를 해줄것이라고 생각할지도 모르겠지만 CloseHandle 한다고 해서 file 이 flush 된다는 얘기는 MSDN 어디에서도 찾아볼 수 없다. 실제로도 CloseHandle() 만으로는 물리적으로 disk 에 write 되지 않고 단지 캐쉬에 write 저장될 뿐이다. 다시 open 해보면 변경된 내역을 확인이 가능한것처럼 보이겠지만 그것은 write/close/open/read 가 모두 OS 의 디스크 캐쉬상에서 이루어 졌기 때문이다. CloseHandle() 후에 PC 코드를 뽑았다 다시 부팅해서 읽게 되면.. 운이 나쁘면 뒤의 일부분은 write 되지 않는것을 발견할 수 있을 것이다.
그렇다면 Win32 에서 데이터가 원하는 시점에 disk 에 기록되게 하려면 어떻게 해야하느냐? 방법은 FlushFileBuffers() 를 명시적으로 호출 해 주는 것이다. 여전히 CloseHandle() 과는 별개라는것을 주의 할것. CloseHandle() 은 내부적으로 FlushFileBuffers() 를 호출하지 않는다.
이제 CRT 의 경우를 살펴보자. CRT 의 fflush() 가 disk 에 write 해주는것 아니었냐고? 안타깝게도 대답은 'No' 이다. CRT 의 fopen()/fwrite()/fclose() 들은 내부적으로 FILE 단위의 버퍼링을 가지고 있으며 fflush() 는 그 버퍼링을 flush 해주는 것일 뿐이다. 그러니까 CRT 에서 fflush() 를 호출하게 되면 FlushFileBuffers() 가 호출되는게 아니라 그동안 쌓여있던 데이터를 그냥 WriteFile() - UNIX 계열에서는 write() - 해 줄 뿐이다. 결국 여전히 데이터가 OS 의 디스크 캐쉬에만 기록되고 물리적으로는 기록되지 않을 가능성이 남아있게 된다. system-call 로 구현될 수 밖에 없는 CRT 의 특성상 이는 모든 OS 에서도 일어날 수 있는 증상이다.
그래서 M$ 의 경우 fopen()/fflush() 의 extension 을 제공한다. 물론 이것은 표준이 아니다. 사용법은 간단한데 fopen() 시에 'c' 플래그를 추가하게 되면 fflush() 시에 FlushFileBuffers() 가 추가적으로 호출된다.물론 여기서도 fclose() 만으로는 물리적인 기록을 기대할 수 없다.
정리해보면, Win32 의 경우 disk 에 저장될 것이라 기대할 수 있는 코드는 다음 두가지다.
위의 코드를 수행해 보고 HDD 램프를 지켜보라. 간헐적으로 깜빡일 것이다. fclose() 만으로는 실제 disk 에 기록이 되지 않는다는 얘기다. #2 의 주석을 제거해도 마찬가지다. "wb" 옵션을 "wbc" 로 바꾸고 #2 의 주석을 제거해야 비로소 HDD 램프가 미친듯이 깜빡이고 시스템이 엄청나게 느려지는것을 확인할 수 있을 것이다. Win32 API 도 마찬가지.
어찌보면 사소한 문제로 보일수도 있지만 어플리케이션의 업데이트 루틴을 작성하는 사람이라면 꼭 알아두어야 한다. 유저가 수만명 단위로 늘어나게 되면, 분명히 발생하기 때문이다. 나역시 직접 당해보기 전까지는 fflush() 를 하고 파일 핸들을 닫으면 당연히 disk 에 저장 될거라고 알고 있었기 때문에 이것을 알아내는데에 고생을 좀 했다. 부디 이 포스팅을 읽는 분들은 같은 삽질을 하지 마시길...
대략 Ssook Path Engine라는 이름이다..; 사실은 지형데이터이지만 Level이란 네이밍은 지형렌더링쪽에 쓰고 있고, Space란 네이밍은 실제 폴리곤용 네이밍에 쓰고 있는데다..공간 데이터도 아닌지라..;; 마땅히 쓸 네이밍이 없어서 결국 Path라는 네이밍을 썼다..;
알고리즘의 내용은 Multi Height Tile정도가 되겠다. 여러개의 높이를 가지고 있는 타일 데이터다..
김성민씨의 Space Filling Volume을 보고 나니 이럴바엔 예전 2D때 쓰던 방식을 그냥 쓰는게...으흠? 그거 괜찮겠는걸... 하고 만든 내용이다.. 사실 만든 내용이라기보단 말한대로 2D때 많이 쓰던 내용이다. ( 아닌가 나만 쓴 내용인가-_-a 2D때도 어디서 보고 만든건 아니긴 했지만 )
일단 잡설은 접어두고 스샷부터 보쟈
대충 이런식이다. 보면 다리위와 아래에 높이 데이터가 있고 오브젝트가 있는부분은 높이 데이터가 없다. 그냥 타일로 나누었고, 하나의 타일은 갈 수 있다/없다가 아니라 높이 값을 가진다. 그리고 여러개의 높이 값을 가지고, 그 높이 값을 비교해서 갈 수 있다/없다 를 판단한다는 내용이다.
내용이 긴 관계로 자세한 내용을 보실분은 more를 클릭해서 보세요.
위에 보이는건 꽃무늬-_-가 아니라.. 하나의 타일에서 옆타일을 갈 수 있나/없나 를 나타낸다. 화살표가 있으면 그 쪽 방향으로 갈 수 있다는걸 말한다. 파일에 저장하지는 않는다.
마을의 전경은 대략 이런 느낌이다.
생성 알고리즘은 간단하다. 적당한 단위(1미터를 사용하고 있다.)안에 들어오는 폴리곤 리스트를 추려내서 bsp에서 사용하는 삼각형 쪼개기로 정확히 단위 안에 들어오는 부분들을 추려낸뒤 적당히 충돌폴리곤과 겹치지 않는 밟을수 있는 폴리곤들을 추려내면 된다.
집오브젝트의 입구부분이다. 파란색은 밟을수 있는 폴리곤 빨간색은 충돌 폴리곤 흰색은 지형이다.
와이어 프레임만 보면 이런 느낌
거기서 한 타일을 위에서 얘기한것처럼 분류별로 영역안(1미터*1미터)안에 들어오는 폴리곤들을 뽑은 이미지다. 실제로는 bsp는 삼각형단위로 쪼개기 때문에 속도를 위해서 라인단위로 뽑을 수 있게 만들었다. 잘보면 삼각형으로 구성되어 있지 않은걸 알 수 있다.
원래의 이미지와 함께 보면 이런 느낌 이런 경우는 블록킹용 폴리곤덕분에 밟을 수 있는 높이는 없다! 라고 나온다. 젤 높은 밟을 수 있는 폴리곤 부터 검사해서 위쪽으로 4미터이내에 다른 폴리곤이 있으면 그 높이는 못쓰는높이-_-a다 라고 판단하고 있다.
머 대략 알고리즘의 내용은 이게 끝이다-_- 간단하다..;
장점은 구현이 간단하고 타일이라 접근속도도 빠르고, 길찾기라던가 여러가지들이 작업하기 편하다...이고 단점은 타일이라 실제로 보기에는 갈 수 있어도 못간다던가 하는 문제가 생긴다. 클라이언트의 경우 폴리곤으로 한번 더 검사를 할 수 있으니 공중에 뜬다던가 하는건 막을 수 있다. 하지만 단점의 경우는 작은 단위를 사용하면 충분히 해결 될 수 있는 문제이다. 한 0.2미터 정도면 충분히 디테일해서 실제로 돌아다녀봐도 어색하지 않다.
현재 게임은 맵이 워낙 넓어놔서 1미터단위를 사용할 수 밖에 없지만.
일단 내용은 서버와 클라이언트가 동일한 지형정보를 처리하여서 서버상에서 벽을 뚫고 다닌다던가 하는 핵을 봉쇄하고, NPC의 길찾기에도 쓰쟈.. 라는 내용으로 나온 내용이다.
그럼 메모리를 계산해보자.. 현재 사용하는 맵은 약4,000*4,000미터에 1미터단위를 기준으로 하고 있다.(너무 넓다-.ㅜ) 보통의 경우는 1000*1000미터에 0.25미터 단위를 기준으로 하면 같은 메모리가 나온다.
우선은 높이리스트의 포인터를 가져야 하므로 하나의 단위가 4바이트의 메모리를 차지한다. 4000*4000*4하면 대략 64메가 보통 하나의 단위가 하나의 높이를 가지면(여러개의 높이를 가지기도 하지만 오브젝트덕에 안가지는 경우도 있으니) 4000*4000*2하면 대략 32메가(높이단위를 WORD로 했을때) 현재의 높이단위는 0.1미터로 해서 6553미터 정도를 사용할 수 있다.
이정도면 높이가 좀 복잡해도 100메가 이내이고 이정도면 서버에서 하나의 머신에 1기가 정도를 맵데이터용으로 할당한다면 10개정도의 맵을 가지고 있을 수 있다.
여기서 좀 최적화 하면 높이 데이터가 중복되는게 많기 때문에 그쪽의 용량은 더 줄일 수 있고 WORD인덱스를 사용할 수 있을정도로 줄일 수 있다면(높이 단위를 좀 더 넓히면 중복데이터가 더 많아진다) 40메가 이내로 줄일 수 있다.
아니면 그냥 사용한다고 해도 단위를 조절하면 만약 1000미터에 1미터 단위를 사용한다고 하면 6메가 1000미터에 0.5미터 단위를 사용한다면 24메가 정도이다.
위의 알고리즘은 현재 시스템이 높이에 의한 시스템(절벽에서 떨어지면 높이에 따라 데미지를 입는다던가 높이차에 따라 스킬사용이 제한된다던가)하는 내용이 있어서 그렇고 그렇지 않다면 높이값자체는 그다지 중요해지지 않기 때문에 공간분할을 사용하면 데이터를 확~ 줄일수도 있다.
일단은 여기까지가 버전1의 내용이고.. 새로 개발이 들어가는 버전2에는 다음 내용들이 들어간다.
- 중복데이터 제거를 통한 메모리 절약 내용은 위에 설명한 대로
- 높이데이터가 아닌 공간데이터 저장 데이터에 높이값을 종류를 구분하는 형식 10미터 (충돌 - 위쪽) 5미터 (충돌 - 아래쪽) 1미터 (밟음) 이런형태다. 1미터에 지형이 있고 5~10미터사이에 오브젝트가 걸려 있는 경우를 표현한다. 당연하게 열려있는 공간은 10미터 이상과 1~5미터 사이이다.
이 내용이 추가되면서 가능해지는건 * 크리쳐의 크기에 따른 충돌처리 위의 내용으로는 4미터 이하의 크리쳐만 지나갈 수 있다. * 비행 공간 데이터로 날아다니는것에 대한 충돌처리가 가능하다. 크리쳐 용도보다는 발사하는 스킬형태에 대한 충돌처리용도 잠수상태의 수영 ( 물위에서의 수영은 쉽지만 잠수상태의 수영은 비행과 마찬가지로 공간데이터가 필요하다. )
- 길찾기 속도향상을 위한 갈수 있는 방향 데이터 저장 현재는 옆타일의 높이들을 직접 비교하고 있다. 그전에 방향별로 갈수 있는 높이가 있는 지를 검사할 수 있으면 길찾기 속도를 높일 수 있다.
뭐 이정도 내용이다.
현재 스케줄 조율을 하고 있지만. 어느정도까지 할 수 있을지는 모르겠다.
조금 먼 내용이지만 2.5에 넣을 내용중에 하나는 - 높이값에대한 충돌데이터 저장 위에 말한것처럼 현재 맵의 크기로 인해 단위를 크게 쓸 수 밖에 없어서 하나의 높이값 이내에 추가적으로 4*4정도로 충돌정보를 저장하면 0.25미터 단위를 쓰는 효과를 나게 할 수 있다. 물론 오브젝트 충돌의 경우만 가능하고 높이로 인해 못가는 경우는 좀 힘들다. 머 높이로 인해 못가는 경우도 하나의 높이를 다시 여러개로 쪼개서 각각 따로 충돌정보를 가지고 있을 수도 있겠지만...
아니면 이 내용대신에 공간 분할이 들어갈지도 모르겠다. 하지만 높이 데이터를 살리면서 공간 분할은 아무래도 힘들지도..흠..
어쨋건 전에 패스엔진을 고려해서 테스트 해보았는데 위에 있는 내용처럼 높이에 대한 처리라던가 메모리라던가 하는 내용들이 감당이 안되서 만든 시스템인데.. 필요하신 분들이 있을까봐 정리해서 공개해둔다.
invalid-file
