파티클 효과의 기본 최적화 기법

9장에서 만든 발자국과 마법, 무기 효과는 하나씩 보면 가볍지만, 전투 장면에서 수십 개가 한꺼번에 터지면 프레임 레이트(FPS)를 크게 떨어뜨릴 수 있습니다. 아무리 멋진 효과라도 프레임을 지키지 못하면 실제 프로젝트에서 유지하기 어렵습니다. 파티클은 CPU와 GPU를 모두 쓰므로, 처음부터 예산을 정하고 그 안에서 만드는 습관이 중요합니다. 이 글에서는 입자 수와 렌더링, 계산의 비용을 줄이는 기본 기법과 거리에 따른 품질 조절을 정리하고, 플랫폼별 예산의 예를 살펴본 뒤, 입자 수를 줄인 결과와 예산을 통과했는지를 구분해 판단해 봅니다.

---

입자 수 관리하기

동시에 살아 있는 입자의 수는 시뮬레이션이 해야 할 일의 양을 정하는 큰 요인입니다. 하지만 비용은 입자 수만으로 정해지지 않으며, 시스템 인스턴스의 수와 화면에서 덮는 픽셀, 머티리얼의 비용도 함께 봐야 합니다. 입자가 늘면 같은 계산의 총량도 늘지만, 비용이 늘 기하급수적으로 커지는 것은 아닙니다. CPU와 GPU의 실행 방식, 겹침, 메모리, 병렬 처리에 따라 실제로 늘어나는 모양이 달라집니다.

입자 수를 줄이는 첫 방법은 생성량을 줄이는 것입니다. 효과의 목표를 이루는 데 필요한 만큼만 만들도록 Spawn Rate와 Spawn Burst Instantaneous의 Spawn Count를 조절하고, 눈으로 보아 큰 차이가 없는 작은 입자는 과감히 줄이거나 빼는 것을 검토합니다.

두 번째 방법은 수명을 줄이는 것입니다. 수명은 곧 입자가 월드에 있는 시간이므로, 화면에서 사라져 보이는 순간까지의 시간을 되도록 짧게 두어 동시에 살아 있는 입자를 줄입니다. 연기나 안개처럼 오래 남아야 하는 효과도 카메라와의 거리에 따라 수명을 조절하는 LOD(Level of Detail)를 쓸 수 있습니다.

세 번째로 생성량과 인스턴스에 상한을 둡니다. Spawn Rate와 버스트, Lifetime을 함께 제한하는데, 생성률과 수명이 일정한 정상 상태라면 대략 생성률 × 수명이 동시에 살아 있는 입자의 수이고, 버스트와 수명의 분포는 따로 따집니다. 이펙트 타입(Effect Type)에서는 시스템과 효과 무리의 인스턴스 수 제한과 컬링을 정합니다. 이것은 모든 이미터에 있는 범용 Max Particles 속성과는 다른 것입니다.

---

렌더링 비용 줄이기

입자를 그리는 일은 GPU에 큰 부담을 줄 수 있으므로 머티리얼과 렌더러의 설정에 주의합니다. 대부분의 입자 효과는 빛의 영향을 받지 않는 Unlit을 쓰는 것이 가장 효율적이고, Default Lit은 물리적인 파편처럼 꼭 필요한 경우에만 씁니다.

블렌드 모드마다 비용의 특징이 다릅니다. Additive는 불꽃이나 에너지, 스파크처럼 빛나는 효과에 알맞지만, 겹친 픽셀을 여러 번 칠하므로 Translucent보다 언제나 싼 것은 아닙니다. Translucent는 연기나 안개, 물방울 같은 반투명 효과에 꼭 필요하지만, 같은 픽셀을 여러 번 그리는 오버드로우(overdraw)의 비용이 매우 크므로 조심해서 씁니다. 겹치는 입자의 수와 화면 면적, 겹침, 텍스처 샘플 수를 줄이며, 알파를 0으로 낮춰도 입자와 드로우가 그대로라면 비용이 남는다는 점을 기억합니다. Masked는 불투명한 부분과 완전히 투명한 부분만 있을 때 쓰는데, 깊이 처리에서 이점이 있을 수 있지만 실제 비용은 비교해 봐야 하고 부드러운 가장자리는 표현하기 어렵습니다.

