반응형

Lerp (linearInterpolate)

A 와 B 두개에 노드를 연결 하는데 alpha 가 0 이면 A 색상을 alpha 가 1 이면 B색상을 보간하여 리턴한다, alpha 에 alpha 이미지를 연결 할수도 있음







https://docs.unrealengine.com/latest/INT/BlueprintAPI/Math/Float/Lerp/index.html

Lerp

Linearly interpolates between A and B based on Alpha (100% of A when Alpha=0 and 100% of B when Alpha=1)

Target is Kismet Math Library

Lerp
A
0.0
B
0.0
Alpha
0.0
Return Value

Inputs

A
Float
B
Float
Alpha
Float

Outputs

Return Value
Float


반응형
반응형

유니티에서는 미리 사용할 게임 오브젝트를 만들어 놓은 다음,
Prefab으로 만들어서, 게임 상에서 재사용을 용이하게 함


http://metalkim.tistory.com/342


[Unity 유니티] Prefab(프리펩) 이란?


1. Prefab ( 프리펩 ) 이란?


Prefab은, 유니티의 핵심 기능 중 하나로써 게임 오브젝트를 하나의 형틀로 만들어 언제든지 인스턴스화 할 수 있도록 만드는 것이다.

예를 들어보면,


Cube 1 이란 오브젝트를 만들고, 프리펩화 하면, 게임 도중 간단한 호출만으로 Cube 1을 양산할 수 있게 된다.

이것은 현실의 도장과도 비슷한 개념이다.


만들어진 도장만 있으면, 잉크만으로도 언제든지 도장에 파여진 문양을 새길 수 있는 것과 같다.


이 프리펩은 언제든지 수정이 가능하고, 모든 프리펩에 적용이 가능하다. ( 도장의 모양을 바꾸는것을 생각하면 된다. )






2. Prefab (프리펩) 화 하는 방법


프리펩 화 하는 방법은 매우 간단하다.


계층 뷰 ( Hierarchy ) 에서 프로젝트 뷰 ( Project ) 뷰로 오브젝트를 드래그 하는것만으로도 프리펩 화가 가능하며, 미리 만들어 놓은 프로젝트 뷰의 프리펩에 드래그 해도 해당 오브젝트가 프리펩 화 된다.


마찬가지로 프로젝트 뷰에서 계층 뷰나 씬 뷰에 드래그를 하는 것 만으로도 오브젝트를 찍어낼 수 있다.


혹은 함수 Instantiate 로도 프리펩을 오브젝트로 불러낼 수 있다.



반응형
반응형

https://www.youtube.com/watch?v=hTdTiIEluR4





ppt 자료

http://www.slideshare.net/MrDustinLee/ss-33346625



반응형
반응형

https://msdn.microsoft.com/ko-kr/library/58918ffs.aspx


형식에 대한 System.Type 개체를 얻는 데 사용됩니다. typeof 식의 형식은 다음과 같습니다.

System.Type type = typeof(int); // type 을 얻어와 인스턴스를 만들 수도 있음 -> http://3dmpengines.tistory.com/1507

식의 런타임 형식을 얻으려면 다음 예제와 같이 .NET Framework 메서드 GetType을 사용합니다.

int i = 0;
System.Type type = i.GetType();

typeof 연산자는 오버로드되지 않습니다.

typeof 연산자는 열린 제네릭 형식에도 사용할 수 있습니다. 형식 매개 변수가 둘 이상인 형식을 지정할 때는 적절한 수의 쉼표를 사용해야 합니다. 다음 예제에서는 메서드의 반환 형식이 제네릭 IEnumerable<T>인지 여부를 확인하는 방법을 보여 줍니다. 메서드는 MethodInfo 형식의 인스턴스라고 가정합니다.

string s = method.ReturnType.GetInterface
    (typeof(System.Collections.Generic.IEnumerable<>).FullName);

public class ExampleClass
{
   public int sampleMember;
   public void SampleMethod() {}

   static void Main()
   {
      Type t = typeof(ExampleClass);
      // Alternatively, you could use
      // ExampleClass obj = new ExampleClass();
      // Type t = obj.GetType();

      Console.WriteLine("Methods:");
      System.Reflection.MethodInfo[] methodInfo = t.GetMethods();

      foreach (System.Reflection.MethodInfo mInfo in methodInfo)
         Console.WriteLine(mInfo.ToString());

      Console.WriteLine("Members:");
      System.Reflection.MemberInfo[] memberInfo = t.GetMembers();

      foreach (System.Reflection.MemberInfo mInfo in memberInfo)
         Console.WriteLine(mInfo.ToString());
   }
}
/*
 Output:
    Methods:
    Void SampleMethod()
    System.String ToString()
    Boolean Equals(System.Object)
    Int32 GetHashCode()
    System.Type GetType()
    Members:
    Void SampleMethod()
    System.String ToString()
    Boolean Equals(System.Object)
    Int32 GetHashCode()
    System.Type GetType()
    Void .ctor()
    Int32 sampleMember
*/





http://www.lionheart.pe.kr/?document_srl=883&mid=board_uFoa63&listStyle=viewer



유니티 엔진에서  C# 싱글톤

 

public class MyHttp : MonoBehaviour

{


      private static MyHttp s_Instance = null;
 
      public static MyHttp instance 
      {
            get 
            {
                   if (s_Instance == null) 
                   {
                         s_Instance = FindObjectOfType(typeof(MyHttp)) as MyHttp;
                   }

                   // 여전히 null일 경우 새로운 인스턴스 생성
                   if (s_Instance == null) 
                   {
                         GameObject obj = new GameObject("MyHttp");
                         s_Instance = obj.AddComponent(typeof (MyHttp)) as MyHttp;
                   }
                   return s_Instance;
             }
      }
 
      void OnApplicationQuit() 
      {
           s_Instance = null;
      }


}

 

 

유니티 엔진에서  인스턴스 중복 방지

 

public class GameMgr : MonoBehaviour 
{
 
        public static GameMgr instance;
 
        void Awake()
        {
                  if(instance != null)  //  DontDestroyOnLoad(this.gameObject); 인해 해당 오브젝트가 계속 쌓이는 것을 방지
                  {
                            //Destroy(this); // 해당 스크립트를 삭제
                           Destroy(this.gameObject); // 해당 오브젝트를 삭제
                           return;
                  }

                  instance = this;
                 //DontDestroyOnLoad(this);
                 DontDestroyOnLoad(this.gameObject);
                 Application.targetFrameRate = 60; // 최대 프레임은 60으로 지정
        }


}


 

반응형
반응형


http://gilverlight.net/3439



유니티는 스크립트 언어로 C#을 지원하고 있습니다.

 

윈도우 운영체제 사용자들 중

"C# 언어를 이용한 개발은 비주얼 스튜디오에서 하는 것이 가장 편하다"는데에

이견을 가지시는 분이 없으실 것입니다.

 

저도 그렇습니다.

나쁘게 말하면 타성에 젖었다라고 할 수 있지만,

뭔가 쓰던 가락이 있어서라고 할까요?

 

자, 그럼 유니티 편집기에서 비주얼 스튜디오를 기본 스크립트 편집기로

지정하는 방법을 알아보겠습니다.

 

 

1. 유니티 편집기를 띄웁니다.

 

2. 메뉴 중 [Edit - Preferences...]를 선택합니다.

 

 

 

3. 왼쪽 목록에서 [External Tools]를 선택합니다. 그리고 오른편의 [External Script Editor]에서

Microsoft Visual Studio(설치 버전은 다를 수 있습니다.)를 선택합니다.

 

만약, 목록에서 Microsoft Visual Studio가 보이지 않으시면, [Browse...]를 선택하시고,

Visual Studio가 설치된 장소를 찾아가 devenv.exe를 선택해 주시면 됩니다.

 

 

 

4. 이렇게 설정하고 나면, 유니티 편집기에서 스크립트에 더블 클릭을 했을 때,

자동으로 비주얼 스튜디오가 그 스크립트를 열어 줍니다.

 

반응형
반응형

http://goo.gl/9dXn3u




빈 프로젝트에서 게임브리오 세팅법을 알아 보자.

1. 빈 프로젝트를 만든후 
2. 속성 -> 추가 포함 디렉터리 -> 게임브리오 설치시 include 를지정 
3. 속성 -> 링커 -> 일반 -> 추가 라이브러리 디렉터리에 빌드에 맞는 라이브러리 폴더를지정
4. 속성 -> 링커 -> 추가 종속성 -> NiSystem.lib NiFloodgate.lib NiMain.lib NiMesh.lib NiCollision.lib NiAnimation.lib NiParticle.lib NiApplication.lib NiVisualTracker.lib NiInput.lib NiEntity.lib NiFont.lib NiTerrain.lib NiSample.lib NiUserInterface.lib NiCursor.lib 추가






이러고 빌드 하면 에러가 떨어 진다 ㅋ 짜증나는 LIBCMT.lib 링크 에러 후덜덜 

5. 속성 -> 링커 -> 특정 라이브러리 무시 -> LIBCMT.lib 추가

이러고 빌드 하면 또 에러가 떨어 진다.
게임브리오만에 전처리기가 있는듯 하다. 

6. 속성 -> C/C++ -> 전처리기 -> NIDEBUG, NIRELEASE, NISHIPPING 추가 
이렇게 세팅후 빌드를 하면 아주 잘된다.~ 



7. 나 같은 경우는 포함 파일과 라이브러리 파일들은 패스 지정이 귀찬아서 
도구 -> 옵션 -> 프로젝트 및 솔루션 -> VC++디렉터리 -> 라이브러리 파일 -> 경로 추가


도구 -> 옵션 -> 프로젝트 및 솔루션 -> VC++디렉터리 -> 포함 파일 -> 경로 추가


이렇게 하였다 둘중 아무거나 선택해도 가능하다. 

위 샷은 NiApplication 을 빈프로젝트에서 상속후 뿌려본 보습 튜토리얼 1번과 같은 실행화면

반응형
반응형

http://unitykoreawiki.com/



유니티 공식문서

edit SideBar

안녕하세요. 유니티코리아 공식문서 사이트에 오신 것을 환영합니다.

본 페이지는 www.unitykoreawiki.com 과 연결되어 있습니다.

더 큰 페이지에서 보시려면 위의 링크를 눌러주세요.

본 페이지에서는 유니티 유저 매뉴얼과 레퍼런스 매뉴얼 등의 유니티 공식문서들을 보실 수 있게 컨텐츠들을 제공하고 있습니다.

목차








유니티 매뉴얼

유니티에 오신 것을 환영합니다.

유니티는 사용자 분들이 최고의 인터랙티브 환경과 멀티미디어의 경험을 창조하는 것을 돕기 위하여 만들어졌습니다. 이 매뉴얼은 여러분이 유니티를 어떻게 이용하는지 기초부터 고급 테크닉까지 모두 배울 수 있게 해드립니다. 처음부터 끝까지 읽으셔도 좋고 참조용으로 사용하셔도 좋습니다.

이 매뉴얼은 몇가지 다른 섹션으로 나뉘어 있습니다. 첫 섹션, 유저 가이드(User Guide) 는 유니티 인터페이스, 에셋 작업방식(워크플로우), 그리고 게임을 만드는 기초에 대한 소개입니다. 만약 여러분이 유니티를 처음 접하시는 것이라면 유니티 기초(Unity Basics) 안의 섹션들을 읽고서 배우시는 것을 추천해드립니다.

iOS 가이드 (iOS Guide) 는 iOS 특정 스크립팅 API, 최적화, 일반 플랫폼 개발 질문들 등의 iOS 관련 토픽들을 보여줍니다.

안드로이드 가이드 (Android Guide) 는 안드로이드 SDK 셋업과 일반 개발 질문들 등의 안드로이드 관련 토픽들을 보여줍니다.

다음 섹션인 FAQ 는 몇몇 절차들을 밟아야 해결 되는 일반적인 작업 수행 방법들에 관련 흔히 물어보는 질문들을 묶어논 것입니다.

마지막 섹션인 고급 (Advanced) 섹션은 게임 최적화, 셰이더, 파일 크기, 배치 (deployment) 등의 토픽들을 보여줍니다.

그리고 유니티를 사용한 게임 제작의 다양한 가능성들을 자세하게 살펴보기 위해 레퍼런스 매뉴얼 (Reference Manual) 과 스크립팅 레퍼런스 (Scripting Reference) 도 읽어보시기 바랍니다.

만약 찾는 답을 구하지 못하셨을 경우, www.unity3dkorea.com 의 유니티 Q&A 섹션을 이용하시거나 Unity Answers , Unity Forums 등을 이용하시면 답을 찾으실 수 있습니다..

즐겁게 읽어보시기 바랍니다, 
유니티 팀

유니티 매뉴얼 가이드는 특정 플랫폼에만 해당되는 섹션들로 구성되어 있습니다. 보시길 원하는 플랫폼 섹션으로 이동하셔서 보시기 바랍니다. 특정 플랫폼 관련 정보는 각 페이지에 보여주기 삼각형을 누르시면 보실 수 있습니다. 

    

목차


반응형
반응형

http://unitykoreawiki.com/index.php?n=KrMain.UnityHotkeys


반응형
반응형

http://www.unrealengine.com/html5/


파이어폭스가 필요한듯 하네요


언리얼이... 아.............. .나 ㅡ.ㅡ;;;


유니티~~ 유니티~~~~ 응?

반응형
반응형

http://topnanis.tistory.com/161



물리엔진이란 - 오브젝트를 대상으로 질량, 속도, 마찰, 유체저항 등의 수치를 이용하여 뉴턴역학 모델을 시뮬레이트 하는 프로그램을 통칭하며 자연계의 물리 현상을 프로그램 내에서 시뮬레이트 하는 프로그램 라이브러리입니다.

에이지 오브 엠파이어시리즈에선 3 부터 였죠. 물리엔진이 도입되면서 대포알 각도와 힘에 따라 사람이나 건물 파편이 늘 다르게 튕기는 모습이 연출되어 넋을 잃고 대포를 쏘던 기억이 나네요. 게임의 감초역할을 하는 물리엔진은 적소에 잘 쓴다면.. 빛이 반짝반짝 난답니다(생각보다는 활용도가 높진 않더라구요) 

