아래에서 퍼옴

http://chulin28ho.egloos.com/5267860

사내게시판에 올릴 내용인데 여기다 먼저 정리한 후 올립니당.

에또.. 이 부분에 대해 개념을 가지신 그래픽 디자이너분이나 기획자분이 많지 않은 관계로,
게다가 이것이 설명된 책은 일단 프로그래머 책이다 보니 보기가 힘들고 (!!!) 그림을 대충 그려서 (!!!) 알아먹기가 보통 힘든게 아닌 관계로
좀 더 쉽게 만들어서 그래픽 디자이너나 기획자가 볼 수 있게 만들어 올려봅니다.

일단 Z 값의 구조는 다음과 같습니다.


 

ps: 으악 X와 Y가 바뀌었다.


모니터는 평면이지만, 그 안에는 가상의 3차원 메트릭스가 펼쳐져 있지요.
그래서 카메라 방향이 위 그림처럼 있다 치면, 화면에서의 깊이값이 바로 Z 방향입니다. 깊이라고도 하죠.

이건 어떨때 사용하느냐... 하면 어느 놈이 앞에 있냐? 랄때 사용합니다.

즉 아래 그림처럼 깊이값이 있다고 칩시다.


 

카메라와 가까운 곳은 0이고, 먼 곳은 9 겠지요. (진짜는 당연히 이정도가 아니겠지요.굉장히 큽니다. 물론 몇 비트로 지원해 주느냐에 대한 한계는 있지만.)
그런데 여기에 떡하고 평면이 나왔다 칩시다.


 

 4의 깊이에 평면이 있게 되는 거군요.
만약 이 뒤에 공이 있다면?




 

당연히 화면에서는 안보여야 정상입니다. 근데 어떻게 안보인다는걸 알 수 있습니까?
바로 '깊이값' 이 다르기 때문입니다.

plan 은 깊이 4에 있는데 공은 8 ~12  부근에 있습니다. 이걸로 뒤에 있다는걸 알 수 있다는 것입니다.
즉 모니터의 각 픽셀이  4의 위치에 있는 plan들로 채워져 있다는 것을 어디다가 적어 놔야 할 겁니다.  아래처럼 말입니다.  


 

그리고 이제부터 다른 걸 그릴때, 4보다 큰 숫자의 Z 값이 나오는 픽셀이면 안 찍어 버리면 되는 것입니다.

다시 말해서,  찍을때 보니 Z 값이 2나 3처럼 4보다 작은 (앞에 있는) 위치의 픽셀이면,
 이번엔 그 픽셀 부분을 다시 갱신해 버리고 찍어버리는 겁니다.



 

즉 이렇게 되는 거지요.


 

(* 주: 사실은 위 그림에서 공이 절반만 걸친 부분의 깊이값은 뭐냐.. .라고 혼동하실분이 계시겠지만, 실제로는 저 칸 하나가 한 픽셀이기 때문에 걱정하신것 같은 일은 안일어 납니다 ;ㅅ; 알아보기 쉽게 격자를 확대하다보니...)

그러므로 이런 깊이값은 지속적으로 저장되고 업데이트 되어야 합니다.
이것을 이미지로 만들어 놓은 것이 Z 버퍼라 불리는 그것입니다.

http://www.felixgers.de/teaching/jogl/depthbufferALgo.html

마치 fog와도 같게 생긴 Z 버퍼를 보시면, 검은 색은 카메라와 가까운 곳을 의미하고
흰색은 먼 곳을 의미한다는 것을 알 수 있습니다. (그리고 진짜로 fog도 이걸 이용합니다! )
 
이  z 버퍼의 좋은 점은, 찍는 순서고 나발이고 하나도 필요가 없다는 것입니다.
앞의 놈이 먼저 찍히나, 뒤의 놈이 먼저 찍히나 생각할게 없습니다. 아니 오히려 앞의 놈이 먼저 찍혀주는게 고맙지요.
뒤가 먼저 찍히면 뒤의 것을 그리고 Z 버퍼를 업데이트 한 다음에 다시 앞의 것을 그리고  Z  버퍼를 업데이트해 줘야 하지만 앞의 것을 한 번 그려놓으면 뒤의 것은 하나도 안그리면 되니까요.

이것이 Z 버퍼의 개념입니다. 간단하고 명쾌합니다.
그렇지만 , 반투명이 되어서 알파 블렌딩 (Alpha blending) 이 되면 얘기는 좀 심각해지게 됩니다 ....


Posted by 노을삼킨별
,

아래에서 퍼옴
http://eppengine.com/zbxe/programmig/3075

1. max sdk 를 설치하면 max sdk 폴더가 생성된다.

2. 생성된 max sdk 폴더에는 howto 라는 폴더가 존재한다.

3. 그 폴더 안쪽에는 다시 3dsmaxPluginWizard 라는 폴더가 존재한다.

4. 3dsmaxPluginWizard 폴더 안쪽에 있는 3dsmaxPluginWizard.vsz 폴더를 텍스트 문서 편집기로 연다.

5. 3dsmaxPluginWizard.vsz 에서 수정해야할 부분은 한군데가 있는데

   Param="ABSOLUTE_PATH = [Absolute Path Location of 3dsmaxPluginWizard Root Directory]"

요 부분이다.

6. 윗 부분을 wizard 가있는 절대경로를 입력한다. 예를들어

 예> Param = "G:\Program Files\Autodesk\3ds Max 2010 SDK\maxsdk\howto\3dsmaxPluginWizard"

요렇게..

7. 주의 사항은 위 폴더명 기록시 젤 뒤에 slash 를 붙여서는 안된다.

 예> Param = "G:\Program Files\Autodesk\3ds Max 2010 SDK\maxsdk\howto\3dsmaxPluginWizard \"

8. 그리고는 현재 visual stuido 폴더로 들어가서 vc 라는 폴더 아래에 있는 vcprojects 라는 폴더를 연다.

예> G:\Program Files\Microsoft Visual Studio 8\VC\vcprojects

9. 그 폴더 안쪽에 wizard 폴더에 있는 파일 3개를 복사한다.

  3dsmaxPluginWizard.ico
  3dsmaxPluginWizard.vsdir
  3dsmaxPluginWizard.vsz ( 위에서 수정한 파일이다. )

10. visual studio 를 새로 실행하면  max wizard 가 추가되어 있음.

Posted by 노을삼킨별
,

아래에서 퍼옴
http://eppengine.com/zbxe/2179

; 어두운 곳에서 spot light 와 같은 형태의 light source 가 있을때 우리는 shafts of light 를 볼 수 있다.

무대뒤의 조명과 같은 표현을  light shaft 라고 하며, 이러한 표현법에는 여러가지 방법이 있다.

대표적으로 많이 사용하는 방법중 2가지만 소개하겠다.

1. 빌보드 입자를 활용한 방법.

- 빌보드 입자를 활용한 방법은 라이트 위치에서부터 라이트 방향으로 수개의 빌보드 입자를 렌더링 하는 방법으로,

  라이트 위치에서의 깊이값을 활용하여 빛의 그림자 표현을 한다.

  라이트 위치에서부터의 깊이값을 렌더링 하고 안하고에 의해서 빛의 그림자를 만들수도 그렇지 않을수도 있으며
 
  렌더링된 깊이값을 활용하여, 스팟라이트 조명에의한 자연스런 그림자 연출이 가능하다.
 
  단점으로는 성능적인 부분과 빌보드 입자를 적게 사용했을경우 생기는 어색한 비쥬얼적인 부분.


2. 화면공간에서의 처리방법

- 화면공간에서 라이트의 위치를 기준으로 라이트 방향으로의 샘플링을 통해 처리하는 방법.

 장점은 특별한 소스코드의 변경없이 light shafts 처리를 할 수 있으며, 특히 그럴듯한 연출에도 불구하고
 
 퍼포먼스상의 저하를 많이 줄일 수 있다. ( screen 의 1/4 만큼의 텍스쳐를 활용하는 방법등을 활용)

 물론 적절한 선처리( 밝은부분검출과 검출된 부분을 활용한 빛의 늘여짐처리 )는 필수.

 

Posted by 노을삼킨별
,

아래에서 퍼옴
http://eppengine.com/zbxe/programmig/2982


SSAO (Screen Space Ambient Occlusion) 처리 기법(소스포함)

SSAO 는 최근에 많이 이슈가 되고 있는 GI 기법중 하나이다.
GI 라고 하면 단순히 모든 오브젝트가 빛을 발산하는 주체가 된다고만 생각하는데, (빛 반사를 통해.. )
빛으로인해 생겨지는 그림자 역시 GI중 하나이다.
SSAO 는 많은 사람들이 알고 있듯이 환경광 차폐를 화면공간에서 처리하는 기법으로
크게 깊이를 이용한 기법, 깊이와 상방벡터를 이용하는 기법 두가지가 있다.
환경광 차폐가 일어나는 경우에 대해서는 KGC2009 강연자료중 Lighting In Screen Space 의 ppt 자료를 참고.
여하튼.. 위에서 이야기한 두가지 기법 모두 장단이 있기에 적절한 방식을 선택해서 사용하면 되겠다.

uniform sampler2D som;  // Depth texture 