텍스처는 필요한 만큼의 해상도만 씁니다. 작은 스파크에 2K 텍스처를 쓰는 것은 낭비입니다. 대상 플랫폼과 알파, 데이터의 용도에 맞는 압축과 밉 설정을 적용해 VRAM 사용량을 줄입니다.

머티리얼의 DepthFade는 다른 표면과 만나는 자리를 부드럽게 하지만 깊이 샘플링과 머티리얼의 비용이 들므로 필요한 곳에만 씁니다. 모션 블러(Motion Blur)도 보기에는 좋지만 GPU에 부담을 주므로, 필요에 따라 끄거나 세기를 조절합니다.

Light Renderer는 꼭 필요할 때만 씁니다. 그 비용은 조명의 수와 반경, 겹침, 렌더링 방식에 따라 달라지므로, 언제나 다른 렌더러보다 비싸다고 단정하지는 않습니다. 폭발의 섬광처럼 꼭 필요한 경우에만 쓰고, 색의 밝기와 반경 바인딩, 조명의 수와 반경을 조절합니다. 밝기를 낮추는 것만으로 조명의 계산이 없어지지는 않습니다. 또 쓰는 엔진 버전과 렌더링 방식이 지원하는 옵션만 씁니다. 예를 들어 UE 5.8의 MegaLights에 관한 그림자 옵션을 모든 나이아가라 Light Renderer의 범용 그림자나 GI 스위치로 일반화하지 않습니다.

---

계산 비용 줄이기

입자의 움직임과 속성을 계산하는 업데이트 단계도 성능에 큰 영향을 줍니다. 먼저 Particle Update에서 쓰지 않거나 효과에 거의 영향을 주지 않는 모듈과 노드를 과감히 지웁니다. 모듈마다 일정한 계산 비용이 들기 때문입니다. 특히 Collision은 비용이 크므로 정말 필요할 때만 더하고, 부딪히면 없애는 응답을 쓰거나 충돌이 필요 없는 입자에서는 빼는 식으로 설정을 다듬습니다.

노이즈 힘은 유기적인 움직임을 만들지만 계산 비용이 듭니다. 주파수는 주로 공간 패턴의 크기를 바꾸므로, 값을 올린다는 이유만으로 계산이 늘어난다고 단정하지 말고 실제 모듈의 구현과 측정 결과를 봅니다. 시간에 따라 패턴이 바뀌는 속도는 보이는 모습을 바꿀 뿐이며, 비용은 표본 수와 알고리즘, 입자 수, 실행 빈도로 확인합니다.

조건 노드도 비용과 관련이 있습니다. 높이가 일정 이상일 때만 중력을 주거나 특정 상태에서만 힘을 주는 식으로 If 같은 동적 선택 노드를 쓸 수 있지만, 한쪽 결과만 쓰더라도 양쪽의 입력이 모두 계산될 수 있습니다. 비용을 빼는 것이 목적이라면 정적 스위치나 모듈 끄기를 쓰고, 실제 컴파일과 프로파일 결과를 확인합니다.

계산은 되도록 단순하게 합니다. 제곱근(Sqrt)처럼 비싼 연산 대신, 가능하다면 길이의 제곱(Length Squared)끼리 비교하는 편이 효율적입니다. 데이터 인터페이스도 편리하지만, 본이 아주 많은 스켈레탈 메시처럼 참조하는 데이터가 복잡하면 비용이 커지므로 필요한 데이터만 가져옵니다.

---

거리에 따른 품질 조절

