나이아가라 이펙트 디버깅 기초

숙련된 FX 아티스트라도 효과를 만들다 보면 예상하지 못한 문제를 만납니다. 입자가 보이지 않거나, 이상하게 움직이거나, 프레임을 떨어뜨리는 식입니다. 이런 문제를 찾아 고치는 과정이 디버깅(debugging)이며, 짐작으로 값을 바꿔 보는 대신 원인을 하나씩 좁혀 가는 것이 핵심입니다. 언리얼 엔진은 나이아가라를 디버깅하는 도구를 엔진 안에 갖추고 있습니다. 이 글에서는 증상별로 먼저 점검할 항목을 정리하고, 나이아가라 디버거와 통계 명령, 나이아가라 에디터 안의 디버깅 기능을 살펴본 뒤, 보이지 않는 효과의 원인을 한 단계씩 좁혀 봅니다.

---

흔한 문제와 점검 항목

디버깅을 시작하기 전에 자주 생기는 문제를 알고 기본적인 점검부터 하면 시간을 아낄 수 있습니다. 문제는 대개 입자가 보이지 않는 것, 이상하게 움직이는 것, 프레임을 떨어뜨리는 것 가운데 하나로 나타나며, 증상마다 먼저 의심할 곳이 다릅니다. 아래 점검 항목은 효과가 실행되는지, 입자가 만들어지는지, 만든 입자를 그릴 수 있는지처럼 앞 단계부터 확인하도록 적었습니다. 앞 단계가 막혀 있으면 뒤 단계의 설정을 아무리 바꿔도 결과가 달라지지 않기 때문입니다.

입자가 전혀 보이지 않을 때

먼저 실행되고 있는지를 봅니다. 나이아가라 컴포넌트가 켜져 있는지, 즉 블루프린트나 레벨 시퀀서에서 Activate가 불렸거나 Auto Activate가 켜져 있는지 확인합니다. 이미터도 켜져 있는지, Emitter State의 수명 주기와 실행 상태가 어떤지, 품질 단계에서 빠지거나 컬링되지 않았는지 봅니다.

다음으로 입자가 만들어지는지를 봅니다. Spawn Rate나 버스트의 개수가 0이 아닌지, 수명이 너무 짧아 생기자마자 사라지지 않는지 확인합니다.

그다음 보일 수 있는 상태인지를 봅니다. 스프라이트 크기나 메시 크기가 0이 아닌지 확인하고, 머티리얼이 제대로 지정되었는지와 블렌드 모드, 셰이딩 모델, 투명도 설정이 맞는지 봅니다. 특히 Translucent 머티리얼은 그리는 순서 때문에 보이지 않을 수 있습니다. 거리 컬링 설정 때문에 멀리서 그려지지 않는지, 작게 잡힌 Fixed Bounds 때문에 잘리지 않는지도 확인합니다. 마지막으로 렌더러가 Light Renderer 하나뿐인지 봅니다. Light Renderer는 빛만 만들 뿐 입자 자체를 그리지 않습니다.

입자가 이상하게 움직이거나 모양이 이상할 때

초기 속도가 의도한 방향으로 주어졌는지 확인합니다. 그다음 Gravity Force나 Drag, 노이즈 힘 같은 힘 모듈의 세기가 너무 강하거나 약하지 않은지 봅니다. Scale Color나 Scale Sprite Size처럼 시간에 따른 변화를 정하는 NormalizedAge 커브가 의도대로 동작하는지, Collision의 Restitution과 Friction, 충돌 방식이 맞는지도 확인합니다. 데이터 인터페이스로 바깥의 데이터를 가져온다면, Actor Component 데이터 인터페이스나 프로젝트의 데이터 인터페이스가 가리키는 원본이 유효한지도 봅니다.

성능이 떨어질 때

생성률과 버스트, 수명, 동시에 재생되는 시스템의 수가 너무 크지 않은지 먼저 봅니다. 입자가 지나치게 많으면 비용이 커집니다. Translucent 머티리얼이 많이 겹치면 오버드로우로 부담이 크게 늘고, Light Renderer나 그림자처럼 동적인 조명을 만드는 일도 비용이 큽니다. 복잡한 모듈 스크립트는 실제로 얼마나 자주, 몇 개의 입자에서 실행되는지 프로파일로 확인하며, 룩업 테이블이나 삼각 함수라는 이름만 보고 병목이라고 판단하지 않습니다. Collision도 트레이스 방식이나 복잡한 형태에 대한 충돌 검사는 비용이 큽니다.

---

나이아가라 디버거

나이아가라 디버거(Niagara Debugger)는 효과의 실시간 상태를 살펴보고 성능의 병목을 찾는 데 가장 쓸모가 큰 도구입니다. 레벨 에디터에서는 Tools > Debug > Niagara Debugger로 열고, 나이아가라 에디터에서는 Debug 메뉴에서 Debug HUD나 FX Outliner를 엽니다. 메뉴의 위치는 버전에 따라 다를 수 있습니다.