uniform sampler2D rand; // Random texture
uniform vec2 camerarange = vec2(1.0, 1024.0);
     
   float pw = 1.0/800.0*0.5;
   float ph = 1.0/600.0*0.5

   float readDepth(in vec2 coord) 
   { 
     if (coord.x<0||coord.y<0) return 1.0;
      float nearZ = camerarange.x; 
      float farZ =camerarange.y; 
      float posZ = texture2D(som, coord).x;  
      return (2.0 * nearZ) / (nearZ + farZ - posZ * (farZ - nearZ)); 
   }  

   float compareDepths(in float depth1, in float depth2,inout int far) 
   { 

     float diff = (depth1 - depth2)*100; //depth difference (0-100)
     float gdisplace = 0.2; //gauss bell center
     float garea = 2.0; //gauss bell width 2

     //reduce left bell width to avoid self-shadowing
     if (diff<gdisplace){
        garea = 0.1;
     }else{
        far = 1;
     }
     float gauss = pow(2.7182,-2*(diff-gdisplace)*(diff-gdisplace)/(garea*garea));

     return gauss;
   } 

   float calAO(float depth,float dw, float dh) 
   { 
     float temp = 0;
     float temp2 = 0;
     float coordw = gl_TexCoord[0].x + dw/depth;
     float coordh = gl_TexCoord[0].y + dh/depth;
     float coordw2 = gl_TexCoord[0].x - dw/depth;
     float coordh2 = gl_TexCoord[0].y - dh/depth;

     if (coordw  < 1.0 && coordw  > 0.0 && coordh < 1.0 && coordh  > 0.0){
     vec2 coord = vec2(coordw , coordh);
        vec2 coord2 = vec2(coordw2, coordh2);
        int far = 0;
     temp = compareDepths(depth, readDepth(coord),far);

        //DEPTH EXTRAPOLATION:
        if (far > 0){
          temp2 = compareDepths(readDepth(coord2),depth,far);
          temp += (1.0-temp)*temp2;
        }
     }

     return temp; 
   }  
    
   void main(void
   { 
     //randomization texture:
     vec2 fres = vec2(20,20);
     vec3 random = texture2D(rand, gl_TexCoord[0].st*fres.xy);
     random = random*2.0-vec3(1.0);

     //initialize stuff:
     float depth = readDepth(gl_TexCoord[0]); 
     float ao = 0.0;

     for(int i=0; i<4; ++i)
     { 
       //calculate color bleeding and ao:
       ao+=calAO(depth,  pw, ph); 
       ao+=calAO(depth,  pw, -ph); 
       ao+=calAO(depth,  -pw, ph); 
       ao+=calAO(depth,  -pw, -ph);

       ao+=calAO(depth,  pw*1.2, 0); 
       ao+=calAO(depth,  -pw*1.2, 0); 
       ao+=calAO(depth,  0, ph*1.2); 
       ao+=calAO(depth,  0, -ph*1.2);
    
       //sample jittering:
       pw += random.x*0.0007;
       ph += random.y*0.0007;

       //increase sampling area:
       pw *= 1.7
       ph *= 1.7;   
     }        

     //final values, some adjusting:
     vec3 finalAO = vec3(1.0-(ao/32.0));


     gl_FragColor = vec4(0.3+finalAO*0.7,1.0); 
   } 

장점 : 따로 blur pass 를 실행할 필요가 없다. ( 랜덤맵 텍스쳐를 활용하기에 가능한 부분)
         시각적 품질이 나쁘지 않다.
         노멀 버퍼없이도 깔끔하다.

단점 : 전통적 ssao 보다는 좀 느리다.
         역시 노멀 버퍼를 사용하지 않는 것 으로 인한 약간의 시각적 어색함이 존재.. 약간...


'게임 개발 > 3D 게임 플밍' 카테고리의 다른 글

3d max plugin wizard 생성하기  (0) 2010.03.17
Light Shaft  (0) 2010.03.17
SSGI 관련 정리 (소스 포함)  (0) 2010.03.17
언리얼 엔진 3 ( Unreal Engine 3 )  (0) 2009.12.03
BSP를 이용한 3D Game Programming  (0) 2005.11.16
Posted by 노을삼킨별
,

아래에서 퍼옴
http://eppengine.com/zbxe/2985#2



SSGI 는 GI 를 화면공간에서 처리하는 기법으로 화면상에 나타나 있는 모든 오브젝트들은 빛을 반사하여 발광하는 주체가 된다는 개념으로 예를들어, 붉은색 대리석 바닦에 놓여 있는 오브젝트의 경우 아래쪽은 ( 대리석과 맞닿아 있는 부분) 붉은색 빛이 표현 되어져야 한다 는 개념. 물론 SSGI 는 태생적으로 화면공간에서의 처리기법 이므로 화면밖의 오브젝트에대해서는 GI 개념을 적용하기가 애매한 부분이 있다. 전 처리를 통해 물론 해결은 가능하지만, 일반적인 기법에서는 화면밖의 붉은색 오브젝트는 화면안쪽에 있는 어떠한 오브젝트에도 영향을 주지 못한다.
그럼에도 SSGI 를 사용하지 않는 경우보다 훨씬 사실적이고 자연스러운 표현이 가능하다.
SSGI 는 크게 3가지 방식으로 사용되는데 전처리를 통해 마스킹 해 놓는 방식, 깊이만을 활용한 방식, 깊이와 노멀을 둘다 활용하는 방식이 있다. 아래는 깊이만을 활용한 방식이다.

uniform sampler2D som;  // Depth texture 
uniform sampler2D rand; // Random texture
uniform sampler2D color; // Color texture


uniform vec2 camerarange = vec2(1.0, 1024.0);
     
   float pw = 1.0/800.0*0.5;
   float ph = 1.0/600.0*0.5

   float readDepth(in vec2 coord) 
   { 
     if (coord.x<0||coord.y<0) return 1.0;
      float nearZ = camerarange.x; 
      float farZ =camerarange.y; 
      float posZ = texture2D(som, coord).x;  
      return (2.0 * nearZ) / (nearZ + farZ - posZ * (farZ - nearZ)); 
   }  

   vec3 readColor(in vec2 coord) 
   { 
     return texture2D(color, coord).xyz; 
   }

   float compareDepths(in float depth1, in float depth2) 
   { 
     float gauss = 0.0;
     float diff = (depth1 - depth2)*100.0; //depth difference (0-100)
     float gdisplace = 0.2; //gauss bell center
     float garea = 3.0; //gauss bell width

     //reduce left bell width to avoid self-shadowing
     if (diff<gdisplace) garea = 0.2;

     gauss = pow(2.7182,-2*(diff-gdisplace)*(diff-gdisplace)/(garea*garea));

     return max(0.2,gauss); 
   } 

   vec3 calAO(float depth,float dw, float dh, inout float ao) 
   { 
     float temp = 0;
     vec3 bleed = vec3(0.0,0.0,0.0);
     float coordw = gl_TexCoord[0].x + dw/depth;
     float coordh = gl_TexCoord[0].y + dh/depth;

     if (coordw  < 1.0 && coordw  > 0.0 && coordh < 1.0 && coordh  > 0.0){

     vec2 coord = vec2(coordw , coordh);
     temp = compareDepths(depth, readDepth(coord));
        bleed = readColor(coord);

     }
     ao += temp;
     return temp*bleed; 
   }  
    
   void main(void
   { 
     //randomization texture:
     vec2 fres = vec2(20,20);
     vec3 random = texture2D(rand, gl_TexCoord[0].st*fres.xy);
     random = random*2.0-vec3(1.0);

     //initialize stuff:
     float depth = readDepth(gl_TexCoord[0]);
     vec3 gi = vec3(0.0,0.0,0.0); 
     float ao = 0.0;

     for(int i=0; i<8; ++i)
     { 
       //calculate color bleeding and ao:
       gi += calAO(depth,  pw, ph,ao); 
       gi += calAO(depth,  pw, -ph,ao); 
       gi += calAO(depth,  -pw, ph,ao); 
       gi += calAO(depth,  -pw, -ph,ao);
    
       //sample jittering:
       pw += random.x*0.0005;
       ph += random.y*0.0005;

       //increase sampling area:
       pw *= 1.4
       ph *= 1.4;   
     }        

     //final values, some adjusting:
     vec3 finalAO = vec3(1.0-(ao/32.0));
     vec3 finalGI = (gi/32)*0.6;

     gl_FragColor = vec4(readColor(gl_TexCoord[0])*finalAO+finalGI,1.0); 
   } 


장점, 단점은 ssao 랑 비슷

'게임 개발 > 3D 게임 플밍' 카테고리의 다른 글

Light Shaft  (0) 2010.03.17
SSAO (Screen Space Ambient Occlusion) 처리 기법(소스포함)  (0) 2010.03.17
언리얼 엔진 3 ( Unreal Engine 3 )  (0) 2009.12.03
BSP를 이용한 3D Game Programming  (0) 2005.11.16
GLUT 시작  (0) 2005.11.11
Posted by 노을삼킨별
,
아래에서 퍼옴
http://blog.naver.com/kingsalsero?Redirect=Log&logNo=70015615005


언리얼 엔진 3 ( Unreal Engine 3 )

가격
· 1 타이틀당 $500,000 (업그레이드 1년간 지원)
o 1년 후 업그레이드 1년에 $100,000
§ 원래는 크게 두가지의 버전으로 나뉘어서 언리얼 엔진 3.0 최종버전 (2008년)까지 무상 업그레이드, 언리얼 엔진 3.5 (2010년)는 추가로 비용을 지불 하고 업그레이드 받게 할 정책이었으나 업데이트의 빈도가 잦고 업데이트 내용이 많고 새로운 기술, 툴, 서드파티 기술의 IPP의 추가가 많아짐에 따라서 크게 3.0, 3.5로 두가지 버전으로 나누지 않고 언리얼 엔진 4가 나오기 이전인 2010년까지 지속적으로 꾸준한 업데이트가 되며 1년당 유지보수 비용을 받는 정책으로 바뀌었다. 업데이트는 꾸준하게 진행된다. 1년간 업데이트가 $100,000씩 하는 이유는 꾸준한 버전업에 엔진과 툴셋의 많은 기능개선과 발전이 있기 때문이다.
o 1 플랫폼 추가당 $50,000
o 멀티플 라이센스시 타이틀당 가격이 내려간다.
· 계약 조건에 따라서 가격이 상이하게 다르다.
엔진 역사 : (이전 역사는 언리얼 엔진 2 참고)
언리얼 엔진 2.0은 매우 많은 게임들에 사용되었으며 PC용 FPS에서는 거의 언리얼 엔진이 관례가 되었다. 이 후에 64비트의 지원과 여러가지 향상점이 있는 언리얼 엔진 2.5가 나오고 그 다음 버전으로 현재의 언리얼 엔진 3.0이 나온다.
언리얼 엔진 3.0은 기존의 장점인 깔끔한 코드 구조가 더욱 커스터마이징하기에 좋고 확장성이 더욱 증대되어 이전 버전보다도 더욱 융통성이 좋게 개선되었으며 개발 툴 역시 전보다 많은 진보를 이루어서 차세대 게임 개발에 편리한 많은 잇점을 제공한다. 뿐만 아니라 이제는 더 이상 FPS 장르에만 특화된 게임 엔진이 아니며 모든 장르를 쉽게 수용할 수 있는 구조로 크게 개선이 되었으며 엔진 코드와 게임 코드의 뚜렷한 경계를 지었음에도 엔진의 유연성과 코드의 연동성은 기존보다 더 개선되었기 때문에 프로그래밍시의 많은 기술적 난점을 해소하였다. 그리고 이젠 PC 뿐만 아니라 콘솔 기기도 본격적으로 지원을 함으로서 차세대 콘솔을 완벽지원하며 차세대 콘솔 기기인 Xbox 360와 PlayStation 3의 공식 미들웨어로 언리얼 엔진 3가 선정되었다.
지금 해외에선 언리얼 엔진 3가 차세대 콘솔 및 PC 게임 개발의 관례가 되어있으며 앞으로 게임 엔진 미들웨어의 중요성과 필요성이 점점 부각되어가고 있는 시점에서 지난 콘솔 세대의 미들웨어 선두주자인 렌더웨어(RenderWare)를 완전히 압도적으로 제치고 게임 엔진 미들웨어 시장의 선두주자로 달리고 있다.
렌더웨어가 단순히 그래픽스 라이브러리에 그쳐있는 반면에 언리얼 엔진은 버전업을 거듭하면서 방대한 게임 엔진으로 거듭났고 단순히 방대한게 아니라 방대한 엔진이 깔끔한 구조와 편리한 개발툴을 제공함으로서 개발 프로세서에 큰 향상을 주기 때문에 개발자들에게 크게 각광받고 있다.
언리얼 엔진 3가 처음 라이센스되기 시작했을 때는 미완성된 엔진이라는 말들도 조금 떠돌기는 했었으나 2007년 3월 현재는 매우 안정성이 좋으며 이전보다 더 향상된 툴과 나아진 엔진의 퍼포먼스와 다양한 미들웨어 IPP를 제공함으로서 훨씬 향상된 모습을 갖추고 있다.
언리얼 엔진 3는 다음 세대의 언리얼 엔진인 언리얼 엔진 4 (2010년 말경이나 2011년 초경에 출시할 예정이다)가 나오기 이전인 2010년까지 꾸준하게 현저한 향상과 두드러지게 새로운 특징들의 추가(significant enhancement and adding major new features)가 있을 것이라고 강조하고 있다.
· 작년 11월에 발매된 기어스 오브 워에 쓰인 언리얼 엔진 3 버전과 현재 2007년 3월자 언리얼 엔진 3 최신 버전을 비교해보면 불과 몇달정도 사이에 큰 렌더링 엔진이나 여러가지 부분에서 큰 향샹이 이루어졌다.
개발사 : 에픽 게임즈 (Epic Games)
엔진 타입 : 통합형 범용 게임엔진
· 언리얼 엔진 3는 더 이상 FPS에 특화된 게임엔진이 아니다. 언리얼 엔진 2를 포함한 쥬피터 엔진 시리즈, 시리어스 엔진 시리즈, 크라이 엔진 시리즈등의 다른 통합형 FPS 게임엔진들은 기본적으로 FPS에 맞추어진 엔진이라서 MMORPG나 다른 장르의 개발시에 변경에 어느정도의 어려움이 있다. 하지만 언리얼 엔진 3는 그런 어려움이 전혀 없이 매우 순조롭게 커스터마이징이 가능하다. 다양한 장르를 고려하기 때문에 심리스 월드도 기본 지원된다. 그리고 FPS용 네트워크 엔진이나 MMO용 네트워크 엔진이 따로 제공되며 액션 게임용 인공지능 엔진이나 MMO용 길찾기 엔진등 다양한 게임의 환경과 기획과 문제점들을 고려한 기술들이 제공된다.
엔진 구성 및 업데이트
· 이전까지와는 다르게 게임 코드와 엔진 코드가 완전히 분리되어 제공된다. 즉, 순수한 언리얼 엔진으로서 코드가 제공되는 것이다. 그리고 게임 코드와 엔진 코드 및 확장 모듈등의 각 코드간의 경계를 이전보다 더욱 명확하게 함으로서 엔진의 구조적 융통성과 커스터마이징이 용이한 구조와 뛰어난 확장성은 전보다 더욱 강화되었다.
o 그리고 보너스로 에픽에서 개발하는 게임의 모든 소스 코드도 제공된다.
· 엔진의 build 넘버가 올라갈수록 더 엔진에 기능이 추가되거나 새 툴셋이 추가되거나 기존의 성능이 더 향상된다. 기어스 오브 워가 나왔을 때의 엔진보다 언리얼 토너먼트 3에 사용되고 있는 엔진의 버전이 더 높으며 기능이 더 많고 더 최신 기술들이 사용되었다. PC 버전에서는 새로이 출시되는 하드웨어를 활용한 새로운 기술들이 지속적으로 업데이트 되며 콘솔 버전에서도 기술의 추가가 똑같이 이루어지지만 PC에서만 사용 가능한 기술들이 더 많다. 그리고 엔진 버전업이 되면서 최적화 작업도 계속 이루어진다.
제공되는 소스
· 순수한 Unreal Engine 3 (UnrealEd 및 모든 유틸리티 포함)의 Full source code
o 매주 업데이트되는 Unreal Engine 3의 새로운 버전 build codedrop
· Epic의 Unreal Engine 3 사용 게임들의 Full source code
o Gears of War의 Full source code
o Unreal Tournament 3의 Full source code
· UDN에서 Demiurge Studios에 의해 지속적으로 추가 제공되는 Customize code와 Example code
제공되는 툴
· UnrealEd (언리얼 에디터)
o 기본적인 모습으로는 언리얼 엔진 2의 것과 거의 유사한 모습이지만 다수의 변경과 기존 기본적인 인터페이스 및 기능의 향상이 이루어졌으며 비주얼 셰이더 시스템이나, 파티클, 컷신툴 인공지능 툴셋, 사운드 설정 툴셋, 비주얼로 게임 스크립트짜는 툴같은 기존의 툴들의 성능 및 옵션 개선 및 새로운 툴 추가, 모든 툴은 UnrealEd 내부에 통합되어 있으며 각 툴간에 긴밀하게 상호 연동된다. 
o 주요 세부 툴
§ UnrealMatinee :UnrealEd 내에서 편리하게 도와주는 컷신 제작 툴셋 (언리얼 엔진 2버전에 비해 비약적으로 향상) 
§ UnrealCascade : 언리얼 엔진 2의 파티클 위저드 및 언리얼 엔진 2.5의 파티클 시스템 에디터에 비해서 비약적으로 향상된 파티클 툴셋 
§ UnrealKismet : 게임 플레이나 인공지능 설정등의 모든 스크립팅을 플로우챠트 형식으로 만들어서 비주얼적으로 개발하는 툴셋, UnrealScript를 자동 생성하며 UnrealMatinee로 컷신 스크립트를 짤때도 사용 가능하며, UnrealEd 내의 모든 툴의 스크립트 생성에 사용 가능하다.  
§ Visual Material Editor : 비주얼 툴셋으로 재질 셰이더를 설정하면 자동으로 Cg와 HLSL코드가 생성된다.  
§ Visual Terrain Editor : 실시간 비주얼로 보이는 그대로 지형을 생성하고 초목을 장식하고 광활한 실외 지역을 작업하는 툴 
§ SoundCue Editor : 사운드의 설정을 해주는 툴로 작업환경 전체에 걸쳐서 다양한 세부적 사운드 설정을 해주는 툴 
§ UnrealPhAT : 물리의 모든 세부적인 설정을 해주는 툴로서 게임내 모든 환경과 오브젝트, 탈것, 캐릭터에 물리를 실시간으로 세부적인 설정이 가능한 툴  
§ AnimSet Editor : 모든 애니메이션 세트와 애니메이션 시퀀스를 설정하는 툴 
§ AnimTree Editor : 애니메이션을 비주얼 트리 모양으로 나열해서 한눈에 알아보기 쉽게 구성해 놓고 설정을 할 수 있는 툴 
§ Script Editor : UnrealEd 내에서 모든 스크립트를 바로 열어서 확인 가능하고 수정한 후에 즉석에서 인터프리팅해서 실행할 수 있으며 컴파일해서 적용 시킬수도 있는 툴 
§ Play In Editor : 툴 내에서 직접 모든 것이 적용된 게임 자체를 돌려서 확인하고 작업할 수 있는 툴 
· COLLADA import path for meshes and animation
· 적당한 노말값을 추정하여 노말맵을 생성하는 툴  2,000,000 폴리곤 (노말맵을 추출할 모델)  5,287 폴리곤 (실제 게임에 사용될 모델)  5,287 폴리곤이 사용된 모델에 노말맵을 적용(엔진상에서 보이는 모델)  1,000,000의 폴리곤으로 노말맵을 추출해서 적용한 배경씬  실제 게임상의 폴리곤 수는 500,000
· 디버깅 툴
· 퍼포먼스 모니터링 툴
· UnrealActorX Exporter
o 3D Studio MAX 플러그-인
o MAYA 플러그-인
o Softimage XSI 플러그-인
o 3D Studio MAX, MAYA, Softimage XSI에서 만든 메쉬를 UnrealEd로 곧 바로 적용할 수 있는 플러그-인이다.
· Unreal Engine 3 IPP의 모든 툴셋이 UnrealEd에 연동
o PhysX 물리 엔진 툴셋
§ PhysX 물리 엔진에서 제공하는 SDK 툴셋과 유틸리티들
o FaceFX 툴셋
§ FaceFX에서 제공하는 페이셜 애니메이션 및 립싱크 제작 툴셋
o 이 외에도 Unreal Engine 3 IPP의 툴들을 포함한 다른 툴들이 더 존재하며 언리얼 엔진 3는 2010년까지 업데이트 될 예정으로서 앞으로도 더 많은 툴셋과 유틸리티들이 추가 될 예정에 있다.
제공되는 컨텐츠
· Unreal Engine 3 Example
· Epic의 Unreal Engine 3 사용 게임들의 Example
o Gears of War의 Example contents
o Unreal Tournamentr 3의 Example contents
o Unreal Engine 3 Example contents는 상용 프로젝트에 도입해도 상관없으나 Gears of War나 Unreal Tournament 3의 Example contents는 상용 프로젝트에 도입하면 안된다. 참고용으로만 사용해야 한다.
· Demuirge Studio의 다양한 예제
o Demiurge Studio는 Unreal Developer Network의 지원팀으로 언리얼 엔진의 QA와 개선사항을 담당하고 엔진의 활용법과 다양한 예제를 개발하고 지원팀으로서 Q&A를 진행해준다.
엔진 개발사에서 만든 게임
· 기어스 오브 워
o Xbox 360 - 2006년 11월 7일 출시
o PC - 2008년 출시 예정
· 언리얼 토너먼트 3
o PC - 2007년 출시 예정
o Xbox 360 - 2007년 출시 예정
o PlayStation 3 - 2007년 출시 예정
· 기어스 오브 워 2
o Xbox 360- 개발 예정
o PC - 개발 예정
· 언리얼 3
o PC - 개발 예정
o Xbox 360 - 개발 예정
o PlayStation 3 - 개발 예정
이 엔진을 사용한 대표적인 게임
· 기어스 오브 워
· 레인보우 식스 베가스
· 언리얼 토너먼트 3
· 헉슬리
· 리니지 3
국내에서 쓰이는 게임
· 웹젠의 헉슬리
· 레드덕의 아바와 프로젝트 M(신작 MMORPG라고 한다)
· NC소프트의 리니지 3와 프로젝트 M(김형태씨가 참여해 만드는 MMORPG라고 한다) 및 온라인 FPS 게임을 비롯한 몇개의 작품들
· 소프트맥스의 마그나 카르타 2(Xbox 360용)
· 애니파크의 A4(A3 차기작이며 A4는 임시제목이다)
· CJ 인터넷의 미발표한 MMOG
· N모사의 신작 MMORPG (NC말고 다른 N모사)
· 모사의 프로젝트 F (기사에는 모회사의 프로젝트 F가 언리얼 엔진 3를 사용한다고 나옴)
· 그 외에 아직 미발표한 다수의 개발사들이 언리얼 엔진 3를 사용해서 개발중인데 국내에서는 대부분 FPS나 MMORPG가 많다.
국내에서 엔진을 쓰다가 게임이 취소된 경우
· 웹젠의 PlayStation 3용 게임인 엔드리스 사가
o 언리얼 엔진 3가 게임과 맞지 않다거나 엔진 자체의 문제점으로 취소된 것은 아니고 PlayStation 3의 열악한 개발조건과 회사 수지타산이 맞지 않아서 취소된 경우이다.
§ 그러나 라이센스비용이 낭비된 것은 아니다. 웹젠은 이미 언리얼 엔진 3를 사용해서 헉슬리를 개발하고 있었으며 엔드리스 사가도 언리얼 엔진 3를 사용해서 개발했지만 이미 한번 라이센스 한 상태에서 비용은 더 들지 않으며 게임이 완성되어 출시했을 때 추가비용이 들어가는 것이기 때문이다.
· 엔드리스 사가 외에는 취소된 경우가 아직까지는 없다.
해외에서 쓰이는 게임
· 뛰어난 기술력과 편리한 차세대 툴셋과 뛰어난 확장성으로 PlayStation 2 및 Xbox 세대에서 표준으로 사용되던 렌더웨어(RenderWare)를 제치고 PlayStation 3 및 Xbox 360 세대부터는 콘솔 및 PC 게임 및 온라인 게임 개발 시장을 장악하다시피 하고 있다.
· 다양한 장르에 많이 쓰이며 FPS나 3인칭 액션, 어드벤쳐, RPG, RTS, 카툰 스타일의 캐주얼 게임, MMORPG등 장르를 구분하지 않고 많이 쓰인다.
· MMPOG들도 이미 상당수가 언리얼 엔진 3를 채용하고 있다.
o 시질 게임즈 온라인의 뱅가드 : 사가 오브 히어로즈 (Vanguard : Saga of Heroes)의 확장팩 (뱅가드 원본은 언리얼 엔진 2를 사용해서 만들어졌다)과 차기작
o 샤이안 마운틴 엔터테인먼트의 스타게이트 월즈 (Stargate Worlds)외에 신작 게임들을 언리얼 엔진 3를 사용하여 더 개발할 예정임
o 소니 온라인 엔터테인먼트의 DC 코믹스/유니버스 온라인(DC Comics/Universe Online)와 에버퀘스트 3를 포함해 총 5종의 온라인 게임을 언리얼 엔진 3를 사용해 개발 중
o 오란(Auran)의 퓨리 (Fury)외에 신작 게임들을 언리얼 엔진 3를 사용하여 더 개발 할 예정임
o 보그스터 엔터테인먼트 (Vogster Entertainment)의 크라임크래프트 (Crimecraft)외에 신작 온라인 게임 몇종을 더 언리얼 엔진 3를 사용해 개발 중
o 마이크로소프트 게임 스튜디오의 신작 온라인 게임들 몇종을 언리얼 엔진 3를 사용해 개발 중
o 리얼 타임 월즈 (Realtime Worlds)의 APB (All Point Bulletin)
o 중국의 개발사 천청의 신작 MMORPG
o 중국의 개발사 소프트-월드 (Soft-World)의 신작 MMORPG
o 이 외에 다수의 개발사들이 언리얼 엔진 3를 사용해 온라인 게임을 개발중이거나 개발할 예정에 있다.
· RTS 장르를 만들기 위해서도 이미 몇 개발사들이 언리얼 엔진 3를 채용하고 있다
o 에이지 오브 엠파이어 (Age of Empire) 시리즈를 만든 앙상블 스튜디오 (Ensemble Studios)에서 언리얼 엔진 3를 사용해서 헤일로 워즈 (Halo Wars)와 새 RTS 게임을 만들고 있다.
o 코헨 (Kohan) 시리즈의 개발사인 타임 게이트 스튜디오 (TimeGate Studios)는 언리얼 엔진 3를 다중 라이센스 계약해서 신작 RTS와 신작 FPS와 신작 RPG 타이틀을 사용할 계획에 있다
· 현재까지 약 50여곳 이상의 업체에서 현재 300여개 이상의 타이틀 개발중, 더 늘어날 것으로 추정된다.
o 소규모 개발사에서는 싱글 라이센스로 사용하거나 큰 유통사의 지원을 받아 사용하는 경우가 많다
o 대규모 개발사에서는 대부분 멀티플 라이센스 계약을 체결해서 사내의 여러 스튜디오 및 팀에서 사용하게 한다.
· 특히 엔진 구조가 매우 플랙시블한 장점을 한껏 활용해서 대형 회사같은 경우에는 멀티플 라이센스로 회사 전체에서 공유하면서 여러 게임에 커스터마이징 되고 그렇게 된 부분들의 장점들을 또 다시 추려내서 각 게임마다 다시 적용하는게 쉬워서 그런 장점으로도 많이 사용되고 있다. 깔끔하고 좋은 코드의 구조와 연동성을 갖지 못한 엔진은 그렇게 할 수 없다. 그런 경우엔 코드가 거의 엉망진창이 된다.
o 언리얼 엔진 2는 특히 유비소프트에서 그렇게 잘 사용하였다.
o 언리얼 엔진 3는 그렇게 사용하는 개발사가 상당히 많다. 해외 서양쪽이나 일본쪽의 대형 유통사 및 개발사들의 경우에 많은 회사들이 다수의 게임에 사용하기 위해서 언리얼 엔진 3를 멀티플 라이센스를 하였다. 언리얼 엔진 3부터는 그런 장점들이 타 플랫폼으로의 이식에도 용이하도록설계되어 있다.
업데이트 : 지속적으로 개량 중, 최적화, 새로운 렌더링 기술, 새로운 툴셋, 기타 요소 등등
· 언리얼 엔진 3는 현재 64-bit 프로세싱, PC와 차세대 콘솔 기기들의 멀티 쓰레딩, Windows Vista와 Direct3D 10의 완전한 활용 및 복셀 렌더링, 새로운 지형 시스템, 실시간 래디오시티같은 신기술이 구현되어 있으며 앞으로도 언리얼 엔진 4가 출시되기 이전인 약 2010년정도까지 계속해서 꾸준하게 엔진이 버전업 되면서 신기술의 추가와 더 편리한 툴셋과 IPP의 추가등 현격한 향상이 있을 것이다.
언리얼 엔진 3의 특징
· C++ DLL 모듈 기반
o Plug-in 컴포넌트화
· 기존의 언리얼 엔진 2보다도 더욱 커스터마이징이 용이한 구조로 개선되었다.
o UnrealScript의 사용으로 여러 모듈 결합이 매우 용이한 점은 전보다 더욱 확장하기 쉽게 개선되었다.
§ 언리얼 엔진이 다른 엔진들과 가장 차별화되는 독보적인 특징으로서 UnrealScript를 사용하여 다양한 모듈을 제어하고 연동할 수 있다는 점이다.
§ 언리얼 엔진에서는 모든 모듈이 언리얼 엔진에서 정의한 각각의 모델로 구성되어 있으며 기존의 존재하는 모델이나 모델 타입 또는 새로운 모델이나 새로운 모델 타입을 추가/변경/삭제가 가능하며 이 모든 것들은 커스터마이징이 가능하다.
§ 모든 모듈과 모델은 UnrealScript를 통해 언리얼 엔진 전체와 매우 유연하게 연동된다. 직접 엔진 코드와 네이티브 코드를 연동을 시키지 않고서도 UnrealScript만을 사용해서도 외부의 모듈을 언리얼 엔진 내에 연동 시켜서 사용할 수 있으며 이런 연동 작업은 UnrealEd 내에서 매우 간단하게 가능하다. UnrealScript를 쓰지 않고 네이티브 코드만 연동 시키는 경우에도 유연한 코드 구조 덕분에 다른 엔진보다 쉬운 장점을 제공하지만 UnrealScript를 쓰는 것은 전혀 어렵지 않으므로 꼭 쓰길 권한다.
o 엔진 제어나 연동 외에도 게임 플레이 스크립트도 UnrealScript로 작성할 수 있다.
§ 게임 플레이 프로그래머/스크립터의 취향이나 성향에 따라서는 C#, Java Script, Rube, Lua와 같은 외부 언어를 적용하거나 외부 언어와 UnrealScript 동시 사용이 가능하다.
§ UnrealScript와 외부 언어 2개 이상 또는 외부 언어만 2개 이상을 동시 사용하는 것도 유연한 코드 구조 덕분에 쉽게 가능하다.
§ 각각 모듈별로 언어를 적용하여 사용이 가능하다.
· UnrealEd와 그 내부의 세부 툴은 C#이나 Visual Basic, Java APP등의 언어로 개발하여 연동하기가 쉬우며 이식도 간단하게 가능하다.
· 엔진 코드와 게임 코드의 명확한 경계로 프로그래밍이 훨씬 수월하게 개선되었다. 언리얼 엔진 2까지는 엔진 코드와 게임 코드가 어느정도 상호 의존적이었다. 그러나 언리얼 엔진 3에서는 그 구분이 더욱 명확해져서 프로그래밍 작업상의 훨씬 효율적인 잇점을 제공한다.
o 엔진을 커스터마이징하여 게임을 개발하던 도중 엔진을 업그레이드 하거나 다른 변경 사항을 적용해도 엔진을 크게 다시 손 볼 필요가 없이 손쉽게 적용 가능하다.
o 각 부분의 코드들의 명확한 경계가 있지만 내부적으로 연동성은 매우 좋다.
· Unreal Engine 3 IPP (Integrated Partners Program)
o 언리얼 엔진 3에선 IPP를 추진하고 엔진에 지속적으로 업데이트 해나간다. 언리얼 엔진 3 IPP는 에픽 자체의 기술이 아닌 외부의 각 분야마다 최고의 미들웨어 솔루션을 라이센스 해서 언리얼 엔진 3에 통합하는 것으로서 그 것은 렌더링 관련, 사운드, 네트워크, 인공지능과 같은 각 분야별 관련 미들웨어나 SDK, 그리고 외부의 다양한 툴셋마저도 통합하는 것을 포함하며 IPP에 포함된 미들웨어들의 라이센스 비용을 따로 필요로 하지 않으며 모두 언리얼 엔진 3 사용 개발사들에게 무상 제공된다. 언리얼 엔진 3 IPP가 생기게 된 연유는 다음과 같다.
§ 현재는 기술의 발전으로 게임 개발에는 고도의 프로그래밍 기술이 필요하게 됐으며 그에 따라서 상용 엔진의 사용이 대세이다. 계속 발전하는 기술은 분야별로 세밀한 각각의 전문적인 엔진들 (렌더링, 애니메이션, 라이팅, 지형, 인도어, 물리, 사운드, 네트워크, 인공지능, 립싱크, 초목 구현 등)에 따라서 한 분야별 엔진들이 만들어지고 라이센스 되기 시작했다. 이 것은 엔진 개발 비용상으로도 어쩔 수 없는 문제이기도 하지만 발전하고 복잡해진 기술로 인해서 각각의 분야별로 전문적인 최고의 솔루션이 만들어지기 위해서는 어쩔 수 없는 현상이다.
o 언리얼 엔진 3는 이러한 각 분야마다 최고의 기술들을 제공하기 위해서이며 또한 만들고자 하는 게임에 따라서도 요구하는게 달라질 수 있으므로 같은 분야라도 (네트워크 부분의 모듈은 현재까지 자체 1개와 2개가 추가됐고 라이팅 관련은 자체와 IPP 1개, 인공지능은 자체 1개와 IPP 2개 등) 여러가지의 외부 기술들을 라이센스 해서 언리얼 엔진 3에 포함함으로서 진정한 최고의 범용 게임 엔진으로서의 길을 걷고 있다. 외부의 기술은 언리얼 엔진 3 라이센스시 그냥 번들 형태로 제공되는게 아니라 언리얼 엔진 3의 잘 짜여진 구조를 바탕으로 외부의 모든 모듈들이 서로간에 긴밀하게 연동되어 있으며 언리얼 엔진 3를 라이센스하면 이 모든 외부 IPP 기술들을 추가적인 비용없이 무상으로 제공받을 수 있다. 연동된 기술들은 언리얼 엔진 3 구조하에 연동된 만큼 언리얼 엔진 3의 기본적인 구성요소와 마찬가지로 UnrealScript를 통해 제어할 수 있으며 UnrealEd에서 곧 바로 사용 가능하며 언리얼 엔진 3의 기본적인 확장 기능성과 마찬가지의 특성을 가지고 있으므로 언리얼 엔진 3와 따로 떨어진 상태로 외부 미들웨어 모듈을 직접 사용하는 것보다 언리얼 엔진 3상에서 순조롭게 커스터마이징이 가능한 잇점도 제공한다. 그리고 언리얼 엔진 3 IPP에 포함된 미들웨어들은 한번의 업데이트로 끝나는 것이 아니라 해당 미들웨어들의 버전업을 수시로 체크하여 언리얼 엔진 3에 지속적으로 최신 버전으로 업데이트 된다.
플랫폼 지원
· 32-bit Windows (Windows XP/Vista, Windows Vista와 DirectX 10 완벽 대응)
· 64-bit Windows (Windows XP/Vista, Windows Vista와 DirectX 10 완벽 대응)
· 32-bit Linux
· 64-bit Linux
· Mac OS X
· Xbox 360 (Gears of War를 통해 Xbox 360상에서의 성능은 충분히 증명이 되었으나 더 향상을 위해 개선중에 있다)
· PlayStation 3 (아직 퍼포먼스상에 문제가 있다. 계속 개선중에 있다)
멀티 쓰레딩
· Xbox 360 (Xenon 프로세서의 트리플 코어에 최적화된 멀티 쓰레딩)
· PlayStation 3 (Cell 프로세서의 다중 코어에 최적화된 멀티 쓰레딩)
· PC (2-코어, 4-코어, 8-코어에 각각 최적화된 멀티 쓰레드 렌더링/멀티 쓰레딩/멀티 쓰레드 프로세싱)
o 렌더링 시스템을 멀티 쓰레드로 처리
o 렌더링, 물리 연산, 인공지능, 사운드를 각각 멀티 쓰레드로 처리
o 기타 모듈을 멀티 쓰레드로 지정하여 처리
로딩 시스템
· Zone-based Loading System
· Backgrounds Loading System
· Seamless Loading System
렌더링 엔진
· 멀티 쓰레딩 렌더링 지원
· 렌더링 API 지원
o Direct3D 9 (Windows XP/Vista, Xbox 360)
o Direct3D 10 (Windows Vista)
o OpenGL 2 (Windows XP/Vista, Linux, MacOS X, PlayStation 3)
· 하드웨어 쉐이더 (Hardware shader)
o 쉐이더 모델 2b (Shader model 2b) 하위 호환
o 쉐이더 모델 3 (Shader Model 3) 완벽 지원
o 쉐이더 모델 4 (Shader Model 4) 완벽 지원
§ 지오메트리 쉐이더 (Geometry Shader) 완벽 지원
o 쉐이더 모델 5 (Shader Model 5) 곧 지원 예정
· 인도어 (BSP, CSG, PVS, Occlusion Culling, Static Meshes, Voxel Spaces)   
· 아웃도어 (Height-mapped Terrain, Voxel Terrain)  스크린샷은 구버전으로 최신버전은 이것보다 훨씬 향상되었다.
· 라이팅 & 쉐도우
o High Dynamic Range Rendering/Lighting 
o Per-pixel Diffuse/Specular Lighting 
o Volumetric Lighting
o Stencil Dynamic Shadow Volumes
o Ultra Extreme Multi-sampled High Quality Soft Shadows
o Dynamic Fuzzy Soft Shadows  
o Self-shadows
o Geomerics의 Enlighten이 통합되어 있다. (Unreal Engine 3 IPP)
§ Global Illumination/Radiosity를 구현하고 재반사의 의해 생성되는 Soft Shadows를 실시간으로 구현하는 미들웨어 라이팅 엔진이다.
· 텍스처링
o Alpha Blending
o Light Mapping and Shadow Mapping
o Multi-pass Normal-mapping (Normal map/Bump map/Specular map/gloss map/opacity map/heghit map/offset map/etc)   
o Virtual Displacement Mapping (가상 변위 매핑)
o Real Dispalcement Mapping (변위 매핑)
o Allegorithmic의 ProFX가 통합되어 있다. (Unreal Engine 3 IPP)
· 애니메이션
o Vertex Animation with LOD (Keyframed, Inverse Kinematics, Motion Captured)
o Skeletal Animation with LOD (Animated, Motion Captured)
o Smooth-skinned Geometry with LOD (소프트웨어 및 하드우어 스키닝)
o Animation Blending with LOD (애니메이션 혼합과 LOD)
o OC3 Entertainemtn의 FaceFX가 통합되어 있다. (Unreal Engine 3 IPP)
§ Facial Animation & Lipsync를 구현하는 미들웨어 애니메이션 엔진이다.
· 특수 효과
o Depth-of-field (촛점 심도)
o Motion-blur (모션 블러)
o Distance Fog (Radial, Plane)
o Height Fog (높이 안개)
o Volume Fog (입체 안개) 
o Frame Buffer Distortion (수면 효과나 왜곡 효과 등)  
o Multiple Sky-Box (다중 스카이 박스)
o 기타 등등
· 파티클 시스템
o 일반 파티클
§ 탄피, 불꽃 등
o 소프트 파티클
§ 불, 물, 연기, 모래, 비, 눈, 우박, 안개 등
o Volumetric 파티클
§ 입체로 된 구름, 불, 물방울, 안개, 폭발효과 등을 구현
· Voxel 오브젝트
· 초목 구현
o IDV의 SpeedTreeRT가 통합되어 있다. (Unreal Engine 3 IPP)
· Split-screen rendering (화면 나누기)
· 고해상도 스크린샷 지원 (다양한 이미지 포맷)
물리 엔진
· 멀티 쓰레딩 물리 연산 지원
· Ageia의 PhysX 물리 엔진이 통합되어 있다. (Unreal Engine 3 IPP)
o UnrealScript와 연동되어 있고 UnrealEd 내부에 강력한 물리 컨트롤 툴셋으로 통합되어 있어서 UnrealEd 내에서 곧 바로 사용 가능하며 기본적으로 엔진의 모든 요소들과 연동되어 있어서 특별히 연동 작업이 필요 없다.
· ?RagDoll Physics (봉제인형 물리효과) 지원 
· 모든 오브젝트에 물리적인 충돌 및 감지와 중력효과 지원
· Vehicles Physics (탈것에 물리효과 지원)
o Ageia의 PhysX 물리 연산 하드웨어도 지원한다.
o 물리 + 애니메이션 + 사용자 입력 반응을 지원한다.
· 물리 기반 사운드 지원
o PhysX의 지속적인 업데이트.
o PhysX의 성능은 동명의 PhysX 하드웨어에 기반하면 엄청난 성능을 자랑하지만 소프트웨어적으로 돌아가는 물리 엔진의 성능은 현재 4.0 버전까지 나온 Havok Physics보다 못한 것 같다. 때문에 언리얼 엔진 3를 사용하는 개발사 중에는 언리얼 엔진 3에 무상 제공되는 PhysX 대신에 Havok 물리 엔진을 사용하는 개발사들도 상당수가 있다.
§ 다른 물리 엔진을 PhysX와 혼용하거나 또는 완전히 교체가 가능하며 이런 작업은 매우 간단한 편이다.
인공지능 엔진
· 멀티 쓰레딩 인공지능 연산 지원
· 싱글 플레이 기반의 다양한 A.I. 구현 시스템
· 싱글 플레이에서 동료의 A.I.에 대한 구현 시스템
· 길찾기 구조, BOT A.I., 탈것의 A.I., 팀기반 운용 A.I., 상황 판단 능력등을 보유한 인공지능 엔진
o 빠른 FPS에 최적이지만 길찾기 구조는 MMOG에서도 유용하게 쓸 수 있다.
· Engenuity의 AI Implant이 통합되어 있다. (Unreal Engine 3 IPP)
o 게임에 필요한 다양한 인공지능 기술을 제공하는 고급 미들웨어로서 많은 게임들에 채용되고 있는 인공지능 엔진이다.
· Kynogon의 Kynapse A.I.이 통합되어 있다. (Unreal Engine 3 IPP)
o 3D 월드의 패스 파인딩 (길찾기 구조)에 최적화 된 상용 인공지능 미들웨어이다.
· 두가지 이상의 인공지능 엔진을 언리얼 엔진 3내에서 동시 사용 가능하며 커스터마이징 혹은 필요하다면 외부의 다른 솔루션이나 직접 개발한 모듈을 동시 적용이 가능하다.
사운드 엔진
· 멀티 쓰레딩 사운드 처리
· Creative의 OpenAL (프리 소프트웨어)
o 돌비 서라운드 사운드,
o 모노 및 스테리오와 다중 채널 지원 (4.0, 5.1, 6.1, 7.1)
· OGG Vorbis (프리 소프트웨어)
o SIMD 최적화
· 크로스 플랫폼 DSP 효과 (반전, 기타)
· 마이크로폰 인풋
· 3D Positioning (3D 위치 기반 사운드 포지션), Spatialization (소리 떨림, 울림, 왜곡 효과), Doppler Shift (도플러 이동 사운드 효과)
네트워크 엔진
· 빠른 FPS 액션 게임에 최적화된 64명 기반의 서버-클라이언트 네트워크 엔진
o A.I.들의 무빙, 탈것, 물리 모델과 충돌 감지 예측의 빠른 네트워크 기능을 모두 포함한다.
· TCP 서버 네트워크 엔진
· UDP 기반의 네트워크 엔진
· Quazal Technologies의 Rendez-Vous이 통합되어 있다. (Unreal Engine 3 IPP)
o PC용 고급 상용 네트워크 엔진이다.
· Quazal Technologies의 Spark이 통합되어 있다. (Unreal Engine 3 IPP)
o 콘솔용 고급 상용 네트워크 엔진이다.
· MMO용 서버-클라이언트 네트워크 엔진은 아직까지는 제공되지 않는다.
로컬라이징 유니코드
· 16비트 유니코드를 지원하며 기본적으로 한국어, 중국어, 일본어를 포함한 총 9개국어가 지원되며 여러가지 폰트가 제공된다. 
무비 레코딩 기능
· 엔진을 통한 실시간 Demo 녹화 기능이 기본적으로 제공되며 이 기능은 다양하게 커스터마이징이 가능하다.
· DivX 동영상 포맷으로 동영상 아웃풋 레코딩이 가능한 기능이 기본적으로 통합되어 제공된다. (DivX 녹화 기능을 사용하는 것은 별도의 라이센스 비용이 필요 없지만 DivX 라이브러리를 제공 받기 위해서는 직접 DivX에 라이센스 해야 한다)
· RAD Game Tools의 Bink Video가 통합되어 있다. (Unreal Engine 3 IPP)
o 언리얼 엔진 3상에 통합되어 있으며 별도의 비용이 필요 없이 Bink Video에서 제공하는 다양한 포맷으로 녹화와 재생 및 편집이 가능하다.
Unreal Developer Network (UDN) 개발자 네트워크 지원
· 언리얼 엔진 2와 마찬가지로 UDN에서 개발자들끼리 다양한 정보나 기술, 소스 코드, 커스텀 유틸리티, 커스텀 툴셋, 커스텀 이펙트등을 공유 가능하다.
· 에픽에서 공식적으로 제공하는 예제 및 샘플등이 제공된다.
· 언리얼 엔진 3에 기본적으로 없는 다양한 종류의 렌더링 기술 및 기타 기능, 새로운 툴들을 추가적으로 지원 받을 수 있다.
o 자체적으로 커스터마이징을 하는 것 외에 엔진에 기본적으로 없는 기능들을 선택적으로 골라서 지원받아 커스터마이징 하는 것이 가능하다.
o 이것은 현재 지속적으로 추가 중이며 차후 언리얼 엔진 3.5와 함께 많은 내용들이 업데이트 될 것이다.
Unreal Engine 3 Integrated Partners Program (Unreal Engine 3 IPP)
· Unreal Engine 3 Integrated Partners Program은 에픽 서드 파티들이나 외부의 훌륭한 미들웨어들을 언리얼 엔진 3상에 통합하는 것을 의미하며 줄여서 Unreal Engine 3 IPP라고 부른다.
o 외부 미들웨어는 렌더링 관련, 네트워크 관련, 물리, 애니메이션, 인공지능 관련등 각 분야의 뛰어난 기술을 언리얼 엔진 3를 사용하는 개발사들에게 제공하기 위한 목적이며 새로운 미들웨어가 Unreal Engine 3 IPP로 계약이 되면 곧바로 언리얼 엔진 3의 다음 버전업에 포함이 되며 이 Unreal Engine 3 IPP로 추가된 미들웨어는 언리얼 엔진 3의 기본적인 기능으로 자리잡게 되므로 각 미들웨어 개발사에게 별도의 라이센스 비용을 들일필요가 없이 언리얼 엔진 3를 사용함으로서 해당 미들웨어들을 모두 무상으로 사용할 수 있다.
· IPP 체결이 된 미들웨어들은 단순히 언리얼 엔진 3에 번들로 제공되는게 아니라 언리얼 엔진의 코어 시스템 기반하에 엔진과 완전하게 융합되서 제공된다.
o Unreal Engine 3 IPP로 제공되는 모든 미들웨어들은 UnrealScript를 통해서 제어할 수 있으며 UnrealEd상에서 곧바로 사용할 수 있다.
o Unreal Engine 3 IPP로 제공되는 모든 미들웨어들의 툴은 UnrealEd상의 내부 툴로 포함되며 UnrealEd 내의 여러 툴간의 각 상호작용이 이루어진다.
o Unreal Engine 3 IPP로 제공되는 모든 미들웨어들은 언리얼 엔진 3의 모든 기능들과의 상호 연동은 물론 Unreal Engine 3 IPP로 포함된 모든 미들웨어들간의 상호 연동이 가능하게 된 상태로 제공이 된다.
o Unreal Engine 3 IPP에 포함되는 모든 미들웨어들은 항상 최신버전을 유지하기 위해서 해당 미들웨어의 최신버전이 릴리즈되면 언리얼 엔진 3의 최신버전에 해당 미들웨어의 최신버전을 Unreal Engine 3 IPP에 업데이트 한다.
· Unreal Engine 3 IPP에 현재까지 포함된 리스트는 다음과 같다
o Ageia의 PhysX (언리얼 엔진 3가 라이센스 되기 전부터 포함)
§ 물리 엔진 SDK, 툴셋
§ 물리 엔진은 언리얼 엔진 3와 완전하게 융합
§ 기본적인 물리현상, 탈것, 파티클등의 특수효과에 적용 가능하게 융합
§ 툴셋은 UnrealEd 상의 PhAT라는 물리 셋팅 툴의 일부로 완전하게 통합
o OC3 Entertainment의 FaceFX Technology (2005년 10월 18일부터 포함)
§ 페이셜 애니메이션 및 립싱크 엔진 및 툴셋
§ 페이셜 애니메이션과 립싱크 엔진의 기능은 언리얼 엔진 3상에 완전하게 통합
§ 툴셋은 UnrealEd상에 완전하게 통합
o RAD Game Tools의 Bink Video (2006년 초에 포함)
§ 동영상 녹화, 편집 및 재생하는 미들웨어
o Quazal Technologies의 Rendez-Vous (2006년 9월 28일부터 포함)
§ 네트워크 엔진
o Quazal Technologies의 Spark (2006년 9월 28일부터 포함)
§ 네트워크 엔진
o Fonix Speech의 VoiceIn (2006년 10월 2일부터 포함)
§ 음성 인식 엔진
o Engenuity의 AI Implant (2006년 10월 3일부터 포함)
§ 인공지능 엔진
o IDV의 SpeedTreeRT (2006년 10월 5일부터 포함)
§ 초목 구현 시스템
§ 언리얼 엔진 3상에 통합된 물리 엔진이나 라이팅 엔진을 통해서 새로운 라이팅과 쉐도우를 적용하거나 물리 현상을 적용이 가능
§ IPP로 포함되기 전에는 언리얼 엔진 3를 구입하고서도 SpeedTreeRT를 따로 비용을 들여서 라이센스 해야했지만 지금은 IPP에 포함되어서 비용을 따로 들일 필요 없이 언리얼 엔진 3에서 SpeedTreeRT를 사용할 수 있다
o Digimask의 Digimask SDK (2006년 11월 1일부터 포함)
§ 게이머가 직접 자신의 얼굴을 게임 속 캐릭터의 얼굴로 만들 수 있는 안면 모델 생성 및 적용 솔루션
§ 머리 모양과 얼굴의 텍스처를 생성하고 적용이 가능
§ Unreal Engine 3 IPP로 포함된 미들웨어인 FaceFX와 연동해서 사실적인 페이셜 애니메이션과 립싱크가 가능
§ Unreal Engine 3 IPP로 포함된 미들웨어인 VoiceIn까지 연동해서 게임중에 자신의 음성을 이용해 실시간 립싱크도 적용이 가능
o Kynogon의 Kynapse A.I. (2006년 11월 2일부터 포함)
§ 인공지능 엔진
o Geomerics의 Enlighten (2007년 2월 19일부터 포함)
§ 실시간 글로벌 일루미네이션 (Real-Time Global Illumination), 래디오시티 (Radiosity) 라이팅 및 재반사에 의해 생성되는 부드러운 그림자 (Soft Shadows)를 구현하는 엔진 차세대 라이팅 엔진
o Allegorithmic의 ProFX (2007년 3월 1일부터 포함)
§ Flexibility하게 절차적 텍스처 (Procedural Textures)를 생성하여 Shading 처리하는 차세대 텍스처 렌더링 엔진
 
토론
언리얼 엔진 3는 Direct3D 9b의 Shader Model 2x를 최소사양으로 하며 Shader Model 2.0 및 그 이하의 고정 파이프라인 렌더링과의 하위호환성을 완전히 배제한 완전한 Shader Based Rendering을 추구합니다. 그 이하는 고려되지 않기 때문에 그 이하를 염두하는 게임이라면 언리얼 엔진 3를 선택하지 말고 언리얼 엔진 2나 다른 엔진을 선택하는게 옳습니다. --아무개
쉐이더 3.0 이상아닌가요? PC로 나온 레인보우식스 베가스,RoboHordes 데모를 보면 Radeon x800 시리즈도 지원을 하지 않습니다(분명히 x800은 쉐이더 2.x 이상을 지원하는데).그리고 언리얼 엔진 3에 대한 단점은 전혀 없군요. 2를 써본 경험으론 그렇게 유연한 엔진이란 생각은 들지 않던데요. --다른 아무개
UE2는 프로젝트에 쓴게 아니지만 소스만 봤는데 UE3에 비해서는 유연함이 많이 떨어지는 편입니다. 하지만 그전부터 언리얼 엔진 시리즈가 유연함에서 좋다고 한 이유는 다른 통합형 엔진에 비해서 구조가 이쁘기 때문입니다. 적어도 제가 본 엔진중 시리어스 샘과 파 크라이와 리스텍중에선 UE2가 코드의 상태가 잘 정리되있고 코드 내부도 modify하기에 편리한 점이 있죠.(예: core(UE써봤다면 뭔지 아시겠죠)에서 구현하는 uvm으로 모든 코드가 들어온 다음에 다시 분산시키고 engine에 핵심적인 기술이 들어있고 나머지 세부 객체를 파생시켜서 연동하는 형태와 모듈 객체마다 패키지 파일을 써서 언리얼 스크립트로 컨트롤하거나 텍스트 파일을 일부 떨궈서 텍스트 편집기로만 간단하게 설정할수 있는점을 들수 있겠네요. UE3도 같은 구조에서 더 광범위하고 편하게 쓰도록 확장되어 있습니다.
UE3의 단점을 들라면 글쎄요. 지금까지 단점은 특별히 느끼지 못했지만 저마다 뭔가 불만을 토로할수는 있겠죠. 저는 단점은 못느꼈습니다. 굳이 단점을 하나 말하라면 전 일주일마다 한번씩 업데이트 받아야한다는 강박관념(?)정도? 아니 업데이트 한다고 개발에 큰 차질이 생기는것도 아니고 별로 상관은 없지만. 그 외엔 개발중 생기는 트러블과 어려움은 어떤 엔진을 써도 마찬가지고 그런 이유가 UE3로 인해 생긴다고 생각되지 않으니까요. 예전부터 상용 엔진이나 미들웨어를 도입하는 사람들이 불만을 토로하는 경우를 종종봐왔는데 그런 경우는 "엔진에서 뭐든 그냥 알아서 다 해주겠지"라는 안일한 태도를 갖고 있는 사람들이거나 실력 부족인 경우가 대부분이었고 그렇게 불만 갖는 친구들 치고서 프로젝트가 순조로운걸 못봤습니다. 이건 물론 저만의 시각일수도 있지만 적어도 제가 봐왔던건 그렇습니다.
마지막으로 UE3는 쉐이더 2.x부터 돕니다. 레인보우 식스 베가스나 로보뭐시기는 안해봤지만 그 게임들이 지원안하는건 그 게임들 문제겠지요. 쉐이더 2.x를 지원하는 라데온 9xxx 시리즈부터 돌고 지포스는 쉐이더 3.0 지원하는 6xxx부터 제대로 돕니다. 다만 최신 드라이버는 쉐이더 3.0 기준으로 개발되고 있고요. 현재는 쉐이더 4 기반 드라이버가 준비되서 제공될려고 하고있습니다.
--UE3쓰는이
지금은 회사에서 나왔지만 얼마전까지만 해도 UE3를 쓰던 사람입니다. 저도 UE3 쓰면서 단점을 굳이 찾으라는 말은 억지로 단점이라고 짚어내지 않고서야는 이 엔진의 단점을 말하기란 다른 일로 생긴 문제를 억지로 엔진의 탓으로 핑계대는 것이라고 밖에 생각되지 않습니다. 뭐 팀원이나 팀장등의 입장으로서는 그런 발언 한마디에 자기들 밥줄이 걸린 문제니까 이해할만하지만요. --도타쿠
맞습니다. 언리얼 엔진 3 좋기만 하더만요. 엔진에 핑계대는 사람치고 자기 실력에 문제가 없는 사람없었다는... 언리얼 엔진 2까지는 조금 그렇지만 언리얼 엔진 3에는 투정부릴게 전혀 없습니다. 게임브리오만 쓰다가 언리얼 엔진 2, 3 구경해보니까 2는 좀 그래도 3는 차원이 다르더군요. 언리얼 엔진 3 쓰면서 느낀점은 이 대단한 엔진을 쓰면서 엔진에 핑계대는다는것은 프로그래머로서의 자질부터 스스로 체크해봐야겠다는 생각뿐이었습니다. --낙잠자자
정책이 저렇게 바뀐건 알지만 1년 유지보수에 $100,000인가요? --- 도타쿠
HDR 구현에 관심이 많은데, 라데온 9xxx 씨리즈에서도 된다니 신기하네요, 라데온 9xxx 씨리즈는 A16B16G16R16F에서 alpha blending을 지원하지 않는 걸로 알고 있습니다. 언리얼 엔진 3기반 게임은 pix로 잠깐 잡아보면 백버퍼가 A16B16G16R16F 인거 같던데 여튼 신기하군요 --- 지나가던이의 의견
HDR 구현에 대한 자료들은 인터넷 검색을 통해서 보시면 많은 자료들을 찾으실 수 있을겁니다. 파크라이 (크라이 엔진 1)는 HDR 구현을 SM2 이하에서는 구현하지 못했으나 나중에 나온 스플린터셀 3,4 시리즈나 언리얼 엔진 3, 하프라이프 2의 소스 엔진을 비롯해 요즘엔 SM2에서도 HDR을 구현합니다. 언리얼 엔진 3에선 SM3 이상 모드에서는 R16 G16 B16 A16모드나 R32 G32 B32 A32로도 HDR을 구현하는것도 가능합니다. 지포스 7000 계열 카드에서는 올 R32 G32 B32 A32모드로 돌리면 FSAA나 지연 렌더링을 사용 불가하게 되지만 이후의 카드에서는 가능합니다. --- UE3 사용자 의견

Posted by 노을삼킨별
,

BSP를 이용한 3D Game Programming

 

신용우

 

 

강좌 1. BSP의 이해

 

장면 관리(Scene Management)

        실제 게임에 사용하는 폴리곤의 개수는 갈수록 늘어가는 추세이며 이는 하드웨어의 발달에 힘입은 바가 크다. 최신의 비디오 카드들은 CPU를 능가하는 GPU(Graphics Processing Unit)을 탑재하고 있으며 이는 초당 수백만 폴리곤을 화면에 무리없이 그려낸다. 그럼에도 불구하고 3차원 게임 개발이 어려운 이유는 무엇인가? 역설적일지는 모르지만 개발자의 입장에서 보면 하드웨어가 게임을 모두 정석대로 소화하기엔 여전히 느리기 때문이다. 모든 개발자들은 자신이 만든 게임이 시스템 사양과 관계없이 초당 30프레임 이상으로 잘 동작하기를 바란다. 이를 위해 필연적으로 CPU와 GPU의 연산을 줄이는 특별한 방법(어떤 면에서는 trick에 가까운)이 필요하다. 개발자들은 이러한 방법들을 추상화 하여 쉽게 개발하기 위해 게임 엔진을 설계한다.

        개발자의 입장에서 게임 시나리오가 확정된 이후 3차원 게임을 개발을 시작하려고 할 때 처음 해야하는 일은 게임 엔진의 기초를 확립하는 것이다. 개발하려는 게임의 특성에 따라 각기 차이점은 있겠지만 엔진은 기본적으로 복잡한 장면(Complex Scene)을 관리할 수 있어야 한다. 장면(Scene)은 크게 정적 객체(Static Object)와 동적 객체(Dynamic Object)로 구분할 수 있다. 정적 객체란 게임의 실행시 한번 로딩한 이후 변하지 않는 객체, 즉 정적 게임 맵(Static Game Map)을 의미한다. 그러나 움직이는 문이나 동적 광원, 캐릭터, 아이템은 모두 동적 객체에 속한다. 그러나 장면 관리를 제어하기 위한 게임 엔진의 설계는 말처럼 쉽지는 않다. 많은 개발자들은 보다 뛰어난 장면 관리를 위한 방법들을 고안하였으며 이중  대표적인 것이 퀘이크(Quake)에서 사용한 BSP 기반 게임 엔진이다.

 

퀘이크 게임 엔진

        둠 시리즈로 유명한 ID소프트웨어의 존 칼막(John Calmak)은 1995년도에 완전한 3D 환경의 게임인 퀘이크를 출시하였는데 이는 BSP, PVS, Light Map등 그 당시로서는 매우 획기적인 기술들을 도입한 놀라울만한 게임이었다. 이후 많은 개발자들이 퀘이크와 유사한 게임 엔진을 개발하기 위해 부단히 노력하였으며 이는 퀘이크 장르의 게임들이 쏟아져 나오는 계기가 되었다. 저자 또한 퀘이크 게임 엔진의 분석을 통해 많은 것을 배울 수 있었다. 이 문서 또한 그와 유사한 게임 엔진을 제작하는 기법에 대한 방법을 다룰 것이다.

 

 

[그림 1]. Quake (ID Software)

 

        스크린샷이 최신 게임들에 비해 초라해 보이는가? 그러나 최신 게임들 조차도 이 게임에 적용된 모든 기술들을 아직도 복습해서 사용하고 있다. 그럼 이와 같은 게임을 만들려면 어떻게 해야 하는가? 간단하게 설명하면 다음과 같다.

1. 게임 맵 데이터를 바탕으로 하여 BSP 트리를 구축한다.

2. 이 트리 구조를 응용하여 PVS를 생성한다.

3. 동적 객체에 대한 Object PVS를 생성한다.

4. 라이트맵(Light Map)을 생성한다.

이게 무슨말인지 모른다고 해서 걱정할 필요는 없다. 만약 여러분이 위의 내용을 다 알고 있다면 이 문서를 볼 이유가 없다. 이제 차근차근 도표와 예제를 통해 설명해 나갈 것이다.

 

사전 지식

        이 글은 독자들이 다음과 같은 사전 지식이 있다고 가정한다. 만약 자신이 부족하다고 생각한다면 다른 책들을 참고하길 바란다.

1. Standard C & C++ 프로그래밍

2. STL (Standard Template Library)

3. Visual C++을 이용한 Win32 프로그래밍

4. OpenGL

5. 3차원 그래픽스에 대한 기초 수학 (특히 벡터, 행렬)

        글은 되도록 쉽게 쓰려고 노력하였으나 글재주가 엉망이라 내가 봐도 좀 한심한 부분이 있다. 똑똑한 사람일수록 글을 쉽게 쓴다는 말이 일리가 있는 것 같다. 부족한 점이 있더라도 이쁘게 봐주길 바란다.

 

BSP의 개념

        BSP(Binary Space Partitioning)이란 공간을 분할하는 정보를 담고있는 2진 트리를 의미한다. BSP는 원래 은면 제거(Hidden Surface Removal)을 목적으로 고안하였으나 BSP의 공간 분할에 대한 특성으로 인해 그 응용 범위는 넓게 확장되었다. 이 장에서는 고전적인 BSP의 제작 방법을 다룰것이다. 여기서 고전적이란 의미는 일반적으로 그래픽스에서 사용하는 BSP를 의미한다. 고전적 BSP는 실제 게임에서 사용하는 BSP와는 약간 틀린점이 있지만 본질적으로 개념은 동일하다. 게임에서 사용하는 BSP는 고전적인 BSP를 변형한 Solid Leaf BSP를 주로 사용하는데 이는 공간을 개발자들이 관리할 수 있는 형태로 분할하는데 도움을 준다. 또한 적절히 분할한 공간을 이용하여 PVS(Potential Visiblity Set)를 구성할 수 있는 기반으로 사용할 수 있다.

그럼 어떻게 BSP를 생성할 것인가? 폴리곤으로 구성된 입체를 BSP 트리 형태로 표현하는 방법은 다음과 같다.

1. 입체를 구성하는 폴리곤 리스트에서 하나를 선택하여 기준으로 삼는다.

2. 새로운 BSP 노드를 생성하여 선택한 폴리곤을 노드에 추가한다.

3. 선택한 폴리곤의 평면의 방정식을 구한 후에 나머지 폴리곤을 모두 테스트하여 평면의 앞에 있는 폴리곤과 뒤에 있는 폴리곤을 분류하여 리스트를 만든다. 즉, 앞쪽 리스트와 뒤쪽 리스트를 완성한다.

4. 앞쪽 리스트에서 하나의 폴리곤을 선택하여 기준으로 삼는다. 선택한 폴리곤은 이전에 선택한 폴리곤의 하위 Front 노드에 저장한다. 리스트에 남는 폴리곤이 없을 때 까지 2의 과정을 재귀적으로 반복한다.

5. 뒤쪽 리스트에서 하나의 폴리곤을 선택하여 기준으로 삼는다. 선택한 폴리곤은 이전에 선택한 폴리곤의 하위 Back 노드에 저장한다. 리스트에 남는 폴리곤이 없을 때 까지 2의 과정을 재귀적으로 반복한다.

위의 내용이 잘 이해가 되는가? 무슨 말인지 모르겠다면 당신은 정상이다. 그럼 예를 들어 살펴보자.


BSP 트리 구성의 기초

        게임 맵은 폴리곤의 집합이다. 이러한 폴리곤은 최소 세개의 정점(Vertex)을 가지고 있으며 이들 정점들은 하나의 평면을 결정한다. 따라서 모든 폴리곤은 자신이 속한 평면의 방정식을 얻을 수 있다. [그림 2]는 하나의 폴리곤이 하나의 평면에 속해 있음을 보여준다. 그럼 이러한 평면을 어떻게 구할 것인지 알아보자.

[그림 2] 삼각 폴리곤 ABC가 하나의 평면을 결정하고 있음

 

        그렇다면 어떻게 폴리곤의 정보를 이용하여 폴리곤이 속한 평면을 구할 수 있을까? 다 알고 있겠지만 초보자들을 위해 간단히 설명하겠다. 일반적으로 평면의 방정식은 다음과 같다.

ax + by + cz + d = 0

(x, y, z는 변수이고 a, b, c, d는 상수)

이중 a, b, c는 평면의 방향벡터(Normal Vector)이므로 벡터 AB와 BC의 Cross Product를 얻으면 그 값은 a, b, c와 일치한다.

Vector(a, b, c) = AB CrossProduct BC

만약 폴리곤의 회전 방향에 대한 표현법이 CW(Clock Wise) 방식이라면 Vector(a, b, c)는 평면의 방향벡터와 일치할 것이다. 그러나 폴리곤의 회전방향이 CCW(Clock Counter Wise)라면 평면의 방향벡터와 반대방향의 값을 얻는다. 이점에 주의하라.

참고 - CW란 시점에서 폴리곤을 바라볼때 폴리곤을 구성하는 정점의 순서가 시계 방향으로 돌아갈 경우 평면이 시점에 대하여 앞면을 향한다고 정의하는 방법이다. 반대로 CCW는 정점의 순서가 반시계 방향으로 돌아갈때 평면이 시점에 대하여 앞면을 향한다고 정의한다. 일반적으로 OpenGL에서는 CW를 기본값으로 사용하며 D3D 에서는 CCW를 사용한다.

이제 a, b, c의 값을 알고 있으므로 d의 값은 다음과 같다.

d = -(ax + by + cz)

폴리곤의 정점은 평면 내부에 위치하기 때문에 x, y, z에 대입하면 성립한다. 따라서 x, y, z에 폴리곤의 정점 중 하나를 선택하여 대입하면 d의 값을 쉽게 얻을 수 있다. 폴리곤이 평면을 결정하는 방법은 BSP를 제작하는데 자주 사용할 것이다. 이제 폴리곤과 평면의 차이를 이해하였으면 다음으로 그림의 표현법에 대해 알아보자.

[그림 3]을 보면 이 맵은 4개의 폴리곤으로 이루어져 있다. 이 그림은 3차원적으로 폴리곤을 표현하고 있지만 [그림 4]는 동일한 내용을 2차원적으로 표현하고 있다. 앞으로는[그림 4]와 같은 형태로 폴리곤의 배치를 표현할 것이다.

 

[그림 3]

 

 

[그림 4]

 

        [그림 4]에서 화살표는 평면의 방향을 의미한다. 그럼 이를 바탕으로 BSP를 직접 생성해 보자. 먼저 BSP는 이진 트리 구조(Binary Tree)이다. 이진 트리 구조란 하나의 노드가 2개의 하위 노드를 가짐을 의미한다. BSP의 첫번째 하위 노드에는 자신을 기준으로 앞쪽에 위치한 폴리곤을 저장하며, 두번째 하위 노드에는 뒤쪽에 위치시키는 것을 규칙으로 한다. 먼저 최상위 루트(root) 노드로 B를 선택하자.

[그림 5]

 

        왜 하필 B를 루트 노드로 선택했을까? 지금으로선 별 의미 없다. 아무거나 선택해도 상관없다. 이제 트리 구조의 루트에 B가 위치할 것이다. [그림 5]를 보면 루트에  B가 위치함을 알 수 있다. B를 기준으로 하위 노드 2개가 있음을 알 수 있는데 이는 각각 자신을 기준으로 앞쪽에 위치한 폴리곤을 가리키는 Front 노드와 뒤쪽을 가리키는 Back 노드를 가지고 있다. 현재는 Front와 Back노드 모두 비어있는 상태이다.

        이제 A를 선택하자. [그림 4]을 보면 B를 기준으로 볼 때 A는 B의 뒤에 위치함을 알 수 있다. 루트에는 이미 B가 위치하고 있으므로 B의 하위 Front 노드에 A를 추가한다.

 

 

[그림 6]

 

그런데 좀 이상하지 않은가? 확실히 A노드는 B의 뒤에 위치하는가? [그림 7]와 [그림 8]을 비교해 보라.

 

[그림 7]

 

[그림 8]

 

        [그림 7]와 [그림 8]은 A의 방향 벡터가 반대 방향으로 위치해 있다. 그럼에도 불구하고 두 경우 모두 B를 기준으로 A는 뒤에 위치한다고 판단한다. 왜 이런 결과를 얻는가? 폴리곤 A를 구성하는 모든 정점은 폴리곤 B의 뒤에 위치하기 때문에 결국 A는 B의 뒤에 위치한다는 것을 알 수 있다. 다시 말하면 기준이 되는 B의 방향성만 의미가 있을 뿐 A의 방향성은 무시한다. 따라서 [그림 7]과 [그림 8]은 모두 [그림 6]의 형태로 배치함을 원칙으로 한다.

        그렇다면 A를 기준으로 선택한다면 어떻게 될까? [그림 7]의 경우 폴리곤 B는 A에 대해 뒤쪽에 위치한다. [그림 8]의 경우 폴리곤 B는 A에 대해 앞쪽에 위치한다.

        다음으로 남은 폴리곤 C, D중에서 D를 먼저 선택하자. D를 트리에 넣기 위해 먼저 루트 노드 B와 비교를 한다. D는 B의 앞쪽에 위치하므로 B의 하위 Front 노드에 저장한다. [그림 9]

        이제 마지막으로 남은 폴리곤 C를 트리에 넣는다. C를 B와 비교해 보니 B의 앞에 위치한다. 따라서 C를 B의 하위 Front 노드에 추가하면 트리는 [그림 10]와 같은 형태를 이룬다. 하위 Front 노드에는 C, D 두개의폴리곤을 저장하고 있으므로 다음엔 C와 D를 위의 요령으로 다시 분할하자. 이번에는 D를 기준 폴리곤으로 잡으면 D의 뒤에 C가 위치하므로 D의 하위 Back 노드에 C를 보낸다. 이제 BSP 트리를 완성하였다. [그림 11]

 

2진 트리구조와 효율성

        위의 예제에서 폴리곤 A, B, C, D에 대하여 B-A-D-C의 순서로 BSP 트리를 생성하였다. 그런데 어떠한 폴리곤을 먼저 선택하느냐에 따라 여러가지 트리 형태가 나타날 수 있다. 결국 트리 형태는 폴리곤의 선택 순서에 달린 것이다. 만약 폴리곤을 D-C-B-A의 순서로 선택하여 트리를 구성한다면 어떻게 될까? [그림 12]와 같은 형태를 이룬다.

 

        [그림 12]가 [그림 11]에 비해 효율적인 트리라고 말할 수 있는가? 그렇지 않다. [그림 11]의 경우 트리의 깊이가 3인데 반해 [그림 12]는 4이다. 따라서 트리를 탐색하려 할 경우 [그림 11]의 경우가 더 유리하다고 할 수 있다. 따라서 BSP를 생성할 때 기준 폴리곤의 선택을 최적화하여 트리의 깊이를 최소화할 필요성이 있다.

 

 

동일 평면상의 폴리곤

        BSP는 특정 폴리곤이 다른 폴리곤에 대하여 앞쪽에 있는가 뒤쪽에 있는가를 판단하는 근거를 제공한다. 그러기 위해서 특정 폴리곤을 선택하여 이를 기준으로 삼아 나머지 폴리곤들을 재배치(Classify)하였다. 그런데 선택한 기준 폴리곤의 평면에 대하여 동일한 평면에 위치하는 폴리곤은 어떻게 처리할 것인가? 이때에는 기준 폴리곤을 포함하는 노드에 같이 추가한다.

 

        위의 그림에서 A를 기준 폴리곤으로 선택하였다 가정하자. 나머지 폴리곤 B, C, D를 A의 평면에 관해 분류하려고 보니 모두 동일 평면에 위치하고 있다. 게다가 C와 같은 경우 동일 평면상에 위치하고 있음에도 불구하고 반대 방향을 향하고 있다. 이 경우 어떻게 할 것인가? 정답은 B, C, D를 A를 포함하는 노드에 그냥 추가하는 것이다. BSP 노드는 2개의 연결 리스트(Linked List)를 가지고 있는데 그중 하나는 동일 평면상에 위치하며 동일한 방향성을 가지는 폴리곤을 저장하고, 나머지 하나는 동일 평면상에 위치하지만 반대 방향성을 가지는 폴리곤을 저장한다.

이와 같은 정보를 저장하기 위한 BSP 노드의 클래스를 정의하면 다음과 같다.

 

class CBspNode

{

public:

float PlaneEquation[4];                 // 기준 폴리곤에서 얻은 평면의 방정식

LinkedList SamePolyList;             // 동일 평면, 동일 방향의 폴리곤 저장

LinkedList OppositePolyList;         // 동일 평면, 반대 방향의 폴리곤 저장

CBspNode *pFrontNode; // 하위 Front 노드

CBspNode *pBackNode; // 하위 Back 노드

};

 

 

[그림 14]

 

        [그림 14]에서 기준 폴리곤 A는 폴리곤 B를 가로지르고 있다. 폴리곤 B의 일부는 A의 앞에 있고 일부는 뒤에 있다. 이러한 경우 폴리곤 B를 두 조각으로 분할하여 각기 저장한다. [그림 15] 을 보면 A를 포함하는 평면에 대해 B가 B1과 B2로 분할된 것을 볼 수 있다. 여기서 B1은 A의 앞쪽이 있고 B2는 뒤쪽에 있으므로 각각 A의 하위 Front 노드와 하위 Back 노드에 추가한다.

 

예제

        지금까지 다룬 내용이 BSP 트리를 구축하기 위해 필요한 모든 내용이다. 위의 내용을 정확하게 알 수 있는지 자신이 없다면 다음 문제를 보며 연습하길 바란다. [그림 16]에 좀 더 많은 숫자의 폴리곤을 배치하였다.  그림에서 보듯이 폴리곤 A, K, L은 동일 평면에 위치하고 폴리곤 B는 폴리곤 E를 분할함에 주의해서 스스로 BSP를 분할해 보고 결과를 비교해 보자. 폴리곤의 선택 순서에 따라 결과가 달라짐에 주의하라.

 

[그림 16]

 

1. A를 기준 폴리곤으로 선택한다. K와 L이 동일 평면에 위치하므로 A를 포함하는 노드에 추가한 후에 하위 Front와 하위 Back노드를 추가한다

 

 

2. 하위 Front 노드를 구성하는 B, C, D, E, F, G중에서 B를 기준 폴리곤으로 선택하여 다시 분류한다. 이때 B는 E를 분할(Subdiv)하여 앞쪽에 위치한 E1과 뒤쪽에 위치한 E2를 얻은 후에 각각의 하위 노드에 저장한다.

3. 나머지 폴리곤들도 위의 요령으로 재귀적으로 구성한다. 결과는 다음과 같다.

 

        자, 대충 이해했는가? 다음 강좌에서는 실제적으로 이러한 BSP를 C++을 이용해 구현하는 법에 대해 알아볼 것이다. 지금 다루는 내용은 고전적인 BSP이고 실제 게임에서 사용하는 BSP와는 조금 다르다는것을 기억하고 다음 강좌를 기대하길 바란다.


Posted by 노을삼킨별
,

출처 : http://blog.naver.com/vane77/20000744655

GLUT Tutorial

GLUT 설정

by Antonio

원문 : http://www.lighthouse3d.com/opengl/glut/index.php3?1

GLUT 는 OpenGL 을 위한 표준 유틸리티 툴킷입니다. 즉 OpenGL 용 어플리케이션의 개발을 편하게 할 수 있도록 도와주는 도구로 생각하면 됩니다. Mark J. Kilgard 씨가 GLUT 를 만들었는데, 그 이유는 특정 윈도우 시스템들을 알지 못해도 OpenGL 용 어플리케이션을 만들 수 있도록 하기 위해서 였죠. 너무나 고마운 일 아닙니까? Mark J. Kilgard 씨와 GLUT 에 고마워합시다~ :) GLUT 를 사용하면 X 윈도우 시스템이나 마이크로소프트의 윈도우 시스템에 대해서 배우지 않고도 OpenGL 용 어플리케이션을 만들 수 있습니다. Kilgard 씨가 X 윈도우용의 GLUT 를 만들었고 나중에 Nate Robins 씨가 마이크로소프트 윈도우즈용의 GLUT 를 만들었답니다. 우리 모두 이 두사람의 위대한 업적에 갈채를 보냅시다!

이 강좌는 GLUT 를 사용해서 어플리케이션을 만드는 방법을 설명합니다. 단, 예제의 코드를 가능한 간단하게 만들기 위해서 화려한 시각 효과 같은건 만들지 않겠습니다.

무엇이 필요한가요?

GLUT 를 이용해서 어플리케이션을 만들려면 우선 최신버전의 GLUT 가 필요해요. 당연한 얘기인가요 ;) 이 글을 쓸 때, GLUT 의 최신버전은 3.7 이었습니다. GLUT 배포판은 아주 많은 예제를 포함하고 있기 때문에 이 강좌를 다 보고 난 다음에 예제를 분석해 보는 것이 좋겠죠? 당연한 얘기입니다! :) GLUT 가 없거나 GLUT 에 대해서 궁금한 것이 있으면 GLUTs 웹페이지를 살펴보세요.

