▷ 사용기술
DirectX 9.0b 기반으로 개발하며, Shader는 버전 1.1을 사용한다.
아래 각 주제에 대한 정리는 파트별 책임자가 작성한 기술사양을 바탕으로
팀장(전태진)이 정리한 것으로, 문제 해결을 위해 팀이 공동으로 연구를 했지만
보다 완성도를 높이기 위해 주제별로 담당을 정해 프로젝트를 진행했다.

      # 애니메이션 (담당 조종호)
      # 지형 (담당 조준형) 
      # FrameWork (담당 김창훈)
      # 인공지능 (담당 강현진)
      # 사운드효과와 인터페이스 (담당 정규진)
      # Tree 생성 (담당 노일헌)
      # 테스트 보고서의 예 ; 지형 삽질 비서 (조준형, 2004/01/06)
     
    오브젝트 위치와 카메라 FarZ, 게임제한 시간 등은 외부파일로 저장해서 쉽게 변경이 가능하고, 최대한 카메라 가시거리를 크게 잡아서 배경과 부드럽게 섞이도록 했다.
  -. Near_Z = 10.0
        Far_Z = 7000.0
  -. For start = 5000.0
            end = 7000.0
  -. 필드 Height Map size ; 513 * 513
        Scale = 100,     Height Scale = 30
  -. Default Map size ;  512 * 512
        Detail Map size ;  512 * 512
    Lighting Map size ; 1024 * 1024
        ( 고정 광원에 대한 고정 오브젝트의 그림자처리 )
          게임영역 size ; 6,400 * 6,400
        (정방형으로 중앙 부분으로 한정)  

 

▶ 애니메이션 (담당 조종호)               ▲...
1) 3ds Max에서 모델링과 키프레임 애니메이션을 제작하고
    SMD형식(하프라이프 SDK방식)으로 익스포트한 후, 인덱스 참조 방식으로
    다시 데이타를 가공해서 자체 포맷(*.tmd)으로 변환해서 사용한다.
2) 캐릭터 애니메이션은 상,하반신 분리처리가 가능하며,
    상, 하반신 동작 조합으로 다양한 동작을 표현할 수 있다.
3) 외부 데이터 파일에서 간단하게 범프매핑 사용여부를 설정하고 노말맵 파일을
    추가하는 방식으로 캐릭터와 오브젝트에 범프 매핑을 부여할 수 있다.
4) 하드웨어 가속 스키닝을 위한 행렬팔레트를 버택스 쉐이더를 사용해서 조작한다.

< TMD_Browser >  

9) 최종보고서
캐릭터 에니메이션

3d게임에서 캐릭터 에니메이션 시키는 방법에는 여러가지가 있습니다.
바이패드에 각각의 마디가 되는 오브젝트를 붙여서 캐릭터를 만들 수도 있고,
실제 캐릭터가 움직이는 모든 버택스를 저장하고
(때에따라 압축을 한다거나 데이터를 줄여서) 그것을 보여주는 트위닝도 있습니다.
스키닝이란 버택스 단위로 자신이 속한 bone의 움직임을 따라 움직이는 방법입니다.
바이패드 에니메이션은 바이패드 단위로 모든 버택스에 똑 같은 변환을 적용시켜줘도
되었지만, 스키닝에서는 각 버택스마다 따로 변환을 시켜줘야 합니다.
그래서 정점쉐이더가 나오기 이전까지는 소프트웨어 스키닝을 하여야 했습니다.

하지만 현재는 버택스 쉐이더를 이용하여 스키닝을 하드웨어 가속으로 처리 할 수
있습니다. 모리노리의 캐릭터 에니메이션은 쉐이더를 이용한 하드웨어 가속 스키닝을
하였으며, 이를 위해 smd포멧을 변형하여 처리 하였습니다.
스키닝을 위한 행렬팔레트를 위해 버택스 쉐이더를 사용 하였습니다.
이는 쉐이더의 상수 레지스터에 여러개의 에니메이션 행렬을 입력하고,
각 버택스의 bone의 인덱스로 사용되어야 할 에니메이션 행렬을 찿아서
변환하는 방식입니다.

그외에도 캐릭터의 상,하반신 에니메이션을 분리하여 처리가능하도록 하여,
모든 에니메이션을 만들 필요가 없이 동작의 조합만으로 다른 동작을 표현가능하도록
하였습니다.

