???? 나이아가라의 확장성 및 모범 사례

이 문서에 요약된 전략들의 주 목표는 개별 및 총체적 수준에서 파티클 시스템이 수행하는 작업량을 줄이는 것입니다. 첫 번째 튜토리얼의 지침을 통해 추가 작업이 어디에서 발생하는지 파악할 수 있으며, 이 튜토리얼은 해당 영역에서 변경 작업을 수행하는 도구와 옵션을 제공합니다. 일반적으로 작업량을 줄일 때, 불필요한 작업을 피하거나 오버헤드가 적은 해결책을 선택할 수 있습니다.

 

 

 

인스턴스 개수: 레벨 내 시스템 개수 줄이기

최적화된 시스템이라 할지라도 레벨에 충분히 많은 수가 있다면 성능에 영향을 미칠 수 있습니다. 기본적으로 우리는 `Niagara World Manager`를 사용하여 동일한 시스템의 인스턴스를 일괄적으로 틱(tick)하지만, 시스템의 인스턴스가 많을수록 게임 스레드(Game Thread)에서 수행해야 하는 작업이 늘어납니다. 일반적으로, 동일한 수의 파티클을 더 많은 인스턴스에 걸쳐 시뮬레이션하는 것은 수행되는 작업량 측면에서 성능이 떨어집니다. 하지만 인스턴스가 많으면 나이아가라가 파티클을 더 세밀한 수준에서 컬링(cull)할 수 있으므로, 소수의 대규모 인스턴스와 다수의 소규모 인스턴스 간에는 상충 관계가 있습니다.

 

인스턴스 개수 감소 전략

전반적으로 레벨에 스폰하는 시스템의 수를 제어하거나, 스폰된 후 더 적극적으로 컬링함으로써 인스턴스 수를 줄일 수 있습니다. 두 접근 방식 모두 장점이 있으며, 우리는 둘 다를 위한 도구를 제공하지만, 일반적으로 프로젝트를 위한 일부 핵심 이펙트 유형(Effect Types)을 설정하고 모든 나이아가라 시스템에 하나씩 할당하는 것으로 시작하는 것이 가장 좋습니다.

 

 

확장성 및 이펙트 유형

나이아가라는 이펙트 유형(Effect Type) 에셋을 포함하여 재사용 가능한 자산을 통해 다양한 확장성 옵션을 제공합니다. 이 에셋은 모든 시스템에 적용할 수 있으며, 나이아가라 에셋 내에서 시스템, 이미터 및 렌더러 수준에서 직접 재정의(override)할 수 있습니다. 이를 통해 Medium, High, Epic과 같은 확장성 수준과 플랫폼별로 제어할 수 있으므로, 프로젝트가 대상으로 하는 각 플랫폼에 따라 각 수준이 의미하는 바를 다르게 설정할 수 있습니다. 이러한 설정 중 다수는 컬링을 통해 레벨의 나이아가라 시스템 인스턴스 수를 줄이지만, 스폰되는 파티클 수를 줄이거나, 비용이 많이 드는 렌더러를 비활성화하거나, 이미터와 시스템 전체를 비활성화하는 데에도 사용될 수 있습니다.

 

 

서비스로서의 시스템 (System as a Service)

인스턴스 수를 줄이는 또 다른 접근 방식은 이미 존재하는 시스템을 최대한 활용하는 것입니다. 투사체(projectiles)나 충돌(impacts)과 같은 파티클 효과의 경우, 집중된 영역에서 짧은 시간 안에 여러 인스턴스가 스폰되는 것이 일반적입니다. 여기서 풀링(Pooling)을 활용하여 이 인스턴스들에 대한 컴포넌트 재할당을 방지할 수 있지만, 이를 재활성화하는 데에는 여전히 오버헤드가 있으며, 이전 인스턴스가 완료되어 풀로 반환되는 것에 의존합니다. '서비스로서의 시스템(System as a Service)' 접근 방식은 레벨에 새로운 시스템을 추가하는 대신 기존 시스템에 새로운 파티클을 추가하는 것을 목표로 합니다. 5.4 버전은 이 워크플로우를 간소화하는 새로운 기능을 도입하고 있으며, 이전 버전에서는 대신 사용자 파라미터(User Parameters)를 사용할 수 있습니다. 이 전략은 다음 튜토리얼에서 더 자세히 다루어질 예정입니다.

 

 

