나이아가라의 주요 기능과 장점

캐스케이드와 나이아가라의 차이에서 두 도구가 효과를 구성하는 방식이 어떻게 다른지 비교했습니다. 이번에는 나이아가라 쪽으로 시선을 옮겨, 효과를 이루는 단위와 계산이 실행되는 위치, 게임과 값을 주고받는 방법, 문제를 찾는 도구를 차례로 살펴봅니다. 각 기능이 어떤 이점을 주는지와 함께, 그 이점이 저절로 생기지 않는 조건도 짚어 두면 이후 장에서 설정을 고를 때 판단하기 쉬워집니다.

---

시스템, 이미터, 모듈로 나누어 만든다

나이아가라의 가장 큰 장점은 모듈성입니다. 파티클을 만들고 움직이고 그리는 과정을 작은 단위로 나누어 만들 수 있고, 그 단위를 여러 효과에서 다시 쓸 수 있습니다. 나이아가라의 효과는 다음 네 가지 단위로 이루어집니다.

• 시스템(System): 여러 이미터를 묶어 레벨에 배치하는 효과의 단위입니다.
• 이미터(Emitter): 한 무리의 파티클을 어떻게 만들고 갱신하고 표현할지를 정합니다. 시스템 안에서 연기, 불꽃, 파편처럼 역할을 나누어 맡습니다.
• 모듈(Module): 파티클의 속성을 다루는 작은 기능 단위입니다. 초기 속도를 더하는 Add Velocity, 색에 배율을 곱하는 Scale Color, 한 번에 여러 입자를 만드는 Spawn Burst Instantaneous가 그 예입니다.
• 스크래치 패드(Scratch Pad): 기본 모듈로 부족한 동작을 직접 만드는 공간입니다. 코드를 직접 쓰지 않고 노드를 이어 붙이는 비주얼 스크립팅 방식으로 독특한 파티클 동작을 만들 수 있습니다.

특정 움직임이나 색 변화를 모듈 하나로 만들어 두면, 여러 이미터나 시스템에 붙여 같은 동작을 빠르게 만들 수 있습니다. 한 번 만든 로직을 여러 곳에서 다시 쓰므로 작업 시간이 줄고, 효과마다 동작이 조금씩 달라지는 일도 막을 수 있습니다. 잘 만든 블록을 조합해 여러 모양을 만드는 것과 비슷하지만, 블록과 달리 모듈은 같은 이미터 안에서 위에서 아래로 실행 순서가 있어 순서를 바꾸면 결과도 달라질 수 있습니다.

---

계산을 CPU와 GPU 가운데 어디서 할까

나이아가라는 하드웨어의 병렬 처리 능력을 살릴 수 있도록 데이터 지향 구조로 설계되었습니다. 그렇지만 처리할 수 있는 입자의 수와 프레임 시간은 하드웨어와 모듈, 렌더러, 화면 면적에 따라 달라지므로, 특정 개수를 정해 두고 그만큼은 언제나 괜찮다고 말할 수는 없습니다.

입자의 계산을 GPU로 옮기는 기능이 GPU 시뮬레이션입니다. 이미터의 시뮬레이션 대상(Sim Target)을 GPU Compute Sim으로 바꾸면, 입자를 만들고 갱신하는 계산을 GPU가 맡습니다. 그런데 이것으로 이미터의 모든 일이 GPU로 넘어가는 것은 아닙니다.

위 그림은 일반적인 나이아가라 스크립트 이미터에서 시뮬레이션 대상을 바꿀 때 무엇이 옮겨 가는지 비교합니다. 왼쪽의 CPU Sim에서는 System과 Emitter 스크립트, 그리고 Particle Spawn과 Particle Update, Simulation Stage 같은 입자 스크립트가 모두 CPU 영역에 있습니다. 오른쪽의 GPU Sim에서는 입자 스크립트만 GPU 영역으로 옮겨 가고 System과 Emitter 스크립트는 여전히 CPU에 남습니다. 그래서 GPU로 바꿀 때는 쓰는 모듈과 데이터 인터페이스가 GPU를 지원하는지, 목표 플랫폼에서 GPU 시뮬레이션을 쓸 수 있는지를 확인해야 합니다.

그림 아래쪽은 시뮬레이션 비용과 렌더링 비용을 따로 보라고 말합니다. GPU 시뮬레이션은 이미터 수나 시스템 인스턴스 수에서 오는 CPU 비용을 없애지 않고, 머티리얼과 화면 면적에서 오는 렌더링 비용도 없애지 않습니다. 입자가 적거나 GPU가 이미 병목이라면 CPU 시뮬레이션이 나을 수도 있으므로, 같은 장면과 입자 수, 카메라, 해상도에서 측정해 고릅니다. 이 그림은 실행 대상의 범위를 비교한 것이며, 호출 순서나 실제로 측정한 성능 차트가 아닙니다.