모리노리에서 캐릭터와 오브젝트에는 범프매핑을 지원합니다.
데이터 파일에 간단하게 범프매핑 사용여부를 설정하고 노말맵 파일을
추가 해주기만 하면 범프매핑을 사용 할 수 있습니다.

물의 표현

물의 표현방법에는 버택스 단위의 표현방법과 픽셀 단위의 표현방법으로 나눌 수
있습니다. 버택스 단위 표현방법은 물의 파동들을 버택스를 움직임으로서 보다 더
사실적으로 보여줄 수 있는 장점이 있지만, 버택스의 수가 많아야
그 효과가 좋기 때문에 넓은 지형에는 사용이 힘듭니다.

픽셀 단위 표현방법은 반사 효과나 굴절효과를 픽셀단위로 처리 하기 때문에
그 속도가 픽셀의 갯수에 선형적으로 증가 하게 됩니다.
즉 적은 버택스로도 표현 가능하기 때문에 버택스 병목을 줄일 수 있습니다.

반사효과의 경우 반사 텍스쳐를 만들어서 할수도 있고,
큐브맵을 이용하여 표현 할 수도 있습니다.

모리노리의 물은 버택스, 픽셀 쉐이더를 이용한
Cube Environment bump mapping입니다. 카메라를 중심으로 일정 프레임 마다
cube map을 생성하고, 이를 범프맵핑이 적용되는 물표면에 사용하게 됩니다.
픽셀 단위의 표현방법이긴 하지만, 버택스가 지나치게 적을 경우 레스터라이제이션에서
선형보간으로 인해 환경매핑된 텍스쳐가 출렁이는 현상이 일어나게 됩니다.
이를 보완하기 위해 물에 두단계의 LOD를 적용했습니다.

캐릭터 등이 물에 들어왔을때 생기는 파원은 버택스 단위 물 처리의 경우
각 버택스 단위로 스프링을 연결하여 멋있게 표현 할 수 있지만,
픽셀 단위 처리 방식이기 때문에 파원 텍스쳐를 이용하였습니다.
파원 텍스쳐는 단순히 둥글게 그려진 텍스쳐 입니다.
캐릭터가 물에 들어오게 되면 이 파원 텍스쳐를 데칼로 물에 깔고,
일정시간마다 이 데칼의 크기를 크게 하면서 데칼을 투명하게 합니다.
나중에 데칼이 완전투명하게 되면 데칼을 소멸시킵니다.
새로운 데칼을 추가하고, 일정시간이 되면 먼저 들어온 순서대로 소멸시키기 위해
queue와 유사한 자료구조가 필요했으며, 이를위해 stl의 list를 이용했습니다.

라이트맵

고정 물체에는 실시간 광원계산보다는 정교하게 전처리 계산된 광원맵을 텍스쳐로
이용하는것이 성능향상과 효과 모두를 만족 시키기에 적절 합니다.
라이트맵을 생성하는 여러가지 방법이 있습니다만, 모리노리에서는 조금 독특한
'오클루젼 쿼리와 버택스 쉐이더를 이용한' 라이트맵 생성 방법을 사용하였습니다.

이 방법으로 지형의 음영뿐만 아니라 지형위의 고정오브젝트 들의 그림자도
쉽고 빠르게 생성 할 수 있습니다.

자세한 사항은 http://KIN3D.net 의 'Enjoy GameStudy'의 제가 쓴 문서를
참조해 주시기 바랍니다

- 종호기술사양.txt


 

▶ 지형 (담당 조준형)                         ▲...
한쪽이 물가에 접한 평평한 초원으로 주변부엔 산이 있으며
양을 모으는 울타리가 가운데 위치한다.
그 밖의 풍차, 농가, 울타리, 바위, 나무, 풀 등의 오브젝트로 필드를 구성한다.
1) Quadtree 기반으로 높이맵을 그대로 뿌리는 방식으로 지형 구현
    화면에 보이는 노드들을 선별하기 위해선 각 노드별로 컬링이 검사가
    되어야 하며, 각 노드들을 어떻게 빨리 컬링 검사를 하느냐에 따라 렌더링 속도가
    달라진다. Quadtree의 빠른 컬링 기법은 아래의 Flipcode 의 문서를 참고하였다.
    http://www.flipcode.com/articles/article_frustumculling.shtml
