결과 구하기

캐스케이드의 코어 시스템 - GPU/게임 스레드/렌더 스레드

캐스케이드는 UE4 의 코어 엔진 시스템인 게임 스레드, 렌더 스레드, GPU 에 걸쳐 동적으로 비용을 분산시키는 탄탄한 파티클 시스템을 만들어 냅니다.

• 파티클 시뮬레이션 시간 (틱) 은 게임 스레드에서 계산됩니다. (gamethread)
• 파티클 데이터 마무리(지오메트리 패킹, 드로 콜 따위)는 렌더 스레드에서 계산됩니다.
• 파티클 비주얼(셰이더 복잡도, 오버드로 등)은 GPU 에서 계산됩니다.

이러한 시스템 모두 서로 병렬적으로 계산되므로, 어느 한 시스템이 지체되면 렌더링 프로세스에 병목현상이 있다는 뜻이고, 프레임율 평균을 떨어뜨리게 됩니다. 즉 캐스케이드 내 파티클 시스템 생성시 세 가지 프로세스 모두 고려하는 것이 중요합니다.

또 한가지, 캐스케이드는 파티클 계산을 게임 스레드에서, 즉 게임플레이가 계산되는 곳과 동일한 곳에서 계산한다는 점을 염두에 두셔야 합니다. 파티클 카운트는 프레임율을 적정 범위 내에 유지시키는 데 매우 중요합니다.

