Try & Error

NiApplication의 멤버변수 NiRendererPtr  m_spRenderer 
는 DX의 디바이스가 생성되면서 할당되어지는 스마트 포인터이다.

하지만 m_spRenderer로 직접 DX제어에 접근할 수는 없다., 즉 디바이스를 얻어올수는 없다.
따라서 다른 수가 필요한데

NiRenderer* pNiRender = m_spRenderer;             // 로 NIRender포인터에 넣어두고
NiDX9Renderer* pDX9Render = (NiDX9Renderer*)pNiRenderer; // 로 형변환 시킨다.

그럼 직접 접근할 수 있다.

pDX9Renderer->GetD3DDevice();  // 로 얻어올수 있다.

충돌정보를 넣어줄 노드는 임시로 NiNodePtr spNiNode; 로 한다~

우선은 바운드 박스로 한다!

NiBoxBV* CollisionBox;
CollisionBox = NiNew NiBoxBV();
CollisionBox->SetCenter(NiPoint3(5.0f,5.0f,5.0f));//바운드박스의 중앙을 잡는다.

바운드 박스의 사이즈 설정
CollisionBox->SetExtent(0, 10.0f);
CollisionBox->SetExtent(1, 10.0f);
CollisionBox->SetExtent(2, 10.0f);

 

여기까지 바운드박스 설정을 한후 충돌데이터에 링크 시킨다.
NiCollisionData *pCollisionData;

 

추가 시켜야할 노드의 정보로 충돌 데이터 생성한다.
pCollisionData = NiNew NiCollisionData(spNiNode);
pCollisionData->SetModelSpaceABV(CollisionBox);//위에서 만든 충돌박스 링크!

 

충돌방식에 대해 세팅한다.
pCollisionData->SetPropagationMode(NiCollisionData::PROPAGATE_NAVER);//콜백을 호출하기 위한 정보 세팅
pCollisionData->SetCollisionMode(NiCollisionData::USE_ABV);//ABV형식의 충돌검사를 한다는거?

 

이로서 충돌 데이터는 완성이다 이제 링크다
spNiNode->SetCollisionObject(pCollisionData);

 

이 박스의 와이어 프레임출력하고 싶을 시에는 박스정보를 이용해 색상을 설정하여 노드를 생성한다.
NiNode* CollisionBoundBox = NiDrawableBV::CreateWireframeBV(CollisionBox, NiColor(0.0f,1.0f,0.0f),1);

 

이걸 노드에 Attach!!!!
spNiNode->AttachChild(CollisionBoundBox);

 

이제 완성된 노드를 업데이트 시키면 된다아...
spNiNode->Update(0.0f);
spNiNode->UpdateProperties();
spNiNode->UpdateEffects();

 

이 노드를 CollisionGroup의 Collider이나 Collidee로 추가후

FindCollisions을 호출시 충돌이 일어나면 연결된 함수 포인터로 넘어간다.

 

...다른 좋은방법 아시는분 설명좀...;

출처 : http://tong.nate.com/ddpstddpst/mymaintong

기본적으로 랜더러는 여러개 생성이 되질 않으므로 하나의 랜더러를 가지고 카메라를 바꿔가며

 

여러창에 랜더링을 해주어야 한다.

 

그것을 위해 제공되는 아주 편리한 메소드가 있더라!

 

CreateSwapChainRenderTargetGroup(0, 윈도우핸들)

 

이것이다.

 

이것을 사용하게 되면 현 윈도우 핸들에 맞춰서 하나의 RenderTargetGroup이 리턴 된다.

 

문제점이 있다면 랜더타켓을 생성만 해주기 때문에 현재 랜더러 해상도에 맞춰서 랜더타켓이 생성이 된다.

 

만약 윈도우 사이즈가 변경이 된다면 랜더러의 해상도를 바꿔주면서 현재 랜더타켓을 삭제하고 다시금 랜더타켓

 

을 생성해야 하는 비효율적인 일을 해야한다.

 

GetSwapChainRenderTargetGroup(윈도우 핸들)

 

위의 메소드는 생성된 랜더타켓을 윈도우핸들을 인자로 받아 그게 맞는 랜더타켓을 리턴받게 된다.

 