이미터 개수: 에셋 수준에서 오버헤드 줄이기

나이아가라 시스템을 구축할 때, 특히 캐스케이드(Cascade)의 패러다임에서 전환하는 경우, 시스템에 포함되는 고유한 시각적 요소나 미묘한 동작 변화를 위해 새로운 이미터를 추가하는 것이 자연스러울 수 있습니다. 그러나 모든 이미터에는 관련 오버헤드가 있으므로 이는 성능에 부정적인 영향을 미칠 수 있습니다.

나이아가라는 CPU에서 스크립트를 실행하기 위해 가상 머신(Virtual Machine, VM)을 사용합니다. 이는 확장성과 병렬화라는 두 가지 주요 이유 때문입니다. GPU의 SIMD 특성을 모방하는 VM을 통해 모든 나이아가라 스크립트가 기본적으로 CPU와 GPU 모두에서 작동할 수 있습니다. 처음부터 스크립트로 구축하면 사용자가 자체 스크립트를 생성하려는 진입 장벽이 낮아져 확장성이 향상되며, SIMD를 위해 설계하면 나이아가라가 CPU에서 실행을 더 쉽게 병렬화할 수 있습니다.

이 VM의 단점은 모든 이미터와 관련된 오버헤드입니다. 파티클 시뮬레이션을 GPU로 대상으로 지정하는 경우에도, 게임 스레드와 상호 작용할 수 있도록 시스템 및 이미터 스크립트는 여전히 CPU에서 실행됩니다. 이는 오버헤드가 고정되어 있으며, 이를 피할 수 있는 유일한 방법은 시스템 내의 이미터 수 또는 레벨 내의 인스턴스 수를 줄이는 것입니다.

5.4 버전에는 확장성 및 기타 기능을 희생하고 성능을 우선하는 실험적인 경량 이미터(Lightweight Emitters)가 있습니다. 향후 버전에서는 이러한 이미터가 VM 오버헤드가 없으므로 이미터 수를 줄이는 데 있어 많은 사용 사례에서 실행 가능한 대안이 될 것입니다.

 

 

완화 전략 (Mitigation Strategies)

다음은 시스템 내 이미터 수를 줄이는 데 사용할 수 있는 몇 가지 전략입니다. 일반적인 아이디어는 시뮬레이션 동작이 거의 동일하고 유일한 차이점이 시각적 요소(렌더러) 또는 시작 위치와 같은 초기화 데이터인 경우, 이를 통합하는 것입니다.

스폰 인덱스(Spawn Index): 스폰 인덱스는 동일한 동작이나 시작 데이터를 갖는 파티클 그룹을 이미터 내에서 생성하는 데 사용될 수 있습니다. 파티클은 스폰 인덱스를 파라미터로 저장하며, 이는 나이아가라 스크립트에서 다른 데이터를 동적으로 선택하는 데 사용될 수 있습니다. 일반적인 예시는 메시의 다른 섹션을 샘플링하기 위한 그룹을 생성하는 것입니다. (예: 포트나이트(Fortnite)에서 캐릭터의 손과 발에서 샘플링하는 콘트레일(contrail) 효과. 캐스케이드에서는 트레일마다 하나의 이미터가 생성되었지만, 나이아가라에서는 전체 효과에 대해 하나의 이미터가 생성되며, 각각 캐릭터 스켈레톤의 다른 본이나 소켓을 샘플링하도록 설정된 네 개의 스폰 그룹이 있습니다.)
다중 렌더러(Multiple Renderers): 나이아가라를 사용하면 단일 이미터가 여러 개의 렌더러를 가질 수 있으므로, 이미터가 시뮬레이션하는 각 파티클에서 여러 시각적 요소를 생성할 수 있습니다. 일반적인 사용 사례는 라이트 렌더러를 스프라이트 또는 메시 렌더러와 결합하여 파티클이 빛을 방출하면서 관련 지오메트리도 갖도록 하는 것입니다.
메시 렌더러(Mesh Renderers): 메시 렌더러는 지정할 메시의 배열을 허용하며, 배열에서 렌더링할 메시를 제어하는 메시 인덱스 바인딩을 가집니다. 이는 렌더러를 복제하고 활성화/비활성화를 설정할 필요 없이 더 다양한 메시 모양을 갖기 위해 다중 렌더러 대신 사용될 수 있습니다.

 

 

