블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2307)
Unity3D (564)
Programming (470)
Unreal (4)
Gamebryo (56)
Tip & Tech (182)
협업 (34)
3DS Max (3)
Game (12)
Utility (114)
Etc (92)
Link (31)
Portfolio (19)
Subject (90)
iOS,OSX (37)
Android (12)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (1)
Memories (19)
Interest (37)
Thinking (36)
한글 (26)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (19)
Exercise (3)
나만의 맛집 (2)
냥이 (9)
육아 (5)
Total1,331,743
Today16
Yesterday113
Statistics Graph

달력

« » 2019.10
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

공지사항

태그목록

'성능향상'에 해당되는 글 1건

  1. 2010.12.20 게임브리오엔진에서 성능 향상을 위한 방법들..

1. NiPick에서의 충돌 검사

일반적으로 충돌 처리를 NiPick을 이용해서 많이 합니다.  그런데 NiPick에는 심각한 문제가 있습니다.  그것은 거리와 상관없이 해당 방향에 있는 모든 오브젝트에 대해서 검사를 한다는 것이죠.

 

NiPick 충돌 검사 비용을 줄이기 위해서는 트라이앵글 충돌검사비용을 줄여주어야 합니다.  그렇게 하기 위해서는 경계구에서 거리가 먼경우(경계구의 중심점과 NiPick.Ray의 origin 위치사이의 거리에서 경계구의 반지름을 뺀 값)에는 아예 그 안에 들어가지 않게 하는 것입니다.  이렇게 하면 속도향상을 상당부분 줄 수 있습니다.

 

NiPick을 이용한 충돌은 기본적으로 카메라 충돌 검사, 서있는 위치 알아오기, 이동방향에 대한 충돌 등 다양하게 적용되겠죠.

 

2. Update 비용

Update 비용은 매우 심각한 편입니다.  이 비용을 줄이기 위해서는 씬그래프를 잘 구성해주어야 합니다.  움직이지 않는 오브젝트는 업데이트가 최초 1회만 실행하면 됩니다.  UpdateSelect, UpdateRigid 등도 모두 낭비라는 사실이죠.

 

그러면 어떻게 하면 될까요? 

 

모델링을 할 때, 노드 이름을 정할 때, 다음과 같은 규칙을 정합니다.  노드 이름에 특별한 기능이 들어가 있는 경우에는 @를 붙여봅니다.  그런다음, 1 = pick, 2 = animation 라고 규정을 하죠.

 

노드이름이 @12tree 라고 한다면, pick이 되면서 animation이 되는 노드입니다.  즉 이런 노드는 따로 보관을 합니다.  그런 후에 pick이 필요하면 pick만 모아둔 트리에서 pick을 합니다.  Update가 필요하면 animation만 모아둔 트리에서 합니다.  이렇게 하면 성능을 많이 향상시킬 수 있습니다.

 

3. 캐릭터

캐릭터에는 기본적으로 skin 애니메이션이 들어가있습니다.  캐릭터쪽을 향상시키기 위해서는 Update를 최소로 불러주는 것이 좋겠죠.  이 경우 UpdateRigid와 Update를 혼용해서 사용하면 유리합니다.  위치이동은 해주어야 하니까요.  거리와 시야각에 따라서 Update 안하거나, updateRigid와 Update의 횟수를 조절해주면 도움이 될 것으로 보입니다.

 

4. 컬링 & 렌더링

이 부분은 제가 테스트해본 역사가 없습니다만, 듀얼 프로세스 시스템에서는 컬링 프로세스와 렌더링 프로세스를 분리해준다면 괄목할만한 성능 향상이 이루어질 것이라 생각됩니다.

 

5. 컬러스페이스

처음에 제작하는 사람중에서 가장 성능향상에 걸림돌이 되는 것은 컬러스페이스 문제입니다.  DDS를 사용하면 컬러스페이스 문제를 줄여줄 수 있습니다.  그러나 호환성 부분은 당연히 떨어집니다.  컬러스페이스가 서로 다른 경우 게임브리오는 텍스처를 생성할 때마다, 컬러스페이스를 변환합니다.  NiDevImgConverter가 이역할을 하고 있습니다.  컬러스페이스는 픽셀단위로 작업되기 때문에 매우 느립니다.

 

6. 그룹핑

같은 재질, 같은 텍스처를 사용한다면, 폴리곤을 합치는 것이 일반적으로 유리합니다.  그러나 폴리곤의 덩치가 커지면 그려지는 횟수가 많아지므로 이에 대해서 잘 판단해야 합니다.  이에 대해서는 게임브리오 문서에도 나와있습니다.  culling과 clipping의 싸움을 적절하게 조화해주어야 합니다.

 

7. 캐싱

거대존을 사용하는 경우에는 모델링 데이터 및 텍스처 데이터의 캐싱이 들어가게 됩니다.  일반적으로 캐싱할 관리자를 프로그램한 후에 필요한 데이터가 있는 경우 그 데이터를 Clone 함수를 이용해서 가져오게 됩니다.  그런데 여기서 문제가 있습니다.  게임브리오는 노드 트리 구조에서 보았을 때, 인스턴스 복사가 안 되고, 노드 트리 자체를 모두 복사하게 됩니다.  노드들이 많은 경우에는 메모리 낭비가 심하게 되어서 전체적으로 성능이 떨어지게 됩니다.  예를 들어서 성(castle) 오브젝트가 있다고 한다면, 성 오브젝트는 무수히 많은 노드들로 이루어질겁니다.  그런데 사용하는 것은 오직 한번뿐인데 Clone을 이용해서 가져온다면.. 두개의 복사본이 있기 때문에 그만큼 메모리 낭비가 심해집니다.

그래서 오브젝트 캐싱을 할 때에는 참조횟수를 지정해서 처음 참조가 되는 경우에는 자신의 포인터를 바로 넘겨주고, 두번째부터는 clone을 해주는 것이 좋습니다.



출처 : http://cafe.naver.com/dxgameprogramming/249

Posted by blueasa

댓글을 달아 주세요