동적 매개변수 시스템의 기초
시스템·이미터·모듈·블루프린트 사이에 사용자 매개변수를 전달해 실행 중 파티클 속성을 외부 값으로 제어합니다.
캐릭터가 빨리 달릴수록 먼지가 더 많이 일고, 체력이 낮아질수록 주변의 효과가 붉게 바뀌게 하고 싶다고 해 봅시다. 지금까지처럼 모듈의 입력에 숫자를 직접 적어 두면 이런 변화를 만들 수 없습니다. 게임이 돌아가는 동안 바깥에서 값을 넘겨받아 모듈의 입력에 연결해야 합니다. 이 글에서는 나이아가라 안에서 값이 어떤 범위에 저장되고 어떻게 흐르는지 살펴보고, 사용자 파라미터(User Parameters)를 만들어 블루프린트에서 효과의 초기 속도를 바꿔 봅니다.
이름이 비슷한 기능이 여럿 있으므로 먼저 구분해 둡니다. 이 글에서 말하는 동적 매개변수는 사용자 파라미터와 모듈 입력의 연결로 게임 중에 효과를 제어하는 방식입니다. 머티리얼로 값을 넘기는 동적 머티리얼 파라미터(Dynamic Material Parameter)의 채널이나, 모듈의 입력값을 계산하는 나이아가라의 동적 입력(Dynamic Input)과는 다른 것입니다.
고정값 대신 연결된 값
모듈의 입력, 예를 들어 Spawn Rate의 생성 수나 Add Velocity의 속도는 보통 에디터에서 숫자를 직접 넣어 고정합니다. 동적 매개변수를 쓰면 이 입력을 플레이어의 체력이나 환경의 온도, 흐르는 시간 같은 게임 안의 다른 값에 연결해 플레이 중에 바꿀 수 있습니다.
이 흐름은 입력과 출력으로 생각하면 이해하기 쉽습니다. 각 모듈은 입자의 위치나 속도, 색 같은 속성을 계산해 다른 모듈이나 렌더러가 쓸 수 있게 내놓습니다. Initialize Particle은 입자의 초기 색을 내놓고, Scale Color는 수명에 따라 바뀐 색을 내놓는 식입니다. 반대로 각 모듈은 일을 하려고 입력을 받는데, 그 입력은 고정값일 수도 있고, 앞 모듈이 내놓은 값일 수도 있고, 바깥에서 넘겨받은 값일 수도 있습니다. 동적 매개변수는 이 입출력의 흐름을 유연하게 만들어, 필요한 정보가 어디서 오든 모듈의 입력에 연결할 수 있게 합니다.
값이 저장되는 범위
나이아가라의 값은 어느 범위에 저장되는지에 따라 이름 앞에 붙는 네임스페이스가 다릅니다. User는 바깥에서 넣는 입력이고, System, Emitter, Particles는 각각 시스템과 이미터, 입자 하나의 범위에 저장되는 값입니다. 동적 입력은 이런 범위가 아니라, 입력값을 계산해 내는 작은 스크립트입니다. 값이 저장되는 범위와 값을 계산하는 방법을 나누어 생각하면 헷갈리지 않습니다.
시스템과 이미터 사이
하나의 시스템은 여러 이미터를 담으며, 시스템 범위의 값은 여러 이미터의 입력에서 함께 읽을 수 있습니다. 예를 들어 시스템에 GlobalScale이라는 값을 두고 각 이미터의 입자 크기나 속도에 곱하면, 시스템 전체의 크기를 한 번에 조절할 수 있습니다.
반대 방향은 그렇게 간단하지 않습니다. 입자마다의 값이나 이미터마다의 결과를 모아 시스템 값으로 올리려면 따로 구현해야 하며, 네임스페이스만 바꾼다고 모이지는 않습니다. 전체 살아 있는 입자 수 같은 값은 디버거에서 확인하고, 그 값을 시뮬레이션의 입력으로 다시 써야 한다면 지원되는 데이터 전달 방식과 실행 순서를 따로 설계합니다.
모듈과 모듈 사이
가장 기본적인 흐름은 스택의 모듈 사이에서 일어납니다. 스택에서는 앞의 모듈이 파라미터 맵에 쓴 속성을 뒤의 모듈이 읽습니다. 예를 들어 Initialize Particle이 정한 처음 Color를 Scale Color가 읽어, 수명에 따른 색 변화의 기준 색으로 씁니다. 이것은 모듈 안의 그래프에서 핀을 잇는 것과는 다른 수준의 흐름입니다.
이미터 사이에 값을 넘기는 것은 또 다릅니다. CPU 충돌 이벤트를 다른 이미터의 이벤트 핸들러로 보내 충돌한 자리에 새 입자를 만들 수는 있지만, Particle Update의 위치를 Emitter Update의 버스트 입력에 바로 연결할 수는 없습니다.
블루프린트와 C++에서
동적 매개변수를 가장 많이 쓰는 곳은 블루프린트(Blueprint)나 C++에서 파티클 시스템의 값을 직접 바꾸는 경우입니다. 캐릭터의 지금 이동 속도를 블루프린트에서 넘겨 Spawn Rate의 입력에 연결하면, 빨리 달릴수록 먼지나 연기가 많이 납니다. 어떤 지점의 온도를 읽어 효과의 색 입력으로 넘기면 온도가 높을수록 불꽃을 밝고 붉게 만들 수 있고, 플레이어의 체력에 따라 캐릭터 주변 효과의 색이나 세기를 바꿀 수도 있습니다.
입력의 값을 정하는 방법
모듈의 입력 옆 드롭다운을 열면 값을 정하는 방법을 고를 수 있습니다. 상수를 직접 넣거나, 다른 파라미터에 연결하거나, Random Range나 커브 같은 동적 입력으로 계산하게 할 수 있습니다. 메뉴의 항목과 지원되는 입력은 자료형과 모듈 버전에 따라 다릅니다. 동적 입력을 고르는 것만으로 바깥에서 넣을 수 있는 사용자 파라미터가 생기지는 않는다는 점도 기억해 둡니다.
더 깊이: 스택에서 고친 상수가 머무는 곳
스택에서 모듈 입력에 넣은 상수는 빠른 반복 파라미터(rapid iteration parameter)로 다루어집니다. 나이아가라 스크립트의 API 문서는 RapidIterationParameters를 UI에서 고쳐 가며 반복하는 최상위 값을 모두 담는 파라미터 저장소라고 설명합니다. 이름 그대로 효과를 만드는 동안 값을 자주 바꿔 보기 좋게 따로 보관해 두는 값들입니다.
시스템 속성의 Bake Out Rapid Iteration은 이 값들을 일반 컴파일에 구워 넣을지 정합니다. System Properties 문서는 이 설정이 실행 성능을 높일 수 있지만, 그 에셋을 고쳐 가며 반복하기는 훨씬 어려워진다고 설명합니다. 그래서 값을 계속 다듬는 동안에는 켜지 않고, 효과의 값이 거의 정해진 뒤 같은 장면에서 켰을 때와 껐을 때의 비용을 비교해 정하는 편이 알맞습니다.
바깥에서 처음 속도 넘기기
예제로 블루프린트에서 효과의 초기 속도를 바꿔 봅니다. 먼저 시스템의 사용자 파라미터에 Vector 타입의 User.CustomVelocity를 만들고 기준값을 정합니다. 이 값은 속도 벡터이므로, 월드의 위치를 나타내는 Position 타입과 구분합니다. 다음으로 Particle Spawn의 Add Velocity를 선택하고 Velocity 입력을 User.CustomVelocity에 연결하며, 모듈의 좌표 공간도 정해 둡니다.
그다음 값을 넣습니다. 레벨에 놓인 나이아가라 컴포넌트의 디테일 패널에서 사용자 파라미터 값을 바꾸거나, 블루프린트에서 그 컴포넌트를 대상으로 Set Niagara Variable (Vector3) 노드를 써서 같은 이름과 타입의 값을 넣습니다. 이때 노드의 대상이 다른 인스턴스를 가리키고 있지 않은지 참조를 확인합니다.
값을 바꾼 뒤에는 새로 생기는 입자를 비교합니다. 이 입력은 Particle Spawn에서만 읽으므로, 이미 살아 있는 입자의 속도가 다시 초기화되지는 않습니다. 기존 입자에도 영향을 주고 싶다면 Particle Update에서 이 값을 어떤 힘이나 속성으로 읽을지 따로 설계해야 합니다. 마지막으로 Particle Update에 위치를 계산하는 모듈이 있는지, 그 뒤에서 Velocity를 다시 쓰는 모듈이 없는지 확인합니다. 값이 제대로 넘어왔더라도 Solve Forces and Velocity가 없거나 다른 모듈이 덮어쓰면 기대한 움직임이 나오지 않습니다.
Spawn에서만 읽은 입력은 새 입자에 적용됩니다
User X 100으로 A 생성→값 200 변경→새 B 200/A 100 유지의 명확한 입자별 초기값 소비 시점이다.
NIAGARA · CH4-2
Spawn에서만 읽은 입력은 새 입자에 적용됩니다
User.CustomVelocity를 Particle Spawn의 Add Velocity에 연결한 본문 예입니다. 기본 초기 X 속도는 0이며 User X를 100에서 200cm/s로 바꿉니다. 다른 속도 작성자와 힘은 없다고 가정합니다.
화살표는 생성 시점의 입력 소비와 A의 시간 경과를 나타냅니다. 변경 후 A와 B는 서로 다른 입자이며, B에서 A로 값을 전달하는 관계는 없습니다.
값 변경 전 · User X=100
입자 A 생성 → 초기 X 속도100cm/s
Particle Spawn이 그 시점의 User 입력을 읽습니다.
값 변경 후 · User X=200
기존 A → X100cm/s 유지
새 입자 B → 초기 X200cm/s
살아 있는 A의 Spawn 단계는 다시 실행되지 않습니다. B의 Spawn은 변경된 입력을 읽습니다.
작성한 값의 실제 소비 위치를 확인합니다
Blueprint에서 정확한 Niagara Component에 같은 이름·Vector 타입을 설정하고, 모듈의 입력 연결과 좌표 공간을 확인합니다.
기존 입자에도 값을 적용하려면 Particle Update에서 읽고 어떤 속성·힘으로 사용할지 따로 설계합니다. 이후 Solve나 Velocity 작성자가 결과를 바꿀 수 있습니다.
이 비교는 초기 속도 입력의 소비 시점을 나타냅니다. 위치 곡선·실제 엔진 캡처가 아니며 게임 속도 제어가 머티리얼 Dynamic Parameter 채널을 통과한다는 뜻도 아닙니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 본문·주석 | User.CustomVelocity를 Particle Spawn의 Add Velocity에 연결한 본문 예입니다. 기본 초기 X 속도는 0이며 User X를 100에서 200 cm/s로 바꿉니다. 다른 속도 작성자와 힘은 없다고 가정합니다. |
| 관계·조건 설명 | User X가 100일 때 태어난 A는 100 cm/s를 받는다. 입력을 200으로 바꾸면 새로 태어나는 B는 200 cm/s를 받지만 이미 태어난 A의 Spawn은 다시 실행되지 않아 100 cm/s를 유지한다. 다른 속도 작성자나 힘은 없다. A의 두 노드는 같은 입자의 서로 다른 시점이다. |
| 노드·연결선 라벨 | X 속도 100 cm/s |
| 노드·연결선 라벨 | X 속도 200 cm/s |
| 본문·주석 | 입자 A 생성 → 초기 X 속도 100 cm/s |
| 본문·주석 | 기존 A → X 100 cm/s 유지 |
| 본문·주석 | 새 입자 B → 초기 X 200 cm/s |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| A 생성 User X=100을 새 입자 A가 초기값으로 읽는다. |
|
|
| User 변경 게임이 User X를 200으로 바꾼다. |
|
|
| B 생성 새 입자 B가 새 초기값을 읽는다. |
|
|
Spawn에서만 읽은 입력은 새 입자에 적용됩니다
User X 100으로 A 생성→값 200 변경→새 B 200/A 100 유지의 명확한 입자별 초기값 소비 시점이다.
NIAGARA · CH4-2
Spawn에서만 읽은 입력은 새 입자에 적용됩니다
User.CustomVelocity를 Particle Spawn의 Add Velocity에 연결한 본문 예입니다. 기본 초기 X 속도는 0이며 User X를 100에서 200cm/s로 바꿉니다. 다른 속도 작성자와 힘은 없다고 가정합니다.
화살표는 생성 시점의 입력 소비와 A의 시간 경과를 나타냅니다. 변경 후 A와 B는 서로 다른 입자이며, B에서 A로 값을 전달하는 관계는 없습니다.
값 변경 전 · User X=100
입자 A 생성 → 초기 X 속도100cm/s
Particle Spawn이 그 시점의 User 입력을 읽습니다.
값 변경 후 · User X=200
기존 A → X100cm/s 유지
새 입자 B → 초기 X200cm/s
살아 있는 A의 Spawn 단계는 다시 실행되지 않습니다. B의 Spawn은 변경된 입력을 읽습니다.
작성한 값의 실제 소비 위치를 확인합니다
Blueprint에서 정확한 Niagara Component에 같은 이름·Vector 타입을 설정하고, 모듈의 입력 연결과 좌표 공간을 확인합니다.
기존 입자에도 값을 적용하려면 Particle Update에서 읽고 어떤 속성·힘으로 사용할지 따로 설계합니다. 이후 Solve나 Velocity 작성자가 결과를 바꿀 수 있습니다.
이 비교는 초기 속도 입력의 소비 시점을 나타냅니다. 위치 곡선·실제 엔진 캡처가 아니며 게임 속도 제어가 머티리얼 Dynamic Parameter 채널을 통과한다는 뜻도 아닙니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 본문·주석 | User.CustomVelocity를 Particle Spawn의 Add Velocity에 연결한 본문 예입니다. 기본 초기 X 속도는 0이며 User X를 100에서 200 cm/s로 바꿉니다. 다른 속도 작성자와 힘은 없다고 가정합니다. |
| 관계·조건 설명 | User X가 100일 때 태어난 A는 100 cm/s를 받는다. 입력을 200으로 바꾸면 새로 태어나는 B는 200 cm/s를 받지만 이미 태어난 A의 Spawn은 다시 실행되지 않아 100 cm/s를 유지한다. 다른 속도 작성자나 힘은 없다. A의 두 노드는 같은 입자의 서로 다른 시점이다. |
| 노드·연결선 라벨 | X 속도 100 cm/s |
| 노드·연결선 라벨 | X 속도 200 cm/s |
| 본문·주석 | 입자 A 생성 → 초기 X 속도 100 cm/s |
| 본문·주석 | 기존 A → X 100 cm/s 유지 |
| 본문·주석 | 새 입자 B → 초기 X 200 cm/s |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| A 생성 User X=100을 새 입자 A가 초기값으로 읽는다. |
|
|
| User 변경 게임이 User X를 200으로 바꾼다. |
|
|
| B 생성 새 입자 B가 새 초기값을 읽는다. |
|
|
위 그림은 Particle Spawn에서만 읽은 입력이 새 입자에만 적용된다는 것을 보여 줍니다. 기본 초기 X 속도는 0이고 다른 속도를 쓰는 모듈이나 힘은 없다고 가정합니다. 왼쪽의 변경 전 단계에서 User X가 100cm/s일 때 태어난 입자 A는 그 시점의 입력을 읽어 X 속도 100cm/s를 받습니다. 오른쪽의 변경 후 단계에서 User X를 200cm/s로 바꾸면, 새로 태어나는 입자 B는 바뀐 입력을 읽어 200cm/s로 시작하지만, 이미 살아 있는 A의 Spawn 단계는 다시 실행되지 않으므로 A는 100cm/s를 유지합니다. 그림의 화살표는 생성 시점에 입력을 읽는 관계와 A에게 흐른 시간을 나타내며, B에서 A로 값이 전달되는 관계는 없습니다.
그림 아래의 설명은 넣은 값이 실제로 어디서 읽히는지 확인하라고 말합니다. 블루프린트에서 정확한 나이아가라 컴포넌트에 같은 이름과 Vector 타입으로 값을 넣었는지, 모듈의 입력 연결과 좌표 공간이 맞는지 봅니다. 또 이 비교는 초기 속도 입력을 언제 읽는지를 나타낸 것이라 위치의 곡선이나 실제 엔진 화면이 아니며, 게임의 속도 제어가 머티리얼의 동적 파라미터 채널을 거친다는 뜻도 아닙니다.
비슷한 이름 구분하기
이름이 비슷한 세 가지 기능의 역할을 표로 정리하면 다음과 같습니다.
| 이름 | 역할 |
|---|---|
| 사용자 파라미터(User Parameter) | 블루프린트나 C++, 컴포넌트에서 설정하는 시스템 인스턴스의 입력 |
| 동적 입력(Dynamic Input) | 커브나 무작위 값, 수식으로 모듈의 입력값을 계산 |
| 동적 머티리얼 파라미터(Dynamic Material Parameter) | 나이아가라의 속성을 렌더러 바인딩과 채널을 거쳐 머티리얼로 전달 |
머티리얼 채널을 쓰는 경우에는 모듈의 Dynamic Material Parameter 값과 렌더러의 해당 바인딩, 머티리얼 노드의 인덱스와 채널을 서로 맞춰야 합니다. 그렇다고 속도나 생성률 같은 제어가 모두 이 머티리얼 경로를 거치는 것은 아닙니다. 머티리얼 쪽의 연결은 커스텀 머티리얼과의 통합에서 다시 다룹니다.
정리
- 동적 매개변수는 모듈의 입력을 고정값 대신 사용자 파라미터나 다른 파라미터에 연결해 게임 중에 효과를 바꾸는 방식입니다.
User는 바깥에서 넣는 입력이고System,Emitter,Particles는 각 범위의 값이며, 동적 입력은 값을 계산하는 스크립트입니다.- 시스템 값은 여러 이미터에서 읽을 수 있지만, 입자나 이미터의 값을 시스템 값으로 모으려면 따로 구현해야 합니다.
- 블루프린트에서는 정확한 컴포넌트를 대상으로 같은 이름과 타입으로
Set Niagara Variable계열 노드를 써서 값을 넣습니다. - Particle Spawn에서만 읽는 입력은 새로 태어나는 입자에만 적용되며, 이미 살아 있는 입자에 반영하려면 Particle Update에서 읽도록 설계합니다.
연습 문제
1. 두 컴포넌트에서 값 바꾸기
컴포넌트 A와 B가 같은 시스템 에셋을 쓰고, 각각 User X를 100cm/s로 설정했습니다. 입력은 Particle Spawn에서만 읽고 초기 속도는 0입니다. A의 값만 -50cm/s로 바꿨습니다. 그 뒤 A와 B에서 새로 태어난 입자의 X 속도는 얼마이며, A에서 이미 살아 있던 100cm/s 입자도 -50cm/s로 바뀔까요?
해설 보기
A의 새 입자는 -50cm/s, B의 새 입자는 100cm/s입니다. 같은 시스템 에셋을 쓴다고 해서 두 컴포넌트의 인스턴스 입력이 함께 바뀌지는 않습니다. 사용자 파라미터는 컴포넌트마다 따로 가진 값이기 때문입니다.
A에서 이미 살아 있던 입자는 Spawn 단계가 다시 실행되지 않으므로 100cm/s를 유지합니다. 결과가 기대와 다르면 블루프린트의 대상 컴포넌트와 파라미터의 이름과 타입, 그리고 모듈이 값을 읽는 그룹을 먼저 확인합니다. 이 문제에는 다시 초기화하거나 Update에서 값을 쓰는 다른 모듈이 없다고 가정했습니다.
2. 값은 넣었는데 움직임이 없다
User.CustomVelocity를 Add Velocity에 연결하고 블루프린트에서 값을 넣었습니다. 디버거로 보면 입자의 Velocity 속성은 바뀌어 있는데, 입자가 생긴 자리에서 움직이지 않습니다. 무엇을 확인해야 할까요?
해설 보기
값은 제대로 넘어왔으므로, 속도가 위치로 이어지는 단계를 확인합니다. Particle Update에 Solve Forces and Velocity가 있는지 보고, 없다면 추가합니다. 이 모듈이 없으면 속도가 위치 계산에 반영되지 않습니다.
모듈이 있다면 그 뒤에서 Velocity나 Position을 다시 쓰는 모듈이 있는지 확인합니다. 다른 모듈이 값을 덮어쓰면 넘겨받은 속도가 결과에 남지 않습니다.
3. 동적 입력을 골랐는데 블루프린트에 없다
Spawn Rate 입력에 Random Range Float 동적 입력을 연결했습니다. 그런데 블루프린트에서 이 범위의 최솟값과 최댓값을 바꾸려고 보니, 넣을 수 있는 파라미터가 없습니다. 왜 그럴까요?
해설 보기
동적 입력은 모듈의 입력값을 계산하는 스크립트일 뿐, 바깥에서 값을 넣을 수 있는 사용자 파라미터를 만들어 주지 않습니다. 그래서 동적 입력의 최솟값과 최댓값은 고정값으로 남아 있습니다.
블루프린트에서 범위를 바꾸려면 시스템에 User.MinRate와 User.MaxRate 같은 사용자 파라미터를 만들고, Random Range Float의 최솟값과 최댓값 입력을 그 파라미터에 연결합니다.
사용자 파라미터를 설정하는 위치는 Epic의 시스템 설정 레퍼런스에서 확인할 수 있습니다.
다음 글 커브와 그래디언트 데이터에서는 수명에 따라 값을 바꾸는 커브와 색 그래디언트를 만들고 모듈의 입력에 연결해 봅니다.