여기에서는 공개된 대표적인 물리엔진인 Erin Catto님의 Box2d로 설명하겠습니다. (참고로 저희 과제중에 블럭마스터(http://topnanis.tistory.com/91)가 이 라이브러리를 사용했습니다. 그땐 C#에서 했었는데. 자바에서도 오브젝티브c에서도 각각의 버젼이 나와 있을정도로 보편적입니다)




물론 복잡한 것이 아니라면 손코딩으로 흉내를 낼수 있겠지만 [조인트]나, [충돌] 등의 복잡함이 추가된다면 엔진을 사용하는 것이 훨씬 편리하고 정확한 값을 얻을 수 있습니다. 만약 도형이 시간에 따라 아래로 일정하게 떨어지는 프로그램이 있다면 box2D hello world 프로그램에서는 가속도를 붙이며 떨어지는 모습을 볼수 있습니다.

기본프로그램에서는 좌표값과 앵글이 숫자로만 표시되지만 약간 변형하여 바람(가로중력)에 따라 문자열이 날리며 떨어지는 모습을 구현하도록 할께요. 
제목은.. box2D in fall 로 하겠어요 :)

초기 환경 설정이 약간 까다로워 물리엔진을 쓰지 못하는 분들을 위해 글을 적어야 겠다고 생각했답니다. 환경설정은 게임프로그래밍의 대가 게미조아님이 알려주신거예요. 다른 방법은 에러가 나더라구요. 꼭 이렇게 해보세요.

 
1. 우선 http://code.google.com/p/box2d/downloads/list 로 가서 Box2D_v2.2.1.zip를 받습니다.



lib파일을 사용하기 위해 우선 빌드를 시켜야 합니다.

2. 압축을 풀어 ./Box2D_v2.2.1/Build/vs2010.sln를 실행한뒤,  디버깅모드로 한번, 릴리즈모드로 한번 컴파일을 시킵니다.



그러면 로딩이 걸리면서 빌드가 되고 오른쪽 아래와 같이 폴더 안에 .lib 파일이 각각 생겨납니다. (에러는 무시하셔두 됩니다) 이 경로를 프로젝트 lib링크를 위해 메모장에 기억해둡니다.(간단하게 이(bin)폴더를 c:\에 옮겨두셔두 좋겠죠)


3. vs2010에 c 콘솔 프로젝트는 아래 내용 소스가 들어갑니다. 기본소스에 주석을 빼고, 위치를 찍어주기 위한 약간의 코드가 추가되었습니다.

testblog.cpp




4. 그리고 #include <Box2D\Box2D.h>를 위해서 ./Box2D_v2.2.1\Box2D 폴더를 C:\Program Files\Microsoft Visual Studio 10.0\VC\include에다 옮겨줍니다. 즉,



이렇게 됩니다. 그러면.. 인클루드가 잘 되겠죠.


5. 그리고 메뉴에 Project - Properties - Configuration Properties - VC++ Directories - Library Dir - 

디버깅 모드일때는 아까 2번 주소의 디버깅으로

릴리즈 모드일때는 아까 2번 주소의 릴리즈로 링크를 걸어줍니다.



6. 그리고 Box2D.lib추가 (귀찮아서 사진으로 대체.. )
 





8. 그리고 실행합니다. 오.. 글자가 데굴데굴 굴러다니죠


 


실행파일을 첨부합니다~



반응형
반응형





캐릭터

UE3를 활용하여 자신의 프로젝트에 맞는 캐릭터를 구현하기에 앞서 UE3에 이미 구현되어 있는 캐릭터 작동 방식을 분석하기로 한다. 그리하여 캐릭터 구현에 필요한 기능이 중복구현됨을 막고 효율적으로 UE3에 통합될 수 있도록 한다.

여기서 살펴볼 내용은 Core기능에 해당하는 AnimTree, AnimSet, Morph 등의 기능이 아니라, 로직에 해당하는 Pawn, PlayerController, PlayerReplicationInfo 등의 오버뷰와 이들이 엔진 내 어떤 포지션에 해당하는지를 중점으로 살펴본다.

캐릭터 Bone 구조

분석 요소

UE3에서 캐릭터를 구현하는데 필요한 요소들을 살펴본다.

Pawn

  • 특징
    • Actor→Pawn 상속
    • player 나 AI 가 컨트롤하기 위한 Base Actor 클래스에 해당한다.
    • mesh, collision, physics 등의 기능이 있고, 데미지를 주며 소리를 내고 무기나 다른 소지품을 들고 다니며, 월드상 다른 Pawn 과의 물리적 인터렉션 등을 담당한다.
  • 기능
    • 캐릭터가 돌아 다닐 수 있는 floor 에 대한 성격을 정의한다.
      • Pawn 이 서있는 지면의 Normal ( Floor, PHYS_Spider, PHYS_Walking 에서만 쓰인다. )
      • 올라갈 수 있는 floor 높이를 정의. ( MaxStepHeight, MaxJumpHeight )
      • 내려갈 수 있는 floor 높이를 정의. ( LedgeCheckThreshold )
      • 이동 가능한 floor 경사면 값 지정. ( WalkableFloorZ, 이는 floor 의 normal 벡터와 UpVector 를 내적한 스칼라 값 이며 Pawn은 기본적으로 0.7 (~= 45 degree) 로 초기화 되어 있다. )
      • 상기 3가지 사항은 캐릭터 이동 및 PathFinding 등에 활용된다.
    • 모든 Pawn을 링크드리스트로 관리. ( NextPawn, 월드 상 모든 Pawn 순회에 용이하다. )
    • Crouch 관련 정보 정의 가능
      • 웅크릴 수 있다. ( bCanCrouch )
      • 웅크리길 원한다. ( bWantsToCrouch )
      • 웅크린 상태이다. ( bIsCrouched )
      • 다시 일어서고 싶다. ( bTryToUncrouch )
      • Crouch 시, 실린더 정보 ( CrouchHeight, CrouchRadius )
      • 웅크리기 & 일어서기 이벤트 함수 제공.
        // APawn::performPhysics 로부터 호출
        void APawn::Crouch(INT bClientSimulation)
        {
            ...
        }
         
        void APawn::UnCrouch(INT bClientSimulation)
        {
            ...
        }
    • 이동 목적지에 다다르면 smooth하게 속도를 줄이면서 멈춘다. ( bReducedSpeed )
    • 여러 행위들에 대한 플래그
      • 점프기능이 있다. ( bJumpCapable )
      • 점프할 수 있다. ( bCanJump )
      • 데미지 입을 수 있다. ( bCanBeDamaged )
      • 웅크릴 수 있다. ( bCanCrouch )
      • 날 수 있다. ( bCanFly )
      • 수영할 수 있다. ( bCanSwim )
      • 텔레포트할 수 있다. ( bCanTeleport )
      • 걸을 수 있다. ( bCanWalk )
      • 사다리에 오를 수 있다. ( bCanClimbLadders )
      • 횡이동 할 수 있다. ( bCanStrafe )
      • 이 밖에 다양한 플래그 들 ( bAvoidLedges, bStopAtLedges, bAllowLedgeOverhang, bSimulatedGravity, bIgnoreForces, bCanWalkOffLedges, bCanBeBaseForPawns, bSimGravityDisabled, bDirectHitWall, bPushesRigidBodies, bForceFloorCheck, bForceKeepAnchor )
      • 곧 Pawn 에서 제거될 것 같은? 플래그 들 ( bCanMantle, bCanClimbUp, bCanClimbCeilings, bCanSwatTurn, bCanLeap, bCanCoverSlip )
    • AI 관련 변수
      • 성별 ( bIsFemale )
      • 아이템을 집을 수 있다. ( bCanPickupInventory )
      • AI가 날 무시하게 할 수 있다. ( bAmbientCreature )
      • 소리를 들을 수 있다. ( bLOSHearing )
      • 벽을 통해 들려오는 숨죽인 소리를 들을 수 있다. ( bMuffledHearing )
      • 게임 시작 시 controller 에 의해 소유되지 않도록 한다. vehicle 들은 게임 시작 시 controller 에 의해 선점되면 안되겠지.. ( bDontPossess )
      • 난 움직일 수 없다. ( bStationary )
      • 무기 사용할 수 없다. ( bNoWeaponFiring )
      • 뭔가를 사용할 수 있다. ( bCanUse )
      • 이 밖에 다양한 플래그 들 ( bModifyReachSpecCost, bModifyNavPointDest, bPathfindingsAsVehicle, )
      • Path Finding 관련
        • 내가 길을 찾는 방법 ( PathSearchType )
        • 기타 관련 변수 들 ( PathConstraintList, PathGoalList )
      • 들을 수 있는 거리 ( HearingThreshold )
      • 소리를 들을 수 있는 각성도 ( Alertness, -1 ~ 1 사이의 값으로써 높을 수록 소리를 더 잘 들을 수 있다. )
      • 시야 거리 ( SightRadius )
      • 시야 각 ( PeripheralVision, degree 의 cosine 값, default 로 -0.75 ~= 140 도 )
      • 물리적 업데이트할 모니터링 시간 ( AvgPhysicsTime, AI 가 목적지로 가기 위해 업데이트할 시간? 구불구불하게 가거나 똑바로 가게 하는 등의 처리를 위한 변수 )
    • 이동 관련 속성
      • 희망 무브먼트 속도 ( DesiredSpeed & MaxDesiredSpeed, GroundSpeed 에 곱해지므로 실질적으로 Pawn 의 전체적 무브먼트 스피드라고 보아도 무방 )
        // Pawn.uc
        defaultproperties
        {
            ...
            DesiredSpeed=+00001.00000
            ...
        }
         
        // UnController.cpp
        void AController::MoveTo( ... )
        {
            ...
            Pawn->DesiredSpeed = Pawn->MaxDesiredSpeed;
            ...
        }
         
        void AController::MoveToward( ... )
        {
            ...
            Pawn->DesiredSpeed = Pawn->MaxDesiredSpeed;
            ...
        }
         
        // UnPhysic.cpp
        FLOAT APawn::MaxSpeedModifier()
        {
            ...
            if ( !IsHumanControlled() )
            {
                Result *= DesiredSpeed;  // 사람이 조종하지 않는 녀석에 한해서만 적용
            }
            ...
        }
      • 가장 가까운 path ( Anchor )
      • nav mesh 인덱싱 ( AnchorItem, 헌데 사용되지는 않음 )
      • 최근에 도달한 가까운 path ( LastAnchor )
      • 마지막 path finding 실패 시기 ( FindAnchorFailedTime, FindPath() 함수 시도가 실패한 마지막 시간 )
      • 마지막 유효 path 발견 시기 ( LastValidAnchorTime )
      • 도착점 offset ( DestinationOffset )
      • 루트상 다음 지점의 반지름 ( NextPathRadius )
      • 구불구불 이동
        • 방향 ( SerpentineDir )
        • 거리 ( SerpentineDist )
        • 시간 ( SerpentineTime, 구불구불 이동 시 횡이동 시도하기 전까지 직진할 시간 )
    • 물리?
      • Pawn 의 질량 ( Mass )
        // Pawn.uc
        function CrushedBy( Pawn OtherPawn )
        {
            TakeDamage(
                ( 1 - OtherPawn.Velocity.Z / 400 ) * OtherPawn.Mass / Mass,   // 데미지, 위에서 내리누를 때 상대방과의 질량에 대비하여 데미지를 가감하는 용도.
                OtherPawn.Controller,                                         // 유발자 Controller
                Location,                                                     // HitLocation
                vect( 0, 0, 0 ),                                              // Momentum
                class'DmgType_Crushed' );                                     // 데미지 타입
        }
         
        event TakeDamage( ... )
        {
            ...
            momentum = momentum / Mass;     // 데미지가 가해질 때 전해진 충격량으로부터 움직일 속도를 구함. F=ma -> a=F/m
            ...
        }
      • 수영할 때 적용할 물 부양성 ( Buoyancy, 1=자연스러운 부양성 0=no부양성 )
        // UnPhysic.cpp
        void APawn::CalcVelocity( ... )
        {
            ...
            if ( bBuoyant )
            {
                Velocity.Z += GetGravityZ() * DeltaTime * ( 1.f - Buoyancy );  // Buoyancy 가 0 이면 중력을 그대로 적용한다.
            }
            ...
        }
      • 밀리어택 최대거리 ( MeleeRange, 일반적인 밀리어택이 아니라 이동하는 도중 목적지까지의 거리를 가늠하는데 사용하는 것 같음 )
    • 일반
      • 스폰 시간 ( SpawnTime, 스폰 후 일정시간동안 데미지 감소따위를 하는 데 사용. 관련변수 UTGame.SpawnProtectionTime )
      • view pitching 제한 ( MaxPitchLimit )
    • 무브먼트
      • controller 없이도 physics 돌려라~ ( bRunPhysicsWithNoController, acceleration 이 아닌 velocity 에 의해서만 움직이게 되겠다. )
      • 풀 악셀 ( bForceMaxAccel, 기존 acceleration 무시하고 풀악셀로 최대 velocity 를 이끌어 낸다. )
      • 최대 지형 이동 속도 ( GroundSpeed )
      • 최대 수영 이동 속도 ( WaterSpeed )
      • 최대 활강 이동 속도 ( AirSpeed )
      • 최대 등반 이동 속도 ( LadderSpeed )
      • 가속 비율 ( AccelRate, 이것이 곱해져 acceleration 을 구한다. )
      • 점프 속도 ( JumpZ, 수직 up 방향 속도 )
      • 수중 이탈 속도 ( OutofWaterZ, 점프로 물 밖으로 이탈할 때 z up 방향 속도. 물 근처 난간위로 올라가는 것을 보장하기 위해 설정하는 값인듯 )
        // Pawn.uc
        function JumpOutOfWater( vector jumpDir )
        {
            ...
            velocity.Z = OutofWaterZ;  // set here so physics uses this for remainder of tick
            ...
        }
      • 수중 이탈 가능 높이 ( MaxOutOfWaterStepHeight, 수영하며 수중이탈 가능한올라갈 수 있는 높이 )
      • 낙하 최대 가속도 제한할까? ( bLimitFallAccel )
      • 공중에서의 컨트롤 시간 factor ( AirControl, acceleration 을 이 시간만큼 적용한 후 테스트하는 용도 )
        // UnPhysic.cpp
        void APawn::physFalling( FLOAT deltaTime, INT Iterations )
        {
            ...
            if ( !bDoRootMotion && TickAirControl > 0.05f )
            {
                // 현재 velocity 에 TickAirControl 시간만큼 경과 후 delta velocity 까지 더한 후 이동거리를 체크한다.
                FVector TestWalk = ( TickAirControl * AccelRate * Acceleration.SafeNormal() + Velocity ) * deltaTime;
                TestWalk.Z = 0.f;
                ... // 이후는 현재 Location 으로부터 TestWalk 만큼 이동한 곳에 특정 world 오브젝트가 있는지 (지형 포함) 체크한다.
            }
            ...
        }
      • 걷기&웅크리기 속도 퍼센티지 ( WalkingPct & CrouchedPct, 기본 이동 속도에 곱하여 걷기속도 및 웅크리기속도를 구하는 방식에 사용 )
        // UnPhysic.cpp
        FLOAT APawn::MaxSpeedModifier()
        {
            ...
            if ( bIsCrouched )
            {
                Result *= CrouchedPct;
            }
            else if ( bIsWalking )
            {
                Result *= WalkingPct;   // 바로 위에서 Pawn 의 무브먼트 속도를 Result 에 누적하여 구하고 그것을 Walking 상태여부에 따라 곱하여 현재 무브먼트 속도를 구한다.
            }
            ...
        }
      • 데미지 없이 낙하 가능한 속도 ( MaxFallSpeed, velocity 와 비교된다. )
      • AI들은 이보다 적은 낙하속도가 가능한 길을 택할 것이다. ( AIMaxFallSpeedFactor, 바로 위 변수와 곱하여 AI를 위한 낙하 속도를 구함 MaxFallSpeed * AIMaxFallSpeedFactor )
    • Camera 관련
      • Pawn 카메라 높이 ( BaseEyeHeight )
        // UnPawn.cpp
        FVector APawn::GetPawnViewLocation()
        {
            return Location + FVector( 0.f, 0.f, 1.f ) * BaseEyeHeight;
        }
      • 계산된/조절된 Pawn 카메라 높이 ( EyeHeight )
    • 숨쉬기/HP
      • 숨을 쉬기 위한 머리 ( HeadVolume )
      • HP ( Health )
      • 최대 HP ( HealthMax )
      • HP 를 모든 클라에게 복제할까? ( bReplicateHealthToAll )
      • 숨쉬기 타이머 ( BreathTime, 물에 빠졌을 때 일정 시간마다 데미지를 주기 위한 주기 )
        // UnLevTic.cpp
        void APawn::TickSpecial( FLOAT DeltaSeconds )
        {
            // Authority 이고 BreathTime 중이라면
            if ( Role == ROLE_Authority && BreathTime > 0.f )
            {
                BreathTime -= DeltaSeconds;
         
                if ( BreathTime < 0.001f )
                {
                    // 때가 됐다면 BreathTimer 호출 (바로 아래)
                    BreathTime = 0.0f;
                    eventBreathTimer();
                }
            }
         
            ...
        }
         
        // Pawn.uc
        event BreathTimer()
        {
            if ( HeadVolume.bWaterVolume )
            {
                if ( Health < 0 || WorldInfo.NetMode == NM_Client || DrivenVehicle != None )
                    return;    // 죽었거나 클라이언트거나 무엇인가를 타고있다면 무시
         
                TakeDrowningDamage();    // 익사 피해
         
                if ( Health > 0 )
                    BreathTime = 2.0;    // 2초 후 다시 BreathTimer 호출
            }
            else
            {
                BreathTime = 0.0;        // 더 이상 피해는 없음
            }
        }
      • 얼마만큼 숨을 참을 수 있는가? ( UnderWaterTime, 최초 입수 시 BreathTime 에 대입되는 값. 이 시간이 지나면 위의 BreathTimer 함수에 나와있는대로 2초마다 데미지 )
        // UTPawn.uc
        event HeadVolumeChange( PhysicsVolume newHeadVolume )
        {
            ...
         
            else if ( ... )
            {
                BreathTime = UnderWaterTime;    // 입수 시 숨쉬기 타이머 발동
            }
        }
         
        defaultproperties
        {
            ...
            UnderWaterTime=+00020.000000    // 20초
            ...
        }
      • 마지막으로 피해를 입은 시간 ( LastPainTime, BOT 의 경우 피격받고 일정 시간동안 Aim 을 불안정하게 하기위한 용도로써 활용된다. )
        // Pawn.uc
        function PlayHit( ... )
        {
            ...
            LastPainTime = WorldInfo.TimeSeconds;
        }
    • 루트모션
      • 루트모션 속도 ( RMVelocity, 클라이언트에서 루트모션을 재현하기 위한 용도의 변수. 또는 Controller.bPreciseDestination정확한 이동 기능이 활성화일 때 사용되기도 함. )
      • 강제 루트모션 속도 사용 ( bForceRMVelocity, 이 값이 true 면 APawn::CalcVelocity() 에서 RMVelocity 값을 직접적으로 사용 )
        // UnPhysic.cpp
        void APawn::CalcVelocity( ... )
        {
            ...
            if ( bForceRMVelocity )
            {
                Velocity = RMVelocity;
                return;
            }
            ...
        }
      • 강제 일반적인 속도계산 ( bForceRegularVelocity, 이 값이 true 면 APawn::CalcVelocity() 에서 RMVelocity 값을 절대로 사용하지 않는다. )
    • 사운드와 노이즈
      • 여러 변수들 ( noise1spot, noise1time, noise1other, noise1loudness, noise2spot, noise2time, noise2other, noise2loudness )
      • 사운드 음 꺾기 ( SoundDampening )
    • 데미지
      • 데미지 증가 ( DamageScaling ) *

Controller

PlayerController

PlayerReplicationInfo

UTGame 관련

샘플로 제공되는 언리얼토너먼트3 (이하 UTGame) 의 캐릭터를 구현하는데 활용된 여러 요소들을 추가적으로 살펴본다.

UTFamilyInfo

UTPlayerReplicationInfo

이동

정확한 이동

엔진에서 목표지점destination까지 정확하게 이동시켜주는 로직이 존재한다.

대략적인 방법은 이렇다.

  1. 정확히 도달해야 하는 목표지점을 설정한다. (by controller)
  2. 매 프레임마다 도착했는지 여부를 검사하고 아직 도달하지 못했다면 적절한 velocity 를 계산한다.
  3. 목표지점destination에서의 허용 Offset 안에 도달하면 이벤트함수를 호출한다. ( Controller.ReachedPreciseDestination() )

관련 변수/함수는 아래와 같다.

  • 변수
    // Pawn.uc
    var float             DestinationOffset;          // 목표지점으로부터의 허용 Offset
     
    // Controller.uc
    var bool              bPreciseDestination;        // 목표지점에 맞는 velocity 를 강제할 것인지의 여부, 정확한 이동을 수행할 것인지 여부와 상통
    var BasedPosition     DestinationPosition;        // 목표지점
  • 함수
    // UnPhysic.cpp
    void Pawn::CalcVelocity( ... )
    {
        ...
        // RooMotion 일 경우를 제외하고 '정확한 이동' 처리를 수행한다.
        if ( !bDoRootMotionAccel && Controller && Controller->bPreciseDestination )
        {
            FVector Dest = controller->GetDestinationPosition();   // Controller.DestinationPosition 을 Vector 로 형변환하여 리턴
            if ( ReachedDestination( Location, Dest, NULL ) )
            {
                Controller->bPreciseDestination = FALSE;           // '정확한 이동'을 종료
                Controller->eventReachedPreciseDestination();      // 종료 이벤트 호출
     
                Velocity = FVector( 0.f );
                Acceleration = FVector( 0.f );
            }
            else if ( bForceMaxAccel )
            {
                const FVector Dir = (Dest - Location).SafeNormal();
                Acceleration      = Dir * MaxAccel;
                Velocity          = Dir * MaxSpeed;
            }
            else
            {
                Velocity = (Dest - Location) / DeltaTime;
            }
            ...
        }
        ...
    }
     
    // UnPawn.cpp
    UBOOL APawn::ReachedDestination( ... )
    {
        ...
     
        return ReachThresholdTest( ... );
    }
     
    UBOOL APawn::ReachThresholdTest( ... )
    {
        ...
        FLOAT Threshold = ThresholdAdjust + CylinerComponent->CollisionRadius + DestinationOffset;    // 도착으로 인정할 유효 반지름을 계산
        ...
        if ( Dir.SizeSquared() > Threshold * Threshold )
            return FALSE;
        ...
        // 적절하게 테스트하고
        return TRUE;        // 도착했다고 판정
    }

상기 APawn::ReachThresholdTest 함수의 동입부에 도착지점으로부터의 허용 반지름을 계산하는 부분이 있는데, 이 값에 음수를 주어 좀 더 정확한 목표지점에 도달하게 할 수 있다.

무브먼트

언리얼엔진3에 기본적으로 제공되는 UTGame 을 기반으로 한 분석내용이다.

웅크리기 Crouch

코드플로우

  • 발생
    1. DefaultInput.ini
      • .Bindings=(Name=“C”,Command=“GBA_Duck”)
      • .Bindings=(Name=“GBA_Duck”,Command=“Duck | onrelease UnDuck | Axis aUp Speed=-1.0 AbsoluteAxis=100”)
    2. simulated exec function Duck() (UTPlayerInput.uc)
      • bDuck = true;
  • 루프1
    1. state PlayerWalking::ProcessMove(…) (PlayerController.uc) ← state PlayerWalking::ProcessMove(…) (UTPlayerController.uc) ← state PlayerWalking::PlayerMove(float DeltaTime) (PlayerController.uc) ← state PlayerWalking::PlayerMove(float DeltaTime) (UTPlayerController.uc) ← event PlyaerTick(float DeltaTime) (PlayerController.uc) ← event PlayerTick(float DeltaTime) (UTPlayerController.uc)
      • CheckJumpOrDuck();
    2. function CheckJumpOrDuck() (UTPlayerController.uc)
      • 점프나 더블점프를 수행하는 함수를 호출
      • Pawn.ShouldCrouch(bDuck != 0);
    3. funciton SouldCrouch( bool bCrouch ) (Pawn.uc)
      • bWantsToCrouch = bCrouch;
  • 루프2
    1. AActor::TickAuthoritative ← AActor::Tick ← APawn::Tick ← TickActors<FDeferredTickList::FGlobalActorIterator>
      • performPhysics 호출
    2. APawn::performPhysics(float DeltaSeconds) (UnPhysic.cpp)
      • 적절한 조건을 체크한 후 (bWantsToCrouch, bIsCrouched 따위) Crouch() 나 UnCrouch() 를 호출
    3. APawn::Crouch(INT bClientSimulation) (UnPawn.cpp)
      • Collision Cylinder 의 반지름과 높이를 CrouchRadius 와 CrouchHeight 로 변경
      • Crouch Collision Cylinder 가 더 커졌다면 지면을 침범했는지 체크한다.
      • eventStartCrouch( 높이차이 ) 호출
    4. simulated event StartCrouch(float HeightAdjust) (UTPawn.uc)
      • Super.StartCrouch(HeightAdjust);
      • CrouchMeshZOffset = HeightAdjust;
    5. simulated event StartCrouch(float HeightAdjust) (Pawn.uc)
      • EyeHeight 조절
      • OldZ 조절
      • BaseEyeHeight 조절

특이사항

  • 웅크리기에 사용될 충돌영역 정보인 CrouchRadius, CrouchHeight 를 세팅해야 한다.
  • 이때 MaxStepHeight 가 CollisionHeight - CrouchHeight 보다는 커야 한다. MaxStepHeight 는 캐릭터가 자연스럽게 이동 가능한 최대 허용높이이다. 웅크리기가 발동되면 내부적으로 캐릭터 바운딩실린더 높이를 조절하는데 그 갭이 MaxStepHeight 보다 크면 캐릭터는 Falling 운동을 하게끔 처리된다. (엔진 내부적으로) 때문에 주의가 필요하다.

점프 Jump

코드 플로우

  1. 발동
    // DefaultInput.ini
    .Bindings=(Name="GBA_Jump",Command="Jump | Axis aUp Speed=+1.0 AbsoluteAxis=100")
  2. 플래그 체크
    // UTPlayerInput.uc
    exec function Jump()
    {
        ...
        Super.Jump();
        ...
    }
     
    // PlayerInput.uc
    exec function Jump()
    {
        ...
        bPressedJump = true;
    }
  3. 지연 점프
    // PlayerController.uc
    state PlayerWalking
    {
        ...
        function PlayerMove( float DeltaTime )
        {
            ...
            // 지금 점프할 수 없는 상황이면 지연시킨다.
            if ( bPressedJump && Pawn.CannotJumpNow() )
            {
                bSaveJump = true;
                bPressedJump = false;
            }
            ...
        }
        ...
    }
  4. 점프 시도여부 체크 (매 프레임)
    // UTPlayerController.uc
    function CheckJumpOrDuck()
    {
        ...
        else if ( bPressedJump )
        {
            Pawn.DoJump( bUpdateing );
        }
        ...
    }
     
    // PlayerController.uc
    function CheckJumpOrDuck()
    {
        if ( bPressedJump && (Pawn != None) )
        {
            Pawn.DoJump( bUpdating );
        }
    }
  5. 실제 점프로직 처리
    // UTPawn.uc
    function bool DoJump( bool bUpdating )
    {
        ...
        if ( Physics ==PHYS_Spider )
            Velocity = JumpZ * Floor;
        else if ( Physics == PHYS_Ladder )
            Velocity.Z = 0
        else if ( bIsWalking )
            Velocity.Z = Default.JumpZ;
        else
            // 보통 이부분에 걸린다.
            Velocity.Z = JumpZ;
        ...
    }

부가기능

TurnInPlace

Pawn 의 현재 Rotation 을 기준으로 좌우 일정 반경을 회전할 동안 발이 땅에 접지한 상태로 있는 기능을 지원한다. UnrealEngine3 에서는 이 기능을 Turn-In-Place 라고 지칭한다. 이를 수행하는 레이어는 UDKPawn 이다.

분석 포인트

  • AnimTree 노드 캐싱
    // UTPawn.uc
    simulated event PostInitAnimTree(SkeletalMeshComponent SkelComp)
    {
        ...
        // 허리쪽 Bone 을 제어하는 컨트롤 캐싱 (RootRot 이란 이름을 가진 SkelControlSingleBone 컨트롤)
        RootRotControl = SkelControlSingleBone( mesh.FindSkelControl( 'RootRot' ) );
        ...
        // 조준 노드 캐싱
        AimNode = AnimNodeAimOffset( mesh.FindAnimNode( 'AimNode' ) );
        ...
    }
  • 업데이트 로직
    // UDKPawn.cpp
    void AUDKPawn::TickSpecial( FLOAT DeltaSeconds )
    {
        ...
        // 현재 Aim pitch 와 yaw 를 얻는다.
        INT PawnAimPitch;
        if ( Controller )
        {
            // 컨트롤러의 Pitch를 얻는다.
            PawnAimPitch = Controller->Rotation.Pitch;
        }
        else
        {
            // Pawn 의 Pitch를 얻는다.
            PawnAimPitch = Rotation.Pitch;
     
            if ( PawnAimPitch == 0 )
            {
                PawnAimPitch = RemoteViewPitch << 8;
            }
        }
     
        // Pawn 의 최종 조준 Pitch
        PawnAimPitch = UnwindRot( PawnAimPitch );
     
        INT PawnAimYaw = UnwindRot( Rotation.Yaw );
        // Pawn 의 최종 조준 Yaw (가 될 값)
        INT AimYaw = 0;
     
        if ( Physics == PHYS_Walking && Velocity.Size() < KINDA_SMALL_NUMBER )
        {
            // PawnAimYaw 는 손이 향하는 방향, RootYaw 는 발이 향하는 방향이라 생각하면 이해가 쉽다.
            INT CurrentAimYaw = UnwindRot( PawnAimYaw - RootYaw );
            INT RootRot = 0;
     
            if ( CurrentAimYaw > MaxYawAim )
            {
                RootRot = ( CurrentAimYaw - MaxYawAim );
            }
            else if ( CurrentAimYaw < -MaxYawAim )
            {
                RootRot = ( CurrentAimYaw - (-MaxYawAim) );
            }
     
            RootYaw += RootRot;
            RootYawSpeed += ( (FLOAT)RootRot ) / DeltaSeconds;
     
            // 최종 손과 발의 offset. 이것이 곧 Aim 노드에 적용될 Yaw
            AimYaw = UnwindRot( PawnAimYaw - RootYaw );
        }
        else
        {
            RootYaw = Rotation.Yaw;
            RootYawSpeed = 0.f;
            AimYaw = 0;
        }
     
        // 좌우 90 도 회전을 각각 -1, 1 로 매핑시킨 값으로 변환
        if ( !bNoWeaponFiring )
        {
            CurrentSkelAim.X = Clamp<FLOAT>( ( (FLOAT)AimYaw / 16384.f ), -1.f, 1.f );
            CurrentSkelAim.Y = Clamp<FLOAT>( ( (FLOAT)PawnAimPitch / 16384.f ), -1.f, 1.f );
        }
     
        // 허리를 Aim 의 반대쪽으로 회전. 즉, 손의 방향이 Pawn Rotation 과 일치하고 발의 방향을 보정하는 방식
        if ( RootRotControl )
        {
            RootRotControl->BoneRotation.Yaw = -AimYaw;
        }
     
        // Aim 업데이트
        if ( AimNode )
        {
            AimNode->Aim = CurrentSkelAim;
        }
        ...
    }

분석

참고

반응형
반응형

스크립트에 의한 네이티브코드 생성

개요

UnrealScript 를 사용하다 보면 Native 레이어와 상호 통신을 해야할 필요가 생긴다. 이 때 Script 의 내용을 Native 가 인식할 수 있도록 글루코드를 생성할 필요가 있는데 여기서는 이것에 대해 다뤄보도록 한다.

UnrealScript

스크립트 컴파일

이어지는 설명을 이해하려면 스크립트 컴파일하는 법을 먼저 알아야 한다. 컴파일은 게임 실행파일을 이용한1) 콘솔명령어로 수행되며 거두절미하고 바로 명령어 때려본다.

// 이하 콘솔명령어이며, 실행파일은 UTGame.exe 라고 가정한다.
UTGame.exe make                            // 릴리즈로 빌드
UTGame.exe make -full                      // 릴리즈로 풀 빌드
UTGame.exe make -debug                     // 디버그로 빌드 (스크립트를 디버깅하기 위해)
UTGame.exe make -debug -full               // 디버그로 풀 빌드

Native 글루코드 생성

UnrealScript 에서 Native 코드를 생성하는 키워드는 아래와 같다.

// UTGame/Classes/UTWeapon.uc
class UTWeapon extends UDKWeapon
    native // 이 키워드가 붙으면 Native 글루코드가 생성된다.
    ...

:!: 글루코드가 생성되는 파일명도 지정할 수 있다.

위와 같이 native 키워드 뒤에 아무것도 없다면 [패키지명]+Classes.h 에 글루코드가 생성된다. (위 예제와 같이) UTGame 의 경우 UTGameClasses.h 파일에 AUTWeapon 클래스에 대한 선언이 되어있는 것을 확인할 수 있다.

만약 native( MyWeapon ) 와 같이 괄호 안에 특정 명칭을 넣는다면 [패키지명]+[괄호內명]+Classes.h 에 글루코드가 생성된다. 위의 경우 UTGameMyWeaponClasses.h 에 해당된다.2)

글루코드 등록 및 정의

위와같이 글루코드의 헤더가 생성되면 이제 정의(.cpp)를 하고 등록을 할 차례다.

글루코드 정의

스크립트 내에서 네이티브 함수를 지정하는 방법은 여럿 있지만 여기선 그 설명은 생략하고 클래스와 네이티브 함수를 정의하는 방법에 대해 설명하겠다. (위의 UTWeapon 을 예로들어 계속 설명)

먼저 적당한 .cpp 파일을 만든다. UTWeapon.cpp 라고 파일을 만든 후 그 안의 내용은 아래와 같아야 한다.

// UTWeapon.cpp
#include "UTGame.h"
#include "UTGameMyWeaponClasses.h"    // UTWeapon이 선언된 헤더
 
IMPLEMENT_CLASS(AUTWeapon);           // 클래스의 기본적인 기능들을 정의
 
UBOOL AUTWeapon::Tick( FLOAT DeltaTime, ELevelTick TickType )
{
    ...
}

여기서 핵심은 IMPLEMENT_CLASS 이다. 이것은 엔진 내에서 필요한 기본기능 및 글루코드에 필요한 기능들을 자동으로 정의해주는 매크로이다.

나머지 함수들은 알아서 정의한다.

글루코드 등록

이제 엔진이 알 수 있도록 글루코드를 등록할 차례이다. 복잡한 설명은 생략하고 바로 코드 들어간다.

// UTGame.cpp
 
...
 
#include "UTGameMyWeaponClasses.h"                  // 다른 헤더들을 보고 "여기다 싶은 곳" 에 모두 포함시킨다.
 
...
 
void AutoInitializeRegistrantsUTGame( INT& Lookup )
{
    AUTO_INITIALIZE_REGISTRANTS_UTGAME;
    AUTO_INITIALIZE_REGISTRANTS_UTGAME_MYWEAPON;    // 여기서 등록
    ...
}
 
