Anatomy of Nebula3 - Terms


Anatomy of Nebula3 - Terms


Nebula3는 Nebula2에 비해서 훨씬 더 많은 클래스들로 구성이 되어 있다. (하지만 실제 코드의 라인수는 훨씬 적다.) 또 새로운 클래스들이 많기 때문에 다소 생소한 부분도 많다. 이들 클래스들 간의 관계를 잘 살펴서 이해하면 전체적인 구조를 쉽게 파악할 수있다. 이 글에서는 이들 클래스들 중에서 비슷한 이름으로 헷갈리기 쉽거나 파악이 모호한 것들의 관계에 대해서 설명한다.


1. Render Layer

여기에서는 Nebula3의 세가지 레이어 중에서 Render Layer에 속하는 클래스들에 대해서 설명한다.

DisplayDevice와 RenderDevice의 구분


디스플레이 디바이스는 윈도우의 창, 렌더 디바이스는 렌더링 드라이버와 관련한 것으로 win32에서는 Direct3D 디바이스를 캡슐화한 것이다. 렌더 디바이스는 자신의 백버퍼의 내요을 디스플레이 디바이스에 출력하는 처리를 한다.

Stage와 View의 구분


stage는 전체 장면을 구성하는 모든 엔티티들을 포함하는 것으로 무대의 의미로 이해할 수 있다. view는 현재 카메라로 컬링된 장면을포함한다. 즉, view는 stage에서 컬링을 통해서 현재 카메라를 통해서 보이는 엔티티들, 다시 이야기하면 렌더링해야 하는객체들을 포함한다.

Model과 Resource의 구분

Model은 Resouce 클래스를 상속하는 클래스로 Resoucre의 하위 개념이다. 즉, 리소스의 하나로 생각할 수 있는데 리소스중에서도 렌더링과 관련한 리소스가 바로 Model이다. Model은 렌더링할 객체를 위한 템플릿으로 사용된다.

namespace Models
{
class Model : public Resources::Resource
{
    ...
};
}


Model과 ModelNode의 구분


Model은 렌더링할 객체를 위한 템플릿으로 파일 등으로 리소스를 읽으면 하나 이상의 ModelNode를 가진다. 파일로부터 리소스를읽어 들였다고 바로 렌더링하는 것이 아니라 Model은 ModelInstance를 생성하고 생성한 ModelInstance를 렌더링에 사용한다.

ModelNode와 같이 -Node의 이름을 가지는 클래스들은 장면 구성을 위한 변환(Transform) 정보를 가지며, 장면 처리를 위해서 계층(Hierarchy)을 구성할 수 있다.

ModelNode과 ModelNodeIntance의 구분


Nebula에서의 Node는 장면(Scene) 트리를 구성하는 트리의 노드를 의미한다. 즉, 렌더링과 관련되는 것이다.

ModelNode - 리소스의 관점, 직접 렌더링하지 않는다. 읽어 들인 Node를 렌더링하기 위해서는 Instance를 생성해야 한다.

읽어 들인 Model을 렌더링하기 위해서는 적어도 하나 이상의 ModelInstance가 필요한데 이 ModelInstance는 Model 클래스 객체가 생성한다.


Ptr<ModelInstance> modelInstance = model->CreateInstance();


ModelNodeInstance는 렌더링 인스턴스로 매 프레임마다 갱신해야 하는 처리는 멤버 함수 Update() 함수 내에서 처리한다.

namespace Model
{
class ModelNodeInstance :  : public Core::RefCounted
{
    ...
    // 매 프레임마다 호출된다.
    virtual void Update();
    ...
};
}



(계속...)

by kimsama | 2009/03/24 16:24 | Nebula3 | 트랙백 | 덧글(0)

Unity3D Windows

Unity3D 2.5 윈도우즈 버전이 나왔습니다. 그 동안 관심은 있었는데 Mac이 없어서 그림의 떡이었던 분들은 한번 트라이해 보시길~

저도 지금 막 설치했습니다. ^^

Unity3D 2.5 다운로드 (이메일 주소를 기입하고 windows 버전을 다운 받으면 됩니다)

by kimsama | 2009/03/19 11:17 | Development | 트랙백 | 덧글(1)

ShaderX 인세

이 맘때면 ShaderX의 인세가 도착합니다. 올 해에도 어김없이 우편이 왔습니다만... $19.45 군요. ㅡㅡ;

$25 미만의 금액은 수표가 발행 되지 않기 때문에 올해 인세는 그냥 떡 사먹은 셈 쳐야 겠습니다. 쩝.

내년에도 그냥 우편물만 받을 가능성이 거의 100%일듯 한데 말입니다....

그렇게 보면 딱 두 해 정도 약발이 있다고 생각해야 겠군요. ㅎ

by kimsama | 2009/03/18 11:20 | General | 트랙백 | 덧글(1)

아키텍트

류한석 소장님의 블로그에 좋은 글이 올라 왔네요.