효과의 양을 조절하는 장치로는 스케일러빌리티(Scalability)가 있습니다. 이펙트 타입(Effect Type)과 시스템, 이미터의 설정에서 거리와 가시성, 품질 단계에 따라 효과를 걸러 내거나 생성량을 줄이도록 구성합니다. 아무 설정 없이도 효과의 복잡도가 자동으로 줄어드는 것은 아니며, 메시 하나의 세부 수준을 바꾸는 메시 LOD와 효과 전체의 품질을 제한하는 설정도 서로 다른 것입니다. Epic의 성능 지침은 입자 수와 별도로 이미터 수 자체에도 CPU 비용이 든다고 설명합니다.

---

게임과 값을 주고받는다

나이아가라는 파티클을 만들고 움직이는 데서 그치지 않고, 게임 플레이와 값을 주고받으며 반응할 수 있습니다. 캐릭터의 이동 속도, 피격 여부, 닿은 물체의 재질, 날씨 같은 게임 안의 데이터를 플레이 중에 파티클 시스템에 넘기면, 그 값에 따라 파티클의 동작과 모양이 바뀝니다. 예를 들어 캐릭터가 달릴 때만 먼지를 더 많이 일으키거나, 물속에 들어가면 입자의 밀도를 바꿀 수 있습니다.

기본 모듈로 원하는 동작을 만들 수 없을 때는 나이아가라의 비주얼 스크립팅으로 로직을 직접 만듭니다. C++을 몰라도 노드로 동작을 만들 수 있으므로, 아티스트가 프로그래머를 기다리지 않고 아이디어를 바로 시험해 볼 수 있습니다.

한 이미터에서 일어난 일을 다른 이미터에 알리는 이벤트 방식도 있습니다. 한 이미터에서 충돌이나 수명 종료 같은 이벤트가 생기면, 다른 이미터의 이벤트 핸들러(Event Handler)가 이를 받아 그 자리에 입자를 더 만들 수 있습니다. 다만 이 나이아가라 이벤트 방식은 CPU 시뮬레이션에서만 쓸 수 있습니다. 게임플레이 코드로 결과를 돌려주거나 GPU 시뮬레이션 사이에서 데이터를 넘기려면 별도의 연결이 필요하며, 이벤트 모듈을 넣는 것만으로 그런 연결이 생기지는 않습니다.

이런 기능들 덕분에 플레이어의 행동에 반응하는 게임 월드를 만들 수 있고, 아티스트가 의도한 연출을 실제 효과로 옮기기 쉬워집니다.

---

문제를 찾아가는 도구

복잡한 효과를 만들다 보면 예상하지 못한 문제를 자주 만납니다. 나이아가라는 이런 문제를 찾도록 디버깅과 프로파일링 도구를 함께 제공합니다. 나이아가라 디버거(Niagara Debugger)는 실행 중인 시스템과 파티클의 속성 변화를 보여 주므로, 어떤 모듈이 어떤 값을 바꾸는지와 파티클의 수명이 어떻게 흘러가는지를 확인할 수 있습니다. 성능 프로파일링 도구로는 시스템의 각 부분이 연산 자원을 얼마나 쓰는지 살펴보고 병목을 찾아 줄일 수 있습니다.

이 도구들을 쓰면 짐작으로 값을 바꿔 보는 대신 실제 값과 비용을 보며 고칠 수 있으므로, 개발 시간이 줄고 성능 목표에 맞는 효과를 만들기 쉬워집니다.

---

무엇을 공통 모듈로 뺄까

모듈성이 장점이라고 해서 처음부터 모든 것을 공통 모듈로 만들 필요는 없습니다. 먼저 효과 하나에서 필요한 동작을 만들어 보고, 여러 곳에서 되풀이해 쓰는 계산만 공통 모듈로 나눕니다. 스크래치 패드의 로컬 모듈을 다른 에셋에서도 써야 한다면 모듈 에셋으로 내보내고, 속도나 색, 강도처럼 쓰는 곳마다 달라지는 값은 입력으로 노출합니다.

실습을 시작하기 전에는 목표 프레임 시간과 화면 점유율, 외부 입력이 필요한지를 정해 둡니다. 파티클 수와 수명, 생성률, 그리고 CPU와 GPU 가운데 어디서 실행하는지를 함께 기록해 두면 나중에 설정을 바꿨을 때 비교 기준이 됩니다.

이미터 수도 비교할 거리입니다. 한 시스템에 이미터가 12개 있고, 어느 순간 각 이미터에 입자가 20개씩 살아 있다면 전체 입자는 12 × 20 = 240개입니다. 동작이 같아서 이 240개를 이미터 하나로 묶을 수 있다면 전체 입자 수는 그대로지만, System과 Emitter 스크립트, 이미터를 관리하는 데 드는 CPU 비용을 줄일 여지가 생깁니다. 다만 묶기 전에 표현과 입력, 컬링 조건까지 같은지 확인해야 하며, 이미터 수가 12분의 1이 되었다고 전체 FPS가 12배가 된다고 계산해서는 안 됩니다. 프레임 시간에는 이미터 관리 말고도 입자 계산과 렌더링 같은 비용이 함께 들어 있기 때문입니다.