GLUT 를 사용해서 C 언어로 어플리케이션을 만들려면 3 개의 파일이 필요합니다. :

  • glut.h - 이 파일은 어플리케이션의 소스코드에 항상 포함해야하는 파일입니다. 이 파일은 대개 여러분이 사용하는 개발툴 시스템의 include 폴더 아래에 있는 gl 폴더에 들어있습니다.
  • glut.lib ( SGI 의 윈도우즈 버전 ) 과 glut32.lib ( 마이크로소프트 버전 ) - 이 파일은 glut 를 이용하는 어플리케이션이라면 반드시 링크해야 합니다. 대개 개발툴 시스템의 lib 폴더에 들어있죠.
  • glut.dll ( SGI 의 윈도우즈 버전 ) 또는 glut32.dll ( 마이크로소프트 버전 ) - OpenGL 을 사용하기 위해서 둘 중 하나만 선택하면 됩니다. 마이크로소프트 버전의 glut 를 사용하려면 glut32.dll 파일을 선택하세요. 이 파일은 운영체제의 system 폴더에 있어야합니다.

Visual C/C++ 6.0 환경 설정하기

Visual C/C++ 로 프로젝트를 만들려면 두가지를 설정해줘야 합니다. 하나는 콘솔 프로그램으로 만들 것인지 아니면 Win32 프로그램으로 만들 것인지 정해야합니다. 콘솔로 만들게 되면 어플리케이션은 두 개의 창을 갖게 됩니다. 하나는 콘솔창이고 다른 하나의 OpenGL 창이랍니다. Win32 를 선택했을 때 GLUT 를 사용하면 Win32 로 어플리케이션을 만들 때 만나게 되는 '프로그래머 혼란스럽게 하기' 란 장애물을 피해갈 수 있습니다. :) 이를 위해서 아래의 과정을 따라 하나만 바꿔주세요.

  1. 주메뉴의 Project->Settings 를 선택하세요.
  2. 대화상자에서 "Link" 탭을 선택하세요.
  3. 콤보박스의 "Category" 에서 "Output" 을 선택하세요.
  4. "Entry-point symbol" 에디트박스에 "mainCRTStartup" 이라고 입력하세요.