2) 물 반사와 풀의 움직임 등 자연을 사실적으로 표현
    물은 버전 1.1의 픽셀 쉐이더를 사용하며,
    cube environment bump mapping을 이용한 환경맵핑으로
    게임의 속도에 영향을 끼치지 않기위해 100프레임마다 한번씩 갱신한다.
3) 고정 오브젝트의 그림자 처리는 전처리로 광원이 계산된 텍스쳐를 붙이는
    "라이트맵" 기술을 응용했으며, 그림자 부분에 캐릭터들이 들어갔을 경우는
    본래의 색상을 감쇄시켜 음영이 생긴 것처럼 보이게 표현한다.

 

9) 지형 최종보고서
* Scene Graph
3D 엔진에 있어 가장 중요한 부분은 아마 Scene Graph 일 것이다.
“보이지 않는 것은 그리지 않는다.” 라는 기본 개념 아래 지금 것 개발되어 온
Scene Graph의 종류를 보면 Quadtree, Octree, BSP 등 여러가지가 있지만,
그 중에서 본 프로젝트에서 사용한 알고리즘은 Leaf 기반의 Quadtree 이다.

Quadtree 는 QuadNode를 4개씩 우리가 원하는 최소 크기의 노드가 될 때까지
재귀적으로 나누어 놓은 것이며, 노드의 최소 단위 즉, Leaf 에
지형 메쉬, 오브젝트등을 담아 화면에 보이는 것만을 렌더링 하도록 하는 것이다.

화면에 보이는 노드들을 선별하기 위해선 각 노드별로 컬링이 검사가 되어야 하며,
각 노드들을 어떻게 빨리 컬링 검사를 하느냐에 따라 렌더링 속도가 달라진다.
Quadtree의 빠른 컬링 기법은 아래의 Flipcode 의 문서를 참조하였다.

Reference URL : http://www.flipcode.com/articles/article_frustumculling.shtml

이를 구현하기 위해선 QuadNode별로 Axis-Aligned Bounding Box(AABB),
Bounding Sphere를 포함하고 있어야 한다.
각 QuadNode의 AABB는 노드의 가장 높은 지형의 높이 값과 가장 낮은 지형의 높이 값을
이용하여 만들고 Sphere는 AABB를 감싸는 구로 만들면 되겠다.
또한 Frustum은 기본적인 6개의 평면 외에 Frustum을 감싸는
Bounding Sphere를 구현해야 한다.

* Terrain
본 프로젝트에서 지형을 구현하기 위해 CLOD, SLOD 등 여러 가지 방법을 시도해 보았다.
지금의 하드웨어 사양(Geforce TI4200 기준)에서는 CLOD 혹은 SLOD 는
T-Crack 과 Popping을 잡기 위해 Geomorphing을 구현하는 것이 더 느렸으며
위의 Scene Graph에서 이용한 Quadtree 기반으로 높이맵을 그대로 뿌려 주는 것이
훨씬 빨랐다. 게임에 따라 다르며 하드웨어의 발전에 따라 세계적인 추세도
SLOD 혹은 높이맵을 그대로 뿌려주는 것이니 본 프로젝트에서도
높이맵을 그대로 뿌려주는 방식을 택했다. 물론 저 사양에서는
픽셀 래스터라이즈를 줄여 주는 것이 더 빠르므로 SLOD를 이용하는 것이 옳을 것이다.

- 작성자 : Interval 팀원 엔진 지형 담당 조준형


 

▶ FrameWork (담당 김창훈)               ▲...
1) 게임 전반
    -. 게임의 각 장면(인트로, 메인메뉴, 게임플레이, 게임종료 등)을
    상태클래스패턴을 이용하여 관리한다.
    -. 인트로 : 2D 이미지를 이용하여 페이드-인
    -. 메인메뉴 : AVI 동영상을 화면에 출력하고, 그 위에 메인메뉴를 출력한다.
    -. 로딩화면 : 로딩 중이라는 것을 알리기 위해, 로딩중에 2D 이미지를 띄운다.
    -. 게임 플레이중 : ESC를 누르면 메뉴가 뜨도록 하고,
    SceneGraph를 이용하여 장면을 관리한다.
    -. 게임 도중 종료 : 현재 화면을 흑백으로 만드는 효과를 주고 프로그램을 끝낸다.
    -. 정상적 게임 종료 : 스코어 등의 결과가 나오고, 메인메뉴로 다시 간다.