디버거를 열면 먼저 연결된 PIE나 대상 기기의 세션을 확인하고, 시스템이나 액터의 필터로 문제의 효과를 좁힙니다. 이때 같은 맵과 카메라, 입력, 재생 시점을 적어 두어야 나중에 같은 조건으로 비교할 수 있습니다.

그다음 확인하려는 목적에 맞는 도구를 고릅니다. Debug HUD는 실행 상태나 입자 수 같은 표시 항목을 켜고, 필요한 속성과 바운드를 화면에 보여 줍니다. 모든 속성이 모든 시뮬레이션 대상에서 같은 방식으로 보이는 것은 아닙니다. FX Outliner는 Capture로 월드와 시스템, 인스턴스, 이미터의 상태를 모읍니다. Perf 옵션으로 잴 때는 어떤 항목이 표시되고 어디까지 모으는지 확인합니다. Playback으로는 일시 정지와 재생, 한 프레임 앞으로 가기(Step), 재생 속도를 조절할 수 있습니다. 이전 프레임으로 되감는 기능이 있다고 가정하지 말고, 필요하면 처음으로 되돌린 뒤 같은 조건으로 다시 재생합니다. 나이아가라의 재생 속도를 바꿔도 월드 전체의 시간이 함께 바뀌지는 않습니다.

GPU 시뮬레이션의 속성을 CPU로 읽어 오는 readback은 몇 프레임의 지연과 메모리 비용이 있습니다. 그래서 그 값을 한 프레임 뒤의 화면과 정확히 같은 순간의 값으로 비교하지 않습니다.

---

통계 명령

콘솔 명령으로 나이아가라와 렌더링의 성능 통계를 빠르게 확인할 수 있습니다. 게임을 플레이하는 중에 ~ 키를 눌러 개발자 콘솔을 엽니다.

stat Niagara는 나이아가라의 집계 통계를 보여 줍니다. 표시되는 항목은 빌드와 엔진 버전에 따라 다르며, 모든 시스템 하나하나의 GPU 비용을 바로 보여 준다고 가정하지 않습니다. 원인이 되는 시스템은 FX Outliner와 필터, 프로파일을 함께 써서 좁힙니다.

stat GPU는 GPU 렌더링의 자세한 통계를 보여 주며, 반투명(Translucency)이나 후처리(Post Processing) 같은 항목으로 GPU 병목의 원인을 찾게 도와줍니다. stat InitViews는 가시성과 컬링, 가림(occlusion) 같은 화면 준비 작업의 비용을 분석하는 명령이며, SSAO의 비용을 직접 재는 명령은 아닙니다. profilegpu는 지금 화면을 그리는 데 쓰인 GPU 작업을 자세한 타임라인으로 보여 주므로, GPU 오버드로우나 특정 렌더링 단계의 문제를 찾는 데 쓸모가 있습니다.

---

나이아가라 에디터 안의 디버깅 기능

나이아가라 시스템 에디터 안에서도 원인을 좁힐 수 있습니다. 스택과 미리보기에서는 Spawn에서 초기값을 정하는지, Update에서 틱마다 덮어쓰는지 확인합니다. 힘과 충돌, Solve Forces and Velocity의 순서와 Local, 월드 공간도 함께 대조하며, Collision은 Solve 바로 앞에 있어야 합니다.

입자의 속성 값을 보고 싶다면 속성 스프레드시트(Attribute Spreadsheet)로 지원되는 시뮬레이션의 속성을 캡처해 비교합니다. 일반 파라미터(Parameters) 패널은 살아 있는 모든 입자의 지금 값을 보여 주는 목록이 아닙니다. CPU VM의 모듈 통계와 GPU의 측정도 서로 구분합니다.

문제를 다시 만들 때는 일시 정지와 한 프레임 앞으로 가기로, 처음으로 값이 어긋나는 시점을 좁힙니다. 바깥에서 넣는 사용자 파라미터가 관련되어 있다면, 부르는 대상 컴포넌트와 파라미터의 이름과 타입, 그리고 Activate 전후에 언제 값을 넘기는지를 함께 확인합니다.

---

보이지 않는 원인을 한 단계씩 좁히기

문제의 시스템 하나로 필터를 좁힌 Debug HUD에서, 시스템이 켜져 있고 살아 있는 입자가 20개로 표시되었다고 가정해 봅시다. 입자가 있으므로 이것은 Spawn Rate가 0이라는 뜻이 아닙니다. 그러면 다음으로 볼 것은 크기가 0인지, 머티리얼이 맞는지, 바운드와 컬링, 그리고 렌더러가 실제로 무엇을 그리는지입니다. 반대로 입자 수가 0이었다면 실행과 생성, 수명, 그리고 값을 모은 시점부터 대조합니다.