void AutoGenerateNamesUTGame()
{
    ...
    #include "UTGameMyWeaponClasses.h"              // 여기서 이름 (Name) 등록
    ...
}
 
...
1) 언리얼엔진3로 개발된 게임의 실행파일에 스크립트 컴파일 모듈이 포함되어 있다.
2) 현재(20100909)확인해본 결과, 간혹 헤더파일이 생성되지 않는 경우가 있다. 아마 엔진버그같은데 이럴땐 헤더파일을 수동으로 생성해주고 스크립트 컴파일을 해주면 잘 반영된다.

반응형
반응형

 PackageNames.AddItem(TEXT("Sample02_LoadPackage"));

네이티브 패키지 목록에 패키지 추가하기

void appGetGameNativeScriptPackageNames(TArray<FString>& PackageNames, UBOOL bCanIncludeEditorOnlyPackages)
{
...
   PackageNames.AddItem(TEXT("AutoGenExample"));
}

반응형
반응형

http://donggas90.blog.me/100141378528



[UDK] 프로그래밍 초보를 위한 언리얼 스크립트 코드 10선

  

이번 포스트는 프로그래밍을 UDK로 처음 접하시는 분을 위해 적어 볼까 합니다.

 

 

먼저 UDK(언리얼 엔진)는 언리얼 스크립트라는 자신들만의 언어를 사용합니다.

 

 

언리얼 스크립트를 위한 비쥬얼 스튜디오 플러그인 엔프린지와

스크립팅을 시작하는 방법에 대해서는 아래 포스트에서 확인하세요.

http://donggas90.blog.me/100127258591

 

 

그리고 짠 언리얼 스크립트를 어떻게 게임과 에디터에 적용하는 지에 대한 정보는

아래 포스트를 확인하세요.

http://donggas90.blog.me/100134298424

 

 

위 두 포스트의 내용을 숙지하셨다는 가정 하에 시작하겠습니다.

 

 

1. 클래스 오버라이드 - extends

 

  class HUD extends Actor;

 HUD.uc의 일부입니다.

 

class는 앞으로 클래스를 선언할 것임을 나타 냅니다.

 

HUD는 이 클래스의 이름을 나타내며, uc파일과 이름이 같아야 합니다. 

 

extends는 이 클래스가 어느 클래스를 오버라이드하고 있는지 가르킵니다.

 

Actor는 extends가 가르키고 있는 클래스 입니다.

 

;는 여기까지 클래스 선언이 끝났음을 알리고 있습니다. 

 

 

오버라이드란 extends가 가르키는 클래스의 모든 내용을 전부 그대로 복사한다는 뜻입니다.

 

복사'당한' 클래스는 부모 클래스가 되고, 복사'받은' 클래스는 자식 클래스가 됩니다.

 

비록 그 내용이 여기 일일이 적혀 있지는 않지만 적혀져 있는 것으로 간주하는 것입니다.

 

 

그리고 또 다른 의미로 '덮어쓴다'는 의미가 있습니다.

 

부모 클래스에 있는 것을 다시 새로 쓸 때, 오버라이드했다고 합니다.

 

 

언리얼 스크립트 파일들을 하나하나 열어 보시면

 

모든 클래스들이 계속해서 다른 클래스를 오버라이드하고 있음을 알 수 있습니다.

 

그리고 그 가장 위에는 Object클래스가 있고 그 바로 밑에는 Actor가 있습니다.

 

즉, 모든 언리얼 스크립트의 시조는 Object입니다.

 

 

 

2. 변수 선언 - var

 

var string A;

var int B;

var(Variable) float C;

var bool D; 

var는 앞으로 변수를 선언할 것임을 나타냅니다. 

 

이것들은 이 변수가 어떤 타입인지 나타 냅니다. 

 

string이란 문자열을 말합니다. 

 

int란 정수를 말합니다. 

 

float이란 실수 말합니다.

 

bool이란 참, 거짓 논리자입니다. 

 

A는 이 변수의 이름이 A임을 나타냅니다.

 

;는 여기까지 변수의 선언이 끝났음을 나타냅니다. 

 

(Variable)란 언리얼 에디터에서 클래스 프로퍼티 창에

 

Variable이라는 카테고리를 만들고 이 변수를 표시하라는 의미이며 

 

반드시 필요하지는 않습니다. 

 

 

이런 방법으로 변수에 이름을 붙여 줄 수 있습니다. 

 

변수의 종류는 더 많지만 일단 이 정도만 알아도 대부분의 데이터 주무르기가 가능합니다.

 

 

변수에 값을 넣는 방법은 아래와 같습니다.

A = "string";

B = 123;

= 1.f;

이것들은 값을 넣어줄 대상입니다.

 

값을 받을 대상은 항상 왼쪽에 위치합니다.

 

=는 왼쪽에 있는 것에 오른쪽 것을 넣는다는 뜻입니다. 

 

일반적으로 사용하는 의미와는 다릅니다. 

 

넣을 대상과 넣어 줄것의 타입이 일치해야 함을 유의하세요. 

 

"string"은 문자열 string을 나타냅니다. " 가 양쪽으로 사용됐음에 유의하세요.

 

123는 정수 123(백이십삼)을 나타냅니다. 

 

별다른 기호를 사용하지 않아도 됩니다. 

 

1.f는 실수 1(일)을 나타냅니다. 

 

언리얼 스크립트에서는 정수와 실수를 구분하기 위해 

 

실수에는 특수한 표기 방법을 사용합니다. 

 

값의 끝에 f를 붙이는 것이 그것입니다.

 

만약 소수점 자리가 없다면 .(온점)과 함께 f를 붙입니다.

 

;는 여기까지 명령이 끝났음을 알립니다. 

 

 

* 심화

var array<int> A;

 

A[0] = 1;

A[100] = 2;

 

배열은 이름은 같은데 다른 번호를 가진 여러 값의 무리입니다.

 

 

 

 

3. 기본값 - DefaultProperties

 

DefaultProperties
{ 

 A = 123

} 

DefaultProperties{ 는 앞으로 기본값 영역이 시작될 것임을 의미합니다. 

 

A의 기본값이 123임을 의미합니다. 여기서 세미콜론(;)은 선택 사항입니다.

 

} 는 기본값 영역이 끝났음을 의미합니다. 

 

 

이렇게 하면 A는 UDK가 시작되면 항상 123일 것입니다. 

 

이런식으로 기본값이 필요할 경우 정의해 줄 수 있습니다.

 

 

* 심화

런타임이 초기화될 때마다 이 영역의 기본값이 로드됩니다.

 

 

4. 함수 - function

 

함수를 선언하는 방법은 아래와 같습니다.

 

function EXAMPLE()

{

A = 123;

}

function{}는 함수 영역을 나타냅니다. 

 

EXAMPLE는 함수의 이름을 나타냅니다.

 

()는 함수에 사용할 인수(파라미터)의 목록입니다. 

 

자세한 내용은 아래에... 

 

A = 123;는 함수에서 할 것입니다. 

 

 

이 함수가 집행되면  A = 123;을 할 것입니다.

 

하지만 재밌는 점은 이렇게 만들더라도 실질적으로 작동은 되지 않습니다.

 

왜냐면 언리얼 엔진이 이 함수를 호출하지 않기 때문입니다.

 

따라서 이 함수를 작동하게 하려면

 

언리얼 엔진이 호출하는 함수 안에서 이 함수를 호출해야 합니다.

 

simulated event Tick(float DeltaTime)
{
 

 EXAMPLE();

} 

대표적인 예로 Tick이라는 이벤트가 있습니다.

 

이 이벤트는 일정 시간 간격으로 계속 이 영역을 집행합니다.

 

그리고 그 시간 간격은 DeltaTime에 실수 타입으로 저장합니다.

 

 

이벤트는 함수와는 성격이 다른데, 이벤트는 모두 언리얼 엔진이 특정 상황이나 조건에서 호출하는 것입니다.

 

임의로 프로그래머가 호출할 수 없습니다.

 

 

 

function EXAMPLE( int B )

{  

A = 25;

A = B;

} 

 

EXAMPLE( 12 ); 

A는 12 

위 스크립트는 인수 사용의 대표적인 예입니다.

 

인수는 함수를 선언할 당시에는 타입만 지정돼 있습니다.

 

뭔가 값은 없습니다.

 

하지만 다른 곳에서 사용되었을 때 그 값을 지정해 주고

 

함수 내용을 집행하게 됩니다.

 

 

 

 

5. 함수의 변수화 - return

 

앞에서 함수에 대해 알아 봤습니다.

 

그런데 함수에서 뭔가 계산한 뒤 바로 무엇인가 얻고 싶을 경우가 생길 겁니다.

 

따로 변수의 도움 없이 말입니다.

 

function int EXAMPLE()

{

A = 123; 

return A; 

} 

 

B =  EXAMPLE();

B는 123 

int로 이 함수는 정수 결과를 출력할 것임을 나타냅니다. 

 

return A; 로 이 함수의 출력 값은 A값임을 알립니다.

 

이렇게 하면 함수 내에서 계산한 값을 또 다른 변수에 넣어주고

 

다시 받아서 B에 할당하는 번거로운 과정이 생략됩니다. 

 

* 심화

function Ex ( out int A )

{

A = B + C ;

return;

}

값을 직접 받지 않고 간접으로 받을 수도 있습니다.

 

 

6. 부모 함수 집행 - super

 

오버라이드는 덮어쓴다는 개념이 있다고 말씀 드렸습니다.

 

덮어쓰게 되면 이전의 것은 없어지고 새로운 것만 작성되게 됩니다.

 

함수 역시 오버라이드할 수 있습니다.

 

그런데 함수를 통째로 다시 쓰지 않고 나만의 새로운 코드만 추가하고 싶을 때가 있습니다.

 

이럴 때 쓰는 것이 super코드입니다.

function EXAMPLE()

{

super(Actor).Example(); 

A = 123;

}

super.Example();로 가장 가까운 부모에 있는 Example()함수를 집행하도록 합니다. 

 

 (Actor)는 선택 사항인데 어느 클래스에 있는 부모 함수를 집행할지 지정합니다.

 

 부모 엑터 클래스의 함수가 집행된 뒤 A=123; 집행되게 됩니다.

 

게임의 기본 틀을 구성하는 함수여서 마음데로 수정이 어렵거나

 

언리얼 엔진이 호출하는 이벤트에 내용을 덧붙이고 싶을 때 아주 유용합니다.

 

 

 

7. 조건부 - if

 

뭔가 조건을 제시하고 그게 맞다면 실행되게 하고 싶을 때가 많을 겁니다.

 

이럴 때 쓸 수 있는 것이 if 코드 입니다.

if ( A == 1 )

{

 B = 1;

} 

else if ( A == 2 )

{ 

B = 2; 

} 

else 

{ 

B = 3; 

} 

이것들은 한 묶음입니다. if와 else는 처음과 끝에 각각 하나만 올 수 있고 

 

else if 는 원하는 만큼 쓸 수 있습니다. 

 

이것이 참이면 그 아래 영역을 집행합니다. 

 

즉, A가 1이면 B는 1이될 겁니다. 

 

여기에 사용되는 논리 판단 기호에 유의하세요. 

 

==는 서로 같은지 비교합니다. 

 

!=는 서로 다른지 비교합니다.

 

이외에 <, >, <=, >=는 일반적인 수학에서 쓰는 그데로입니다. 

 

if는 조건 부분을 무조건 참인지 거짓인지 판단합니다.

else if 는 if의 조건이 거짓일 경우 참인지 거짓인지 판단합니다.

else 는 if 와 else if 의 조건 모두가 거짓이면 집행합니다.

 

 

위에서 적어드린데로 프로그램이 조건을 검사하게 됩니다.

 

조건을 검사하려면 CPU가 계산을 해야하고

 

그러면 리소스가 소모 됩니다.

 

게임을 최적화하려면 if를 남발하지 말고 적절히 else를 이용해야 합니다.

 

 

조건을 검사할 때, 꼭 한 가지가 아니라 여러 가지의 조건을 쓰는 경우가 있습니다.

 

이럴 때 수학에서는 AND, OR라는 표현을 쓰는데

 

프로그래밍에도 이런 개념이 존재합니다.

if ( A == 1 && B == 3 )

{

B = 1;

}

else if ( A == 2 || B == 1 )

{

B = 2;

}

&&(쉬프트 + 숫자 7)는 AND라는 의미입니다.

 

||(쉬프트 + \)는 OR라는 의미입니다.

 

 

덧붙여 이런 것도 가능합니다.

var bool A;

 

A = true;

B = 0;

 

if ( A )

{

B = 1;

} 

 

B는 1 

조건 부분이 참(true)인지 거짓(false)인지 검사하는 것이기 때문에

 

조건 그 자체가 참인 경우도 집행됩니다.

 

* 심화

switch(A) 

{ 

case(1) : 

//A가 1이면 집행합니다. 

break;//으로 집행의 끝을 알립니다. 

 

default: 

//A와 관계 없이 집행합니다.

break; 

} 

 

 

8. 변수의 무리 - struct

 

변수들을 여럿 선언하고 보면

 

이따금씩 서로 관련이 있는 변수인 경우가 있습니다.

 

예를 들면 게임 케릭터의 능력치입니다.

 

힘 변수를 선언하고 지능 변수를 각각 선언한다면

 

관리하기가 쉽지 않겠죠.

 

왜냐면 케릭터가 하나가 아닐테니까요.

 

그리고 새로운 능력치를 추가하려면 대부분의 코드들을 뜯어 고쳐야할 것입니다.

 

이럴 때 필요한 것이 바로 구조체, struct 코드입니다.

struct CharacterInfo

{

var int Strength;

var int Intelligence;

};

struct로 여기부터 구조체를 선언하겠다고 알립니다. 

 

CharacterInfo는 이 구조체의 이름입니다. 

 

var int Strength; 구조체에 포함된 변수입니다. 

 

; 구조체를 선언한 뒤 붙이는 것을 잊지 마세요. 

 

그런데 이걸 어떻게 사용하는 걸까요.

 

<strong></strong>

var CharacterInfo A;

구조체를 선언하면 마치 변수 타입인 것처럼 사용할 수 있습니다.

 

A라는 이름을 가진 CharacterInfo 구조체를 만들었습니다.

 

그렇다면 구조체에 포함된 변수는 어떻게 쓰는 걸까요.

 

A.Strength = 123;

A.Intelligence = 321;

구조체의 이름 뒤에 온점을 붙여 그 속에 포함된 변수를 부를 수 있습니다.

 

 

다른 이름의 같은 구조체가 있습니다.

 

하나의 값을 다른 하나에 넣어 주기 위해

 

포함된 변수를 하나하나씩 불러 할당하고 있습니다.

 

var CharacterInfo A; 

var CharacterInfo B; 

 

A.Strength = B.Strength;

A.Intelligence = B.Intelligence;

물론 이런 방법을 쓸 수도 있지만 

 

굳이 일일이 값들을 불러오지 않아도 됩니다.

 

var CharacterInfo A;

var CharacterInfo B;

 

A = B;

 

 

 

 

9. 메모 - /* **/

 

프로그래밍 언어는 우리가 쓰는 말과는 전혀 다릅니다.

 

그리고 복잡한 함수나 추상적인 이름의 변수를 사용해야 하는 경우가 자주 발생합니다.

 

이를 설명하기 위해 메모, 주석을 달게 됩니다.

/** 수 두 개를 더하는 함수 */

function int Add( int A, int B )

{

C = A + B;

return C;

}

/** */이 부호가 사용된 문자들은 모두 무시됩니다.

 

비쥬얼 스튜디오와 엔프린지를 사용하는 경우

 

Add에 마우스를 올리면 툴팁이 나오는데

 

두번째 줄에 주석의 내용이 표시됩니다.

 

 

* 심화

/** 수 두 개를 더하는 함수

* @param A 더할 첫번째 값

* @param B 더할 두번째 값 */

<strong></strong>

function int Add( int A, int B )

{

C = A + B;

return C;

} 

파라미터마다 개별적인 주석을 달 수도 있습니다. 

 

 

 

10. 디버깅 - `log 

 

버그는 예상치 못한 곳에서 주로 발생합니다. 

 

버그를 해결하는 작업을 디버깅이라 하는데 

 

디버깅을 위해서 사용되는 코드가 있습니다. 

 

바로 `log코드입니다. 

 

`는 1의 왼쪽에 있는 키입니다.

 

쉬프트를 누르면 ~이 되는 키죠.

`log("test");

이런 식으로 사용합니다.

 

괄호안의 내용은 문자열이므로 쌍따옴표를 사용해야 합니다.

 

그런데 이 글자는 어디서 확인하는 것일까요.

 

UDK에서 게임 태스트를 시작합니다.

 

그리고 커멘드라인에 SHOWLOG를 입력하면

 

윈도우 cmd같은 검은 창이 표시됩니다.

 

만약 로그가 정상적으로 집행됐다면

 

그곳에 하얀색 글씨로 test란 글자가 나타날 겁니다.

 

 

이런 단순 문자열 로그는 특정 함수나 조건부가 제대로 동작하는지

 

파악할 때 유용합니다.

 

 

만약 변수 값이 궁금할 때는 어떻게 할까요.

 

그럴 때는 이렇게 합니다.

var int A;

