반응형


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

그냥 발표용인듯.. 

반응형

+ Recent posts