이처럼 확인한 사실 하나로 앞에서 나열한 모든 원인을 한꺼번에 확정하지 않습니다. 설정을 하나 바꾸고 같은 카메라와 시점에서 비교하기를 되풀이합니다.

증상에 따라 먼저 볼 곳을 정리하면 다음과 같습니다.

한 번에 원인 하나만 바꾸고 같은 조건에서 다시 잽니다. Debug HUD나 화면의 텍스트, readback도 그 자체로 비용을 만들 수 있으므로, 최종적으로 성능을 비교할 때는 꼭 필요한 측정만 남깁니다. GPU 통계와 콘솔 명령의 지원은 빌드 구성과 RHI, 대상 기기에 따라 확인합니다.

---

정리

• 디버깅은 짐작으로 값을 바꾸는 대신, 실행과 생성, 보이는 상태의 순서로 원인을 하나씩 좁혀 가는 과정입니다.
• 보이지 않을 때는 컴포넌트와 이미터의 실행, 생성 수와 수명, 크기와 머티리얼, 바운드와 컬링을 보고, 렌더러가 Light Renderer뿐이 아닌지 확인합니다.
• 나이아가라 디버거의 Debug HUD와 FX Outliner, Playback으로 상태를 보고 잡아 두며, 되감기가 있다고 가정하지 않습니다.
• stat Niagara, stat GPU, stat InitViews, profilegpu는 재는 범위가 서로 다르며, 원인이 되는 시스템은 디버거와 프로파일로 좁힙니다.
• 에디터에서는 스택의 쓰는 순서와 속성 스프레드시트로 값을 확인하고, 한 번에 하나만 바꿔 같은 조건에서 비교합니다.

---

연습 문제

1. 덮어쓰는 Update와 Light Renderer

Spawn에서 크기를 2로 쓰는데, Update의 모듈이 틱마다 고정값 10을 다시 씁니다. 바깥의 Float 입력을 3으로 바꿨는데 다음 Update 뒤에 크기가 3이 되지 않았다면, 바깥에서 부른 것이 실패했다고 확정할 수 있을까요? 또 입자 20개가 살아 있는데 렌더러가 Light Renderer뿐이라면, 스프라이트가 보여야 한다고 기대할 수 있을까요?

해설 보기

확정할 수 없습니다. Update의 고정 모듈이 틱마다 10으로 덮어쓰고 있으므로, 부르는 대상과 이름, 타입과 함께 어떤 모듈이 마지막으로 값을 쓰는지 확인해야 합니다. 바깥의 값을 원하는 시점에 읽도록 연결하지 않으면, 부르는 값만 바꿔도 결과는 그대로일 수 있습니다.

스프라이트도 기대할 수 없습니다. Light Renderer는 입자의 스프라이트를 대신 그리지 않으므로, 스프라이트가 필요하다면 Sprite Renderer와 그 머티리얼을 따로 구성합니다. 여기의 입자 수와 값은 판단을 연습하기 위한 가정이며, 실제 Debug HUD의 캡처가 아닙니다.

2. 입자 수가 0일 때

Debug HUD에서 문제의 시스템은 켜져 있는데 살아 있는 입자 수가 계속 0입니다. 어떤 순서로 확인해야 할까요?

해설 보기

입자가 아예 없으므로 보이는 상태보다 생성 쪽을 먼저 봅니다. 이미터가 켜져 있고 Emitter State가 실행 중인지, 품질 단계에서 빠지지 않았는지 확인합니다. 그다음 Spawn Rate나 버스트의 개수가 0이 아닌지, 버스트라면 그 시점이 이미 지나지 않았는지 봅니다.

생성은 되는데 곧바로 0이 된다면 수명이 너무 짧거나, 충돌이나 Kill 조건이 생기자마자 입자를 없애는지 확인합니다. 마지막으로 값을 모은 시점이 효과가 끝난 뒤가 아닌지도 봅니다.

3. 측정 도구가 바꾼 비용

성능을 비교하려고 Debug HUD에 여러 속성을 띄우고 readback을 켠 채 프레임 시간을 재었더니, 바꾸기 전보다 오히려 느려졌습니다. 최적화가 실패한 걸까요?

해설 보기

꼭 그렇지는 않습니다. Debug HUD의 표시와 화면의 텍스트, GPU readback도 그 자체로 비용을 만들므로, 측정 도구가 결과를 바꿨을 수 있습니다.

최종적으로 성능을 비교할 때는 꼭 필요한 측정만 남기고, 바꾸기 전과 후를 같은 도구 설정과 같은 조건에서 잽니다. 그래야 변경의 효과와 도구의 비용을 구분할 수 있습니다.

도구의 구성은 Epic의 나이아가라 디버거 문서와 나이아가라 에디터 UI 레퍼런스에서 확인할 수 있습니다.

다음 글 에셋 관리의 기본 개념에서는 나이아가라 시스템이 참조하는 에셋들의 관계를 파악하고, 공용 에셋을 안전하게 바꾸고 정리하는 방법을 살펴봅니다.