기본적인 프로젝트 설정 및 관리
프로젝트의 나이아가라 플러그인·스케일러빌리티를 설정하고 명명·폴더·공용 모듈·사용자 변수 규칙을 표준화합니다.
효과를 하나씩 잘 만드는 것과 여러 사람이 수백 개의 효과를 함께 관리하는 것은 다른 일입니다. 누가 만든 시스템인지, 어느 폴더에 무엇이 있는지, 바깥에서 어떤 값을 넣어야 하는지가 정해져 있지 않으면, 프로젝트가 커질수록 같은 효과를 다시 만들거나 남이 만든 효과를 고치다 깨뜨리는 일이 늘어납니다. 그래서 나이아가라를 제대로 쓰려면 프로젝트 차원에서 설정을 정리하고 에셋을 체계적으로 관리해야 합니다. 이것이 협업을 매끄럽게 하고, 프로젝트의 성능과 안정성을 지키며, 나중의 유지보수를 쉽게 만드는 바탕이 됩니다. 이 글에서는 나이아가라에 영향을 주는 프로젝트 설정과 에셋의 이름과 폴더 규칙, 재사용 방법, 사용자 파라미터의 약속, 버전 관리와의 연결을 정리합니다.
프로젝트 설정
언리얼 엔진의 프로젝트 설정(Project Settings)에는 나이아가라 전체의 동작과 성능에 영향을 주는 설정들이 있습니다.
Plugins > Niagara 설정에서는 기본 이펙트 타입(Effect Type)과 품질 수준 같은 공통 정책을 확인합니다. 다만 나이아가라에 관한 설정이 모두 여기 모여 있는 것은 아닙니다. CPU와 GPU 시뮬레이션은 이미터마다 Sim Target으로 고르며, GPU 시뮬레이션에도 시스템과 이미터를 관리하는 CPU 비용이 있고 플랫폼과 데이터 인터페이스의 지원을 확인해야 합니다. 생성을 멈추는 것은 컴포넌트의 활성 상태와 이미터의 수명 주기로 제어합니다. 입자 수는 생성률과 버스트, 수명으로 설계하고, 이펙트 타입의 거리와 인스턴스 수, 예산에 따른 컬링과 시스템의 덮어쓰기로 관리합니다. 반복해서 만드는 효과는 Spawn 노드의 Pooling Method 같은 컴포넌트 풀링 설정을 씁니다. 입자 수의 상한이나 모든 시스템의 일시 정지를 전역 체크박스 하나로 정한다고 가정하지 않습니다.
Engine > Rendering 설정에도 효과와 관련된 항목이 있습니다. Generate Mesh Distance Fields는 GPU 거리 필드 충돌을 쓰려면 켜야 하며, 대상 플랫폼이 지원하는지도 확인해야 합니다. 이 기능을 쓰지 않거나 특정 플랫폼이 지원하지 않는다면 꺼서 리소스를 아낄 수 있습니다. 모션 블러(Motion Blur)는 입자에도 적용될 수 있어 시네마틱에는 도움이 되지만 성능에 영향을 주므로, 게임의 목표 프레임 레이트에 맞춰 조절하거나 끕니다. 블룸(Bloom)은 입자의 발광을 강조해 마법 효과 같은 데 시각적인 힘을 더하는데, 프로젝트의 기본 적용 여부와 포스트 프로세스 볼륨이나 카메라에서 덮어쓰는 세기를 구분합니다.
Engine > Physics 설정에서는 게임플레이 충돌에 쓰는 Physical Material과 Surface Type을 정리합니다. 나이아가라의 CPU 트레이스와 GPU Scene Depth, Distance Fields 충돌은 입력과 반응의 경로가 서로 다르므로, 물리 머티리얼이 모든 나이아가라 입자에 저절로 적용된다고 가정하지 않습니다.
에셋 이름과 폴더 구조
나이아가라 에셋을 체계적으로 관리하는 일은 특히 팀 프로젝트에서 중요합니다. 이름에는 일관된 접두사를 붙여 에셋의 종류를 한눈에 알아볼 수 있게 합니다.
NS_(Niagara System): 나이아가라 시스템 에셋입니다.NS_Explosion_Fire,NS_Character_Footstep_Dust가 그 예입니다.NE_(Niagara Emitter): 나이아가라 이미터 에셋입니다.NE_Fire_Core,NE_Smoke_Trail이 그 예입니다.NC_(Niagara Component): 블루프린트에 추가하는 나이아가라 컴포넌트의 변수 이름에 붙이며, 쓸지는 선택입니다.
이름은 [효과 종류]_[하위 종류]_[설명] 같은 형태로 짓습니다. NS_Weapon_Pistol_MuzzleFlash가 그 예입니다. 무기(Weapon) 효과 가운데 권총(Pistol)의 총구 화염(MuzzleFlash)이라는 뜻이며, 아래 폴더 구조에서는 Weapon/Pistol 폴더에 들어갑니다.
폴더는 Content/FX나 Content/Effects 같은 최상위 폴더를 만들고, 그 아래에 Fire, Water, Impact, Character, Weapon처럼 효과의 종류별로 하위 폴더를 둡니다. 각 효과의 폴더 안에는 그 시스템과 관련된 이미터, 머티리얼, 텍스처를 함께 두어 관련 에셋을 쉽게 찾게 합니다. Content/FX/Explosions/Explosion_Large/NS_Explosion_Large가 그 예입니다. 아래는 이런 규칙을 따른 폴더 구조의 예입니다.
이미터와 모듈 다시 쓰기
나이아가라의 모듈 구조는 에셋을 다시 쓰기에 좋습니다. 잘 만든 불꽃의 중심이나 기본 연기, 스파크 같은 이미터는 독립된 에셋으로 저장해 여러 시스템에서 다시 쓸 수 있습니다. 작업 시간이 줄고 시각적인 스타일도 고르게 유지됩니다. 시스템 안의 이미터는 오른쪽 클릭 메뉴의 Create Asset From This로 에셋으로 만들 수 있습니다. 다시 쓸 때는 부모와의 상속, 고른 버전, 로컬에서 덮어쓴 값을 확인합니다. 독립된 복사본에는 부모를 고쳐도 그 변경이 저절로 전달되지 않습니다.
자주 쓰는 복잡한 계산이나 특정 로직은 모듈 스크립트(Module Script)로 저장해 다시 씁니다. 거리에 따른 힘이나 직접 만든 충돌 처리가 그 예입니다. 스크래치 패드에서 만든 모듈은 에셋으로 내보내 나이아가라 모듈 스크립트로 만들 수 있으며, 이때 바깥에서 받는 입력과 의존 관계를 정리하고, 공유하는 버전을 바꿨을 때의 영향을 확인합니다.
새 시스템을 만들 때 제공되는 템플릿도 적극적으로 씁니다. 기본 구조가 갖춰져 있어 시작하기 쉽고 배우는 데도 도움이 됩니다. 쓸모 있는 시스템은 직접 템플릿으로 저장해 다시 쓸 수도 있습니다.
사용자 파라미터의 약속
사용자 파라미터를 잘 쓰면 시스템이 유연해지고 유지보수도 쉬워집니다. 블루프린트나 레벨 시퀀서, 게임 코드에서 효과의 색이나 크기, 생성률, 세기 같은 핵심 속성을 쉽게 바꿀 수 있도록 사용자 파라미터로 노출합니다. 그러면 아티스트는 나이아가라에서 효과를 만들고 사용자 파라미터를 노출하고, 프로그래머는 그 파라미터를 게임 로직에 연결해 상호작용을 만드는 식으로 일을 나눌 수 있어, 서로의 작업에 주는 영향이 줄어듭니다.
값을 시험하거나 균형을 맞출 때는 컴포넌트에 Set Niagara Variable을 부르거나, 프로젝트에 연결한 디버그 UI로 값을 넘깁니다. 사용자 파라미터가 저절로 콘솔 변수로 등록되지는 않습니다. 그래서 파라미터마다 이름과 타입, 단위, 기본값, 허용 범위, 그리고 Spawn과 Update 가운데 어디서 읽는지를 함께 기록해 둡니다.
이 약속을 하나 만들어 봅니다. 시험용 시스템에 Float 사용자 파라미터 User.Intensity를 추가하고, 기본값 0.5, 허용 범위 0에서 1, 단위는 비율로 정합니다. 그리고 Spawn Rate의 입력을 고정값 80에서 80 × Clamp(User.Intensity, 0, 1)을 읽는 계산으로 바꿔 연결해야, 이 값이 생성량에 영향을 줍니다. 파라미터를 추가하거나 컴포넌트에서 값을 넣는 것만으로 모듈의 입력이 저절로 연결되지는 않습니다. 같은 컴포넌트를 대상으로 정확한 이름과 Float 타입으로 값을 넣고, 켜진 뒤에도 그 값을 읽는 모듈과 단계에서 바뀐 값이 쓰이는지 확인합니다.
이렇게 연결했다면 Intensity가 0.25일 때 요청되는 생성률은 80 × 0.25 = 20개/초입니다. 실제로 살아 있는 입자의 수는 수명과 버스트, 실행 상태, 컬링도 함께 따져야 합니다. 또 프로젝트의 기본 이펙트 타입과 시스템마다 지정한 값도 구분합니다. 공식 프로젝트 설정 문서에 따르면 기본 이펙트 타입은 비어 있을(null) 수 있으므로, 기본값을 정했다고 모든 시스템이 같은 정책을 따른다고 읽지 않습니다.
버전 관리와 연결하기
팀 프로젝트에서는 Git이나 Perforce 같은 버전 관리 시스템(VCS)으로 나이아가라 에셋을 관리합니다. Perforce에서는 고치기 전에 체크아웃하고 독점 잠금 설정을 확인합니다. Git에서는 커밋과 공유를 위한 push를 구분하고, 바이너리 파일을 여러 사람이 동시에 고치지 않도록 팀의 담당 규칙이나 Git LFS의 잠금 정책을 정합니다.
나이아가라 에셋은 바이너리 파일이라 충돌이 생기면 손으로 합치기 어렵습니다. 그래서 자주 커밋하고, 충돌을 줄이는 작업 규칙을 미리 정하는 것이 중요합니다.
에셋을 옮기거나 이름을 바꾸면 이전 경로에 리디렉터(redirector)가 남습니다. 콘텐츠 브라우저의 Filters 메뉴에서 Other Filters > Show Redirectors를 켜 리디렉터를 보이게 한 뒤, 리디렉터를 오른쪽 클릭해 Fixup을 실행하거나 폴더의 오른쪽 클릭 메뉴에서 리디렉터를 정리하는 항목을 실행해 참조를 새 경로로 고칩니다. 이때 참조하는 패키지를 쓸 수 있게 열어 다시 저장할 수 있어야 하며, 정리에 실패한 리디렉터를 파일 탐색기에서 직접 지우지 않습니다. 리디렉터가 참조를 이어 주고 정리되는 과정은 언리얼 기본 교재의 에셋 브라우저와 폴더 구조에서 자세히 다룹니다.
공용 설정을 바꾼 뒤에는 영향을 받는 시스템과 바깥에서 사용자 파라미터를 부르는 곳을 확인하고, 대표 맵과 대상 플랫폼의 패키지에서 같은 기능과 성능 예산이 유지되는지 비교합니다.
정리
- 나이아가라에 영향을 주는 설정은
Plugins > Niagara와 렌더링, 물리 설정, 그리고 이미터마다의Sim Target과 이펙트 타입처럼 여러 곳에 나뉘어 있습니다. - 에셋에는
NS_,NE_같은 일관된 접두사와[효과 종류]_[하위 종류]_[설명]형태의 이름을 붙이고, 효과의 종류별로 폴더를 나눕니다. - 잘 만든 이미터와 모듈은 에셋으로 만들어 다시 쓰며, 부모와의 상속과 버전, 덮어쓴 값을 확인합니다.
- 사용자 파라미터는 이름과 타입, 단위, 기본값, 범위, 읽는 단계를 약속으로 남기고, 모듈의 입력에 실제로 연결해야 값이 쓰입니다.
- 바이너리 에셋은 잠금과 자주 하는 커밋으로 충돌을 줄이고, 옮긴 뒤에는 에디터에서 리디렉터를 정리합니다.
연습 문제
1. 범위를 넘는 값과 연결되지 않은 입력
같은 계산에 Intensity 1.5가 들어오면 Clamp를 거친 생성률은 얼마일까요? 또 모듈이 여전히 고정값 80을 읽는 상태에서 Intensity 0.25를 넣으면 같은 20개/초가 나올까요? 사용자 파라미터는 저절로 콘솔 변수가 될까요?
해설 보기
1.5는 Clamp로 1에 묶이므로 생성률은 80 × 1 = 80개/초입니다.
모듈이 고정값 80을 읽고 있다면 넣어 준 0.25를 쓰지 않으므로, 이 연결에서 기대한 20개/초는 나오지 않고 80개/초 그대로입니다. 파라미터의 이름과 타입이 맞아도 모듈이 실제로 그 값을 읽도록 연결해야 합니다. 또 사용자 파라미터는 저절로 콘솔 변수로 등록되지 않습니다. 이 수치는 정해 둔 입력으로 계산한 모델이며, 엔진에서 실행해 확인한 결과는 아닙니다.
2. 부모를 고쳐도 바뀌지 않는 이미터
공용 불꽃 이미터 에셋의 색을 바꿨는데, 어떤 시스템의 불꽃은 바뀌지 않습니다. 무엇을 확인해야 할까요?
해설 보기
그 시스템의 이미터가 공용 에셋을 부모로 상속하고 있는지, 아니면 독립된 복사본인지 확인합니다. 독립된 복사본이라면 부모를 고쳐도 변경이 전달되지 않습니다.
상속하고 있다면 그 시스템이 고른 부모의 버전과, 그 시스템 안에서 색을 로컬로 덮어쓴 값이 있는지 확인합니다. 덮어쓴 값이 있으면 부모의 변경보다 그 값이 우선합니다.
3. 이름을 바꾼 뒤 깨진 참조
NS_Fire를 NS_Explosion_Fire로 이름을 바꾸고 폴더도 옮겼더니, 패키징할 때 경고가 납니다. 다른 사람은 파일 탐색기에서 남은 파일을 지우자고 합니다. 어떻게 해야 할까요?
해설 보기
이름을 바꾸거나 옮긴 자리에는 이전 경로를 가리키는 리디렉터가 남고, 그것을 참조하는 에셋이 아직 새 경로로 고쳐지지 않았을 수 있습니다. 파일 탐색기에서 남은 파일을 지우면 그 리디렉터를 참조하던 에셋이 깨집니다.
에디터의 콘텐츠 브라우저에서 리디렉터를 보이게 하고 오른쪽 클릭해 Fixup을 실행하거나, 폴더의 리디렉터 정리 항목을 실행합니다. 참조하는 패키지를 쓸 수 있게 열어 다시 저장해야 하므로, 버전 관리에서 그 패키지들을 체크아웃하거나 잠근 뒤 진행합니다.
설정의 위치는 Epic의 나이아가라 프로젝트 설정 문서에서, 공유하는 이미터와 모듈의 버전은 모듈과 이미터의 버전 관리 문서에서 확인할 수 있습니다.
다음 글 간단한 버전 관리 방법에서는 나이아가라 에셋을 Git이나 Perforce로 관리할 때의 규칙과, 나이아가라 안의 모듈과 이미터 버전 기능을 살펴봅니다.