이미 만든 콘솔 프로젝트를 Win32 어플리케이션 프로젝트로 만들려면 아래의 과정을 따라 설정해주면 됩니다. 콘솔에서 Win32 로 바꾸는 것은 콘솔창을 만들지 않기 위해서겠죠?

  1. 위의 과정을 따라서 entry-point symbol 을 추가합니다.
  2. "Project Options" 에디트박스에서 "subsystem:console" 을 "subsystem:windows" 로 바꿔줍니다.

위의 과정을 일일이 다 해주기 귀찮다면 소스코드의 시작부분에 아래의 코드를 입력해주세요. 위의 과정과 똑같이 프로젝트를 설정해줍니다.

#pragma comment( linker, "/subsystem:\"windows\" /entry:\"mainCRTStartup\"" )

프로젝트를 위의 과정에 따라 올바르게 설정했다면 콘솔창은 없고 OpenGL 창만 있는 어플리케이션이 만들어집니다. 두번째 설정은 GLUT 를 어플리케이션에 링크해주는 것인데 Visual C/C++ 을 사용한다면 아래의 과정을 따라 설정하면 됩니다.

  1. 주메뉴의 Project->Settings 를 선택하세요.
  2. 대화상자에서 "Link" 탭을 선택하세요.
  3. "Object/library modules" 에디트박스에 "opengl32.lib glut32.lib glu32.lib" 을 입력합니다.