카메라와의 거리에 따라 시스템의 복잡도를 조절하는 것은 효과가 큰 최적화입니다. 다만 저절로 되지 않으므로 직접 설정해야 합니다. 나이아가라 이펙트 타입에서는 거리와 가시성, 인스턴스 수, 예산에 따른 컬링을 여러 효과에 공통으로 정하고, 시스템마다 덮어쓴 설정을 관리합니다. 이미터에서는 Platform Set과 품질 단계별 포함 여부, Spawn Count Scale처럼 실제로 지원되는 입력을 설정합니다. 거리에 따라 값이 연속적으로 바뀌게 하려면 거리 입력을 생성률이나 수명에 연결하는 식으로 따로 구성해야 합니다.

바운드도 함께 봅니다. Fixed Bounds가 너무 작으면 보이는 입자가 잘리고, 너무 크면 컬링되지 않아 필요 없는 작업이 남습니다. 효과가 가장 크게 퍼졌을 때와 카메라가 움직일 때를 기준으로 확인합니다. 특정 공간에서 입자를 없애고 싶다면 나이아가라의 Kill Particles in Volume 모듈처럼 입자에 직접 작용하는 경로를 씁니다. 게임플레이용 Kill Volume을 레벨에 두는 것만으로 나이아가라 입자가 저절로 사라지지는 않습니다.

더 깊이: 이펙트 타입이 효과 묶음에 정하는 것

이펙트 타입은 충격 효과와 환경 효과처럼 성격이 같은 나이아가라 시스템들이 함께 쓰는 설정을 담는 에셋이며, 시스템 속성에서 시스템마다 지정합니다. NiagaraEffectType 레퍼런스는 그 주된 쓰임을 효과 묶음의 스케일러빌리티를 다루는 것, 그중에서도 플랫폼마다 가시성과 컬링 반응을 정하는 것이라고 설명합니다. 컬링 반응(Cull Reaction)은 이 타입의 효과가 컬링 검사를 통과하지 못했을 때 어떻게 반응할지 정하는데, 이 타입을 쓰는 모든 효과에 적용되며 효과마다 덮어쓸 수 없습니다. 그래서 컬링되었을 때 다르게 반응해야 하는 효과가 섞여 있다면 이펙트 타입을 나눠야 합니다.

나머지 항목도 무엇을 정하는지 알아 둘 만합니다. Update Frequency는 이 타입의 효과를 얼마나 자주 스케일러빌리티 검사에 올릴지 정합니다. 중요도 처리기(Significance Handler)는 장면 안에서 효과의 상대적인 중요도를 정하고, 그 결과는 인스턴스 수 컬링 같은 다른 스케일러빌리티 시스템이 씁니다. Allow Culling for Local Players는 로컬 플레이어가 조종하는 폰이 소유하거나, 그 폰에 붙어 있거나, 그 폰이 일으킨 효과도 컬링할 수 있게 할지를 정합니다. 이펙트 타입은 검증에도 쓰여서, 여기에 넣은 검증 규칙 세트를 그 타입의 콘텐츠가 모두 통과하는지 확인할 수 있습니다.

---

플랫폼별 예산의 예

아래 표는 예산 문서를 쓰는 연습을 위한 가상의 수치입니다. 엔진이 권장하는 값이나 실제로 잰 결과가 아니므로, 대상 기기와 해상도, 효과의 구성, 그리고 장르와 카메라 거리, 장면의 밀도에 맞춰 반드시 바꿔야 합니다.

예산을 넘으면 측정으로 찾은 병목부터 줄입니다. 시뮬레이션과 픽셀, 인스턴스의 비용은 서로 다른 방법으로 줄여야 하므로, 모든 장면에 같은 순서를 적용하지 않습니다.

같은 카메라와 입력, 품질 단계에서 바꾸기 전과 후의 CPU, GPU 시간을 비교합니다. 화면의 품질이 그대로여도 병목인 시간이 줄지 않았다면 최적화에 성공했다고 적지 않습니다. 또 낮은 품질 단계에서도 공격의 방향과 위험한 범위는 읽을 수 있어야 합니다.