이제 실제 랜더를 할때는 생성한 랜더타켓을 이용해

 

BeginUsingRenderTargetGroup(랜더타켓, 초기화)

 

//여기에 랜더링~

 

EndUsingRenderTargetGroup()

 

이후 디스플레이 시켜주면 끝이다.

 

툴에 4방향 랜더링 할때 유용할듯..

출처 : Tong - The_Ruins님의 GameBryo Engine통

1) Lists(NiTPointerList)
- 포인터나 스마트 포인터 또는 포인터 크기만하거나 더 작은 다른 요소를 저장하고 관리할 수 있다.
- 어떤 요소에서든 삽입/삭제가 효과적.
- 모든 요소를 통해 전/후 반복(iteration)이 효과적.
- 리스트를 검색해서 주어진 값으로 된 요소의 존재와 위치를 찾을 수 있다.
- NiTPointerList의 아이템들은 공유 pool로부터 블록으로 할당되므로, 처리 속도가 빨라지고 메모리 효율적으로 됨.
- 포인터보다 큰 오브젝트들의 리스트에는 NiTObjectList를 사용.

2) Array(NiTArray)
- 거의 모든 타입의 객체가 들어있는 동적 배열을 구현함.
- 이 배열은 늘어나거나 줄어들 수 있으며, 필요하다면 압축(빈 공간을 없애기 위해 요소들을 시프트(shift)시킴)할 수도 있다.
- 고유 타입(char*, float, int 등)에는 NiTPrimitiveArray 사용
- NiMemObject에서 파생한 타입에는 NiTObjectArray 사용.
- 요소의 개수는 65535개로 제한.
  (그 이상을 사용하려면 NiTLargePrimitiveArray나 NiTLargeObjectArray같은 NiTLargeArray 파생 클래스 사용.)

3) Map(NiTPointerMap)
- ("사전"이라고도 알려진) 해시 테이블(hash-table)기능을 구현하여, 어떤 유형의 키든..포인터나 스마트 포인터 또는 포인터 크기만하거나 더 작은 다른 타입의 요소에 맵핑하게 해줌.
- 이 객체를 사용하면 키와 값으로 이루어진 쌍의 저장이나 검색(lookup)이 빨라짐.
- 캐릭터의 문자열키 해시 테이블에는 사용 X(NiTStringPointerMap을 사용)
- NiTPointerMap과 NiTStringPointerMap의 아이템들은 공유 pool로부터 블록으로 할당되므로, 이 클래스의 처리 속도가 빨라지고 메모리 효율적으로 됨.
- 포인터보다 큰 오브젝트들의 맵에는 NiTMap이나 NiTStringMap을 사용.

4) StringMap
- NiTStringMap과 NiTStringPointerMap 객체는 NiTMap 및 NiTPointerMap 객체와 비슷한 방식으로 기능하지만 character string을 키로 받아들이며, 키 해싱(key hashing)을 위해 문자열을 비교함.

5) FixedStringMap(NiTFixedStringMap)
- NiTMap 객체와 비슷한 방식으로 기능하나 NiFixedString 객체를 키로 받아들임.

6) Queue(NiTQueue)
- 거의 모든 타입의 객체에 대한 선입선출(FIFO) 큐를 구현함.
- 스마트 포인터는 지원되지 않음.

7) Set(NiTSet)
- 거의 모든 타입의 객체에 대한 순서 없는 세트를 구현.
- 스마트 포인터는 지원되지 않음.
- 고유 타입(char*, float, int, 등)에는 NiTPrimitiveSet을 사용
- NiMemObject에서 파생한 타입에는 NiTObjectSet을 사용
- 오브젝트의 스마트 포인터에는 레퍼런스 카운트를 올바르게 처리하는 NiTObjectPtrSet이나 NiTPrimitivePtrSet을 사용.

8) Pool(NiTPool)
- 작은 객체들의 pool을 구현.
- 이렇게 하면 어플리케이션은 작은 객체들을 개별적으로 할당/해제하기 보단, 이 객체들을 한꺼번에 할당하고 pool을 통해 재사용할 수 있게 됨.