주목 : glu32.lib 과 opengl32.lib 을 추가했습니다. 이 두개의 라이브러리 파일은 OpenGL 의 표준 라이브러리입니다. GLU 는 OpenGL 이 배포하는 표준 API 입니다.

모든 설정이 끝났나요? 잘 끝냈기를 바랍니다 :) 그럼 이제 GLUT 를 이용해서 어플리케이션을 만들어봅시다. 이 강좌에서 확실하지 않거나 궁금한 점이 있으면 연락해 주세요. 성실하게 답해드릴께요. 이런 강좌는 여러분들의 참여가 아주 중요하거든요.

이 강좌가 여러분들에게 도움이 되길 바랍니다. - Antonio -


좋은 팁!

출처: Grafix3d.net

Posted by 노을삼킨별
,

출처 : http://leechen.wzsoft.com/ 사이트의 <이준곤> 님이 쓰신 글

디바이스가 바뀔때, 렌더 상태(render-state)나 텍스쳐 스테이지 상태(texture-stage-state), 또는 스트림 소스(stream-source)등이 얼만큼의 비용이 드는지 알고 싶어 할 것이다. 또한 최적화 루틴으로 과부하가 걸리는 상태를 피하고 싶을 것이다. 이럴 때 정확한 함수의 실행 클럭 수치를 파악하고 있다면 좀더 최적화된 게임 개발이 될 것이라 생각된다.