(#OverdrawGraphics)

오버드로 - GPU

스프라이트 표면에 머티리얼을 추가하면, 그 머티리얼에는 인스트럭션 카운트 비용이 생깁니다. 반투명 오브젝트의 경우, 반투명이 중첩될 때마다 오버드로가 생겨 인스트럭션 비용이 올라갑니다. 반투명 레이어가 많을 수록 비용이 높아집니다. 가장 단순한 형태의 오버드로는 다음과 같이 설명할 수 있습니다:

	오버드로 = 픽셀 셰이더 비용 = 레이어 수 * 레이어에 영향받는 픽셀 평균 수 * 레이어에 대한 인스트럭션 평균 수
Copy full snippet

오버드로 = 픽셀 셰이더 비용 = 레이어 수 * 레이어에 영향받는 픽셀 평균 수 * 레이어에 대한 인스트럭션 평균 수

셰이더 복잡도 모드로 보면 쉽게 확인할 수 있지요. 인스트럭션 수가 밝은 빨강은 300, 분홍은 600, 하양은 900 이상입니다. PC 에서 Alt+8 키를 치면 셰이더 복잡도 모드를 볼 수 있습니다.

머티리얼의 인스트럭션 수는 머티리얼 에디터에서 확인할 수 있습니다.

셰이더 복잡도는 한 시스템의 비용 추정치를 출력하지만, 반투명은 불투명 오브젝트 앞에 있을 때도 비용이 있으므로, 그 비용은 씬에 따라 달라지기도 합니다.

이펙트 사용량을 검사하는 것은 중요합니다. 어느 주어진 상황에서 호출가능한 이펙트는 (무기 임팩트 등) 일반적으로 특정 상황에 맞추기 위해 커스텀 빌드할 수 있는 이펙트보다 가벼울 필요가 있습니다. 비용적인 동요가 심한 상황에서 그려질 것이기 때문입니다.

제어 가능한 수준의 오버드로 임팩트를 내기 위해 취해볼 수 있는 방법은:

• 방출(emission) 속도 감소.
• 머티리얼 인스트럭션 수 감소.
• 파티클 스케일 감소 (화면 덜 차지).
• 다양한 뷰 거리에서 비용 절감을 위해 근처/먼거리 파티클 방출용 LOD 생성.
• 일직선으로 배치된 이미터(정적으로 배치된 이펙트)가 서로 중첩되는지 검사.

(#GameThread)

LOD - 레벨 오브 디테일 - GPU/게임 스레드

캐스케이드의 LOD 를 통해 사용자가 플레이어에서 이미터까지의 거리에 따라 모듈과 행위를 제어할 수 있습니다. 파티클 시스템에 있는 특성을 수정하여 LOD 시스템을 활용할 수 있습니다.

LOD 셋업 관련해서 좀 더 기술적인 정보는 캐스케이드 사용 안내서 페이지의 파티클 시스템 레벨 오브 디테일(LOD) 부분을 참고해 주시기 바랍니다.

LOD 를 만들 때 중요한 점 한가지는, 공유되지 않은 모듈에 관련해서는 메모리 비용이 있다는 점입니다. LOD 에 걸쳐 가급적 많은 모듈을 공유하면 메모리 풋프린트를 줄일 수 있습니다. 수정하고픈 특성에 대해서만 고유한 모듈 세팅을 만드시기 바랍니다.

LOD 거리 검사 시간

LOD Distance Check Time 은 게임에서 사용할 LOD 결정을 위해, 플레이어와 씬에 놓인 이미터까지의 거리를 얼마나 자주 검사할지 나타냅니다. LOD Method 가 자동(automatic)으로 설정되어 있을 때 작동합니다.

자동은 본질적으로 게임이 LOD 를 결정하게 만드는 것입니다. LOD Distance Check Time 을 늘리면, 검사 간격이 늘어납니다. LOD Distance Check Time 은 초 단위로 계산되므로, 이 설정을 할 때는 플레이어의 최대 이동 속력을 고려해야 합니다. LOD Distance Check Time 를 0.00 으로 설정하면 매 프레임마다 거리가 계산되어, 퍼포먼스가 낮아질 수 있습니다.

LOD 메서드 - 게임 스레드

LOD Method 의 적절한 세팅은 퍼포먼스와 비주얼에 매우 중요할 수 있습니다.

Automatic (자동) - 게임은 LOD Distance Check Time 세팅을 사용하여 이펙트에 지정된 거리 파라미터에 따라 LOD 를 설정합니다. 전형적으로 루핑되면서 게임 코드로 호출되지는 않는 앰비언트 이펙트(배경 효과)에 사용됩니다.

Direct Set (직접 설정) - 이펙트가 스폰될 때 (보통 게임 코드로) LOD 가 결정된 후 정의된 LOD 에 남아 있습니다. 전형적으로 폭발이나 충격처럼 터지는 이펙트에 사용됩니다.

Activate Automatic (능동형 자동) - 이펙트가 스폰될 때 LOD 에 정의된 거리 파라미터에 따라 LOD 가 결정됩니다. 전형적으로 한 번 스폰되면 절대 바뀔 일이 없는 LOD 를 요하는, 블루프린트 등에 의해 호출되는 폭발 이펙트에 사용됩니다.

고정 vs 비고정 바운드 - 게임 스레드

바운드(경계)는 엔진이 이펙트의 표시여부를 결정하는 방법 중 하나입니다. 이러한 보이지 않는 좌표를 통해 엔진더러 한 이펙트가 시야에 있는지 없는지 일러 줍니다. 바운드의 구석이 보인다면 엔진은 이펙트의 컴포넌트를 필요한 만큼 계산합니다.

바운드는 매 프레임마다의 값비싼 검사와 업데이트이므로, 바운드를 고정되게 설정하고 얼마나 크게 할 지를 결정하는 것이 좋습니다. 어떤 경우에는 바운드를 꽤 크게 잡아 폭발에 흩날리는 파편을 모두 보고 싶을 때가 있습니다. 비용을 낮추려는 경우 바운드를 핵심 컴포넌트에 꼭 맞게 잡으면, 바운드가 시야를 벗어났을 때 이펙트가 튀어나올 수 있다는 위험만 감수하면 퍼포먼스를 높일 수 있습니다.

고정 vs 비고정 바운드에 관해 유의해야 할 고려사항이 약간 있습니다.

로켓 자취나 트레이서나 프로젝타일 같은 것에 붙는 그 무엇이든, 빠르게 움직이는 이펙트는 고정 바운드를 설정하지 말거나, 고정 바운드를 설정하더라도 꽤 크게 하여 이미터가 바운드 밖을 날지 않도록 해야 합니다.

바운드를 설정할 때는 시스템에 정의된 좌표계가 로컬인지 월드인지에 유의하십시오. 이미터가 바운드 반대 방향으로 회전되면, 이펙트의 엘리먼트가 바운드 밖으로 날아가서, 엘리먼트가 뷰 밖으로 튀어나가는 현상이 발생할 수 있습니다.

(#RenderThread)

드로 콜 - 렌더 스레드

파티클 시스템 안의 드로 콜은 가끔 추적하기 까다로울 수 있습니다. 드로 콜 비용을 알아볼 때는 유념해야할 복합적인 요소가 여러가지 있습니다.

스프라이트 파티클 방출은 화면 오리엔테이션과 무관하게 이미터당 1 드로 콜입니다.

메시 방출은 방출된 메시의 갯수와는 상관없이 메시 이미터당 1 드로 콜입니다. 하지만 모바일 디바이스에서는 방출된 메시당 1 드로 콜입니다. 즉 모바일 디바이스에서는 이펙트에 이미터가 둘 있고, 각각 메시를 10 개씩 방출한다면, 그 파티클 시스템에 관련된 총 비용은 20 드로 콜입니다.

머티리얼 패스 역시도 드로 콜 비용을 결정합니다. 머티리얼에 패스가 많을 수록 이펙트의 드로 콜도 늘어납니다.

예를 들어:

• 파티클 시스템 A 구성: 스프라이트를 12 개 스폰하고, 1 패스 머티리얼을 사용하는 이미터가 1 개인 경우, 전체 시스템 비용은 1 드로 입니다.
• 파티클 시스템 B 구성: 스프라이트를 12 개 스폰하고, 2 패스 머티리얼을 사용하는 이미터가 1 개인 경우, 전체 시스템 비용은 2 드로 입니다.
• 파티클 시스템 C 구성: 메시를 12 개 스폰하고, 2 패스 머티리얼을 사용하는 이미터가 1 개인 경우,
  • 모바일 플랫폼에서: 전체 시스템 비용은 24 드로 입니다. (콜 당 2 패스 x 메시마다 드로 콜 하나씩이니 12 메시 = 24 드로)
  • 다른 모든 플랫폼에서: 전체 시스템 비용은 2 드로 입니다.
• 파티클 시스템 D 구성: 메시를 6 개 스폰하고, 2 패스 머티리얼을 사용하는 이미터 하나, 스프라이트를 10 개 스폰하고, 1 패스 머티리얼을 사용하는 이미터도 하나 있는 경우, 전체 시스템 비용은 13 드로 입니다. (콜 당 2 패스 x 6 메시 = 12 드로, 1 패스 x 10 스프라이트 = 1 드로)

패스를 올리는 머티리얼 특성은 다음과 같습니다:

반투명 머티리얼 = 1 패스 베이스

• 디스토션(왜곡)에 +2
• bUseLitTranslucencyDepthPass (라이팅된 반투명 뎁스 패스 사용)에 +1
• bUseLitTranslucencyPostRenderDepthPass (라이팅된 반투명 포스트 렌더 뎁스 패스 사용)에 +1
• bUsedWithFogVolumes (포그 볼륨과 사용됨)에 +2

불투명 / 마스킹된 머티리얼 = 2 패스 베이스

어느 씬에 대한 드로 콜은 DumpParticleFrameRenderingStats 명령으로 확인할 수 있습니다. 이 명령은 드로 콜 비용을 자세히 나열하는 스프레드 시트를 출력합니다.

드로 콜의 영향은 렌더되고 있는 뷰의 수에 비례하여 증가합니다. 즉 분할화면에서는 효과가 배가된다는 뜻입니다. 분할화면에서의 이펙트 최적화하기 관련 상세 정보는 VFX 최적화: 분할화면 페이지를 참고하시기 바랍니다.

이펙트를 구성할 때나 최적화할 때는 이러한 비용을 염두에 두는 것이 중요합니다. 렌더 스레드가 드로 콜때문에 높고, 배경은 예산 내에 있다면 여기서부터 찾아보기 시작하는 것이 좋겠습니다.

메시 방출 - 게임 스레드 / 렌더 스레드

메시 방출은 캐스케이드의 매우 강력한 기능 중 하나입니다. 모바일 디바이스에서는 가끔은 남용되기도 하는 기능인데, 메시 방출 속도가 드로 콜 수에 비례하기 때문입니다. 추가적으로 메시의 버텍스 수를 낮추는 것도 좋은 생각입니다.

어떤 경우엔 단 한 번의 메시 방출로도 커다란 오브젝트 볼륨 흉내를 가짜로 낼 수 있는데, 이를테면 잔해 볼륨을 만드는 데 필요한 잡다한 스프라이트 위치 계산을 할 필요가 없어지는 것입니다.

CPU 콜리전 - 게임 스레드

전형적으로 UE4 에는 파티클 콜리전 관련된 비용이 높기에 필요할 때만 사용해야 합니다.

콜리전 비용을 최소화하기 위해 사용할 수 있는 여러가지 세팅은:

1. MaxCollisions: 이 값은 가급적 낮게 잡으십시오.
2. Collision Completion Option: 이 옵션을 HaltCollisions/Freeze 로 설정하면, MaxCollisions 값에 도달했을 때 씬에 대한 콜리전 검사를 중지합니다.
3. Damping Factor 는 콜리전을 따르는 오브젝트의 튕김을 결정, 값이 낮을 수록 오브젝트를 빨리 쉬게 만들 수 있습니다 (더 낮은 Max Collisions 값).

유닛별 스폰 - GPU/게임 스레드

Spawn Per Unit 은 파티클 시스템이 움직일 때 갭을 메꾸는 데 좋은 캐스케이드 기능입니다. 이 기능이 괜찮아 보이는 파티클 트레일을 만들기에 좋기는 합니다만, 사용할 때는 비주얼양과 퍼포먼스군의 밀땅이 중요합니다!

방출 제어를 위한 팁이 몇 가지 있습니다:

• Unit Scalar 값을 가급적 높게 유지하지만 방출 속도(emission rate) 와 보조를 맞추어, 이펙트를 너무 무겁게 만들지 않는 선에서 원하는 필(fill)을 얻어냅니다.
• Spawn Per Unit 을 사용하여 방출 속도가 높을 것으로 예상되는 경우, 인스트럭션 카운트가 낮은 머티리얼을 사용해 보십시오.
• 방출 가능한 파티클 수를 제한하기 위해 Max Frame Distance 를 조절합니다. 이미터가 이 최대 프레임 거리를 벗어나면, Spawn Per Unit 은 그 거리 안으로 돌아오기 전까지 방출을 중지합니다. 이미터가 씬에 다량의 스프라이트를 쏟아붓는 것을 방지해 줍니다.

메모리 비용

캐스케이드에는 파티클 시스템 정보에 관련된 중요한 정보를 다수 표시해 주는 기능이 있습니다. 이 기능을 켜면 파티클 시스템이 몇이나 할당되어 있는지, 시스템이 파티클을 몇이나 방출하고 있는지에 대한 개념을 잡는데 종종 도움이 됩니다.

Particle Allocation 은 이미터가 일정한 시간에 얼마만큼의 파티클을 월드에 놓을 수 있는지를 결정하며, 파티클 시스템이 얼마만큼의 메모리를 소모할지 결정하는 데 있어 큰 역할을 합니다. 캐스케이드의 보기 드랍다운 메뉴에서 파티클 메모리 보기 옵션을 켜면 메모리 측정치를 볼 수 있습니다.

세팅을 조절하여 메모리 비용 증감을 확인하는 것이 가능합니다.

메모리 풋프린트를 줄이는 방법이 여럿 있는데:

• 시스템의 모듈 갯수를 필요한 행위에 딱 필요한 만큼 줄입니다.
• 루핑 이펙트는 Loop Time/Duration 을(루프당 할당되는 파티클 수를) 줄입니다
• 수명을 (전체적인 파티클 수를) 줄입니다.
• 가급적 많은 모듈을 공유합니다.

캐스케이드에는 한 이미터에서 다음으로 가는 모듈을 공유하는 기능이 있습니다. 이 기능을 사용하면 두 가지 이점이 있습니다. 첫째, 여러 이미터에 걸친 값을 편집하려는 경우, 모듈 하나만 편집해도 다른 모든 세팅을 업데이트할 수 있습니다. 둘째, 모듈을 공유하면 쿠킹된 버전은 그 모듈 비용을 하나의 인스턴스로 치기 때문에 메모리 풋프린트가 줄어듭니다.

좀 더 최근에 쿠커에 추가된 기능은, 파티클 시스템에 있는 모든 모듈을 평가하여 동일한 모듈을 알아낸 다음, 쿠킹 시간에 모듈을 공유하여 메모리 풋프린트를 자동으로 줄이는 것입니다.

틱 시간 - 게임 스레드

Tick Time (틱 시간)은 씬의 파티클 시스템을 업데이트하는 데 걸린 시간입니다. 틱 시간은 stat particles 명령으로 볼 수 있는데, 파티클 평가 비용을 가늠하는 데 필요한 정보를 모두 나열하는 명령입니다.

틱 비용을 줄이는 데 사용할 수 있는 방법은 많이 있습니다.

틱 시간은 씬에 활성인 이미터 액터의 수에 직접적으로 영향받습니다. 씬에 활성 이미터가 많을 수록 틱 시간도 높아집니다. 이미터를 레벨 시작시 루프되게 만들려면 autoActive 로만 설정해야 합니다.

에디터에서 레벨 로드시 다량의 스프라이트/폭발/터지는 이펙트가 보이는 경우, 이러한 이펙트는 실행 시간에 자동으로 평가되며, 레벨이 로드될 때 버벅일 수 있습니다.

이펙트에 파티클 파라미터 를 사용하면, 월드에 이펙트를 놓았을 때 위치 이격(offset)이 가능합니다. 파티클 파라미터를 사용하면 이미터 수를 줄이는 것도 가능하고, 그에 따라 전체적인 틱 비용도 줄어듭니다. 파티클 파라미터는 개별 세팅에 대한 모듈의 분포 목록에서 파티클 파라미터를 선택하여 셋업할 수 있습니다.

이미터 액터가 시야에 있지 않거나 더이상 메모리에 있지 않은 레벨 영역에 관계되어 있을 때는 스트리밍 아웃시키고 끄는 것도 가능합니다. 레벨 지오메트리로 이미터 액터를 스트리밍(대체)하는 것도 틱 부하를 줄이기 좋은 방법입니다. 가끔 대기 효과가 심한 경우, 블루프린트 액션을 사용하여 전투 도중에는 대기 효과를 껐다 켰다 토클시켜 틱 시간과 오버드로를 낮출 수도 있습니다.

메모리에 로드는 되었으나 시야 밖에 (이를테면 위층에) 있는 파티클 시스템 역시도 블루프린트 액션과 스트리밍 볼륨으로 토글시켜 평가 비용을 줄일 수 있습니다.

가끔은 파티클 시스템을 대체하기에 메시 이펙트가 좋을 수 있습니다. 놓인 스태틱 메시는 게임 스레드 상에 평가 비용이 없어, 파티클 시스템 대신 스태틱 메시를 놓는 것이 이로울 때가 많습니다. 비스타(풍경) 이펙트, 포그 이펙트 등도 포함됩니다.

파티클 수는 평가 비용에 직접적인 역할을 합니다. 씬에 파티클이 많을 수록 더 오래 살아남으며, 평가도 더 많이 필요해 집니다. 이펙트에 딱 필요한 만큼으로 수명을 제한시켜 주는 것이야 말로 진리입니다.

파티클 시스템에 LOD 를 켜면 시스템이 최적의 가시 거리에 있지 않을 때의 파티클 방출을 낮출 수 있습니다. 이펙트를 원거리에서 봐 줄 만한 수준의 저품질 상태로 생각해 보면 됩니다. LOD 거리를 필요한 만큼 딱 맞추면 비주얼 퀄리티를 심하게 잃지 않고도 씬의 평가 비용을 훨씬 더 낮출 수 있습니다.

이펙트를 검사하여 콜리전, 비고정 바운드, 너무 높은 스폰 퍼 유닛 카운트 등 낮출 수 있는 비싼 평가 비용을 찾아냅니다. 바운드를 고정 상태로 설정하면 퍼포먼스를 크게 향상시킬 수 있으니, 가능할 때마다 사용해 주어야 하겠습니다.