아키텍트의 자질을 얘기하면서는 “지혜가 없는 탁월함은 의미가 없다, 1)복잡성을 단순성으로 만드는 것이 핵심이다, 2)‘어떻게’가아니라 ‘왜’라는 질문이 중요하다, 감동이 액션을 만들고 이성이 결과를 만든다, 팀원들과 MBTI 검사를 해보자(저는 애니어그램검사를 추천했음)” 등의 얘기도 했고요. 어쨌든 기술, 철학, 커뮤니케이션 스킬 등 다양한 내용을 얘기하고 있습니다.


1)과 2)에 대해서는 오픈 소스 프로젝트 때문에  많이 공감하는 부분입니다.

Nebula Device는 1)에 대한 내용은 엔진 자체가 보여주는 것이라서 쉽게 알 수 있는 부분이지만 2)의 경우에는 겉으로 드러나지 않아 쉬이 알 수 있는 부분은 아닌 것 같습니다. 어려움을 토로하시는 분들은 아마도 2)에 대한 부분이겠지요.

이 블로그도 2)에 대한 나침반 역할이 목적인데 아직도 부족함을 많이 느낍니다.

by kimsama | 2009/03/18 11:11 | Development | 트랙백 | 덧글(0)

Nebula2 - 캐릭터 애니메이션 워크 플로우

이전 포스팅에서 엔진 및 미들웨어 별 캐릭터 워크 플로우에 대해서 이야기한 적이 있습니다.

Nebula2에서는 하나의 애니메이션 파일에 캐릭터의 모든 애니메이션들이 포함되어 있어야 하므로 개발시 새로운 애니메이션 등이 추가될 때 번거로운 점이 있다고 언급했는데 최근에 소스 코드를 보다고 이미 그러한 부분에 대한 코드가 있다는 것을 발견했습니다. 코드는 업데이트 되었지만 부실한(?) 문서와 관련 샘플이 없는 관계로 눈치채지 못했던 것이지요.

Nebula2에서는 nSkinAnimator 대신 nCharacter3Animator 를 이용하면 애니메이션 파일들을 순차적으로 로딩하면서 병합하여 사용할 수 있습니다. 즉, 작업은 개별 애니메이션 파일이 수정되거나 추가될 때마다 지정된 폴더 내로 애니메이션 파일만 추가하면 되며, 엔진에서는 실제로 nCharacter3Animator의 애니메이션을 읽어 들일 때, 해당 폴더의 모든 애니메이션들을 차례로 읽어 들이면서 병합해서 새로운 애니메이션 데이터를 생성합니다. 나머지는 기존의 nSkinAnimator 와 동일하며 차이가 없습니다.

실제로 nCharacter3SkinAnimator::LoadResources() 함수를 살펴 보면 nCombinedAnimation 클래스로 메모리의 애니메이션 파일 객체들을 병합하는 코드를 볼 수 있습니다.

그런데 애니메이션 데이터의 용량이 큰 경우에는 아무래도 이런 방법으로는 처리가 힘듭니다. 이 경우에는 좀 더 지능적인 스트리밍이 필요한데, Nebula2에서의 리소스 관리는 스트리밍 부분은 지원이 약하죠. (Nebula3에서는 모든 리소스에 대한 스트리밍 지원이 기본적으로 지원됩니다)

 nCharacter2SkinAnimator 의 경우 현재 3dsmax 플러그인에서는 지원하고 있지 않습니다만 회사 일도 있고 하니 조만간 업데이트가 이루어지리라 생각합니다. ^^


by kimsama | 2009/03/15 15:11 | Nebula Device | 트랙백 | 덧글(0)

Best Fit


John Ratcliff's Best Fit code

John Ratcliff씨가 자신의 블로그에 충돌 볼륨 계산에 유용하게 사용할 수 있는 볼륨 계산 코드를 올려 놓았습니다.

Best Fit이라는 제목에 걸맞는 멋진 사진과 함께 말입니다. ^^



월드 에디터 등에서 게임 asset들을 임포팅할 때 그래픽 데이터를 임포팅한 다후에 충돌 볼륨을 위한 다른 설정이 필요한 경우가 많은데 Best Fit 루틴 등으로 기본적인 충돌 볼륨을 자동으로 계산해서 바로 시뮬레이션할 수 있도록 하면 편리하겠죠.

망갈로도 두 asset들의 설정이 따로 분리가 되어 있는데 사실 프로그래머 입장에서는 꽤나 번거로운 일입니다. 게임의 polishing  단계에서는 최적화된 충돌 볼륨을 따로 사용해야 하겠지만 일반적인 게임 플레이 코드를 작성하는데에는 러프한 충돌 볼륨으로도 충분합니다. 그런데도 이런 장치가 없으면 충돌 볼륨의 설정 등에 시간을 뺏기게 되는데 의외로 많은 그 시간이 만만치 않습니다. 게다가 이런류의 작업은 짜증을 동반한 스트레스도 함께 유발하죠.

ps. 이 분은 포스팅시 반드시 이미지를 하나씩 첨부하는데요, 간간히 포스팅의 이미지를 보면 굉장한 센스쟁이십니다. ㅋ

by kimsama | 2009/03/15 14:20 | Development | 트랙백 | 덧글(0)

◀ 이전 페이지다음 페이지 ▶