2) 동영상 처리
    -. 간단하게 Video For Windows API를 이용하여 동영상을 처리하며,
    윈도 내부 API를 사용하므로, 코덱만 설치 되어 있으면
    어떤 동영상이든 재생 가능하다.
    -. 동영상 처리 부분은 nehe.gamedev.net의 튜터리얼을 참고하였다.
3) 각 캐릭터의 움직임
    -. 시간에 대해 속도값을 이용하여 프레임이 다르더라도 똑같은 속도로
    움직이도록 처리한다.
    -. 양의 점프 역시 속도와 중력을 계산하여 실제와 유사한 포물선을 그리도록 한다.
4) 사람과 양과 늑대의 상호 반응
    -. 특정 상태일 때 해당 객체에 반응 메시지와 반응을 주는 객체를 넘겨주어서
    처리하며, 각 상태에 따라 메시지의 반응을 다르게 처리한다.
 

9) FrameWork 최종보고서
( 게임 전반 )
- 게임의 각 장면(인트로, 메인메뉴, 게임플레이, 게임종료 등)을 상태클래스패턴을
이용하여 관리하였다.
- 인트로 : 2D 이미지를 이용하여 페이드-인
- 메인메뉴 : AVI 동영상을 화면에 출력하고, 그 위에 메인메뉴를 띄웠다.
- 로딩화면 : 로딩 중이라는 것을 알리기 위해, 로딩중에 2D 이미지를 띄웠다.
- 게임 플레이중 : ESC를 누르면 메뉴가 뜨도록 하고,
SceneGraph를 이용하여 장면을 관리
- 게임 도중 종료 : 현재 화면을 흑백으로 만드는 효과를 주고 프로그램을 끝낸다.
- 정상적 게임 종료 : 스코어 등의 결과가 나오고, 메인메뉴로 다시 간다.
( 동영상 처리 )
- 간단하게 Video For Windows API를 이용하여 동영상을 처리하였다.
윈도 내부 API를 사용하므로, 코덱만 설치 되어 있으면 어떤 동영상이든 재생 가능하다.
- 동영상 처리 부분은 nehe.gamedev.net의 튜터리얼을 참고하였다.

( 각 캐릭터의 움직임 )
- 시간에 대해 속도값을 이용하여 프레임이 다르더라도 똑같은 속도로
움직이도록 처리하였다.
- 양의 점프 역시 속도와 중력을 계산하여 실제와 유사한 포물선을 그리도록 하였다 .

( 사람과 양과 늑대의 상호 반응 )
- 특정 상태일 때 해당 객체에 반응 메시지와 반응을 주는 객체를 넘겨주어 처리하였다.
- 각 상태에 따라 메시지의 반응을 다르게 처리하였다.

- 작성자 : Interval 팀원 엔진_class 유지 관리 담당 김창훈


 

▶ 인공지능 (담당 강현진)                   ▲...
1) FSM(finite-state machine)을 기본으로 설계되었다.
2) 양의 상태
    STATE_Initialize, --> 초기화
    STATE_Wander, --> 대기상태(외부 영향이 없어도 지속적으로 이벤트 발생시킴)
    STATE_Dead, --> 죽음(Data가 없어지는 것이 아니라 보이지 않게 처리)
    STATE_Disappear, --> 죽은 다음 사라짐
    STATE_Pattern, --> 랜덤하게 움직임
    STATE_Threaded, --> 위협받은 상태
    STATE_Runaway, --> 맞았을때 도망

3) 늑대의 상태
    -. 양을 위협하는 존재로서 기본대기(탐색) 상태에서 렌덤하게 움직이다가
    일정영역에 양이 들어오면 공격한다.
    -. 늑대의 수는 게임 레벨등을 고려해서 결정하며 (현재는 5마리 등장)
    양과는 다르게 죽은 후에 일정시간이 지나면 다른 위치에 다시 출현한다.