---

비용을 재는 도구

최적화의 첫걸음은 병목이 어디에 있는지 정확히 아는 것입니다. 나이아가라 디버거(Niagara Debugger)의 Debug HUD와 FX Outliner에서는 대상 시스템과 그 상태를 좁혀 볼 수 있습니다. FX Outliner의 캡처와 CPU VM의 모듈 통계, GPU 프로파일은 재는 범위가 서로 다르며, 모든 모듈의 CPU, GPU 시간이 한 패널에 저절로 나오는 것은 아닙니다.

게임을 플레이하는 중에 개발자 콘솔(~ 키)에서 stat Niagara를 입력하면 나이아가라 시스템 전체의 성능 통계가 화면에 겹쳐 표시되므로, 전반적인 상태를 빠르게 확인할 수 있습니다. 더 깊이 분석하려면 Unreal Insights로 CPU와 GPU 사용량, 메모리 할당, 스레드의 활동을 자세히 살펴 구체적인 병목을 찾습니다.

---

입자 수를 줄인 것과 예산을 통과한 것

입자 수를 줄였다는 사실과 예산을 통과했다는 사실은 구분해야 합니다. 생성률 50개/초, 수명 2초가 일정하고 버스트나 컬링, 추가 Kill이 없는 정상 상태라면 동시에 살아 있는 입자는 약 50 × 2 = 100개입니다. 생성률만 25개/초로 낮추면 약 50개가 됩니다. 이것은 입자 수가 절반이 되었다는 계산일 뿐, 시스템 인스턴스나 화면의 겹침, 머티리얼, 다른 게임 작업까지 절반으로 줄었다는 뜻은 아닙니다.

이번에는 같은 기기와 카메라, 해상도, 입력, 품질에서 얻었다고 가정한 연습용 측정값을 비교해 봅니다. 실제로 엔진을 실행해 얻은 수치는 아닙니다. Frame과 Game, Draw, GPU는 stat unit이 보여 주는 한 프레임 전체의 시간과 게임 스레드, 렌더링 스레드, GPU의 시간이며, 읽는 법은 언리얼 기본 교재의 환경 요소의 성능 분석에서 다룹니다.

나이아가라 GPU의 목표를 1.5ms 이하로 정했다면, 바꾼 뒤의 1ms는 그 부분 예산을 통과합니다. 하지만 60FPS의 전체 프레임 예산은 1000 ÷ 60 ≈ 16.67ms이므로, Frame 18ms는 아직 넘습니다. CPU와 GPU, 화면에 내보내는 경로는 서로 겹쳐 실행될 수 있으므로, 표의 시간을 모두 더해 Frame을 다시 계산하지 않습니다. 다음에 무엇을 바꿀지는 남은 프레임의 경로를 프로파일로 좁혀 정합니다.

---

정리

• 동시에 살아 있는 입자는 생성량과 수명으로 줄이며, 정상 상태에서는 대략 생성률 × 수명이고 범용 Max Particles 속성이 있다고 가정하지 않습니다.
• 렌더링 비용은 셰이딩 모델과 블렌드 모드, 오버드로우, 텍스처, Light Renderer의 수와 반경으로 줄이며, 알파 0이나 밝기 낮추기는 비용을 없애지 않습니다.
• 계산 비용은 필요 없는 모듈과 충돌을 빼고, 동적 선택 대신 정적 스위치를 쓰며, 제곱근 대신 길이의 제곱을 비교해 줄입니다.
• 거리에 따른 품질은 이펙트 타입과 Platform Set, Spawn Count Scale로 직접 설정하며, 바운드가 너무 작거나 크지 않게 맞춥니다.
• 입자 수의 감소와 부분 예산의 통과, 전체 프레임 예산의 통과는 각각 따로 측정해 판단합니다.

---

연습 문제

1. 부분 예산과 전체 예산