`log("variable is"@A);

@는 문자열을 공백 하나를 넣고 합칠 때 사용합니다.

 

만약 A가 123이면

 

로그창에는 이렇게 나타날 것입니다.

 

variable is 123

 

로그 코드는 디버깅에 효과적이기는 하지만

 

로그 또한 집행하려면 CPU가 계산을 해야 합니다.

 

따라서 디버깅이 끝나면 로그 코드는 지워 주세요.

 

반응형
반응형

퍼포스에서 UE3 코드 베이스 싱크를 마치고나면 퍼포스 디포 루트 폴더에 UnrealEngine3 라는 디렉토리가 생길 것입니다.

"UnrealEngine3" 폴더 안에는 다음 디렉토리가 있습니다:

  • Binaries - 이 파일에는 바이너리 오브젝트가 담깁니다. 엔진/게임의 컴파일된 버전, UE3 필수 DLL (DirectX, wx 런타임 등), 에디터 리소스 파일 (아이콘 이미지) 등입니다.
  • Development - 엔진의 모든 소스가 실제로 들어가는 곳으로, 이 폴더 안에는:
    • Build - 저희 CIS(연속 통합 서버) 상에서 여러가지 유형의 빌드를 발송하는 배치 파일을 저장하는 곳입니다. CIS 는 빌드를 검사하여 저희가 빌드 에러를 가급적 빠르게 잡아낼 수 있도록 해 줍니다.
    • Documentation - 문서 파일 저장용 폴더입니다. 저희의 자동 생성 윈도우 도움말 파일(UnrealEngine3.chm)이 여기 저장됩니다. 이 도움말 파일은 언리얼 소스를 빠르게 돌아보는 데 큰 도움이 되는 자료입니다.
    • External - 모든 에픽 외부 라이브러리 소스는 이 폴더에 저장됩니다. libPNG, wxWidgets, zlib, Cg 등입니다.
    • Intermediate - 모든 중간 빌드 파일은 여기 저장됩니다. .obj 파일, 미리컴파일된 헤더 등입니다.
    • Src - 소스 파일과 프로젝트 메이크파일용 폴더입니다. 주요 UnrealEngine3 솔루션은 이 폴더에 있습니다. 솔루션 안에는 각 프로젝트에 대한 폴더 역시 있습니다. 예제 프로젝트는 다음과 같이 나뉘어 있습니다:
      • Game 폴더
        • 프로젝트의 루트 폴더 안에는 프로젝트의 비주얼 스튜디오 프로젝트 파일이 있습니다.
        • Classes - .uc (UnrealScript) 파일을 담는 폴더입니다.
        • Inc - .h 파일을 담는 폴더입니다.
        • Src - .cpp 파일을 담는 폴더입니다.
    • Tools - 다양한 엔진 관련 툴에 대한 소스가 모두 저장된 폴더입니다. UDE 비주얼 스튜디오 매크로나 명령줄 툴같은 것들입니다.
  • Engine/Game 폴더 - Binaries 와 Development 폴더 다음에는 Engine 에 대한 폴더가, 그 이후 엔진을 사용하는 각 게임에 대한 폴더가 하나씩 있습니다.
    • Config - 해당 게임에 사용된 세팅을 저장하는 데 사용된 .ini 파일을 담습니다.
    • Content - 해당 게임용 콘텐츠 패키지를 담는 폴더입니다.
    • Localization - 해당 게임용 현지화 텍스트를 담는 폴더입니다.
    • Logs - 해당 게임 실행시 생성되는 로그 파일을 담는 폴더입니다.
    • Script - 해당 게임에 대한 컴파일된 UnrealScript 코드(.u 파일)를 담습니다.

프로젝트 구조


UE3 는 여러 프로젝트로 나뉘는데, 시스템을 분리하고 크로스-플랫폼 호환성을 쉽게 유지할 수 있도록 하기 위해서입니다.

기본 구조는 (최하위 레벨 코드에서 최상위 레벨까지) 다음과 같습니다:

  • Core
  • Engine
  • Editor
  • UnrealED

참고로 이 프로젝트 모두는 서로의 위에 빌드됩니다. 즉 Engine 은 Core 에 의존, Editor 는 Engine 에 의존, UnrealED 는 Editor 에 의존합니다.

  • Core: Core 는 최하위 레벨 클래스로, 문자열 클래스, 배열 클래스, 메모리 매니저와 같은 것들입니다. 말 그대로 핵심 스크립팅 및 로딩 코드가 있는 곳입니다.

  • Engine: Engine 은 대부분의 렌더링과 게임플레이 코드가 있는 곳입니다. 액터, 충돌 감지는 물론 여러가지 서브시스템에 관련된 코드도 포함되어 있습니다. 대부분의 '게임 인터페이스' 코드가 있는 곳입니다.

  • Editor: Editor 는 에디터가 실행중일 때만 실행되는 클래스와 루틴으로 구성됩니다. 사용자가 폴리곤, 브러시, 터레인을 조작 및 보통 게임내에서는 할 수 없는 다른 작업을 할 수 있도록 해 주는 클래스입니다.

  • UnrealED: UnrealED 는 에디터의 실제 UI 구현으로, 에디터 어플리케이션 코드 전부가 있는 곳입니다. 현재 저희가 선택한 UI 툴키트는 wxWindgets 입니다. 작성할 필요가 있는 wxWidgets 코드는 UnrealED 안에 작성됩니다. 'Editor' 프로젝트에는 편집 툴의 모든 함수성이 들어가고, 코드는 UnrealED 에 들어간다는 개념은 그저 해당 함수성에 대한 UI 감싸개(wrapper)일 뿐입니다.

다른 플랫폼 전용 프로젝트도 여럿 있는데, D3DDrv (렌더링의 Direct 3D 구현), WinDrv (뷰포트 생성, 이벤트 처리 등의 윈도우 구현) 등입니다. 한 프로젝트가 크로스-플랫폼 인터페이스의 특정 플랫폼 전용 구현이라면 보통 Drv 같은 접미사가 붙게 마련입니다.

반응형
반응형


Licensees can log in.

Red links require licensee log in.


Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 홈 > UDK 젬 > 머티리얼 에디터 사용 안내서
UE3 홈 > 머티리얼과 텍스처 > 머티리얼 에디터 사용 안내서

머티리얼 에디터 사용 안내서


문서 변경내역: Dave Burke 작성. Daniel Wright, Richard Nalezynski, Jeff Wilson 수정. 홍성진 번역.

개요


언리얼 에디터의 머티리얼 에디터 사용법에 대한 설명서입니다. 다양한 머티리얼 표현식의 역할에 대한 설명은 Materials Compendium KR (머티리얼 개론) 페이지를, 새 머티리얼 표현식 제작법에 대해서는 Creating Material Expressions KR 페이지를 참고해 주시기 바랍니다.

모바일 플랫폼용 머티리얼 제작에 대한 정보는 Mobile Material Reference KR 페이지를 참고해 주시기 바랍니다.

머티리얼 에디터 열기


머티리얼 에디터는 머티리얼 애셋을 더블클릭하거나 콘텐츠 브라우저의 머티리얼 애셋의 우클릭 맥락 메뉴를 통해 열 수 있습니다. 어느 방법으로나 해당 머티리얼이 머티리얼 에디터에서 편집 가능한 상태로 열리게 됩니다.

머티리얼 에디터 인터페이스


머티리얼 에디터는 여섯 구역으로 구성되어 있습니다:

materialeditor.jpg

  1. 메뉴바
  2. 툴바
  3. 미리보기 패널 - 메시의 머티리얼을 미리봅니다.
  4. 머티리얼 표현식 그래프 패널 - 셰이더 인스트럭션 제작을 위해 이 패널에서 머티리얼 표현식을 결합합니다.
  5. 머티리열 표현식 패널 - 사용가능한 머티리얼 표현식 목록입니다.
  6. 머티리얼 함수 라이브러리 - 사용할 수 있는 머티리얼 함수 목록입니다.
  7. 프로퍼티 패널 - 머티리얼이나 선택된 머티리얼 표현식 노드의 프로퍼티입니다.

메뉴바

  • 프로퍼티 - 프로퍼티 패널이 표시됩니다.
  • 미리보기 - 미리보기 패널이 표시됩니다.
  • 머티리얼 표현식 - 머티리얼 표현식 그래프를 표시합니다.

툴바

toolbar.jpg

다음은 각 툴바 버튼에 대한 설명으로, 툴바 표시상 왼쪽에서 오른쪽 순입니다.

아이콘 설명
toolbar_home.jpg 메인 패널의 좌상단 코너에 베이스 머티리얼 노드가 오도록 머티리얼 표현식 그래프를 옮깁니다.
toolbar_grid.jpg 머티리얼 미리보기 패널의 배경 그리드를 토글합니다.
toolbar_cylinder.jpg toolbar_cube.jpg toolbar_sphere.jpg toolbar_plane.jpg 머티리얼 미리보기에 사용할 표준 모양을 선택합니다.
toolbar_find.jpg 콘텐츠 브라우저를 열고 머티리얼을 선택합니다.
toolbar_usestatic.jpg 콘텐츠 브라우저에서 스태틱 메시를 선택하고 이 버튼을 누르면 선택된 메시를 미리보기 메시로 지정합니다.
toolbar_clean.jpg 머티리얼에 연결되지 않은 머티리얼 표현식 노드를 지웁니다.
toolbar_show.jpg 아무것에도 연결되지 않은 머티리얼 표현식 단자를 표시/숨깁니다.
toolbar_realtime_preview.jpg 켜면 미리보기 메시의 머티리얼을 실시간으로 업데이트합니다. 에디터 성능을 위해서라면 이 옵션은 끄십시오.
toolbar_realtime_expression.jpg 켜면 각 머티리얼 표션식 노드의 머티리얼을 실시간으로 업데이트합니다. 에디터 성능을 위해서라면 이 옵션은 끄십시오.
toolbar_realtime_preview_expression.jpg 이 버튼은 머티리얼 표현식의 bRealtimePreview (실시간 미리보기) 옵션에 대한 글로벌 토글입니다. 켜면 모든 하위표현식의 셰이더는 노드가 추가, 삭제, 연결, 연결 해제, 프로퍼티 값 변경시마다 컴파일됩니다. 에디터 성능을 위해서라면 이 옵션은 끄십시오. 표현식 미리보기 부분을 참고하십시오.
toolbar_apply.jpg 머티리얼 에디터에서 변경한 사항을 원본 머티리얼과 월드에 해당 머티리얼을 사용한 곳에 적용합니다.
toolbar_stats.jpg 표현식 그래프 패널에 머티리얼 통계를 표시/숨깁니다.
toolbar_source.jpg 현재 선택된 표현식에 대한 HLSL 소스 표시를 토글합니다.
toolbar_search.jpg 텍스트 일부가 일치하는 표현식을 검색할 수 있습니다. 자세한 것은 머티리얼 표현식 검색 부분을 참고하십시오.

미리보기 패널

previewpane.jpg

머티리얼 미리보기 패널은 편집중인 머티리얼을 메시에 적용하여 보여줍니다. 마우스 왼쪽 버튼으로 끌면 메시의 회전, 가운데 버튼으로는 패닝, 오른쪽 버튼으로는 줌입니다. 라이트의 방향은 L키를 누르고 좌클릭 드래깅으로 회전시킬 수 있습니다.

관련 툴바 콘트롤(모양 버튼, "미리보기 메시 선택" 콤보 박스, "선택된 스태틱 메시 사용" 버튼 등)을 사용하여 미리보기 메시를 바꿀 수 있스니다. 미리보기 메시는 머티리얼에 저장되므로 다음 번에 머티리얼 에디터에서 열 때도 같은 메시에서 미리볼 수 있습니다.

프로퍼티 패널

propertiespane.jpg

이 패널에는 선택된 머티리얼 표현식에 대한 프로퍼티창이 담깁니다. 선택된 표현식이 없으면 편집중인 머티리얼 자체의 프로퍼티가 표시됩니다.

모든 머티리얼 프로퍼티에 대한 설명은 Materials Overview KR 페이지를 확인하시기 바랍니다.

머티리얼 표현식 패널

expressionpane.jpg

이 패널에는 "드래그 앤 드롭" 방식으로 머티리얼에 놓을 수 있는 머티리얼 표현식이 나열됩니다. 머티리얼 표현식 노드를 새로 놓으려면, 표현식에 좌클릭 > 그래프 패널로 드래그 > 원하는 위치에 드롭 하면 됩니다.

머티리얼 함수 라이브러리

functionpane.jpg

이 패널에는 "드래그 앤 드롭" 방식으로 머티리얼에 놓을 수 있는 머티리얼 함수 목록이 표시됩니다. 새로운 머티리얼 함수를 놓으려면 놓으려는 함수 종류에 왼클릭한 후, 커서를 그래프 패널 위로 끌어 놓습니다. 적합한 머티리얼 함수가 할당된 MaterialFunctionCall 노드가 새로이 놓입니다.

머티리얼 표현식 그래프 패널

graphpane.jpg

이 패널에는 이 머티리얼에 속하는 모든 머티리얼 표현식의 그래프가 포함되어 있습니다. 머티리얼에 사용된 셰이더 인스트럭션 수와 함께 컴파일러 에러 도 좌상단 구석에 표시됩니다. 인스트럭션 수가 적을 수록 머티리얼 비용도 싸집니다. 기본 머티리얼 노드에 연결되지 않은 머티리얼 표현식 노드는 머티리얼의 인스트럭션 수(비용)에 계산되지 않습니다.

머티리얼에는 디폴트로 하나의 머티리얼 노드가 포함되어 있습니다. 이 노드에는 여러가지 입력이 달려 있는데, 각각은 머티리얼의 다양한 면에 관련되어 있으며, 여기에 다른 표현식이나 표현식 망이 연결될 수 있습니다.

material_node.jpg

머티리얼 노드의 여러가지 입력에 대한 설명은 Materials Overview KR 페이지를 확인해 주시기 바랍니다.

콘트롤

머티리얼 에디터의 콘트롤은 언리얼 에디터 내의 다른 툴 콘트롤과 일반적으로는 비슷합니다. 머티리얼 표현식 그래프는 여타 오브젝트 에디터들과 같은 식으로 조작할 수 있으며, 머티리얼 미리보기 메시도 다른 메시 툴과 마찬가지로 방향을 맞출 수 있습니다.

마우스 콘트롤

콘트롤 액션
배경에 좌/우클릭-드래그 머티리얼 표현식 그래프 패닝
마우스 휠 스크롤 줌 인/아웃
좌+우클릭 드래그 줌 인/아웃
오브젝트에 좌클릭 표현식/코멘트 선택
오브젝트에 Ctrl + 좌클릭 표현식/코멘트 선택 토글
Ctrl + 좌클릭 + 드래그 현재 선택/코멘트 옮기기
Ctrl + Alt + 좌클릭 + 드래그 박스 선택
Ctrl + Alt + Shift + 드래그 박스 선택(하여 현재 선택에 추가)
단자에 좌클릭 + 드래그 (하다가 단자나 변수에서 떼면) 연결 생성
연결에 좌클릭 + 드래그 (하다가 같은 종류의 단자나 변수에서 떼면) 연결 이동
단자에 Shift + 좌클릭 단자를 마크합니다. 단자가 마킹된 상태로 다른 단자에 Shift + 클릭하면 두 단자를 연결합니다. 원거리 연결이 매우 빨라집니다.
배경에 우클릭 새 표현식 메뉴를 띄웁니다.
오브젝트에 우클릭 오브젝트 메뉴를 띄웁니다.
단자에 우클릭 오브젝트 메뉴를 띄웁니다.
단자에 Alt + 좌클릭 단자의 무든 연결을 끊습니다.
(미리보기 패널에서) L 키 + 드래그 미리보기 라이트 방향을 돌립니다.

키보드 콘트롤

콘트롤 액션
Ctrl + C 선택된 표현식 복사
Ctrl + V 붙여넣기
Ctrl + W 선택된 오브젝트 복제
Ctrl + Y 다시하기
Ctrl + Z 되돌리기
Delete 선택된 오브젝트 삭제
스페이스바 모든 머티리얼 표현식 미리보기 강제 업데이트
Enter (적용 클릭과 동일)

핫키

자주 사용되는 머티리얼 표현식 유형은 핫키로 놓을 수 있습니다. 단축키를 누르고 노드의 놓을 곳에 좌클릭하면 됩니다. 핫키는 다음과 같습니다:

핫키 표현식
A Add 더하기
B BumpOffset 범프 오프셋
C ComponentMask 컴포넌트 마스크
D Divide 나누기
E Power 파워(승)
F MaterialFunctionCall 머티리얼 함수 호출
I If 만약
L LinearInterpolate 선형 보간
M Multiply 곱하기
N Normalize 정규화
O OneMinus 1빼기
P Panner 패너
R ReflectionVector 리플렉션 벡터
S ScalarParameter 스칼라 파라미터
T TextureSample 텍스처 샘플
U TexCoord 텍스처 좌표
V VectorParameter 벡터 파라미터
1 Constant 상수
2 Constant2Vector 상수 2벡터
3 Constant3Vector 상수 3벡터
4 Constant4Vector 상수 4벡터
Shift + C Comment 코멘트

표현식 코멘트


코멘트는 머티리얼의 역할을 설명하기에 좋으며, 타인은 물론 자신에게도 복잡한 머티리얼 그래프를 이해하는 데 도움이 됩니다. 코멘트는 관련된 노드 위에 나타나는 파랑 텍스트로 표시됩니다. 코멘트는 줌과 별도로 표시되므로 복잡한 머티리얼 그래프를 쉽게 옮겨다닐 수 있습니다.

Comments.jpg

머티리얼 표현식 노드는 해당 노드의 "Desc" 프로퍼티에 텍스트를 입력하여 개별적으로 코멘트를 달 수 있습니다.

여러 노드를 선택하고 'Shift + C'를 쳐서 노드 그룹에 그룹 코멘트를 할당할 수도 있습니다. "새 코멘트" 대화창에 코멘트 텍스트를 입력하고 OK를 칩니다. 선택된 노드가 코멘트 프레임에 묶이게 됩니다. 그룹 코멘트의 노드는 그룹 코멘트 텍스트를 드래그하여 움직일 수 있습니다. 코멘트 프레임의 우하단 코너에 있는 검정 삼각형을 드래그하여 프레임 크기도 조절할 수 있습니다. 그룹 코멘트 내의 노드는 전부 프레임과 함께 움직이므로, 기존 프레임 크기를 조절하여 새 노드를 포함시킬 수도 있습니다.

코멘트를 선택하고 프로퍼티창을 통해 "Text" 프로퍼티를 변경하면 코멘트의 이름을 바꿀 수 있습니다.

표현식 미리보기


RealtimePreviewCloseup.jpg

머티리얼 에디터의 노드에는 좌상단 구석에 작은 박스가 있습니다. 이 박스는 노드의 bRealtimePreview (실시간 미리보기) 프로퍼티를 나타내며: 노랑은 켜짐, 검정은 꺼짐 입니다.

머티리얼이 어떤 식으로든 (생성, 삭제, 연결, 프로퍼티 변경 등등) 바뀔 때마다, bRealtimePreview (실시간 미리보기) 프로퍼티가 켜진 노드는 전부 그 셰이더를 다시 컴파일합니다. 머티리얼 미리보기를 해당 노드에서 최신으로 유지하려면 이런 리컴파일이 필요합니다. 그러나 이런 중간 셰이더 리컴파일은 시간을 잡아먹을 수 있는데, 특히나 머티리얼에 노드가 많을 경우에는 더합니다. 그래서 작업 방해를 피하기 위해서, TextureSample 을 제외한 모든 노드 유형에 대해서는 기본적으로 bRealtimePreview (실시간 미리보기)가 꺼져 있습니다.

스페이스바를 쳐서 강제로 모든 미리보기를 업데이트시킬 수도 있습니다. 아무튼 가급적 많은 노드의 bRealtimePreview (실시간 미리보기)를 끄고, 변경 확인시마다 스페이스를 치는 방식을 통해 반복처리 속도를 높일 수 있습니다.

노드의 좌상단 구석 박스를 클릭하거나, 노드를 선택한 상태에서 프로퍼티 창을 통해 노드의 bRealtimePreview (실시간 미리보기)를 토글할 수 있습니다.

"Toggle Expression Realtime Preview" (표현식 실시간 미리보기 토글) 버튼으로 모든 노드 글로벌 토글이 가능합니다.

컴파일러 에러


머티리얼 망에 무언가 변화가 있을 때마다 머티리얼을 컴파일해 줘야 합니다. 망 내 어느 표현식에 필요한 입력에 연결된 것이 없거나 잘못된 데이터형이 주어지는 경우, 컴파일 에러가 납니다. 이 에러는 그래프 패널 에 표시됩니다.

error_message.jpg

컴파일러 에러에 제공되는 문제 발생 표현식의 종류와 에러에 대한 설명을 통해, 그 문제가 무엇인지 알 수 있습니다. 게다가 에러가 있는 노드는 그래프 패널에 빨갛게 강조되어 보이므로, 쉽게 찾아 필요한 연결을 메꿀 수 있습니다.

error_highlight.jpg

머티리얼 표현식 검색


머티리얼 에디터의 검색 기능을 활용하면 머티리얼 망 내 (코멘트 포함) 어느 노드든, 그 설명이나 각 표현식 종류에 한정된 여러 프로퍼티에 지정한 텍스트가 포함되는 것을 빠르게 찾아 줍니다. 노드에 식별 키워드를 추가해 놓고 나중에 찾아가거나 하기가 쉬워지니, 정처없이 표현식 바다를 허우적대지 않아도 됩니다.

검색 박스에 키워드 전체나 부분을 입력하면 그래프 패널에 있는 표현식의 프로퍼티를 대상으로 검색합니다. 일치되는 것이 현재 활성 결과라면 녹색으로 강조됩니다.

search_highlight.jpg

주: 검색은 대소문자를 구별합니다.

검색 대상 프로퍼티 값은 다음과 같습니다:

표현식 종류 검색되는 프로퍼티
All Desc
Texture Sample Texture
Parameters ParamName
Comment Text
FontSample Font
MaterialFunctionCall MaterialFunction

검색에 NAME= 스위치를 사용하면 특정 표현식 종류만을 대상으로 검색할 수도 있습니다. 예를 들어 모든 텍스처 샘플러를 찾으려면:

NAME=texture

search_next_button.jpgsearch_prev_button.jpg 버튼을 사용하여 검색 결과 표현식 전부를 돌아가며 볼 수 있습니다.

search_cycle.gif

애초부터든, search_next_button.jpgsearch_prev_button.jpg 버튼으로든, 선택된 일치 결과가 보이지 않는 경우, 그래프 패널의 뷰에 나타납니다.

검색을 비우려면 search_clear_button.jpg 버튼을 누르면 됩니다.

반응형
반응형

  • 클래스 선언. 각 클래스는 하나의 부모 클래스를 "extends" (..로부터 파생) 하며, 함께 분포되는 객체들의 콜렉션인 "package" 에 속해 있습니다. 모든 함수 및 변수들은 클래스에 속하며, 그 클래스에 속해 있는 액터를 통해서만 접근할 수 있습니다. 시스템 전체의 글로벌 함수나 변수는 없습니다. 자세한 설명.

  • 변수의 선언. UnrealScript는 가장 기초적인 C/Java의 타입, 객체 참조, 구조체 그리고 배열을 포함하여 매우 다양한 변수 타입의 세트를 지원합니다. 게다가 변수들을 디자이너들이 전혀 프로그래밍 하지 않고 UnrealEd 에서 접근할 수 있는, 편집이 가능한 속성으로 변경할 수 있습니다. 이 속성들은 var 대신 var() 구문을 사용해서 지정됩니다. 자세한 설명.

  • 함수들. 함수는 매개변수의 목록을 취할 수 있으며, 선택적으로 값을 반환합니다. 함수는 로컬 변수를 가질 수 있습니다. 어떤 함수들은 Unreal 엔진 자체에 의해 호출되며 (예: BeginPlay), 어떤 함수들은 다른 곳에서 다른 스크립트 코드로부터 호출됩니다 (예:Trigger). 자세한 설명.

  • 코드. for, while, break, switch, if 등 C 와 Java 의 표준 키워드가 모두 지원됩니다. UnrealScript 에서도 괄호와 세미콜론이 C, C++ 및 Java 에서처럼 사용됩니다.

  • 액터 및 객체 참조. 함수가 객체 참조를 사용하여 다른 객체 내에서 호출되는 여러 경우를 볼 수 있습니다. 자세한 설명

  • 키워드 "state". 이 스크립트는 다수의 "state" 를 정의하고 있습니다. State 는 액터가 그 상태에 있을 때만 집행되는 함수, 변수 그리고 코드의 그룹입니다. 자세한 설명

  • UnrealScript 에서는 키워드, 변수의 이름, 함수 그리고 객체의 이름에 대소문자를 구분하지 않는다는 점에 유의하십시오. UnrealScript 에서는 Demon, demONdemon 이 모두 같은 것을 가리킵니다.

객체의 계층구조

Object 는 Unreal 내 모든 객체의 부모 클래스입니다. 모든 것들이 Object 에서 파생되기 때문에, 어디에서나 Object 클래스 내에 있는 모든 함수들에 접근할 수 있습니다. Object 는 abstract 기초 클래스이므로, 그 자체는 전혀 유용한 일을 하지 않습니다. 모든 기능성은 Texture (텍스처 맵), TextBuffer (텍스트의 덩어리), 그리고 Class (다른 객체의 클래스를 설명하는) 등의 하위클래스에 의해 제공됩니다.

Actor (extends Object) 는 Unreal 내 모든 자립형 게임 객체들의 부모 클래스입니다. Actor 클래스는 액터가 돌아다니고, 다른 액터들과 상호작용하고, 환경에 영향을 주고, 게임에 관련된 다른 유용한 일들을 하는데 필요한 모든 기능성을 함유하고 있습니다.

Pawn (extends Actor) 은 고급 수준의 AI 및 플레이어 콘트롤을 감당하는 Unreal 내 모든 창조물 및 플레이어들의 부모 클래스입니다.

Class (extends Object) 는 객체의 클래스를 설명하는 특별한 종류의 객체입니다. 클래스가 객체이고, 객체가 어떤 객체를 설명한다는 것이 처음에는 혼동스러워 보일지 모릅니다. 그러나 이 개념은 논리적인 것이며 여러분이 Class 객체를 다루어야 할 경우가 많습니다. 예를 들어 UnrealScript 에서 새 액터를 스폰할 때, 그 새 액터의 클래스를 Class 객체로 지정할 수 있습니다.

UnrealScript 를 사용해서 어떠한 Object 클래스에 대한 코드라도 작성할 수 있지만, 99% 의 경우 Actor 에서 파생된 클래스에 대한 코드를 쓰게 될 것입니다. 유용한 UnrealScript 기능성의 대부분은 게임과 관련된 것이며 액터들을 취급하는 것입니다.

클래스

각 스크립트는 정확히 하나의 클래스에 해당되며, 스크립트는 클래스, 클래스의 부모 그리고 그 클래스와 관계있는 모든 추가 정보를 선언하는 것으로 시작됩니다. 가장 간단한 클래스의 형태는 다음과 같습니다:

class MyClass extends MyParentClass;

여기서 저는 "MyParentClass" 의 기능성을 물려받는, "MyClass" 라는 이름의 새 클래스를 선언하고 있습니다. 또, 이 클래스는 "MyPackage" 라는 이름의 패키지 안에 들어 있습니다.

각 클래스는 그 부모 클래스의 변수, 함수 그리고 상태를 모두 물려 받습니다. 클래스는 그 다음에 새 변수의 선언 추가, 새 함수 추가 (또는 기존 함수 오버라이드) 그리고 새 상태를 추가 (또는 기존의 상태에 기능 추가) 할 수 있습니다.

UnrealScript 에서 클래스 디자인의 전형적인 접근방식은, 필요한 모든 기능성을 가지고 있는 기존의 클래스 (예: 괴물들의 베이스 클래스인 Pawn 클래스) 를 확장하는 새 클래스(예: Minotaur 괴물) 을 만드는 것입니다. 이 방식을 따르면 절대로 시간과 노력을 낭비할 필요가 없습니다 – 커스터마이즈 할 필요가 없는 기존의 기능을 모두 유지하면서 커스터마이즈 하고 싶은 새 기능을 간단히 추가할 수 있습니다. 이 접근방식은 Unreal 에서 AI를 구현하는데 특히 효과적입니다. 내장된 AI 시스템이 여러분 고유의 창조물에 대해 구성 요소로서 사용할 수 있는, 놀라운 양의 기본적인 기능성을 제공하기 때문입니다.

클래스 선언은 그 클래스에 영향을 미치는 다수의 선택적 지정자를 취할 수 있습니다:

Native(PackageName)
"이 클래스는 보이지 않는 곳에서 C++ 지원을 사용한다" 는 것을 나타냅니다. Unreal은 native 클래스들이 .EXE 에 C++ 구현을 포함할 것을 기대합니다. Native 클래스만이 native 함수를 선언하거나 native 인터페이스를 구현할 수 있습니다. Native 클래스들은 언제나 다른 native 클래스로부터 파생되어야 합니다. Native 클래스들은 스크립트의 변수들 및 지정한 함수들과 상호작용 하는데 필요한 glue 와 함께, 자동 생성 C++ 헤더 파일을 만들어냅니다. 기본으로, PackageName 은 해당 스크립트가 들어있는 패키지를 말합니다. 예를 들어 클래스가 Engine 패키지 내에 있다면, 결과물인 자동 생성 헤더의 이름은 EngineClasses.h 이 됩니다.
NativeReplication
이 클래스에 대한 변수 값의 복제가 C++ 구현으로 처리된다는 것을 나타냅니다. Native 클래스에서만 유효합니다.
DependsOn(ClassName[,ClassName,...])
ClassName이 이 클래스에 앞서 컴파일된다는 것을 나타냅니다. ClassName으로는 반드시 같은 패키지 (또는 이전의 패키지) 내의 클래스를 지정해야 합니다. 한 DependsOn 줄에서 콤마로 분리하거나, 각 클래스마다 별도의 DependsOn 줄을 사용하여 여러 개의 종속 클래스를 지정할 수 있습니다.
Abstract
클래스를 "abstract 기본 클래스" 로서 선언합니다. 이 클래스는 그 자체로는 아무런 의미가 없기 때문에, 사용자들이 UnrealEd 에서 이 클래스의 액터를 세계에 추가하거나, 게임을 하는 동안 이 클래스의 인스턴스를 만드는 일을 못하게 합니다. 예를 들어 기본 클래스 "Actor" 는 abstract 인 반면, 하위클래스 "Ladder" 는 abstract 이 아닙니다 — 여러분은 Ladder 를 세계에 배치할 수 있지만 Actor 를 세계에 배치할 수는 없습니다. 이 키워드는 본연의 자식 클래스에는 전파되지만 스크립트 자식 클래스에는 전파되지 않습니다.
Deprecated
이 클래스의 모든 객체들이 로드되지만 저장되지는 않게 합니다. 레벨 디자이너들이 에디터에서 맵을 로드할 때 폐기된 액터의 인스턴스가 배치되면 경고를 내보냅니다. 이 키워드는 자식 클래스들에 전파됩니다.
Transient
"이 클래스에 속하는 객체들은 절대로 디스크에 저장되면 안됨”을 말합니다. players 또는 windows 처럼 원래 지속적이지 않은 특정한 종류의 native 클래스와 함께일 때만 유용합니다. 이 키워드는 자식 클래스들에 전파됩니다; 자식 클래스들은 NotTransient 키워드를 사용하여 이 플래그를 오버라이드 할 수 있습니다.
NonTransient
기본 클래스로부터 물려받은 Transient 키워드를 무효로 합니다.
Config(IniName)
이 클래스가 .ini 에 데이터를 저장하는 것이 허용된다는 것을 가리킵니다. 클래스에 구성이 가능한
변수 ("config" 또는 "globalconfig" 와 함께 선언된)가 있으면 이 변수들이 지정한 구성 파일에 저장되도록
합니다. 이 플래그는 모든 자식 클래스에 전파되며, 무효화할 수 없습니다. 그렇지만 자식 클래스는 Config
키워드를 재선언하고 다른 IniName 을 지정함으로써 .ini 파일을 변경할 수 있습니다. 보통 IniName 은
데이터를 저장해 넣을 .ini 파일의 이름을 명기하지만, 여러가지 이름에는 다음과 같이 특별한 의미가
있습니다:
  • Config(Engine): 게임의 이름 뒤에 "Engine.ini" 가 이어지는 Engine 구성 파일을 사용합니다. 예를 들어 ExampleGame 의 엔진 구성 파일 이름은 ExampleEngine.ini가 됩니다.
  • Config(Editor): 게임의 이름 뒤에 "Editor.ini"가 이어지는 Editor 구성 파일을 사용합니다. 예를 들어 ExampleGame 의 에디터 구성 파일 이름은 ExampleEditor.ini 가 됩니다.
  • Config(Game): 게임의 이름 뒤에 "Game.ini" 가 이어지는 Game 구성 파일을 사용합니다. 예를 들어 ExampleGame 의 게임 구성 파일 이름은 ExampleGame.ini 가 됩니다.
  • Config(Input): 게임의 이름 뒤에 "Input.ini" 가 이어지는 Input 구성 파일을 사용합니다. 예를 들어 ExampleGame 의 입력 구성 파일 이름은 ExampleInput.ini 가 됩니다.
PerObjectConfig
이 클래스에 대한 구성 정보는 객체별로 저장되고, 각 객체는 [ObjectName ClassName] 의 포맷으로
객체의 이름을 따른 .ini 파일 내에 섹션을 가지고 있습니다. 이 키워드는 자식 클래스에 전파됩니다.
PerObjectLocalized
이 클래스의 현지화된 데이터는 각 객체마다 정의되며, 각 객체는 [ObjectName ClassName] 의
포맷으로 객체의 이름을 따른 현지화 파일 내에 섹션을 가지고 있습니다. 이 키워드는 자식 클래스에
전파됩니다.
EditInlineNew
에디터. 이 클래스의 객체들이 UnrealEd 속성 창으로부터 작성될 수 있음을 나타냅니다 (기존의 객체에
대한 참조만이 속성창을 통해 배정되는 것이 기본 행태입니다). 이 플래그는 모든 자식 클래스에
전파됩니다; 자식 클래스는 NotEditInlineNew 키워드를 사용하여 이 플래그를 오버라이드 할 수
있습니다.
NotEditInlineNew
에디터. 기본 클래스로부터 물려받은 EditInlineNew 키워드를 무효로 합니다. EditInlineNew 를 사용하는 부모 클래스가 없는 경우에는 효과가 없습니다.
Placeable
에디터. 이 클래스가 UnrealEd 에서 작성되어 레벨, UI 의 장면, 또는 키스멧 창에 배치될 수 있다는 것
나타냅니다 (클래스의 타입에 따라). 이 플래그는 모든 자식 클래스에 전파됩니다;
자식 클래스는 NotPlaceable 키워드를 사용하여 이 플래그를 오버라이드 할 수 있습니다.
NotPlaceable
에디터. 기본 클래스로부터 물려받은 Placeable 키워드를 무효로 합니다. 이 클래스가 UnrealEd 에서
레벨 등에 배치될 수 없음을 나타냅니다.
HideDropDown
에디터. 이 클래스가 UnrealEd 속성 창의 콤보 박스에 나타나지 못하도록 합니다.
HideCategories(Category[,Category,...])
에디터. 이 클래스의 객체들에 대해 UnrealEd 의 속성 창에서 숨겨져야 할 하나 또는 그 이상의
카테고리를 명시합니다.
카테고리가 없이 선언된 변수들을 숨기려면, 그 변수를 선언한 클래스의 이름을 사용합니다.
ShowCategories(Category[,Category,...])
에디터. 기본 클래스로부터 물려받은 HideCategories 키워드를 무효로 합니다.
AutoExpandCategories(Category[,Category,...])
에디터. 이 클래스의 객체들에 대해 UnrealEd 의 속성 창에서 자동으로 확장되어야 할 하나 또는
그 이상의 카테고리를 명시합니다.
카테고리가 없이 선언된 변수들을 자동 확장하려면, 그 변수를 선언한 클래스의 이름을 사용합니다.
Collapsecategories
에디터. 이 클래스의 속성들이 UnrealEd 의 속성 창에서 카테고리로 그룹지어져서는 안된다는 나타냅니다.
이 키워드는 자식 클래스에 전파됩니다; 자식 클래스는 DontCollapseCategories 키워드를 사용하여
이 플래그를 오버라이드 할 수 있습니다.
DontCollapseCategories
에디터. 기본 클래스로부터 물려받은 CollapseCatogories 키워드를 무효로 합니다.
Within ClassName
고급. 이 클래스의 객체들은 ClassName의 인스턴스 없이는 존재할 수 없다는 것을 나타냅니다.
이 클래스의 객체를 만들려면 반드시 ClassName의 인스턴스를 Outer 객체로서 지정해야 합니다.
이 키워드는 반드시 클래스 자체의 선언 뒤에 첫번째로 와야 합니다.
Inherits(ClassName[,ClassName,...])
고급. 복수의 상속에 대해 사용되며 추가의 기본 클래스를 지정합니다.Inherits 줄에서 콤마로
분리하거나, 각 기본 클래스마다 별도의 nherits 줄을 사용하여 복수의 기본 클래스를 지정할
수 있습니다. Native 클래스에 대해서만 유효합니다. UObject 에서 파생된 두 개의 클래스로부터의
복수 상속은 지원되지 않습니다.
Implements(ClassName[,ClassName,...])
고급. 이 클래스에서 구현할 하나 또는 그 이상의 인터페이스 클래스를 명시합니다.
Implements 줄에서 콤마로 분리하거나, 각 인터페이스 클래스마다 별도의 Implements 줄을 사용하여
복수의 인터페이스 클래스를 지정할 수 있습니다. Native 클래스만이 native 인터페이스를 구현할 수 있습니
다.
NoExport
고급. 이 클래스의 C++ 선언이 스크립트 컴파일러에 의해 자동생성된 C++ 헤더 파일에 포함되면 안된다는
것을 나타냅니다. C++ 클래스 선언은 반드시 별도의 헤더 파일에 수동으로 정의되어야 합니다. native
클래스에 대해서만 유효합니다.  

반응형
반응형

udk.exe 설정시 win32/UDK.exe 로 설정

DefaultEngine.ini

ModEditPackages=MyMod 를

ModEditPackages=MyGame 로 변경

.uc 페이지 유니코드 949 로 변경

프로젝트 만들때 솔루션용 디렉터리 만들기 체크 해제

http://blog.naver.com/kiru81?Redirect=Log&logNo=60106380729

nFringe 라는 프로그램을 다운받는디.

http://wiki.pixelminegames.com/index.php?title=Tools:nFringe#First_time_installation

nFringe 를 설치한 후, VC++ 2005 나 2008 을 실행하고 새 프로젝트를 만들게 되면, 프로젝트 형식에 UnrealScript 라는 항목을 볼 수 있다.

VC++ 2005 에서 할 경우에는 한 가지를 더 설치해주어야 한다. 바로 ProjectAggregator2 이다. 위의 링크된 위키사이트에서 다운받을 수 있다. VC++ 2008 로는 테스트해보지 않았지만, 아마 필요없는 것 같다.

프로그램 셋팅 및 코드 작성은 아래 동영상을 참고

http://dl.deathtouchstudios.com/videotutorials/UnrealScriptSeries/

1. UnrealEngine 3 License Project 템플릿으로 프로젝트 생성

2. 프로젝트 속성 > General 탭에 Game > Target Game 을 UnrealEngine 3 Mod 로 바꿈.

Script Compiler > UCC Path 를 Binaries\UDK.exe 로 설정

Script Compiler > Reference Source Path 를 Development\Src 로 설정

3. Build 탭에 Script Outputs > Manually set UCC output directory 를 체크하고 UDKGame\Script 를 경로로 잡아준다.

4. Debug 탭에 StartAction

프로젝트 셋팅 시 Debug 탭에서 Load map at startup 이라는 항목이 있는데, 여기에는 자신이 만들어 저장한 맵의 이름을 저장해야 한다.

아래는 test.udk 로 3인칭 시점의 카메라를 테스트 했던 맵을 지정하고, 실행한 결과이다.

근데 로그를 출력해보는 중에 warning 이 발생.. MyGame.MyGameInfo 를 찾지 못한다는 거였다..

\UDK\UDK-2010-04\UDKGame\Script 에 MyGame.u 파일이 생성되지 않는 것과 관계가 있는걸까?

반응형
반응형




[3DMP engines]

OGRE 오우거 _ITERATOR_DEBUG_LEVEL 에러


오우거 vc 2010 로 빌드시 ' _ITERATOR_DEBUG_LEVEL'에 대해 불일치가 검색되었습니다. ' 와 같은 릴리즈에서 에러날경우

C:/OGRE3D/ogre_src_v1-7-4/Dependencies 에 들어가 버전에 맞는 .sin 파일의 릴리즈 디버그를 빌드 한 후

CMake 에서

OGRE_DEPENDENCIES_DIR C:/OGRE3D/ogre_src_v1-7-4/Dependencies

를 추가 해주고

원래 있던 소스파일에다 덮어 configure, generate 한 후

ALL_BUILD에서 일괄빌드가 아닌

개별적으로 디버깅, 릴리즈모드로 각각 빌드 하면 된다










http://blog.naver.com/codeknight2/110094046557



오우거(OGRE3D) 1.7.1 소스 설치 (VS2005 버전)  OGRE3D 

2010/09/17 04:16

복사http://blog.naver.com/codeknight2/110094046557


현재의 내 컴퓨터 작업환경이 WindowsXP (서비스팩3), 비주얼스튜디오 2005 이므로, 이 환경을 기준으로 작성하였습니다. 혹 비주얼 스튜디오의 버전이나 윈도우를 업글하게 되면 해당 버전에 대해서도 새로 포스트 하도록 하겠습니다.

 

1. 설치전 준비사항

오우거를 설치하기 전에 먼저 컴퓨터에 DirectX SDK가 설치되어야 합니다.

 

DirectX SDK 최신버전인 June 2010 버전은 여기에서 다운 받을 수 있습니다.

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=3021d52b-514e-41d3-ad02-438a3ba730ba

 

그런데, 이 다운로드 페이지에 다음과 같은 내용이 있군요.

 

The June 2010 DirectX SDK includes support for Visual Studio 2010. The DirectX SDK will continue to support Visual Studio 2008 as well. However, Visual Studio 2005 will no longer be supported.

즉, June 2010 버전은 비주얼 스튜디오 2010을 지원하고 2008도 여전히 지원하지만, 비주얼 스튜디오 2005는 더이상 지원하지 않는다는 것입니다. 비주얼 스튜디오 2005를 사용하는 환경에서 DirectX June 2010을 링크하고 컴파일하려고 하면 에러가 발생할 것입니다. 깡패같은 놈들이 아닐 수 없습니다. 다이렉트 엑스 최신버전 사용하고 싶으면 새 컴파일러를 사라, 뭐 이런 소리이군요.

 

비주얼 스튜디오를 상위버전으로 새로 설치할 생각이 없고 계속해서 2005 버전을 사용할 계획이라면, 다음의 링크에서 제가 알고있는 DirectX의 2009년 마지막 릴리즈인 August 2009 버전을 받아서 설치하시면 되겠습니다.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=b66e14b8-8505-4b17-bf80-edb2df5abad4&displaylang=en

 

만일, 컴퓨터에 이미 다른 버전의 DirectX 9.0c SDK가 설치되어 있고 이걸 최근의 버전으로 패치할 생각이 없다면, DirectX SDK 설치는 그냥 건너뛰어도 상관없겠습니다.

 

다음으로, 비주얼 스튜디오 2005를 사용하고 계시는 경우, 비주얼 스튜디오 2005 서비스팩1을 설치해야 합니다.

그 이유는 오우거 엔진의 비주얼 스튜디오 2005 버전의 소스가 서비스팩1 버전을 기준으로 작성되어 있기 때문에 서비스팩 없이 컴파일을 시도하면 여러가지 에러를 만나게 되고, 서비스팩을 설치하지 않으면 해결이 불가능하기 때문이지요.

 

비주얼 스튜디오 2005 서비스팩1은 여기에서 다운로드 받을 수 있습니다.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc

 

만일 사용중인 운영체제가 Windows Vista, Windows Server 2008, Windows7 이라면 다음의 서비스팩을 설치하는 것이 좋습니다.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90E2942D-3AD1-4873-A2EE-4ACC0AACE5B6

 

비주얼 스튜디오 2005가 아닌 다른 컴파일러를 사용하고 있는 경우라면, 혹시 다른 요구사항이 있는지 확인하기 위해 오우거 홈페이지에 가서 인스톨 가이드를 읽어 보시길 바랍니다.

 

위에 제시한 다운로드 URL들은 2010년 9월 16일 현재 유효한 경로로써, 구버전 SDK나 서비스팩의 다운로드 경로를 마이크로소프트가 수시로 변경하기 때문에 향후 어느 시점에서 더이상 유효한 경로가 아닐 수도 있습니다. 이런 경우에는 마이크로소프트 다운로드 페이지에서 검색하여 새 경로를 찾거나, 운영체제 또는 컴파일러의 업그레이드를 추천합니다.

 

 

2. 오우거의 다운로드 및 설치

위의 과정을 모두 마쳤다면 이제 오우거 소스를 다운로드해야 겠지요.

 

오우거 1.7.1 버전의 자동압축 파일을 여기에서 다운로드할 수 있습니다.

http://www.ogre3d.org/download/source

 

다운로드 받은 파일을 실행하면 다음과 같이 압축을 해제할 경로를 묻습니다.

제 경우는 압축을 해제할 경로를 단순히 C드라이브로 지정했는데, 그 이유는 압축을 해제하면 지정된 경로에 ogre_src_v1-7-1 이라는 서브 폴더가 생성되고, 소스들이 그 폴더안에 존재하게 되기 때문입니다.

압축을 해제할 경로로 다른 폴더 이름을 지정해주게 되면 나중에 컴파일하고 나서 생성된 라이브러리들은 상당히 여러 단계 아래의 폴더에 존재하게되고, 나중에 응용프로그램(즉, 게임과 같이 오우거를 사용하는 프로그램)을 만들 때 비주얼 스튜디오에 오우거 라이브러리 경로를 지정해야 하는데, 이 경로 이름의 길이가 매우 길어질 것이기 때문입니다.

저는 개인적으로 긴 경로이름을 싫어하므로 이렇게 한 것인데, 머 임시 폴더를 지정해주고 압축을 해제한 후에 서브폴더들을 상위 경로로 옮기거나, 혹은 긴 경로를 그대로 사용하거나, 또는 오우거 컴파일을 완료한 후에 출력된 라이브러리들과 헤더들 만을 별도의 경로로 옮겨 사용해도 됩니다.

이건 각자의 취향에 따라 선택하면 되고 꼭 제가 한 그대로 하실 필요는 없습니다.

 

압축을 해제할 경로를 지정했다면, Extract를 클릭하여 압축 해제를 시작합니다.

 

압축 해제가 완료된 후에 지정했던 경로에 가보면 위에 보시는 것과 같이 ogre_src_v1-7-1 이라는 폴더가 새로 생성된 것이 보입니다. 그 폴더 안에는 오우거 엔진, 데모들, 도구들의 소스와 도큐먼트들이 들어 있습니다.

 

BuildingOgre.txt 라는 텍스트 파일이 보이는 군요. 사실 이 파일에 설치와 관련된 모든 내용이 설명되어 있습니다. 단지 (영국식)영어로 되어 있다는 것이 단점이지요.

 

위에 압축 해제 이미지를 보시면 제 컴퓨터에 이미 오우거 1.6.3 버전이 설치되어 있는 것이 보이실 것입니다. 제 경우와 같이 이전 버전의 오우거가 이미 설치되어 있다고 하더라도 아무 상관없이 1.7.1 버전을 새로 설치하실 수 있습니다. 다만, 폴더 이름만 다른 이름을 사용하시면 되는 것이지요.

 

이제, Boost 라이브러리를 설치해야 합니다.

Boost는 오우거를 컴파일하기 위해 반드시 필요한 것은 아닙니다. 그러나 오우거의 지형(Terrain) 라이브러리의 페이징 기술에서 리소스의 백그라운드 로딩에 Boost 라이브러리를 사용할 경우 좀 더 빠른 성능을 보여주기 때문에 설치하는 것이 좋겠죠.

물론, 이 라이브러리가 없어도 동작합니다.

 

다음의 경로에서 Boost 라이브러리 인스톨러를 다운로드 할 수 있습니다.

이 포스트를 쓰는 현재 최신버전은 1.44이지만, 오우거 1.7.1은 1.42버전을 사용하여 작성되었으므로, 1.42 버전을 다운 받도록 합니다. (1.44 버전은 오우거를 컴파일할 때 에러가 발생합니다)

http://www.boostpro.com/download/

 

다운받은 인스톨러를 실행하면 위와 같이 Boost라이브러리를 어디에서 다운 받을 것인가를 묻습니다. 적당한 다운로드 서버를 지정해주고 Next를 클릭합니다.

 

Boost 라이브러리는 몇 가지 형태로 미리 컴파일된 라이브러리인데 설치하길 원하는 형식을 선택하라는 창이 뜹니다.

좌측 컴파일러 항목에서는 오우거 컴파일에 사용할 컴파일러의 버전을 선택해 줍니다.

우측 라이브러리 형식에서는 원하는 형식의 라이브러리를 선택합니다. 제 경우에는 최소 설치를 위해 멀티스레드 DLL만을 선택해 주었습니다.

 

다음으로 설치할 라이브러리 항목들을 선택하는 창이 뜹니다.

오우거의 지형엔진이 사용하는 라이브러리는 Boost DateTime과 Boost Thread 입니다. 이 두 항목은 반드시 체크해 주어야 합니다.

선택한 항목의 서브 항목에서 필요하지 않은 버전의 컴파일러는 체크를 해제해 줍니다.

 

선택을 완료하고 Next를 클릭하면 다운로드 및 설치가 시작됩니다.

 

Boost는 상당히 쓸만한 라이브러리이므로, 꼭 오우거가 아니라도 다른 프로그램을 만드는 작업에서 이 라이브러리를 사용할 수도 있으므로 죄다 설치해 주는 것이 좋지만 많은 항목을 선택할 수록 다운로드 시간이 더 오래 걸린다는 것도 염두에 두시기 바랍니다.

 

저는 중국에 거주하고 있는데 인터넷 속도가 엉망이라 다운 받는데 돌아버릴거 같군요.

 

Boost의 인스톨이 완료되었다면 나중에 cmake가 Boost를 제대로 찾을 수 있도록 환경변수를 등록해 주어야 합니다.

[내 컴퓨터 -> 속성 -> 고급 -> 환경 변수 -> 시스템 변수 -> 새로 만들기] 를 선택해서 다음과 같이 BOOST_ROOT 시스템 환경 변수를 추가해 줍니다.

 

변수 값에는 여러분이 설치한 경로를 입력해 주어야 합니다. 인스톨 과정에서 특별히 설치경로를 변경하지 않았다면 위의 이미지와 같은 경로일 것입니다.

 

같은 방법으로 아래 두 개의 변수를 더 등록해 줍니다.

 

BOOST_INCLUDEDIR -> C:\Program Files\boost\boost_1_42

BOOST_LIBRARYDIR -> C:\Program Files\boost\boost_1_42\lib

 

이제 의존성 패키지를 설치해야 합니다.

앞서 오우거의 소스코드를 다운로드 했던 페이지(http://www.ogre3d.org/download/source)에서 Microsoft Visual C++ Dependencies Package를 다운로드 합니다.

OgreDependencies_MSVC_20100501.zip이라는 파일을 다운로드하게 될 것입니다.

이 파일을 앞서 오우거 소스를 압축 해제해서 생성된 폴더 안에 압축을 해제합니다. 이 파일의 압축을 해제하면 Dependencies라는 폴더가 생성되는데, 이 폴더는 오우거 소스 폴더의 OgreMain 폴더와 같은 위치에 존재해야 합니다.

즉, 저의 경우에는 C:\ogre_src_v1-7-1 라는 폴더에 압축을 해제하게 되는 거죠.

 

압축을 해제하고 난 후 오우거 소스 폴더의 모습입니다. 보시는 바와 같이 C:\ogre_src_v1-7-1 폴더 안에 Dependencies라는 폴더가 새로이 생성된 것을 알 수 있습니다.

 

Dependencies 폴더 안에 src라는 폴더가 있을 것인데 그 폴더 안에 들어가 보면 지원되는 비주얼 스튜디오 각 버전에 따른 솔루션 파일 (*.sln)이 있을 것입니다.

자신이 사용하는 버전에 맞는 이름을 가진 솔루션 파일을 비주얼 스튜디오를 사용해서 엽니다.

 

이 솔루션에는 14개의 프로젝트가 포함되어 있을 것입니다. 이 솔루션을 디버그 모드와 릴리즈 모드에서 각각 컴파일합니다.

디버그 모드와 릴리즈 모드를 따로 한번씩 컴파일하는 것 보다는 일괄 빌드 기능을 사용하는 것이 편리합니다.

 

비주얼 스튜디오에서 [빌드 -> 일괄 빌드]를 선택합니다.

 

일괄 빌드 대화상자에서 솔루션에 포함된 모든 프로젝트에 대해서 Win32 디버그와 Win32 릴리즈를 선택해주고 빌드를 클릭합니다.

컴파일이 시작되고, 약간의 시간이 소요될 것입니다.

 

컴파일이 완료되고 난 후에 위와 같이 실패가 없으면 성공입니다.

 

이제 cmake를 이용하여 소스로부터 오우거 프로젝트들을 생성해야 합니다.

cmake는 크로스 플랫폼 빌드 시스템인데, 정확히 말하면 빌드 환경 설정 프로그램이라고 할 수 있습니다. 소스 코드들과 개발 도구 등의 시스템 환경들에 맞춰 가장 적합한 빌드 환경을 만들어 주는 프로그램이라고 할 수 있습니다.

마치 리눅스에서 make 명령을 실행하기 전에 configure를 사용하여 컴파일 환경을 수집하는 것과 같은 역할을 한다고 보면 되겠습니다.

 

우리는 윈도우즈 환경에서 작업하고 있으므로, cmake-gui (윈도우즈 환경에 맞춰진 GUI를 지원하는 버전)를 사용하면 됩니다.

cmake-gui는 여기에서 다운로드 할 수 있습니다.

http://www.cmake.org

특별히 cmake의 소스를 살펴보고 싶은게 아니라면 RESOURCES->Download 에서 Binary distributions -> Windows (Win32 Installer)라고 되어 있는 인스톨러를 다운로드 하도록 합니다.

cmake는 최신버전을 다운로드 하도록 합니다.

 

다운로드가 완료되면 인스톨러를 실행하여 원하는 위치에 설치하고, 설치가 완료되면 cmake-gui를 실행합니다.

 

실행하면 위와 같은 창이 열리는데, Where is the source code: 항목에 우리가 앞서 오우거 소스를 압축해제한 폴더 (즉, OgreMain 폴더가 존재하는 폴더)를 지정해주고, Where to build binaries: 항목에 cmake가 빌드 시스템을 출력하기를 원하는 경로를 지정해 줍니다.

 

cmake가 만드는 결과물은 컴파일이 완료된 오우거 엔진이 아니라, 비주얼 스튜디오로 컴파일할 수 있는 오우거 엔진의 소스 프로젝트라는 것을 기억하시기 바랍니다. cmake로 빌드 환경을 만들고 나서 최종적으로 비주얼 스튜디오를 이용해서 다시 한번 빌드해주어야 비로서 오우거 엔진이 만들어진다는 것이지요.

제 경우는 앞서 오우거 소스를 압축해제한 폴더 안에 VS2005_Build라는 새 폴더를 만들어서 지정해 주었습니다.

 

경로 설정이 완료되었으면, 아래쪽에 있는 Configure 버튼을 클릭합니다.

 

사용하려는 컴파일러 버전을 묻는 대화상자가 나타나는데, 위의 콤보 박스에서 자신이 사용하는 버전의 컴파일러를 선택해 준 후에 Finish를 클릭합니다.

 

그러면 cmake는 시스템 정보와 소스의 정보를 수집하기 시작할 것입니다.

 

정보 수집이 완료되면 아래쪽 안내 창에 Configuring done 이라는 메시지가 나타나면서 프로젝트의 설정 옵션들이 보여집니다.

이 설정들은 대부분 디폴트 상태로 그대로 사용해도 상관이 없습니다. 각 설정 옵션들의 의미를 알고 싶다면 오우거 홈페이지 wiki에서 인스톨 관련 문서를 참조하시기 바랍니다.

 

제 경우에는 디폴트 설정에서 맨 아래에 OGRE_INSTALL_DOCS, OGRE_INSTALL_PDB, OGRE_INSTALL_SAMPLES를 추가로 체크해 주었습니다.

 

설정이 완료되었다면 Configure 버튼을 한번 더 클릭하여 설정을 저장합니다. 저장이 완료되고 나면 옆에 있는 Generate 버튼이 활성화 될 것인데, 이를 클릭합니다.

 

이제 cmake는 우리를 위해서 비주얼 스튜디오 2005로 컴파일할 수 있는 오우거 엔진의 프로젝트들과 솔루션을 만들어 줄 것입니다.

아무런 오류없이 Generating done 이라는 메시지가 나오면 완료된 것입니다.

 

cmake가 빌드 환경 만들기를 완료하고 난 후, 우리가 cmake에게 지정해 주었던 출력 폴더로 가보면 빌드에 필요한 모든 소스들과 솔루션 파일이 생성된 것을 볼 수 있을 것입니다.

 

이 폴더 안에 OGRE.sln 솔루션 파일이 있을 것인데, 이것을 비주얼 스튜디오로 엽니다.

 

솔루션을 열면, 51개의 프로젝트가 포함되어 있을 것인데, 이 중에 ALL_BUILD라는 프로젝트가 보일 것입니다. 이것은 cmake가 우리를 위해 만들어준 프로젝트로, 이 프로젝트만 빌드하면 솔루션의 모든 프로젝트를 빌드해주게 됩니다.

 

이 역시 디버그 모드, 릴리즈 모드로 각각 컴파일 해야 하므로, 일괄 빌드 기능을 이용하도록 합니다.

 

[빌드 -> 일괄 빌드]를 선택하고, 일괄 빌드 대화상자에서 ALL_BUILD 프로젝트에 대해서만 Debug|Win32, Release|Win32 항목을 체크해주고 빌드를 클릭하여 빌드를 시작합니다.

 

이 작업은 시간이 꽤 걸릴 것입니다. 커피한잔 마시면서 담배나 한대 피우며 빌드가 완료되기를 기다립시다.

 

아마도 문제없이 컴파일이 완료되었을 것입니다. 혹시 실패가 하나라도 발생한 다면 빌드 과정을 다시 한번 수행해 줍니다.

 

컴파일이 완료되고 나면 솔루션이 있는 경로에 lib 라는 폴더가 새로이 생성된 것이 보일 것입니다. 이 폴더에는 오우거 엔진의 lib 파일들(여러분이 오우거를 사용하는 응용프로그램을 만들때 링크해주어야 하는 파일들)이 추가되었을 것이며, bin 폴더에는 오우거 엔진의 각종 dll 들이 추가되었을 것입니다.

 

이제, 오우거 엔진이 제대로 컴파일 되었는지 확인 해 봅시다.

솔루션에 포함된 프로젝트들 중에서 SampleBrowser 프로젝트를 시작 프로젝트로 설정합니다.

 

솔루션 탐색기에서 SampleBrowser 프로젝트를 우클릭하고 시작 프로젝트로 설정을 클릭하여 시작 프로젝트로 지정해준 뒤, [디버그 -> 디버그 시작] 또는 툴바의 플레이 버튼을 클릭하여 실행시킵니다.

 

오우거의 설정 대화상자가 나타날 것입니다. Rendering Subsystem: 은 Direct3D9 Rendering Subsystem으로 지정해주고 Full Screen: 을 No로 설정한 뒤 OK를 클릭합니다.

 

오, 마이 갇 !

오우거 1.7.1 엔진의 중대한 버그가 발견되는 순간입니다!

 

오우거가 설정 내용을 저장하기를 시도하려고 할 때 위와 같은 예외가 발생하는 경우가 있습니다.

 

이 예외의 내용으로 검색을 해보니, 다양한 운영체제에서 동일한 예외를 만나는 사람들이 꽤 있는 것 같습니다.

포럼에서 사람들이 하는 이야기로는, 오우거 응용프로그램을 처음 시작할 때 나타난 설정 대화상자에서 선택한 (우리가 조금 전 설정 대화상자에서 선택한 옵션들) 내용을 오우거는 사용자의 홈 디렉토리, 즉, 제 경우에는 "C:\Documents and Settings\리치왕\My Documents\Ogre\Cthugha\ogre.cfg" 이런 경로에 저장하려고 시도하는데, 이 경로에 영문이 아닌 문자가 들어갈 때에 문제가 발생한다고 합니다.

 

그러나, 제가 디버깅해 본 바에 의하면 위의 경로가 정확하게 Root 객체에게 전달되는 것을 확인했습니다. 더우기, 회사에 있는 제 컴퓨터에서는 실행에 아무런 문제가 없었습니다. 또 집에서 사용중인 이 컴퓨터는 1.6.3 버전을 사용할 때에는 아무런 문제가 없었습니다!

 

오우거의 Root 객체가 설정 파일의 경로를 어떻게 결정하는지 디버깅을 해보니, SampleBrowser의 createRoot라는 함수에서 Root 객체의 인스턴스를 생성하면서 생성자에게 경로명을 넘겨주고 있었습니다.

 

위의 코드는 SampleBrowser의 SampleContext.h 파일의 474번째 라인입니다. 위의 이미지에서는 주석처리된 부분이 원래 코드이고, 바로 아래는 제가 테스트를 위해 경로명을 변경하여 하드코딩으로 대체한 코드입니다.

 

일단 이렇게 처리한 후에 SampleBrowser를 다시 컴파일하고 실행하니 정상적으로 실행이 되는 군요.

 

SampleBrowser가 실행된 모습입니다.

 

일단 오우거 엔진의 컴파일은 문제없이 정상적으로 이루어졌다는 것을 확인 할 수 있습니다.

위의 예외 문제의 정확한 원인을 진단하기 위해서는 좀 더 디버깅을 해 봐야 할 것 같습니다.

 

이제, 다 되었습니다. 오우거 설치를 마무리 지을 시간입니다.

다시 비주얼 스튜디오의 솔루션 탐색기를 보면 INSTALL 이라는 이름의 프로젝트가 보일 것입니다. 이 프로젝트를 빌드해주면 우리가 cmake에서 인스톨하기로 선택한 모든 항목들이 sdk라는 새 폴더가 생성되면서 이 폴더로 인스톨이 진행됩니다.

 

일괄 빌드 대화상자를 열고, INSTALL 프로젝트에 대해서만 Debug|Win32, Release|Win32 항목을 체크해주고 빌드합니다.

 

INSTALL 프로젝트를 모두 빌드하고 나면, 솔루션 폴더 아래에 sdk라는 폴더가 새로이 생성된 것이 보일 것입니다. 이 폴더 안의 bin 폴더에는 실제의 오우거 엔진 파일들 즉, DLL 파일들과 CFG 파일들이 인스톨되어 있고, lib 폴더에는 우리가 앞으로 만들게 될 프로그램이 링크할 수 있는 lib 파일들이, 그리고 include 폴더에는 프로그램이 포함할 수 있는 헤더 파일들이 인스톨되어 있습니다.

 

즉, 우리가 오우거를 이용하여 프로그램을 작성할 때, 프로젝트에 추가 포함 디렉터리로 이 include 폴더를, 추가 라이브러리 디렉터리로 이 lib 폴더를 지정해 주어야 한다는 것이지요.

 

media 폴더에는 데모 프로그램들이 사용하는 각종 리소스들(메시 파일들, 텍스처 파일들 등)이 들어 있습니다.

Docs 폴더에는 오우거 매뉴얼과 API 레퍼런스와 같은 문서가 들어 있습니다. 오우거를 공부하면서 참조하면 좋을 것입니다.

 

이 sdk 폴더는 현재 이 경로 그대로 두고 사용해도 되고, sdk 폴더를 따로 다른 경로로 이동시키고 폴더 이름을 자신이 알기 쉽도록 변경해서 사용해도 됩니다. 각자의 취향에 따라 선택하시면 될 것이나, 중요한 것은 여러분이 응용 프로그램 프로젝트를 만들 때 인클루드 디렉토리와 라이브러리 디렉토리의 경로를 지정해 주어야 그 프로젝트가 제대로 컴파일 될 것이란 점이지요.

 

자, 이제 오우거 1.7.1의 설치가 완료되었습니다. 수고하셨습니다 ^^








반응형
반응형
http://vimeo.com/8815075#t=0


This is an early draft of the new Character sample for the OGRE SDK. It features Sinbad the OGRE with third-person game-style controls. It's not done yet, and there are still a few things to add. The ribbon trails are kinda glitchy, but they are just there for fun right now. Probably won't keep them. :)

반응형
반응형

http://www.ogre3d.org/tikiwiki/Ogre+Android&structure=Development#Porting_Ogre_to_Android

Android and C++

Android officially supports native applications built using C or C++. Unfortunately the C++ for Android is currently too sparse for Ogre to be ported using the official development kit(called the NDK(external link)). The most serious feature missing the exception support. Since Ogre makes heavy use of exception, this missing feature would make it very difficult to create a stable port for Android.

Luckily Android is a very open OS. We don't actually need to use the official NDK to develop native applications that work on Android devices. An awesome community member namedCrystax(external link) has created versions of the NDK matched to official NDK releases which fully support C++. By using this custom build system we can create working native applications for Android without having to modify the underlying Android OS.

허허 NDK 가 너무 열악하게 안드로이드를 지원한다는 글을 보고 오우거에서 안드로이드는 개발하기 힘든것인가 라는 생각을 하면서 웹을 뒤져보다가 이 포럼을 봤는데 허허 안드로이드측의 답변일세 ㅋ

대략 해석해놓자면..

핵심 내용은 다행히 안드로이드는 오픈OS 이다. 오우거제작팀(?)은 사실상 안드로이드디바이스에서 돌아가는 native 응용프로그램을 개발하기 위한 공식적인 NDK 사용을 필요로하지 않는다.

Crystax 이라 불리는 멋진 공통구성원이 C++을 완전히 지원하는 공식적인 NDK 에 매칭되는 버전을 만들었다.

이 custom build system 으로 오우거제작팀(?)은 기초가되는 안드로이드 OS를 수정없이 native application 을 만들었다.


아래 주소는 돌아다니다가 우연히 오우거를 안드로이드에 올려놓은 경험담을 적어놓은 곳

http://blog.zcube.kr/

반응형
반응형

어딘가에서 오우거 조사한 pdf 파일

3DMath 2011-05-03 21:53:44 주소복사
조회 23 스크랩 0

그냥 발표용인듯.. 

반응형
반응형

반응형
반응형

Crazy Eddie’s GUI System is a free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!




http://www.cegui.org.uk/wiki/index.php/Main_Page


동적인 상자들을 연결해 놓아 유연하게 연결 표시 해주는 라이브러리 인듯..



Main Page

From CEGUI Wiki - Crazy Eddie's Gui System for Games (Open Source)

Jump to: navigation, search

Welcome to Crazy Eddie's GUI System

Crazy Eddie's GUI System is a free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!

  • Take a look at our binary demos (precompiled for win32 only)
  • Do you like CEGUI? Help us become even better and read our wiki wishlist!

To edit this wiki or to contribute to this site, you must be a registered on our forums
When signing up you are required to fill in an authorisation code, the code is presently: iwillnotspam

Featured Videos from our YouTube Channel

Downloading and Installing

Working with CEGUI

  • Documentation: Information about getting documentation to match with your download
  • Tutorials: All tutorials to help you getting started with CEGUI
  • How-To series: How to deal with a specific feature of CEGUI
  • Manuals: Some more advanced material on using CEGUI

CEGUI for Content Creators

Community Projects

The last 5 additions to the wiki

The last 5 changes to the wiki

Personal tools
Namespaces
Variants
Actions

반응형
반응형
MyGUI is a library for creating Graphical User Interfaces (GUIs) for games and 3D applications. The main goals of mygui are: speed, flexibility and ease of use.

[License: open source]




http://mygui.info/






MyGUI v3.2.0 Released!

February 24th, 2012

Main changes in 3.2.0:

  • Improved font display:
    • Decreased texture memory usage (typically by 50% or more).
    • Added support for Windows FON/FNT bitmap fonts and for embedded SBIT bitmaps in TrueType fonts.
    • Added support for overlapping glyphs.
    • Simple text shadows added (optional).
    • Full FontViewer support to load and create new fonts.
  • Added a new SkinEditor tool.
  • Improved the LayoutEditor and FontEditor tools.
  • Made lots of other improvements and fixes.

More detailed changelog.

MyGUI v3.0.1 Released!

February 13th, 2010

This release contain few fixed bugs, changed license and improved CMake scripts. No API changes was made and this release is highly recommended for those who previously downloaded MyGUI 3.0.0. Changelog.

We also decided to add small exclusion in LGPL for static linking (details).

MyGUI 3.0.0 Released!

January 10th, 2010

Main changes:

  • rendering separated from core, we also implemented pure DirectX and OpenGL renderers in addition to OGRE render.
  • heavily reworked resources system.

For a detailed list see changelog.

MyGUI 2.2.3 Released!

October 4th, 2009

This is bugfix release aimed for those who use 2.2.2 and not using MyGUI from trunk. Strongly recommended for update.

You can download source package here: MyGUI 2.2.3.

SubWidgets

  • subwidget EditText was reimplemented
  • word wrap support in edit mode
  • cursor and text selecting with ManualFont

Widget

  • fixed problem with inherited Disabled and Visible conditions

We have made lots of changes in upcoming MyGUI 3.0 and we working on it very active, but still not ready to release it, so we decided to update current release.

IRC channel

June 7th, 2009

IRC channel was created!
Server: irc.quakenet.org
Channel: #mygui
Welcome!

MyGUI 2.2.2 released!

March 27th, 2009

After long time of active development we finally stopped adding lots of new features, improved everything else and made new stable release, MyGUI 2.2.2. It has lots of changes and improvements since the previous 2.2.0_RC1 version.

You can download source package here: MyGUI 2.2.2.

Here’s list of major changes: Read the rest of this entry »

MyGUI for C#

March 25th, 2009

We have implemented generator wrappers for the library. Generator parsed data from doxygen, and with the help of templates, performs the generation of wrappers. At the moment there are templates for C# and Managed C++. It is also possible to setup generator for other languages if the need arises.

1. C# – MyGUI.Export.dll (exported functions) + MyGUI.Sharp.dll (wrapper using P/Invoke)
2. Managed C++ – MyGUI.Managed.dll (wrapper using CLR)

At this time, a wrapper does not support Mogre due to specifics of the latter, but we are working in this direction, and version that supports Mogre will be presented .
Generator, wrappers and a demo is now available in MyGUI svn: http://my-gui.svn.sourceforge.net/svnroot/my-gui

Blog started!

March 17th, 2009

What’s actually pretty. Here we’ll place announces and some docs about MyGUI architecture.

Now site works a little bit slow, but I think we’ll solve this problem. Fix CSS/JavaScript bugs. Fix content :) .



2007 – Current year 

반응형
반응형

http://begin.pe.kr/category/Ogre3D%20%EC%82%BD%EC%A7%88%EB%9E%80/Basic%20Tutorial%201

'Ogre3D 삽질란/Basic Tutorial 1'에 해당되는 글 3건

  1. 2008/11/08 기초 튜토리얼 1-1
  2. 2008/11/08 기초 튜토리얼 1-2
  3. 2008/11/08 기초 튜토리얼 1-3 (마지막) (5)

기초 튜토리얼 1-1

Ogre3D 삽질란/Basic Tutorial 1 2008/11/08 16:58

기초 튜토리얼 1 (번역 : n_Sys)

입문자 튜토리얼 1: SceneNode, Entity, SceneManager 구성

튜토리얼을 진행하다가 문제점이 생기면 Help 포럼(http://www.ogre3d.org/phpBB2/viewforum.php?f=2) 문의하세요.

목차

* 1 미리 알아야 것들

* 2 소개

* 3 시작하기

* 3.1 최초 코드

* 3.2 문제점 해결하기

* 3.2.1 Message Box 문제

* 3.2.2 환결성정 파일이나 DLL 파일이 없는 문제

* 3.2.3 리소스나 플러그인 문제점들

* 3.2.4 비주얼 스튜디오에서 프로그램이 동작하지 않는문제

* 4 오우거 엔진 동작과정

* 4.1 장면관리자(SceneManager) 기초

* 4.2 엔티티(Entity) 기초

* 4.3 장면노드(SceneNode) 기초

* 5 오우거 응용프로그램 실행하기

* 6 좌표와 벡터

* 7 추가적인 객체 삽입하기

* 8 엔티티에 대해서..

* 9 장면노드에 대해서..

* 10 해볼만 것들

* 10.1 확대(Scale)

* 10.2 회전(Rotations)

* 11 오우거 실행환경

* 11.1 DLLs and Plugins

* 11.2 환경설정 파일

* 11.3 어플리케이션 테스트를 위한 나은 환경 구성하기

* 12 맺음말

미리 알아야 것들

튜토리얼은 C++ 프로그래밍을 할줄 알고 오우거 어플리케이션을 셋업하고 실행할 안다는 가정하에 진행됩니다. (만약 오우거 어플리케이션 설정에 문제점이 있으면 컴파일러별 프로그램 설정 가이드를 참고하세요. - 역자주 : 프로그램 설정 가이드는 번역을 생략합니다) 튜토리얼은 설정가이드에서 설정이외의 사전 지식은 필요 없습니다..

소개

이번 튜토리얼에서는 오우거엔진에서 가장 기초적인 구성물을 소개합니다. (장면관리자-SceneManager, 장면노드-SceneNode, 엔티티-Entity 객체) 앞으로 코드의 많은부분을 다루지는 않을것이지만 독자가 오우거 엔진을 시작하는데 필요한 일반적인 컨셉들에 촛점을 맞출 입니다.

튜토리얼을 진행하면서 독자는 진행단계에 맞추어서 천천히 코드를 스스로 입력하고 결과물을 지켜 필요성이 있습니다. 오우거엔진의 개념을 따라잡는대에는 이것만한 방법이 없습니다! 대충 눈으로 훑고 넘어가지 마세요.

시작하기

최초 코드

튜토리얼에서는 미리 작성된 기본코드를 사용할 것입니다. 나중에 내용을 채우게 createScene 함수를 제외하고는 모두 무시하셔도 됩니다. 나중에 오우거 어플리케이션이 어떻게 동작되는지를 자세하게 살펴볼 예정이지만 지금은 이제 시작한 단계에 불과합니다. 독자가 사용하는 컴파일러에서 프로젝트를 생성하고 아래 코드를 포함한 소스파일을 추가하세요.

#include "ExampleApplication.h"

class TutorialApplication : public ExampleApplication

{

protected:

public:

TutorialApplication()

{

}

~TutorialApplication()

{

}

protected:

void createScene(void)

{

}

};

#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32

#define WIN32_LEAN_AND_MEAN

#include "windows.h"

INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT )

#else

int main(int argc, char **argv)

#endif

{

// Create application object

TutorialApplication app;

try {

app.go();

} catch( Exception& e ) {

#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32

MessageBox( NULL, e.what(), "An exception has occurred!", MB_OK | MB_ICONERROR | MB_TASKMODAL);

#else

fprintf(stderr, "An exception has occurred: %s\n",

e.what());

#endif

}

return 0;

}


만약 오우거SDK Windows 에서 사용한다면 "[OgreSDK_DIRECTORY]\samples\include" 디렉토리(ExampleApplication.h 파일이 있는곳) include 가능하도록 프로젝트에 추가해 주세요. 만약 오우거엔진 소스를 직접 사용하신다면 [OgreSource_DIRECTORY]\Samples\Common\include" 추가해 주세요. 비록 코드가 까만 화면에 프레임수를 보여주는 썰렁한 화면만 보여주는 프로그램이지만 일단은 컴파일 실행이 되도록 해두세요. 다음 과정에서 화면에 뭔가를 추가할 입니다.

프로그램이 동작되면 WASD 키로 움직이고 마우스로 주변을 둘러보는 기능을 합니다. ESC 키는 종료키 입니다.

문제점 해결하기

만약 진행하는데 문제점이 발생하면 'Setting Up An Application'(http://www.ogre3d.org/wiki/index.php/SettingUpAnApplication) 에서 컴파일러 속성을 체크해 보거나 Ogre.log 파일에서 자세한 에러정보를 참조하세요. 만약 도움이 필요하다면 포럼을 검색 (http://www.ogre3d.org/phpBB2/search.php) 주세요. 아마 다른 많은 사람들도 똑같은 문제점을 겪었을 겁니다. 만약 새로운 이슈라면 포럼규칙 (http://www.ogre3d.org/phpBB2/viewtopic.php?t=11886) 읽어보시고 질문(http://www.ogre3d.org/phpBB2/viewforum.php?f=2) 하세요. Ogre.log 파일에서 에러와 관련된 항목이나 예외사항, 에러메세지, 컴파일러 디버거에서 제공하는 정보들을 제공하시는 것이 다른 유저들로부터 답변을 받는데 도움이 것입니다.

나중에 있을 튜토리얼에서는 문제점 해결방법을 포함하지 않을 입니다. 그러니 문제점이 발생되면 여기 이어지는 섹션을 주의깊게 살펴보세요.

Message Box 문제

유니코드를 지원하는 비주얼스튜디오를 사용한다면 다음 에러가 생길 있습니다 :

error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'

Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

문제는 MessageBox 함수가 유니코드(Unicode) 받아야 시점에 안시(ANSI) 코드를 받아서 일어난 에러입니다. 이걸 고치기 위해서는 다음라인을 고쳐 주세요 :

MessageBox( NULL, e.what(), "An exception has occured!", MB_OK | MB_ICONERROR | MB_TASKMODAL);

라인을 다음 라인처럼 수정합니다:

MessageBoxA( NULL, e.what(), "An exception has occured!", MB_OK | MB_ICONERROR | MB_TASKMODAL);

또는 컴파일러에서 유니코드지원 기능을 끄는 방법도 있습니다. 그러나 그렇게 하면 유니코드지원 기능 자체를 사용하지 못하게 됩니다.

에러가 발생하는 이유는 "MessageBox" 함수가 자동적으로 MessageBoxA (ANSI) 또는 MessageBoxW (Wide/Unicode) 프로젝트 설정에 기준하여 선택하기 때문입니다. 코드에서는 ANSI버젼을 강제적으로 사용하게끔 하게 하여 에러를 고칩니다.

환결성정 파일이나 DLL 파일이 없는 문제

새롭게 작성한 프로그램을 빌드하려는데 DLL 파일이 없다거나 환경설정파일(*.cfg) 없다고 빌드가 안된다면 아마 OgreSDK 폴더로부터 복사하지 않았기 때문일 겁니다. 비주얼스튜디오 에서 릴리즈 모드로 빌드할때 릴리즈 실행파일은 [ProjectFolder]\bin\release 생성하고 디버그 실행파일은 [ProjectFolder]\bin\debug 폴더에 생성됩니다. OgreSDK 폴더의 "*.dll" 파일과 "*.cfg" 파일을 해당 폴더로 복사해 주어야 합니다. 다시 말하면 [OgreSDK]\bin\release 폴더로부터 [ProjectFolder]\bin\release 폴더로 복사하고 [OgreSDK]\bin\debug 로부터 [ProjectFolder]\bin\debug 복사해야 한다는 입니다. 그리고 resources.cfg 파일이 옳바른 경로를 가르키도록 수정해줄 필요도 있습니다. 다음 섹션에서 부분에 대해서 자세하게 다룰 입니다.

리소스나 플러그인 문제점들

Plugin.cfg 파일과 Resources.cfg 파일을 실행파일과 같은 폴더에 두세요. Plugin.cfg 파일은 오우거엔진에게 어떤 렌더링 라이브러리가 사용 가능한지(Direct3D9, OpenGL, 기타등등..) 알려줍니다. Resources.cfg 파일은 ExampleApplication 클래스나 텍스쳐, 메쉬, 그리고 스크립트가 어디에 위치하고 있는지에 대한 상세한 경로를 기술합니다. 둘다 텍스트 파일기때문에 어렵지 않게 내부에서 가르키는 경로를 옳바른 경로로 수정할 있습니다. 경로가 잘못된다면 오우거엔진 설정 대화상자로 아무런 렌더링 라이브러리를 선택할 없게 되거나 화면상으로 에러메세지를 출력하거나 Ogre.log 파일에 다음과 비슷한 에러메세지를 보게 겁니다.:

Description: ../../Media/packs/OgreCore.zip - error whilst opening archive: Unable to read zip file

경우에는 Resources.cfg 파일을 열고 폴더 위치를 오우거엔진에 포함된 미디어 폴더가 위치한 포인트로 경로를 바꿔주세요. 알아 두셔야 할것은 $(변수) 같은 환경경로변수 파일 내부에서 사용할 없습니다.

비주얼 스튜디오에서 프로그램이 실행되지 않는문제

만약 비주얼스튜디오 또는 비주얼 C++ 에서 어플리케이션을 생성하고 실행하는데 환경설정문제가 있다면 다수의 경우 디버거 설정문제 입니다. 만약 플레이버튼(메뉴에서 Start Debugging 누르는것과 동일) 누르고 환경설정 파일(*.cfg) 찾을 없다는 예외처리 메세지를 보게 된다면 작업 디렉토리 (Working Directory) 제대로 설정되지 않았다는 입니다.

이러한 문제점을 해결하기위한 정확한 해결방법은 비주얼 C++ 버젼에 따라서 다양하기때문에 제가 정확한 해결방법을 제시할 없지만 기본적인 해결 방법은 동일합니다. 프로젝트의 Solution explorer 에서 (Solution 자체가 아닙니다) 오른쪽 클릭을 하고 properties 메뉴로 갑니다. 어딘가에 디버깅 옵션을 위한 속성이 있을겁니다. 디버깅 옵션에는 "Working Directory" 입력창이 있을겁니다. 입력창에 해당 프로젝트의 실행파일이 생성 되는 위치로 바꿔주세요.

만약 여기다가 입력해야 할지 모르겠으면 "Command" 입력란에 입력된 내용을 똑같이 "Debugging" 넣어주세요. 예를 들면 비주얼C++ 2003에서는 "Command" 입력란은 "..\..\bin\$(ConfigurationName)\$(TargetFileName)" 비슷해야 합니다. "Working Directory" 내용에서는 파일명(TargetFileName) 제거해야 합니다. 이런 경우에는 작업디렉토리는 "..\..\bin\$(ConfigurationName)" 되어야 합니다. 정확한 입력은 비주얼C++ 버젼에 따라 다르고 빌드환경에 따라서도 달라집니다. 그렇기 때문에 작업을 하기전에 Command 입력란을 체크해 두세요. 작업디렉토리의 릴리즈모드와 디버그 모드 둘다 바꾸는것도 잊지 마세요.

비주얼C++ 2005에서는 전체적으로 많이 다를겁니다. "..\..\bin\$(ConfigurationName)" 먼저 해보시는걸 권장하고, 여전히 문제가 지속된다면 Help 포럼에서 상담을 받아보세요.

이렇게 하는 이유는 오우거엔진은 실행파일과 동일한 디렉토리에 특정한 중요한 필수 파일들을 필요로 하기때문에 Working Directory 필수적으로 있어야 하는 파일들이 포함된 디렉토리가 되어야 합니다..


Trackback 1 : Comment 0

기초 튜토리얼 1-2

Ogre3D 삽질란/Basic Tutorial 1 2008/11/08 12:06

오우거 엔진 동작과정

광범위한 주제군요. 앞으로 여러타입의 SceneManager Entity, SceneNode 들과 함께 작업할 입니다. 3가지 클래스들은 오우거 어플리케이션을 구성하는 중요한 구성원들 입니다..

SceneManager 기초

화면상에 표시되는 모든것은 SceneManager 의해 관리됩니다(상상해 보세요). 어떠한 객체들을 화면에 표시하면 SceneManager 객체들의 위치와 움직임을 관리하는 클래스 입니다. 장면을 보기위해 카메라를 생성하면 SceneManager 카메라(추후 튜토리얼에서 다루게 됩니다) 위치를 관리합니다. 평면, 빌보드, , 기타등등.. SceneManager 사용자가 생성한 모든것을 관리합니다.

SceneManager 여러가지 타입이 있습니다. 지형을 그리는 SceneManager, BSP 맵을 그리는 SceneManager, 그리고 많은것들이 있습니다. 다양한 타입의 SceneManager 여기서(http://www.ogre3d.org/wiki/index.php/SceneManagersFAQ) 확인할 있습니다. 튜토리얼을 진행하면서 점점 다양한 SceneManager 들을 다루게 것입니다.

Entity 기초

Entity 장면에 그릴 있는 객체타입중 하나입니다. 3D 메쉬로 표현할 있는 모든것은 Entity 라고 생각하셔도 됩니다. 로봇도 Entity 될수 있고 물고기, 걸어다닐 있는 넓은 땅떵어리도 넓은 형태의 Entity 있습니다. 그러나 , 빌보드, 파티클, 카메라 몇가지 들은Entity 없습니다.

알아두셔야 것은 장면에 그려질 있는 객체들은 그들의 위치와 방향 정보와는 별개로 분리되어 있다는 입니다. 무슨 의미냐면 하나의 Entity 한번의 과정만으로는 그릴 없다는 입니다. 대신에 Entity SceneNode 객체에 (attach)붙여야 하며 SceneNode 붙여진 Entity 위치와 방향에 대한 정보를 가지게 됩니다.

SceneNode 기초

앞서 얘기한대로, SceneNode attach 모든 객체들에 대한 방향과 위치정보를 가지고 있습니다. Entity 생성했을때 SceneNode attach 하기 전에는 실제적으로 그려지지 않습니다. 추가로 말씀드리자면 SceneNode 자체는 화면에 출력되는 객체가 아닙니다. SceneNode 생성하고 Entity attach 해야만 화면상에 뭔가가 그려지게 됩니다.

SceneNode attach 되는 객체의 수에 제한을 받지 않습니다. 예를 들자면 화면을 돌아다니는 캐릭터가 하나 있고 스스로 빛을 내는 후광효과를 내고 싶다고 합시다. 이것을 구현하기위해서 먼저 SceneNode 생성하고 캐릭터 Entity 생성한 해당 SceneNode attach 합니다. 다음 객체를 생성한 아까 생성했던 SceneNode attach 합니다. SceneNode 다른 SceneNode attach 가능하며 이것은 node 들의 계층적 구도를 구현할 있도록 줍니다. 나중에 있을 튜토리얼에서 나은 SceneNode attachment 사용법에 대해서 다룰 예정입니다.

SceneNode 가장 중요한 컨셉중 하나는 SceneNode 위치는 항상 부모 SceneNode 상대적 이라는 각각의 SceneManager 들은 최초의 root node를 가지는데 그 root node 다른 모든 SceneNode 들이 attach 된다는 입니다.

오우거 응용프로그램 실행하기

, 이제 앞서 작성해 코드로 돌아갑시다. TutorialApplication::createScene 멤버함수를 찾으세요. 튜토리얼에서는 함수의 내용만 수정할 입니다. 우리가 먼저 해야 일은 우리가 하고 있는지를 확인할 있도록 주변광 (ambient light) 설정하는 입니다. 우리는setAmbientLight 호출하고 적용할 컬러를 설정할 입니다. 참고로 ColourValue 생성자는 red, green, blue 3가지 색상값을 받는데 각각은 0 1사이의 실수 범위를 가집니다. 라인을 createScene 추가하세요 :

mSceneMgr->setAmbientLight( ColourValue( 1, 1, 1 ) );

다음으로 해야할 일은 Entity 생성하는 입니다. SceneManager createEntity 멤버함수호출에서 처리합니다 :

Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );

여기서 잠깐 가지 질문들이 예상되는군요. 가장먼저 mSceneMgr 어디서 온것이며 관련함수 호출시 어떤 매개변수를 줘야 하는걸까요? 여기서 mSceneMgr 변수는 현재의 SceneManager 객체(ExampleApplication 클래스에서 이미 생성되어 있습니다) 가르킵니다. createEntity 첫번째 매개변수는 만들고자 하는 Entity 이름을 의미합니다. 모든 Entity 들은 고유한 이름을 가져야 합니다. 만약 2개의 Entity 들이 같은 이름을 가진 다면 에러를 발생시킬 입니다. "robot.mesh" 매개변수는 Entity 사용될 메쉬를 의미합니다. 전체적으로 다시말해, ExampleApplication 클래스가 앞으로 사용되어질 메쉬를 미리 메모리에 로드시켜놓은 입니다.

지금 우리는 Entity 생성했고 이제는 SceneNode attach 해야 합니다. 모든 SceneManager 루트 SceneNode 가지고 있고

우리는 루트 SceneNode 로부터 자식 node 생성해 나갈 입니다.

SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );

명령은 먼저 현재 사용되는 SceneManager 통해서 getRootSceneNode 부릅니다. 다음 결과값 포인터(루트 SceneNode입니다) 로부터 createChildSceneNode 호출하게 됩니다. createChildSceneNode 매개변수는 만들어질 SceneNode 이름입니다. Entity 클래스처럼 2 SceneNode들이 같은 이름을 가질 수는 없습니다.

드디어, 로봇이 그려질 위치를 전달하기위해 Entity SceneNode attach 차례입니다 :

node1->attachObject( ent1 );

그리고 끝입니다! 컴파일하고 어플리케이션을 실행하세요. 화면에 있는 로봇 하나를 발견하실것 입니다.

참고 : Robot.mesh OgreCore.zip 파일에 포함되어 있지 않습니다. 튜토리얼을 따르면서 지금 시점에서 어플리케이션이 실행은 되지만 아무것도 표시되지 않을 있습니다. 어플리케이션이 정상적으로 실행되기 위해서 resources.cfg 파일에서 디렉토리를 옳바르게 수정해야 합니다 :

FileSystem=../../media/materials/programs

FileSystem=../../media/materials/scripts

FileSystem=../../media/materials/textures

FileSystem=../../media/models

좌표와 벡터

진행하기 전에, 스크린 좌표계와 오우거 벡터 객체에 대해서 알아야 합니다. 오우거(다른 그래픽 엔진들과 마찬가지로) x, z 축으로 수평면을 표현하고, y 축은 수직축으로 사용됩니다. 지금 모니터를 바라보는 시점에서 x 축은 왼쪽에서 오른쪽 방향이며 오른쪽 방향이 x 양의 방향입니다. y 축은 모니터 바닥에서 윗쪽 방향이며 모니터의 상위쪽이 y 향의 방향입니다. z 축은 모니터 내부에서 바깥쪽 방향이며 스크린 바깥쪽 방향이 z 양의 방향입니다.

로봇이 x 양의 방향을 바라보고 있을까요? 이건 메쉬자체의 속성이자, 메쉬가 어떻게 디자인 되었는가에 따라 다릅니다. 오우거는 사용되는 모델의 방향에 대해서는 상관하지 않습니다. 로드되어지는 각각의 메쉬는 "기본 시작방향" 제각각 다를 있습니다.

2차원(Vector2), 3차원(Vector3), 4차원(Vector4) 이렇게 다양한 차원을 위해서 벡터 클래스가 정의되어 있으며 이중 Vector3 가장 자주 쓰입니다. 만약 벡터개념에 익숙치 않다면 오우거를 이용해 본격적으로 뭔가를 하기전에 복습 하시기를 권합니다.

(http://en.wikipedia.org/wiki/Vector_%28spatial%29)

수학적인 벡터 지식은 복잡한 프로그램을 다룰때 무척 유용하게 쓰입니다.

추가적인 객체 삽입하기

이제 좌표계가 어떻게 적용되는지 이해했으니 살펴보던 코드로 돌아갑시다. 작성했던 3줄의 코드에서 로봇이 나타날 위치를 설정한 부분은 없습니다. 대부분의 오우거 함수들은 디폴트 매개변수값을 가지고 있습니다. 예를 들면 SceneNode::createChildSceneNode 멤버함수는 3개의 매개변수를 가지는데 SceneNode 이름, SceneNode 위치, 마지막으로 SceneNode 바라볼 최초 회전값을 가집니다. 위치값은 보시는것 처럼 (0, 0, 0) 적용되었습니다. 이번에는 원점에서 떨어진 위치에다가 추가적인 SceneNode 만들어 봅시다 :

Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );

SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

node2->attachObject( ent2 );

예전과 비교해 별반 다를바 없어 보입니다. 2가지 부분을 제외하곤 이전에 했던것과 완전 똑같은 코드를 입력했습니다. 가장 먼저 Entity SceneNode 이름을 조금 다르게 설정했습니다. 두번째는 시작위치를 root SceneNode 부터 x축에서 50 단위 거리만큼 떨어지게 설정했습니다(기억해야 것은 모든 SceneNode 위치는 그들의 부모와 상대적인 위치를 가집니다). 컴파일하고 데모를 실행시켜 보십시오. 2개의 로봇이 나란히 있습니다.

Entity 대해서..

Entity 클래스는 매우 광범위 하며, Entity 객체의 모든 사용법을 여기서 설명하지는 않을 이지만.. 시작하기에는 충분할 입니다. 지금 바로 쓰기에 유용한 몇몇 Entity 멤버함수들을 여기서 집고 넘어가고 싶습니다.

첫번째는 Entity::setVisible Entity::isVisible 입니다. 간단하게 함수를 호출하는것만으로 어떠한 Entity 라도 보여지거나 숨겨질 있습니다.만약 Entity 숨기고 나중에 표시해야 한다면 Entity 파괴하고 다시 생성하는것 대신에 함수를 호출하세요.참고로 Entity 들을 위해서 "Pool" 준비할 필요는 없습니다. 메모리에 읽혀질 때마다 모든 객체의 메쉬와 텍스쳐는 한번만 실제적으로 메모리에 적재되기 때문에 메모리공간을 절약하기위해 노력하실 필요가 없습니다. 오직 상대적으로 부담이 적은 Entity 생성과 파괴에 대한 비용부담만 생각하시면 됩니다.

getName 함수는 Entity 이름을 반환하며, getParentSceneNode 함수는 해당 Entity attach 되어 있는 SceneNode 반환합니다.

SceneNodes 대해서..

SceneNode 클래스는 매우 복잡합니다. SceneNode 있는 많은것들이 있는데 가장 유용한 몇가지의 기능들을 살펴볼 것입니다. getPosition setPosition 이용해 SceneNode 위치를 설정하거나 얻어낼 있습니다. SceneNode 연관된 객체의 위치를 translate 명령을 통해서 이동이 가능합니다. SceneNode 객체의 위치를 설정하는것 뿐만 아니라 크기와 회전역시 담당합니다. Scale 함수를 이용해서 객체의 크기를 설정할 있습니다. pitch, yaw, 그리고 roll 함수로 객체를 회전시킬 있습니다. resetOrientation 통해서 수행된 모든 회전을 리셋시킬 수도 있습니다. setOrientation, getOrientation 그리고 rotate 함수들을 이용해서 세부적인 회전을 수행할 수도 있습니다. Quaternions(사원수) 대해서는 많은 튜토리얼을 다루기 전에는 언급하지 않을 예정입니다.

독자는 이미 attachObject 적이 있을것입니다. 만약 SceneNode attach 객체에 변화를 주고 싶다면 여기에 소개되는 연관된 함수들이 매우 유용하게 쓰일 것입니다 : numAttachedObjects, getAttachedObject (여러가지 상황별 함수들이 있음), detachObject (이것 역시 다양한 상황별 함수가 있음), detachAllObjects. 부모 SceneNode 자식 SceneNode 다루는 함수들은 서로 동일하게 쌍으로 존재합니다.

모든 위치이동이 부모 SceneNode 의해 연관되어 수행되는 이상 2개의 SceneNode 들을 함께 이동시키는건 매우 쉽습니다. 현재 어플리케이션 소스에는 다음코드가 존재합니다 :

Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );

SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );

node1->attachObject( ent1 );

Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );

SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

node2->attachObject( ent2 );

만약 5번째 줄을 상태에서 :

SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

이렇게 고치게 된다면? :

SceneNode *node2 = node1->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

RobotNode 자식노드 RobotNode2 만들게 됩니다. node1 움직이는것은 node2 같이 움직이게 되지만 node2 이동은 node1 영향을 주지 않습니다. 예를 들어 코드는 RobotNode2 이동시킵니다.

node2->translate( Vector3( 10, 0, 10 ) );

다음의 코드는 RobotNode 움직이고 RobotNode2 RobotNode 자식인 이상 RobotNode2 동일하게 같이 움직이게 됩니다 :

node1->translate( Vector3( 25, 0, 0 ) );

이런 수행을 하는데 계산하는데 어려움이 있다면 가장 좋은 방법은 최상위 루트 SceneNode 시작하여 아래방향으로 진행하는 입니다. 예를 들면(본문에서 예처럼), node1 로부터 시작하여 (0, 0, 0) (25, 0, 0) 으로 이동시킴으로 node1 위치는 (25, 0, 0) 만큼 부모의 위치로부터 상대적인 공간에 위치하게 됩니다. node2 (50, 0, 0) 에서 시작하여 (10, 0, 10) 으로 이동시 켰으므로 새로운 위치는 (60, 0, 10) 만큼 부모의 위치로부터 상대적인 공간에 위치하게 됩니다.

, 이것들이 실제로 어디에 위치하는지 알아봅시다. 루트 SceneNode 에서 시작합니다. 이것의 위치는 항상 (0, 0, 0) 입니다. 지금 node1 위치는 (root + node1) : (25, 0, 0) = (25, 0, 0) 되겠죠. 별거 아니군요.

, 그럼 현재 node2 node1 자식이므로 이것의 위치는 (root + node1 + node2): (0, 0, 0) + (25, 0, 0) + (60, 0, 10) = (85, 0, 10) 됩니다.

이건 SceneNode 계층적인 위치 구조를 설명하기위한 예시에 불과합니다. 아마 아주 가끔씩 노드들의 절대위치를 계산해야 경우가 생길겁니다.

마지막으로 알아두실 SceneNode Entity 이름은 getSceneNode getEntity 함수 호출로 얻을 있기 때문에 만드는 SceneNode 마다 포인터들을 따로 보관해 필요가 없습니다. 특별히 자주 쓰는것만 쓰기 쉽도록 관리해 주시면 됩니다.

Trackback 0 : Comment 0

기초 튜토리얼 1-3 (마지막)

Ogre3D 삽질란/Basic Tutorial 1 2008/11/08 12:04

해볼만 것들

이제 여러분은 Entity, SceneNode 그리고 SceneManager 기본기를 익혔습니다. 위에서 언급한 소스로부터 로봇을 추가하고 제거하는것을 해보길 권합니다. 해보셨으면 createScene 내용을 모두 지우고 다음의 소스코드들을 동작시켜 보시기 바랍니다 :

Scale

SceneNode scale 함수를 이용해서 메쉬의 크기를 조절할 있습니다. 스케일 수치를 바꿔보고 어떻게 바뀌는지 확인해 보세요 :

Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );

SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode" );

node1->attachObject( ent1 );

node1->scale( .5, 1, 2 );

Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );

SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2", Vector3( 50, 0, 0 ) );

node2->attachObject( ent2 );

node2->scale( 1, 2, 1 );

Rotations

yaw, pitch, roll 함수에 Degree 또는 Radian 수치를 적용해서 객체를 회전시킬 있습니다. Pitch x 축을 주위로 회전합니다. yaw y 그리고 roll z축을 중심으로 회전합니다.

오른손으로 방향을 있습니다 : 엄지손가락을 축으로 다음 다른 손가락이 가르키는 방향이 양의 각도입니다. 예를 들면 pitch(Degree(90)) 라면 엄지손가락은 오른쪽을 가르키고 다른 손가락은 회전방향을 의미합니다. 차근차근 생각해 보세요.

사용자 삽입 이미지

각도(Degree) 수치 조절과 위치변화를 다양하게 조합해 보세요 :

Entity *ent1 = mSceneMgr->createEntity( "Robot", "robot.mesh" );

SceneNode *node1 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode", Vector3( -100, 0, 0 ) );

node1->attachObject( ent1 );

node1->yaw( Degree( -90 ) );

Entity *ent2 = mSceneMgr->createEntity( "Robot2", "robot.mesh" );

SceneNode *node2 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode2");

node2->attachObject( ent2 );

node2->pitch( Degree( -90 ) );

Entity *ent3 = mSceneMgr->createEntity( "Robot3", "robot.mesh" );

SceneNode *node3 = mSceneMgr->getRootSceneNode()->createChildSceneNode( "RobotNode3", Vector3( 100, 0, 0 ) );

node3->attachObject( ent3 );

node3->roll( Degree( -90 ) );


Ogre
실행환경

OgreSDK "bin" 폴더 아래의 debug 또는 release 폴더에서 있는 많은 파일들 (*.dll, *.cfg) 섹션에서 참조할 있습니다. 디버그버젼으로 생성된 프로그램은 OgreSDK debug 폴더내의 파일들을 이용하고 릴리즈버젼의 프로그램은 release 폴더의 파일들을 사용하게 됩니다.

섹션의 대부분은 윈도우즈 환경하에서 다뤄집니다. 리눅스에서도 기본적인 사항들은 동일하게 적용되지만 몇몇 사항들은 약간 다를 있습니다. 만약 리눅스에서 오우거엔진 사용시 문제가 발생하면 오우거 help포럼에 글을 남겨주세요.

DLLs and Plugins

우리는 방금 오우거 환경에서 흥미로운 체험을 해봤습니다. 이제 평상시에 오우거 라이브러리를 사용할때 어떤 편리한 점이 있는지 설명하고자 합니다.

오우거는 크게 3개의 중요그룹으로 나눠지는데, 메인 라이브러리, 플러그인 그리고 써드파티 라이브러리로 나뉘어 집니다.

Main library.

첫번째 그룹은 오우거 라이브러리 자체와 밀접하게 연관되는 공유 라이브러리들을 포함합니다. OgreMain.dll 오우거본체 라이브러리가 포함됩니다. dll 파일은 cg.dll 같은 몇몇 다른 라이브러리를 필요로 합니다. DLL 들은 반드시 항상 오우거 어플리케이션과 함께 포함되어야 합니다.

Plugins.

두번째 공유 라이브러리는 플러그인 입니다. 오우거는 효율적인 기능성분할을 위해 공유라이브러리로 기능을 나누었으며 라이브러리들은 유저의 어플리케이션이 필요로 하는 정도에 따라서 기능을 제공할 도있고 그렇지 않을 있습니다. 오우거와 함께 사용되는 기본적 플러그인들은 "Plugin_" 이라는 prefix 시작되는 파일명을 가집니다. 유저가 필요로하는 플러그인은 유저 스스로 새로운 플러그인을 작성할 있지만, 어떤 튜토리얼에서도 다루지는 않을 계획입니다. 오우거는 렌더링 시스템을 위해서도 플러그인을 사용합니다(OpenGL, DirectX, 기타등등). 이러한 플러그인들은 "RenderSystem_" 이라는 prefix 가집니다. 플러그인들을 추가하거나 삭제하는것 으로도 유저의 어플리케이션의 렌더링 시스템을 설정할 있습니다. 다음과 같은 상황에서는 매우 유용한데 만약 유저가 (예를들면) OpenGL에만 해당되는 쉐이더 프로그래밍이나 특별한 작업을 하는경우 또는 DirectX 에서 동작되는 프로그램에서 OpenGL 기능을 강제로 끄고 싶을때 유저는 단순히 해당되는 렌더링시스템 플러그인을 제거하는 만으로도 기능은 제공되지 않도록 있십니다. 추가적으로 만약 유저가 비표준 플랫폼을 염두한다면 튜토리얼에서는 다루지는 않지만 유저만의 렌더링시스템 플러그인을 작성할 수도 있습니다. 플러그인을 어떻게 제거하는지는 다음 섹션에서 다룰 입니다.


써드파티 라이브러리와 helper 라이브러리.

세번째 공유라이브러리는 써드파티 라이브러리와 helper 라이브러리입니다. 오우거 자체로는 그냥 그래픽 렌더링 라이브러리일 입니다. GUI 시스템이라던지 입력컨트롤, 물리엔진, 기타등등.. 이러한 기능들은 가지고 있지 않습니다. 다른 라이브러리들을 사용하기위해서 다음과 같은 절차를 거쳐야 합니다. 오우거 데모들과 SDK 소수의 써드파티 helper 라이브러리들을 포함하고 있습니다. CEGUI 라이브러리는 오우거와 통합된 GUI 시스템이며 "OgreGUIRenderer.dll" "CEGUI*" 부터 시작되는 파일들은 GUI 시스템의 일부 입니다. CEGUI 사용하는 방법은 나중에 있을 튜토리얼에서 다루어질 입니다. 키보드와 마우스입력은 OIS(입력 시스템) 통해서 최종 처리됩니다. OIS OIS.dll 포함합니다. 이것들 말고도 다른 기능(물리엔진이나 사운드)들을 제공하는 라이브러리들 역시 존재하며(SDK 포함되지 않은것들) 이와 관련된 많은 정보는 위키와 같은 다른 포럼에서 찾을 있습니다.

가장 실용적이고 진정한 문제는 바로 눈앞에서 스스로 테스트 해보는 어플리케이션에서 나오며 모든 기능을 상태(아무것도 제거하지 않은상태) 하에서 테스트해 있습니다. 유저의 어플리케이션 배포가 준비되었을때 릴리즈모드에서 빌드를 해야 것이고 어플리케이션이 필요로 하는 모든 릴리즈용 DLL 파일은 포함되어야 해야 하며, 쓰지않는 DLL 파일은 제거되어야 입니다. 만약 프로그램이 CEGUI 쓰지 않지만 OIS 쓸때, CEGUI 관련 DLL 파일들을 포함하는데 고민할 필요는 없지만 OIS DLL 파일은 반드시 포함되어야 합니다. 그렇지 않으면 어플리케이션은 실행되지 않을 입니다.

환경설정 파일

오우거는 몇몇 환경설정파일을 사용합니다. 파일들은 어떠한 플러그인이 로드되어야 할지, 어플리케이션의 리소스들은 어디에 위치되었는지, 기타등등을 제어합니다. 이제 각각의 환경설정 파일들이 어떠한 일을 하는지 간단하게 살펴볼 것입니다. 만약 세부적인 궁금증이 있다면 바로 오우거 help 포럼으로 보내주세요.

plugins.cfg 파일은 유저의 어플리케이션이 사용하는 플러그인들을 포함합니다. 만약 유저 어플리케이션에서 플러그인을 추가하거나 제거하고 싶다면 파일을 수정하면 됩니다. 플러그인을 제거하기 위해서는 간단히 해당 라인을 제거하거나 라인 가장 앞에 # 붙이는 것으로 주석처리를 하면 됩니다. 플러그인을 추가하고 싶다면 "Plugin=[PluginName]" 같이 라인을 추가하면 됩니다. 참고로 플러그인 이름 끝에 ".DLL" 붙이지 마세요. 플러그인은 "RenderSystem_" 또는 "Plugin_" 으로 시작되어서도 안됩니다. 오우거가 플러그인들을 찾는 위치를 수정하기위해 "PluginFolder" 변수를 수정할 수도 있습니다. 상대경로, 절대경로 모두 사용가능하지만 $(변수) 형태의 환경변수는 사용할 없습니다.

resources.cfg 파일은 오우거가 리소스를 찾기위해 검색해야할 디렉토리 리스트를 담고 있습니다. 리소스는 스크립트, 메쉬, 텍스쳐, 기타 여러가지를 포함하고 있습니다. 절대경로, 상대경로 모두 사용 가능하지만 $(변수) 같은 환경변수는 사용할 없습니다. 참고로 오우거는 하위폴더를 검색하지 않기때문에 만약 여러단계의 폴더를 입력할 필요가 있다면 일일이 작성해 주어야 합니다. 예를 들면 "res\meshes" "res\meshes\small" 디렉토리 트리구조를 가진다면 위해 리소스 파일이 포함된 경로의 2가지 진입점을 리소스 파일에 추가해야 합니다.

media.cfg 파일은 리소스의 일부분에 대한 상세한 정보를 말해줍니다. 지금 시점에서는 수정할 필요가 없으므로 자세한 설명은 생략하겠습니다. 자세한 정보는 메뉴얼과 오우거 포럼에서 찾을 있습니다.

ogre.cfg 파일은 오우거 환경설정 화면에서 생성됩니다. 파일은 유저의 컴퓨터와 그래픽 설정 내용을 기술합니다. 다른 사람들이 각각 다른 설정을 가지는 처럼 유저가 어플리케이션을 배포할때는 파일이 같이 포함되어서는 안됩니다. 유의하실 점은 환경설정을 통하지 않고 파일을 직접적으로 수정하시면 안됩니다.

quake3settings.cfg 파일은 BSPSceneManager 함께 사용됩니다. BSPSceneManager(지금 시점에서는 쓰지 않습니다) 사용하기 전에는 필요하지 않은 파일이므로 무시하세요. 유저 어플리케이션에서 필요없다면 배포하지 마세요. 반면에, 만약 유저가 BSPSceneManager 이용한다면 프로그램의 필요성에 의해 포함될 있습니다.

모든 환경설정 파일들은 오우거에 직접적인 영향을 줍니다. 오우거는 "plugins.cfg", "resources.cfg", 그리고 "media.cfg" 파일들이 실행시 반드시 참조 가능해야합니다. 나중에 있을 튜토리얼에서는 파일들에 관한 내용과 세부적인 작업을 위해 어떻게 그들의 위치정보와 내용을 수정해야 할지를 다룰 입니다.

어플리케이션 테스트를 위한 나은 환경 구성하기

윈도우즈에서 비주얼C++ 사용하는 사람에게만 해당되는 내용입니다.

앞서 여러번 언급했던것 처럼(문제해결 섹션을 포함하여), 오우거는 유저의 프로그램에서 사용되는 각종 환경설정파일, DLL, 미디어 리소스 자원들에 대한 접근이 가능해야 합니다. 많은 사람들은 문제를 위해 OgreSDK bin 폴더로 부터 유저의 프로젝트 디렉토리로 필요한 DLL 파일들을 실행파일과 같은 위치로 복사하여 해결합니다. 방법이 아마 게임이든 다른종류의 프로그램이든 배포에 있어서 최고의 방법일 지도 모릅니다. 배포를 위해서 각종 플러그인을 넣고 빼고 하는 귀찮은 과정을 생략할 있기 때문이죠. 모든 DLL 파일들을 각각의 오우거 프로젝트 폴더로 복사해 넣는것은 공간적, 시간적 낭비임에도 불구하고 많은 상황에서 발생되고 있습니다. 여기 그런 낭비를 줄일 있는 방법이 몇가지 있습니다.

한가지 대안은 OgreSDK DLL 파일들을(플러그인 빼고) 윈도우즈 시스템 폴더로 복사하는 입니다. 이건 오우거를 이용한 실행파일이 어디에 있던간에 필요한 DLL 파일에 접근할 있는게 장점입니다. 작업을 수행하려면 resources.cfg, plugins.cfg 파일에서 media 폴더와 plugins 폴더의 절대경로를 알맞게 각각 수정해 줘야 합니다. 그럼 어디서 프로젝트를 생성하던지 수정된 환경설정 파일들만bin\debug bin\release 디렉토리로 부터 복사하기만 하면 됩니다. 그러나 저는 OgreSDK DLL 파일들의 위치관리가 안될것 같아서 개인적으로는 쓰지 않는 방식입니다. 오우거는 자주 새버젼이 발표되는데 방법으로 업데이트 하려면 귀찮아 집니다.

나은 대안으로는 OgreSDK 파일들은 그대로 놔두고 프로젝트의 작업디렉토리를 OgreSDK bin\release bin\Debug 디렉토리로 설정하는 입니다. 이렇게 하려면 프로젝트의 속성(디버깅 옵션에서)에서 "Working Directory" 입력창 내용을 "C:\OgreSDK\bin\$(ConfigurationName)" 바꿔 주세요. 기본값이 아닌 다른경로로 오우거를 설치했다면 "C:\OgreSDK" 부분을 실제로 설치한 경로로 바꿔줘야 합니다. 그렇게 하신다면 오우거 프로그램 동작을 위해서 아무런 파일도 복사하지 않아도 됩니다. 접근방법이 제가 개인적으로 사용하는 방법입니다. 가지 단점은 환경설정파일을 수정해야 경우, 모든 오우거 프로젝트를 수정해야 한다는것인데.. 안좋긴 합니다. 만약 접근방법을 이용하고 유저 프로젝트를 위해 환경설정파일을 수정해야 한다면 방법 대신에 하던대로 모든 파일을 프로젝트로 복사해 넣으시고 작업디렉토리를 원래 지정되어졌던 내용으로 바꿔주세요.

맺음말

이제 독자는 SceneManager, SceneNode 그리고 Entity 클래스에 대한 기초지식을 습득했습니다. 여기서 소개드린 모든 함수들에 대해서 억지로 익숙해질 필요는 없습니다. 소개드린것은 가장 기초적인 객체들이며 앞으로 자주 쓰이게 것입니다. 다음에 있을 몇몇 튜토리얼에서 여기서 소개드린 모든 것이 자연스럽게 친숙해 것입니다.

그리고 오우거 환경을 설정하는데에도 익숙해져야 합니다

반응형
반응형

http://cafe.naver.com/ogre3d.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=3823&

아이폰에 오우거엔진 사용할때는

사용언어가 objective-c로 개발해야 하는건가요??

초보의 질문이었습니다 ㅎㅎ


  • 2011/03/30 16:42

    제가 드린 질문은 게임로직을 코딩할때..
    오우거를 사용하지 않으면...objective-c로 코딩해야하지만
    오우거를 사용할경우 c나 c++로 아이폰 개발을 할수 있는 환경이 되는건지 ..?
    이것이 궁금했습니다

  • 2011/03/30 16:51

    오브젝트씨가 c/c++ 을 같이 지원하기 때문에, 게임의 경우 대부분 기존 c/c++ 로 코딩하고 윈도 뛰우고 터치 이벤트 처리같은 ui 같은 부분은 코코아라고 하는 오브젝트씨 라이버리를 이용해야 하기때문에, 그 부분만 오브젝트씨로 작성해주면 됩니다. 그래서 오우거 엔진의 경우는 그냥 c/c++ 컴파일해서 ARM 네이티브 코드로 아이폰에 올라가게 됩니다.

  • 2011/03/30 16:52

    안드로이의 경우는 JNI 이용해서 c/c++ 컴파일된 네이티브 코드를 자바에서 호출하는 형태인데, 오브젝트씨가 자바로 바뀐거라고 보면 되겠습니다.

  • 2011/03/30 17:06

    harkon님 답변 감사합니다 ㅎㅎ

반응형
반응형

1.7 이상 버전은 이러한데 이 미만 버전 older versions 는 다르다

http://www.ogre3d.org/licensing 를 참고.

OGRE 1.7 and later

MIT License

Ogre is released under the MIT License, which is a permissive open source license. The only condition is that you distribute the license text included in our distribution with any software that uses OGRE.

Licensing FAQ

Older Versions

This section only applies if you’re using OGRE 1.6 or earlier.


http://www.ogre3d.org/licensing/licensing-faq


Licensing FAQ

  1. Q: Is OGRE really free?
    If you abide by the open source licensing conditions, yes.
  2. Q: Do I have to release my own source code if I use OGRE?
    A: No.
  3. Q: Do I have to release changes I make to OGRE?
    A: From Ogre 1.7 we use the MIT license, which does not require you to do this. However, you should consider the maintenance overhead of keeping your own custom version of OGRE, versus the advantages you might get from participating in the community (such as bugfixes and extensions that others may make on top of yours).
  4. Q: What do I need to do to abide by the MIT license?
    A: Simply include our license text somewhere in your own software distribution; this could be in a text file, in a printed manual, in the credits, etc.
  5. Q: Do I have to display an OGRE logo in my application, in splash screen or startup sequence for example?
    A: No, although we appreciate the publicity if you would like to do this!
  6. Q: At what point do I have to ensure that I’ve complied with the license?
    A: When you distribute any part of your application to a third party.


반응형
반응형

OGRE 설치 & Source 빌드 - window, vs2008 기준, OGRE 1.7.2 Source For Windows

송정헌 2011-02-27 04:21:49 주소복사
조회 1153 스크랩 0

Ogre 설치 가이드

http://www.ogre3d.org/tikiwiki/Prerequisites


1. Visual Studio 2008 (VC9) 버전을 사용할 경우 Microsoft Update 2008 sp1 를 설치 해야한다

다운 목록 :

ATL security fix available from Microsoft Update 2008 sp1

http://www.microsoft.com/downloads/en/details.aspx?familyid=2051a0c1-c9b5-4b0a-a8f5-770a549fd78c&displaylang=en


MinGW 에 대한 설명, 뭐 일단 무료라함

http://blog.naver.com/byuckdan?Redirect=Log&logNo=100123459348

반드시 GCC 4.4.X 를 기반으로 하고 있는 MinGW 를 설치 해야 하며

http://www.ogre3d.org/tikiwiki/Prerequisites 에 기록할 당시 쓰여진 버전은

GCC 4.4.1 을 기반으로 하고 있는 tdm-mingw-1.908.0-4.4.1-2 이다

설치할 적에 Check for updated files on the TDM/MinGW server 체크를 해제 해야

tdm-mingw-1.908.0-4.4.1-2 가 설치 가능하다, 구 버전을 사용하기 위함

tdm-mingw-1.908.0-4.4.1-2.exe

http://code.google.com/p/gcc-offline/downloads/detail?name=tdm-mingw-1.908.0-4.4.1-2.exe&can=2&q=


Direct3D 렌더시스템을 사용하기 위해 DirectX SDK - February 2010 를 설치 한다.

window 정품 유효성 검사를 거친 후 설치 가능함

오래 걸리니 다운 받아 놓으면서 다음을 진행하자, 그전에 SDK 를 다운 받고 DXSDK_DIR 를 등록하는 과정을

기억하고 있어야 함

DirectX SDK - February 2010

동일한 주소:

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=2c7da5fb-ffbb-4af6-8c66-651cbd28ca15###

dx 설치후 cmd 에서 다음을 등록해야 한다

C:\>set DXSDK_DIR
DXSDK_DIR=C:\Program Files\Microsoft DirectX SDK (February 2010)\

Boost 설치는 필수는 아니고 옵션 사항이다.

대략 Boost 를 설치할 경우 빽그라운드 를 로딩할 경우 좀 더 빠른 시간에 Boost threads 로 로딩할 수 있다 함

Ogre 에서 권하는 버전은 1.44.0 버전임

vs2003~vs2010 유저는 부스트 인스톨러로 설치 할 수 있다, 라고 하는데

오우거 홈페이지에서 링크해놓은 링크가 깨진것 같다

boost URL 이 바뀐듯..

그리하여 다음 주소에서 인스톨러를 받을 수 있다.

http://www.boost-consulting.com/download/

실제 받을 수 있는 URL -> http://www.boost-consulting.com/download/boost_1_44_setup.exe

Boost, 무료

http://sourceforge.net/projects/boost/files/boost/1.44.0/boost_1_44_0.zip/download

설치중 옵션에서 다음을 선택

Select your compiler and "Multithreaded" and "Multithreaded Debug".

http://sourceforge.net/projects/ogre/files/ogre-dependencies-vc%2B%2B/1.7/OgreDependencies_MSVC_20101231.zip/download

MinGW 유저는 아래 boost 설치 가이드를 통하여 빌드 한다.

http://www.boost.org/doc/libs/1_44_0/more/getting_started/windows.html


소스

Visual Studio Dependencies

MinGW 컴파일러

MinGW Dependencies


Dependencies
Visual Studio users need to compile the dependencies themselves: Visual Studio Dependencies
MinGW users can grab the precompiled MinGW Dependencies

Unpack the dependencies into either your Ogre source directory, your Ogre build directory or somewhere else.
The directory should be named Dependencies if put into either the source or the build directory.
If you choose to place it elsewhere, you can name it however you like, as long as you're setting an environment variable OGRE_DEPENDENCIES_DIR pointing to its location.

It's recommended to use the last option - OGRE_DEPENDENCIES_DIR - as it makes it easier to manage several different dependencies (vc9, vc10, mingw) on the same computer, against the same Ogre source directory.

Be sure to build the dependencies if using Visual Studio! Find the solution file in Dependencies/src. And don't forget to build in both configurations: debug and release.


오우거 설치 : http://www.ogre3d.org/download/source

Once you have downloaded, if you are new to using OGRE you can find information in the wiki about building OGRE from source, and a series of tutorials.

필요한 툴 파일들 설치

http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Building+Ogre

http://www.ogre3d.org/tikiwiki/Prerequisites

Make sure that you've sorted out the Prerequisites before attempting to build Ogre with CMake!

  1. Make sure you have downloaded, extracted and built the dependencies package
  2. Download CMake. You want the 'Win32 installer' release in the binary distribution section
  3. Run the CMake installer, install wherever you like
  4. Launch CMake via Start > Program Files > CMake 2.8 > CMake
  5. In the "Where is the source code" box, type or browse to the root directory of your OGRE source (the one that contains the OgreMain folder)
  6. In the "Where to build the binaries" box, type or browse to any folder you like - this will be where the build output will go (libraries, headers, dlls & sample exes). The folder does not have to exist yet. Note that you can run this process more than once with different output folders if you want (but we won't complicate matters now)
  7. Hit the 'Configure' button near the bottom of the screen
  8. Pick your target compiler, e.g. "Visual Studio 8 2005"
  9. Answer 'Ok' when asked if you want to create the build directory
  10. Wait for the configure process to finish
  11. The screen will now have a bunch of configuration options on it, which will be red (this is to indicate this is the first time you've seen them). You can see the potential for customising your build here, but for now just click the 'Configure' button again
  12. The values will turn grey, and the 'Generate' button at the bottom will now be enabled. Click 'Generate'
  13. Build files will now be generated in the location you picked, and CMake will say "Generating done"

오우거 빌드파일 뽑아내기

출처 : http://lancekun.com/tc/149

1.7부터 빌드방식이 바뀌어서 몇분들이 도움을 요청하시길래 간단히 컴파일법을 작성하겠습니다.
프로젝트로인해 오랜만의 포스팅이네요 ㅎ

일단 http://www.ogre3d.org/download/source 에 접속하여서
OGRE 1.7.0 RC1 Source For Windows Microsoft Visual C++ Dependencies Package
이 두개를 받습니다.

압축을 풀고 내용물을 한폴더로 모으면 위와 같이 두개의 폴더가 보이는데요.
Dependencies 폴더를 ogre 폴더속으로 넣어줍시다.
(참고: CMake로 컴파일시 한글경로인식이 않되기때문에 경로설정을해줌 C:\ogre-v1-7-0RC1\ogre )

그뒤에 Dependencies 폴더속 Dependencies\src 에 가보면 OgreDependencies 라는 이름으로
각 솔루션 파일이있는데 각자의 VisualStudio에 맞는 솔루션파일을 실행시켜서 솔루션채로 빌드해줍시다.
(저같은경우 VC9을 사용하니 OgreDependencies.VS2008.sln 실행)

: 이때 VS2008.sln 의 Debug, Release 모드 빌드함

여기까지는 이전 오우거 버젼컴파일하는것과 동일하였습니다.
이전에는 여기까지한뒤에 기본적으로 들어있던 OgreMain.sln을 찾아서 컴파일을 해주었는데요
1.7부터는 CMake를 통해 빌드를해야하더라구요.

그러므로 CMake를 받으러 http://www.cmake.org/cmake/resources/software.html 에 접속해서
Windows ZIP으로 되어있는것을받읍시다.(CMake자주사용하시는분아니면 그때그때받아쓰면됨)

자.. 다운이 다되었으면 \bin\cmake-gui.exe 를 실행시킵시다.

이제 CMake로 컴파일 CMakeList가 있는 폴더와 Output을 받아드릴 폴더를 설정해줍니다.
%주의 오우거폴더의 경로에 한글이 있으면 컴파일에 실패합니다.
%주의 CMake의 경로에 한글이있으면 컴파일되지않습니다.

그뒤에 Configure 버튼을 눌러줍니다.

그러면 위와 같은 창이 뜨는데요 여기서 자신이 사용하는 VisualStudio나 각각의 개발환경을
선택해주고 Finish를 눌러줍니다.


정상적으로설정이 되어있는 상태라면 위와같은 화면이 나타날것입니다.

이상태에서 Configure 버튼을 한번더 눌러준뒤 Generate 버튼을 눌러주면 Output되는 폴더속에
OGRE.sln 라는 이름의 솔루션 파일이 생성된것을 확인할수있습니다.


이후는 이전의 버젼을 사용했던것과 같이 엔진라이브러리를 컴파일한후 쓰시고싶은대로 쓰시면
되는겁니다아

엔진 컴파일후 샘플브라우져를 실행한 화면

반응형
반응형


http://coreafive.tistory.com/46

NiAlphaAccumlator
Z버퍼 어플리케이션이 알파 블랜딩된 오브젝트들을 씬 그래프의 원하는 어디에든 놓으면서 렌더링을 정확하게 처리할 수 있도록 해주는 accumulator입니다.
알파블랜딩된 오브젝트들은 서로와 관련하여 정렬된 순서로 그려야 합니다.
알파 블랜딩된 오브젝트들을 마지막에 정렬된 순서대로 그리지 않으면 시각적인 인위적 현상이 생길 수 있다.
이 accumlator는 불투명한 오브젝트드를 정렬하는 불필요한 작업을 없애주면서 알파 블랜딩된 오브젝트들은 뒤에서 앞으로 정렬합니다.
accumlator는 알파 블랜딩 오브젝트들만 미뤄두고 알파블랜딩이 꺼진 오브젝트들은 RegisterObjectArray에 대한 호출 동안에 즉시 렌더링되게 놔둡니다.
각 오브젝트들의 경계 영역의 중심점이나 가장 앞쪽의 점을 바탕으로 간단한 z-sort를 통해 이들을 정렬함으로써 이를 달성합니다.
이런식으로 모든 불투명한 오브젝트가 씬 그래프에서 운행되는 순서대로 제일 먼저 그려진 뒤에, 그 다음 알파 블랜딩된 오브젝트들이 뒤에서 앞으로 정렬된 순서대로 그려집니다.

NiStream
게임브리오 익스포트를 통해 익스포트한 씬 그래프를 로드해야 할때나, 자체적인 어플리케이션으로 미리 저장해둔 씬 그래프를 로드하려고 할 때 사용되어집니다.
여기서 NIF파일을 로드하기 위해 NiApplication::ConvertMediaFilename함수를 사용하는 데, 이 함수는 SetMediaPath로 지정된 경로를 사용해서 완전한 경로를 생성합니다.

bool NIF_Files::CreateScene()
{
// 불투명 오브젝트를 먼저 그린 뒤에,
// 알파 블랜딩된 오브젝트를 z-sort에 따라 순서대로 뒤에서부터 앞으로 그리도록
// 알파 블랜딩 정렬을 설정한다.
NiAlphaAccumulator* pkAccum = NiNew NiAlphaAccumulator;
m_spRenderer->SetSorter(pkAccum);

NiStream kStream;

bool bSuccess = kStream.Load( NiApplication::ConvertMediaFilename( "WORLD.NIF" ) );

if( !bSuccess )
{
// 예외처리
return false;
}

// 최상위 노드를 리턴하여 저장한다.
m_spScene = (NiNode*)kStream.GetObjectAt(0);

// NIF파일에 등록되어있는 카메라를 검색하여 설정하도록 처리합니다.
if( !FindSceneCamera() )
{
// 예외처리
return false;
}
}

NiCamera
씬 그래프의 카메라를 나타냅니다.
이 객체는 고유의 기하하적 표현이 없으나 월드 공간에서 자신의 위치와 방향을 결정하기 위해 부모의 변환을 이용합니다. 이런 구성은 게임브리오에서 카메라가 씬 그래프에 어태치되게 해주며, 안에 있는 카메라와 유도 카메라를 자동으로 따라다니게 만듭니다.

NiNode
신 그래프의 내부 노드를 나타냅니다.
이 노드들은 임의의 개수를 자식으로 가질 수 있으며 Dynamic Effect는 영향을 줄 노드를 지정하는 데, 이 경우 서브트리에서 한 노드에 루트를 두고 있는 모든 객체들이 영향을 받게 됩니다.
노드 서브클래스들은 그 밑에 있는 서브트리에 대한 정렬 동작을 조절할 수 있습니다.
NiNode는 또한 피킹 시스템과 충돌 검사 시스템에 호출의 재귀적인 전달도 제공합니다.

bool NIF_Files::FindSceneCamera()
{
if( m_spScene )
{
// 씬에 설치된 카메라를 찾아서 리턴받아 저장하도록 처리한다.
m_spCamera = FindCamera( m_spScene );
}

return (m_spCamera != NULL);
}

NiCamera* NIF_Files::FindCamera( NiAVObject* pkObject )
{
// 카메라 타입인지를 검사한다.
// 그래서 이게 true라면 카메라 타입으므로
// 변환한 후 리턴한다.
if( NiIsKindOf( NiCamera, pkObject ) )
{
return (NiCamera*)pkObject);
}

// 노드 타입인지를 검사하여 노드 타입이면 실행한다.
else if( NiIsKindOf( NiNode, pkObject ) )
{
// 노드 타입의 객체로 형변환한다.
NiNode* pkNode = (NiNode*) pkObject;

// 노드의 자식 개수만큼 루프를 실행한다.
for (unsigned int ui = 0; ui < pkNode->GetArrayCount(); ui++)
{
// 카메라 타입의 노드를 찾는다.
// 즉 카메라가 여러개 있어도 가장 먼저 찾는 놈을 리턴하도록 처리되겠다.
NiCamera* pkFoundCamera = FindCamera(pkNode->GetAt(ui));
if (pkFoundCamera)
return pkFoundCamera;
}
}
}

반응형

+ Recent posts