4) 버전 1.03에서는 양을 모으는 상태가 추가되고,
    horn모양의 아이콘과 사운드가 인터페이스에 추가되고
    각 상태의 처리 우선순위등이 부분 수정되었다.
 

9) 인공지능 최종보고서
* 양의 인공지능
상태 : STATE_Initialize, --> 초기화
STATE_Wander, --> 대기상태
STATE_Dead, --> 죽음
STATE_Pattern, --> 랜덤 무브
STATE_Threaded, --> 위협받은 상태
STATE_Runaway, --> 맞았을때 도망
STATE_Follow, --> 케릭터 따라가기( 미처리 )
STATE_Disappear, --> 죽은다음 사라짐
STATE_GoFence --> 울타리 주변에 있을때 울타리 안으로 고고

키 : W --> 앞
S --> 뒤
A --> 좌
D --> 우
F --> 양모으기
1 --> 와이어 on
2 --> 와이어 off
3 --> 충돌처리 구 표시
4 --> HP, 위치 표시
F5 --> 카메라 변환(원근 -3인칭- 카메라)
F6 --> 카메라 원래대로 ( 기본 -1인칭- 카메라 )
SPACE --> 점프

Up --> 카메라 변환시 원근(3인칭)카메라 이동(앞)
Down --> '' (뒤)
Left --> '' (좌)
Right --> '' (우)
카메라 변환시 마우스 오른쪽클릭 = 카메라 방향전환

충돌처리 : 케릭터와 고정오브젝트 --> 체크됨 ( 부딪히면 달라붙음 )
케릭터와 양 --> 체크됨 ( 양을 밀고다님 )
양과 양 --> 서로부딪히면 휙 돌면서 떨어짐
양과 고정오브젝트 --> 안됨 ( 처리중 )
* 전체적으로 충돌체크가 아직 미숙함 ( 내가 처리하는거 아님 )

- 작성자 : Interval 팀원 AI 담당 강현진


 

▶ 사운드효과와 인터페이스 (담당 정규진)   ▲...
사운드 효과 ;
DirectShow 와 DirectMusic를 사용하며,
1) DirectShow는 배경음악 play에 사용한 기술로서,     저음질 mp3로 변환하여 부분적으로 편집하여 사용한다.
2) DirectMusic은 물소리, 발자국 소리등의 2D와 3D의 효과음에 사용한다.
    특히, 주인공이 물가근처를 다닐 때, 주인공의 Y값(지면상의 위치)를 조사하여
    물의 Y보다 낮으면 물장구 소리를 높으면 그냥 잔디를 밟는 소리를 재생한다.

인터페이스 ;
1) 넓은시야를 위해 꼭 필요한 정보만을 화면에 표시하며.
    Direct3D의 텍스처 블렌딩기술과 DirectInput 기술을 이용했는데,
    메뉴는 다이렉트 인풋으로 클릭하였을때 그 스프라이트의 값이 true
    (마우스가 그 스프라이트위에 올라와있는 상태) 일때
    클릭이 되었다는 메시지를 보내는 방식으로 구현한다.
 

9) 모리노리의 GUI 기술 문서
작성자 정규진(동명정보기술원 3D게임프로그램개발자 5기)

저는 GUI (Graphic User Interface) 즉 화면에 나타나는 게임의 상태를 유저에게 알려주고
유저로 부터의 입력을 받는 부분을 제작하였습니다.
크게 Direct3D의 텍스처 블렌딩기술과 DirectInput 기술을 이용하였습니다.
인터페이스의 기본은 3D 스프라이트 인데 요즘 흔히 쓰는 방식인 RHW(동차좌표)방식과
직교투영방식을 이용하였습니다.
모리노리에서는 회전이 없는 스프라이트는 RHW방식으로 회전이 필요한 스프라이트는
직교투영 방식을 이용하였습니다. 처음에는 RHW 방식으로 모두 하려고 했으나
스프라이트의 회전이 처리가 어려웠던 이유로 직교투영방식을 같이 쓰게 되었습니다.

