GearObjectPool

GoW2 에서는 사용되는 효과를 효율적으로 사용하기 위한 클래스이다.

효과와 관련된 인스턴스를 미리 여러개 할당하여 놓고 (캐싱) 재활용하는 방식의 도움 클래스라고 할 수 있다.

언리얼엔진3 에서 생성/소멸 관련 함수를 빈번히 호출하는 것을 가급적 피하라고 UDN 문서에서는 명시하고 있다.

때문에 이 루틴을 적극적으로 활용하는 것이 프레임 향상에 도움이 되겠다.

구성

GearObjectPool 이 캐싱해 놓는 대상은 다음과 같다.

  • KActorSpawnable
  • GearProj_BulletTracer
  • ParticleSystemComponent
  • Emitter
  • GearDecal

위 리스트가 핵심이고 별 중요치 않은 것들로는 아래와 같은것들도 있다.

  • RainDropEmitter
  • HailImpactPawnEmitter
  • ActionReload 용 MaterialInstanceConstant
  • PathConstraint

간략한 스샷 한장

5348341259_7b05ab6d9b_o.jpg

Emitter vs ParticleSystemComponent

위의 구성 중에 Emitter 를 캐싱해 두는 녀석이 있는데 이 녀석은 내부적으로 두가지를 캐시해 둔다.

EmitterParticleSystemComponent (이하 PSC) 이다. 이 둘은 같은 기능을 하면서 실질적으로는 다른데 이점을 글로 정리해 둔다.

PSC

  • 파티클 입자 운동을 하는 기본 구성
  • 혼자서는 보여질 수 없는 개체인 Component 이다. Actor 에 Attach 되는 것을 목적으로 함.

Emitter

  • 내부적으로 PSC 를 가지고 있다.
  • 맵 내부에 존재할 수 있는 Actor 이다. PSC 를 위한 특화된 Actor 라고 생각하면 된다.

정리

간단히 말해 Emitter 는 PSC 까지 포함하고 있다고 생각하면 된다.

GearObjectPool 에서 캐시해둔 Emitter 를 얻어올 땐 위치와 회전값까지 지정하지만 PSC 는 그냥 객체만 얻어온다. 얻어온 후 그것을 어떠한 Actor 에게 붙이는 지는 순전히 프로그래머의 몫이다.

흐름

GearObjectPool 이 다루는 객체들을 거의 비슷하게 관리한다.

  1. 초기에 다량의 객체들을 배열로 잡고 미리 할당해둔다.
  2. 순차적으로 인덱스를 늘려가면서 사용한다.
  3. 인덱스가 배열 크기를 넘어서면 다시 0번 인덱스부터 다시 사용한다.

보시다시피 순차적으로 모두 사용하면 다시 처음부터 사용하는 방식이다.

Decal 은 약간 다른 방식으로 관리하는데 방식은 다음과 같다.

  1. 너무 가까운 곳에 같은 Decal 을 다시 출력하려고 하면 제낀다. (비쥬얼적으로 별 차이가 없다는 근거하에)
  2. 가장 오래전에 랜더링된 놈을 찾아서 재활용한다.
  3. 가장 오래전에 랜더링된 놈을 찾지 못했다면1) 가장 오래전에 스폰된 놈을 찾아서 재활용한다.

참조

1) 이 경우는 모든 Decal 이 현재 랜더링되고 있거나 BSP 위에 남겨진 Decal 이라는 의미