따로 정한 조건에서 생성률 30개/초, 수명 1.5초, 나이아가라 GPU 1.2ms, Frame 17ms가 주어졌습니다. 정상 상태의 입자 수와 나이아가라 부분 예산(1.5ms 이하), 60FPS 전체 예산을 통과하는지 각각 구해 보세요. 알파만 0으로 낮추면 시뮬레이션과 드로우가 모두 없어졌다고 결론 내려도 될까요?

해설 보기

정상 상태의 입자는 약 30 × 1.5 = 45개이고, 나이아가라 GPU 1.2ms는 1.5ms 이하이므로 부분 예산을 통과합니다. 그러나 Frame 17ms는 약 16.67ms보다 크므로 60FPS 전체 목표는 통과하지 못합니다.

알파를 0으로 낮추는 것은 보이는 값을 바꿀 뿐이므로, 살아 있는 입자와 렌더러, 드로우가 남아 있는지 따로 확인해야 합니다. 입자 수와 부분 예산이 좋아진 결과는 유지하되, 전체 프레임과 화면의 목표는 따로 확인합니다.

2. 잘려 사라지는 폭발

카메라를 조금만 돌려도 폭발 효과가 화면 가장자리에서 통째로 사라집니다. 효과의 Fixed Bounds가 작게 정해져 있다면 어떻게 고쳐야 할까요?

해설 보기

Fixed Bounds가 실제로 입자가 퍼지는 범위보다 작으면, 엔진은 바운드가 화면 밖에 있다고 보고 효과 전체를 컬링해 버립니다. 그래서 입자가 아직 화면 안에 있는데도 통째로 사라집니다.

효과가 가장 크게 퍼졌을 때의 범위를 감싸도록 바운드를 넓힙니다. 다만 너무 크게 잡으면 화면 밖에서도 컬링되지 않아 필요 없는 작업이 남으므로, 최대로 퍼진 범위와 카메라가 움직일 때를 기준으로 알맞게 맞춥니다.

3. 품질을 낮춰도 읽혀야 하는 것

모바일의 낮은 품질 단계에서 비용을 줄이려고 적의 공격 범위를 알리는 바닥 효과의 생성량을 크게 줄였더니, 범위의 테두리가 흐려져 플레이어가 피하기 어려워졌습니다. 어떻게 접근하면 좋을까요?

해설 보기

이 효과는 게임의 정보를 전달하므로, 비용을 줄이더라도 위험한 범위를 읽을 수 있어야 합니다. 생성량만 크게 줄이면 테두리를 이루던 입자가 사라져 정보가 흐려집니다.

테두리처럼 정보를 전하는 부분은 유지하고, 안쪽을 채우는 장식 입자나 겹침을 줄이는 쪽으로 비용을 줄입니다. 반투명 면적을 줄이거나, 테두리를 입자 대신 단순한 메시나 데칼로 그리는 방법도 비교합니다. 바꾼 뒤에는 같은 조건에서 비용과 함께 범위가 잘 읽히는지 확인합니다.

측정 범위를 나누어 읽는 방법은 Epic의 나이아가라 성능 측정 문서에서 확인할 수 있습니다. 비용을 줄이는 스케일러빌리티 전략은 나이아가라 스케일러빌리티와 권장 사항에서, 디버깅 도구는 나이아가라 디버거 문서에서 볼 수 있습니다.

이것으로 9장을 마칩니다. 9장에서는 효과를 만드는 공통 순서와 불꽃, 연기, 폭발의 시작 값에서 시작해, 발자국과 물 튀김, 마법과 발사체, 캐릭터와 무기의 효과를 만들고, 그 효과들을 예산 안에 맞추는 최적화 기법까지 살펴봤습니다. 다음 장의 기본적인 프로젝트 설정 및 관리부터는 프로젝트 설정과 버전 관리, 디버깅, 에셋 관리, 여러 플랫폼 대응처럼 나이아가라 프로젝트를 꾸려 가는 방법을 다룹니다.