RHW 방식은 D3DXVECTOR4 의 정점의 w 에 1을 넣어주는 방법입니다.
이 경우 정점은 정점 파이프라인을 거치지 않고 그대로 출력되게 됩니다.
그러므로 800 x 600 해상도에서 화면의 좌측 상단이0,0 우측 하단이 800, 600 이 되면서
포그나 라이트의 영향도 받지 않고 그대로 나오게 됩니다.
그러나 밉맵설정에는 영향을 받아서 LINER, POINTER 방식중 어울리는 방식으로
설정해야 합니다. 그리고 각각의 스프라이트는 마우스가 자기 위에 있는지 없는지를
값으로 가지고 있습니다. 그리하여 다이렉트 인풋으로 클릭하였을때
그 스프라이트의 값이 true (마우스가 그 스프라이트위에 올라와있는 상태) 일때
클릭이 되었다는 메시지를 보냅니다.
이런 원리로 모리노리의 메뉴를 구현하였습니다.
길이가 줄어드는 시계막대와 폰트는 텍셀의 값을 변경하여 뿌려주는 방식입니다

9) 모리노리의 사운드 기술문서
작성자 : 정규진(동명정보기술원 게임프로그램개발자5기)

모리노리의 사운드는 크게 DirectShow 와 DirectMusic 으로 구성되어 있습니다.

1. DirectShow를 이용한 배경음악
1) 음원출처 : Pat Metheny 의 A Map of the World 앨범
*저음질mp3로 변환하였고 부분적으로 편집하여 사용하였으나 저작권의 문제가 된다면
자발적으로 바꾸도록 하겠습니다.
2) 상세기술은 전반적으로 DirectShow SDK를 참고 하여 제작.

2. DirectMusic을 이용한 2D, 3D 사운드

1) 음원출처 :
Mythic Entertainment의 Dark Age of Camelot , 게임재료파크(http://kgdb.or.kr)
2) 파일 포맷 형식 : PCM, IMA_ADPCM
3) 상세기술 : DirectMusic SDK 참조
4) 구현원리와 사용 :
2D 사운드와 3D 사운드의 구현 원리는 동일한데 최종버퍼의 출력 모드를
아래와 같이 설정함으로서 구별하도록 했습니다.
DS3DMODE_NORMAL; // 일반적인3D 사운드
DS3DMODE_DISABLE; // 3D기능을 끔 = 2D 사운드

2D 사운드 일 경우 버퍼를 DS3DMODE_DISABLE 로 설정하고
CMusicSystem::Play2D(int ID) 함수를 호출함으로서 소리를 재생합니다.
ID는 세그먼트(리소tm)의이름으로 enum 으로 미리 정의 되어 있습니다.

3D 사운드는 버퍼를 DS3DMODE_NORMAL 로 설정한뒤
CMusicSystem::Play3D(int ID, float x, float y, float z) 함수를 호출합니다.
ID 인자는 2D와 동일하며 음원이 재생되는 위치값 x,y,z를 입력해주어야 합니다.

강물소리는 주인공의 Z 좌표를 실시간으로 받아서 강물 버퍼의 Z 위치에 대입해 줌으로써
플레이어가 항상 강물쪽으로 시선을 돌릴때는 강물소리가 크게 들리도록 하였습니다.
양치기의 발자국 소리는 타이머를 이용하여 한발자국의 소리를 뛸때는
예를 들어 0.5초 마다 한번씩 호출하고 걸어갈때는 0.8초에 한번 호출되는 방식으로
하였습니다.
그리고 주인공의 Y값(지면상의 위치)를 조사하여 물의 Y보다 낮으면
물장구 소리를 높으면 그냥 잔디를 밟는 소리를 재생합니다.


 

▶ Tree 생성 (담당 노일헌)                   ▲...
1) 외부프로그램 형식으로 실린더를 약간 변형해서 구현했으며,
    특성치를 설정하고 렌더링상태에서 버튼을 누르면 바로 SMD 파일을 생성하고,
    최종 데이터 형식은 캐릭터와 같은 자체 포맷(*.tmd)으로 변환해서 사용한다.
 

9) Tree 생성 최종보고서
* 나무(Tree)

실린더를 약간 변형해서 구현했습니다.
렌더링상태에서 버튼을 누르면 바로 SMD 파일을 생성하도록 했습니다.
파일추출만 하는 것이기 때문에 특별히 카메라를 달진 않았습니다.