---

정리

• 나이아가라의 효과는 시스템, 이미터, 모듈로 나뉘며, 스크래치 패드로 기본 모듈에 없는 동작을 직접 만들 수 있습니다.
• GPU 시뮬레이션은 입자 스크립트를 GPU로 옮기지만 System과 Emitter 스크립트는 CPU에 남고, 모듈과 데이터 인터페이스의 GPU 지원도 확인해야 합니다.
• 스케일러빌리티는 이펙트 타입과 시스템, 이미터 설정으로 구성해야 동작하며, 설정 없이 자동으로 최적화되지 않습니다.
• 외부 데이터로 효과를 바꿀 수 있고, 이미터 사이의 나이아가라 이벤트와 이벤트 핸들러는 CPU 시뮬레이션에서만 씁니다.
• 디버거와 프로파일링 도구로 실제 속성 값과 비용을 확인하며, 이미터 수를 줄이는 결정도 같은 조건의 측정으로 판단합니다.

---

연습 문제

1. 이벤트를 쓰는 효과를 GPU로

두 이미터가 CPU에서 생성 이벤트와 수명 종료 이벤트를 주고받는 효과를 GPU 시뮬레이션으로 바꾸려 합니다. 입자 수가 같고 같은 이벤트 모듈을 그대로 두면 연결도 그대로 동작한다고 판단해도 될까요? GPU로 바꾼 뒤에도 CPU에 남는 실행 범위도 함께 적어 보세요.

해설 보기

그렇게 판단할 수 없습니다. 나이아가라 이벤트와 이벤트 핸들러 방식은 CPU 시뮬레이션에서만 쓰므로, GPU 시뮬레이션으로 바꾸면 같은 이벤트 연결이 그대로 동작한다고 볼 수 없습니다. 필요한 데이터를 넘기는 다른 방식을 따로 설계하거나 CPU 시뮬레이션을 유지해야 합니다.

GPU로 바꿔도 일반 스크립트 이미터의 System과 Emitter 스크립트는 CPU에 남습니다. 어느 쪽이 더 빠른지는 같은 장면에서 실제로 측정해 판단합니다.

2. 이미터 12개를 하나로

한 시스템에 동작이 같은 이미터 12개가 있고, 각 이미터에 입자가 20개씩 살아 있습니다. 이미터를 하나로 묶으면 전체 입자 수는 어떻게 되고, 무엇이 줄어들 수 있을까요? FPS가 12배가 된다고 말할 수 있을까요?

해설 보기

전체 입자 수는 12 × 20 = 240개로 묶기 전과 같습니다. 줄어들 수 있는 것은 System과 Emitter 스크립트, 이미터를 관리하는 데 드는 CPU 비용입니다. 묶기 전에 표현과 입력, 컬링 조건이 정말 같은지 확인해야 합니다.

FPS가 12배가 된다고 말할 수 없습니다. 프레임 시간에는 입자 계산과 렌더링처럼 이미터 수와 상관없는 비용도 들어 있으므로, 같은 장면에서 묶기 전과 후를 측정해 비교합니다.

3. 설정하지 않은 스케일러빌리티

멀리 있는 폭발 효과가 화면에서 거의 보이지 않는데도 비용이 그대로 든다는 보고가 있었습니다. 나이아가라가 알아서 멀리 있는 효과를 줄여 주지 않는 이유는 무엇이고, 어디를 확인해야 할까요?

해설 보기

나이아가라의 스케일러빌리티는 설정해야 동작합니다. 거리나 가시성에 따라 효과를 걸러 내거나 생성량을 줄이려면, 이펙트 타입과 시스템, 이미터의 스케일러빌리티 설정에 그 조건을 지정해야 합니다.

그래서 먼저 이 시스템에 이펙트 타입이 지정되어 있는지, 거리 컬링이나 생성량 조절이 설정되어 있는지, 시스템에서 덮어쓴 설정은 없는지를 확인합니다. 메시 LOD는 메시의 세부 수준을 바꾸는 것이라 효과 전체의 양을 줄이는 설정과는 다릅니다.

이미터 수와 스케일러빌리티에 관한 지침은 Epic의 나이아가라 스케일러빌리티와 권장 사항에서, 이벤트 핸들러의 지원 범위는 나이아가라의 이벤트와 이벤트 핸들러 문서에서 확인할 수 있습니다.

다음 글 나이아가라 에디터 인터페이스 소개에서는 나이아가라 에디터를 열었을 때 보이는 패널들의 이름과 역할을 하나씩 살펴봅니다.