API Call Avg # of Cycles
SetVertexDeclaration 6500 - 11250
SetFVF 6400 - 11200
SetVertexShader 3000 - 12100
SetPixelShader 6300 - 7000
SPECULARENABLE 1900 - 11200
SetRenderTarget 6000 - 6250
SetPixelShaderConstant (1 Constant) 1500 - 9000
NORMALIZENORMALS 2200 - 8100
LightEnable 1300 - 9000
SetStreamSource 3700 - 5800
LIGHTING 1700 - 7500
DIFFUSEMATERIALSOURCE 900 - 8300
AMBIENTMATERIALSOURCE 900 - 8200
COLORVERTEX 800 - 7800
SetLight 2200 - 5100
SetTransform 3200 - 3750
SetIndices 900 - 5600
AMBIENT 1150 - 4800
SetTexture 2500 - 3100
SPECULARMATERIALSOURCE 900 - 4600
EMISSIVEMATERIALSOURCE 900 - 4500
SetMaterial 1000 - 3700
ZENABLE 700 - 3900
WRAP0 1600 - 2700
MINFILTER 1700 - 2500
MAGFILTER 1700 - 2400
SetVertexShaderConstant (1 Constant) 1000 - 2700
COLOROP 1500 - 2100
COLORARG2 1300 - 2000
COLORARG1 1300 - 1980
CULLMODE 500 - 2570
CLIPPING 500 - 2550
DrawIndexedPrimitive 1200 - 1400
ADDRESSV 1090 - 1500
ADDRESSU 1070 - 1500
DrawPrimitive 1050 - 1150
SRGBTEXTURE 150 - 1500
STENCILMASK 570 - 700
STENCILZFAIL 500 - 800
STENCILREF 550 - 700
ALPHABLENDENABLE 550 - 700
STENCILFUNC 560 - 680
STENCILWRITEMASK 520 - 700
STENCILFAIL 500 - 750
ZFUNC 510 - 700
ZWRITEENABLE 520 - 680
STENCILENABLE 540 - 650
STENCILPASS 560 - 630
SRCBLEND 500 - 685
TWOSIDEDSTENCILMODE 450 - 590
ALPHATESTENABLE 470 - 525
ALPHAREF 460 - 530
ALPHAFUNC 450 - 540
DESTBLEND 475 - 510
COLORWRITEENABLE 465 - 515
CCW_STENCILFAIL 340 - 560
CCW_STENCILPASS 340 - 545
CCW_STENCILZFAIL 330 - 495
SCISSORTESTENABLE 375 - 440
CCW_STENCILFUNC 250 - 480
SetScissorRect 150 - 340


참고 싸이트 : http://www.circlesoft.org/pages.php?pg=kbasepage&id=12&updateID=18


Posted by 노을삼킨별
,