메뉴 : Mesh -> Solid 및 WireFrame 보기 변환
Extract 버튼 -> SMD 파일 출력

- 작성자 : Interval 팀원 Tree SMD 파일 생성툴 담당 노일헌


 

▶ # 테스트 보고서의 예 ; 지형 삽질 비서 (조준형, 2004/01/06)                   ▲...
www.morinori.net 의 '개발자공간'에 의견과 테스트 결과가 정리되어 있고,
'지형 삽질의 비서'는 그 중 한가지 예이다.

* 지금까지 시도했던것들

1. CLOD with Quadtree
    거리와 높이에 따라 LOD를 실시간으로 적용하는 기법으로
    LOD가 변할 때마다 Popping이 일어나는데 Geomorphing 하기 절라 짜증난다.
   대세는 SLOD 라나 뭐라나....케케케

2. SLOD Patch with Quadtree
    1) 각 패치마다 하나의 정점 버퍼와 LOD별로 인덱스 버퍼를 둔다.
        - 문제점 : 각 패치별로 렌더링되어야 하는데
            정점버퍼 스위칭으로 인해 함수 호출의 오버헤드가 심하다.
    2) 하나의 정점버퍼와 각 패치마다 인덱스 버퍼를 둔다.
        - 문제점 : 인덱스 버퍼 스위칭으로 인해 함수 호출의 오버헤드가 심하다.
            그리고 높이맵 특성상 DrawIndexedPrimitived 에서
            정점의 범위 설정이 어렵다.
    3) 하나의 정점버퍼와 하나의 인덱스 버퍼
        : 각 패치별로 생성되어 있는 인덱스를 실시간으로 인덱스 버퍼에 복사하여 넣는다.
        - 문제점 : 위의 두가지 문제는 해결이 되어 FPS 수는 만족하는 수치가 나온다.
            그런데 LOD가 다른 패치가 서로 인접했을시 크랙문제 발생.
            (크랙이 발생할거라고 생각하고 있었으나 해결책이 너무나도 마음에 안든다.)
            그리고 해결한다해도 여전히 Popping 발생.
        Popping이 두드러지게 보이지 않으나 해결하려 든다면 결국 CLOD 가 되는것일까...

        * 실시간으로 크랙을 해결하려 한다면 SLOD를 쓸 이유가 없다.
            미리 크랙을 고려하여 LOD를 구성하는 수 밖에 없는데
            그것은 너무나도 어려운 과제이다.

    4) 높이 LOD 를 적용후 패치에 담아 렌더링
        최 선생님께서 아이디어를 주셨는데 ROAM에서 QUAD로...케케케
        .쿼드트리를 이용하여 높이 LOD를 적용하고
        .그것을 패치에 담아 렌더링한다.
        - 아직 Scene Graph를 완벽하게 구현하지 못했지만
        - 역시나 숫자 놀이다. 적당하게 조절하면 250~300fps

3. LOD 고 나발이고간에 다 때려쳐라 높이맵 그대로 뿌릴란다.
    동기생 창훈 알고리즘 : 오~ 놀라워라....ㅡㅡ;;; 평균 250fps
    완벽하진 않지만 기대된다. 파이팅!!!

맘에 상처를 입고 쿼드트리와 패치를 이용하여 높이맵 그대로 뿌려 보았지만.....
        Mapsize : 513x513
        Patch : 8
        Scale : 128
        Far Z : 10,000
        디버그로 쿼드 중심에서
        FPS : 최소 130~
        에게게...ㅡㅡ;;;
        죽썼다....젠장

좆나 열받아서 이전에 만들어 났던거 살짝 고치가꼬 마지막 시도 함 해보고
방향을 정하려 한다. 케케케 ^^

- 모든 것을 전처리로
- 높이맵의 특성상 일정한 범위의 정점을 지정하지 못한것을
패치 단위로 모든 패치의 정점을 하나의 정점 버퍼에 저장하고
인덱스 까지 패치 단위로 저장함으로써 해결하려 함

지형에서 머뭇머뭇...케케케
내가 빨리 마무리 해야 할텐데

몇일간 술빨고 정신없이 지내서 요즘 아무생각이 없네요. 멍~~~~~~~
빨리 정신차리고 프로젝트에 전념하겠습니다.
 

▶ 처음으로                 ▲...