풀링: 메모리 관리 및 할당 감소

나이아가라 함수 라이브러리는 `Spawn System at Location` 및 `Spawn System Attached`를 통해 시스템을 스폰할 때 풀링(Pooling) 방법을 선택할 수 있도록 합니다. 풀링되면 동일한 에셋을 기반으로 하는 나이아가라 컴포넌트는 일반적인 방식처럼 할당되고 가비지 컬렉션되지 않습니다. 대신, 더 이상 사용되지 않는 할당된 컴포넌트 풀이 유지되며, 동일한 에셋을 사용하는 새 컴포넌트를 스폰할 때 재사용됩니다. 이는 자주 사용되는 컴포넌트에 대한 할당 및 가비지 컬렉션 비용을 피합니다.

나이아가라 시스템은 성능 아래의 시스템 속성에서 풀 크기와 프라이밍(Priming)을 제어할 수 있습니다. 풀을 프라이밍하면 런타임 할당을 줄일 수 있지만, 에셋이 동적으로 로드되는 경우 히치(hitch)를 유발할 수 있습니다.

 

 

시뮬레이션 비용: 나이아가라 스크립트 최적화 (GPU 대 CPU)

이미터 개수 오버헤드 섹션에서 언급했듯이, 모든 나이아가라 시뮬레이션에는 CPU 오버헤드가 있습니다. CPU 시뮬레이션과 GPU 시뮬레이션을 선택하는 것은 파티클 시뮬레이션의 대상만 변경하며, 이미터에 선택된 Sim Target에 따라 Particle Spawn, Particle Update, Simulation Stages의 스크립트만 변경됩니다.

파티클 스크립트는 병렬화 기회가 가장 크므로 GPU를 대상으로 할 때 가장 큰 이점을 얻으며, 대부분의 경우 GPU 시뮬레이션이 더 높은 성능을 제공하고 더 많은 수의 파티클을 허용합니다. 파티클 수가 적은 이미터의 경우 CPU 시뮬레이션이 더 적합할 수 있습니다. (GPU 리소스를 세밀하게 나눌 수 없기 때문에 1개 파티클의 시뮬레이션이 잠재적으로 64개 파티클과 동일한 리소스를 차지할 수 있습니다.)

일부 프로젝트와 플랫폼에서는 GPU가 병목 현상인 경우가 있으며, CPU 시뮬레이션이 더 적합할 수 있다는 점에 유의하는 것도 중요합니다. 이는 모바일과 같이 GPU 메모리가 적은 플랫폼에서 특히 흔합니다. 반대로, CPU 바운드 프로젝트는 파티클 수가 적더라도 시뮬레이션을 GPU로 옮기는 것이 여전히 도움이 될 수 있습니다. 이는 프로젝트를 개발할 때 이러한 성능 가정을 검증하는 것이 중요한 여러 이유 중 하나입니다.

 

 

기타 모범 사례 (Miscellaneous Best Practices)

프로젝트를 프로파일링(Profiling)하면 병목 현상이 어디에 있는지에 대한 가장 구체적인 데이터를 얻을 수 있으며, 성능 문제를 찾는 가장 좋은 방법입니다. 하지만 모범 사례는 콘텐츠 제작 중에 흔하거나 놓치기 쉬운 실수를 피하는 데 큰 도움이 될 수 있습니다.

 

 

 

 

 

 

 

 

 

에반 언리얼5 이펙트 그룹과정[12월 시작] : https://cafe.naver.com/unrealfx/20727

KUPAFX Stylized 유니티 이펙트 취업과정 : https://cafe.naver.com/unrealfx/21249

트리키 언리얼+후디니 활용 게임 VFX 연출과정 : https://cafe.naver.com/unrealfx/25629

 

max님의 쌩기초 메쉬활용 이펙트과정 1달특강 : https://cafe.naver.com/unrealfx/24469

eVan텍스쳐 단품과정 : https://cafe.naver.com/unrealfx/24468

rak 유니티 UI연출이펙트 : https://gamefx.co.kr/bbs/page.php?hid=Rak_intro