이벤트 기반 파티클 스폰
피격·획득·충돌 이벤트가 발생한 순간에만 시스템을 스폰하고 위치·충격 강도 같은 데이터를 사용자 변수로 전달합니다.
피격·아이템 획득·발사체 충돌처럼 한 번 발생하는 사건에는 필요한 순간에 짧은 Niagara System을 생성합니다. 사건의 위치·방향·강도를 초기값으로 전달하면 같은 효과를 여러 상황에 재사용할 수 있습니다.
위치 스폰과 부착 스폰
- Spawn System at Location: 월드의 지정 위치·회전에 시스템을 만듭니다. 스파크·폭발처럼 발생 지점에 남을 효과에 적합합니다.
- Spawn System Attached: Scene Component에 부착하고 Attach Point Name과 위치 규칙을 지정합니다. Actor 자체를 Attach To Component에 넣지 않습니다. 생성 후 입자까지 따라갈지는 Local Space 설정도 확인합니다.
두 경로 모두 반환 Niagara Component, 초기 활성화, 종료와 회수 정책을 함께 다룹니다. 일반 Spawn 노드에는 임의 변수 목록을 싣는 Parameters 핀이 없습니다. Spawn System at Location 입력·출력
초기값을 먼저 전달하는 순서
활성화 전에 초기값을 전달하는 스폰
게임 Hit→AutoActivate=false 생성→반환 유효성→User 설정→Activate/첫 Burst 읽기의 초기값 경쟁을 피하는 상태 전이 과정이다.
NIAGARA · CH8-3
User 값을 설정한 뒤 Activate합니다
Auto Activate를 끈 상태로 생성하면 첫 Burst가 필요한 초기값을 읽기 전에 값을 전달할 수 있습니다. 도식은 유효한 반환 컴포넌트의 경로입니다.
유효한 반환값
User 이름과 타입을 시스템에 노출한 값과 맞춥니다. 예제의 User.ImpactStrength 0 / 0.5 / 1은 첫 Burst의 0 / 50 / 100개에 대응합니다.
생성 실패
반환값이 무효라면 User 설정과 Activate를 건너뜁니다. 효과 생성 실패가 게임의 명중·피해 처리와 발사체 정리를 막지 않게 합니다.
위치·정리 책임
Location 생성과 Scene Component에 Attach하는 생성은 다릅니다. Local Space와 회전을 함께 확인하고, 유한 효과의 Auto Destroy와 게임 발사체의 Destroy를 각각 설정합니다.
게임의 Hit 이벤트로 생성하는 효과입니다. Niagara 내부 입자 이벤트와 같은 통로가 아닙니다.
Spawn이 실패해도 게임의 충돌 처리는 완료합니다. 효과는 유한 수명과 Auto Destroy로, 발사체는 게임 로직에서 각각 정리합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 원 도표의 관계/값과 동일하다. 유효하게 생성된 뒤 User 값을 먼저 설정하고 Activate한다. 무효 분기는 패널에서 확인한다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 비활성 생성 게임 Hit 뒤 AutoActivate=false로 컴포넌트를 만든다. |
|
|
| User 설정 유효한 반환 컴포넌트에 User 값을 넣는다. |
|
|
| Activate 활성 후 첫 Burst가 설정된 User 값을 읽는다. |
|
|
활성화 전에 초기값을 전달하는 스폰
게임 Hit→AutoActivate=false 생성→반환 유효성→User 설정→Activate/첫 Burst 읽기의 초기값 경쟁을 피하는 상태 전이 과정이다.
NIAGARA · CH8-3
User 값을 설정한 뒤 Activate합니다
Auto Activate를 끈 상태로 생성하면 첫 Burst가 필요한 초기값을 읽기 전에 값을 전달할 수 있습니다. 도식은 유효한 반환 컴포넌트의 경로입니다.
유효한 반환값
User 이름과 타입을 시스템에 노출한 값과 맞춥니다. 예제의 User.ImpactStrength 0 / 0.5 / 1은 첫 Burst의 0 / 50 / 100개에 대응합니다.
생성 실패
반환값이 무효라면 User 설정과 Activate를 건너뜁니다. 효과 생성 실패가 게임의 명중·피해 처리와 발사체 정리를 막지 않게 합니다.
위치·정리 책임
Location 생성과 Scene Component에 Attach하는 생성은 다릅니다. Local Space와 회전을 함께 확인하고, 유한 효과의 Auto Destroy와 게임 발사체의 Destroy를 각각 설정합니다.
게임의 Hit 이벤트로 생성하는 효과입니다. Niagara 내부 입자 이벤트와 같은 통로가 아닙니다.
Spawn이 실패해도 게임의 충돌 처리는 완료합니다. 효과는 유한 수명과 Auto Destroy로, 발사체는 게임 로직에서 각각 정리합니다.
이 예의 조건
- 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
- 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
관계도의 보충 설명
| 범위 | 원문 |
|---|---|
| 관계·조건 설명 | 원 도표의 관계/값과 동일하다. 유효하게 생성된 뒤 User 값을 먼저 설정하고 Activate한다. 무효 분기는 패널에서 확인한다. |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 비활성 생성 게임 Hit 뒤 AutoActivate=false로 컴포넌트를 만든다. |
|
|
| User 설정 유효한 반환 컴포넌트에 User 값을 넣는다. |
|
|
| Activate 활성 후 첫 Burst가 설정된 User 값을 읽는다. |
|
|
Auto Activate를 끄고 생성한 뒤 반환 컴포넌트가 유효하면 타입에 맞는 Set Niagara Variable로 User.* 값을 설정하고 Activate합니다. 시스템 시작 후 Spawn 값만 바꾸면 이미 생성된 Burst에 반영되지 않을 수 있습니다. 이름·타입·모듈 연결까지 맞춰야 합니다.
변수 생성, 값 전달, 모듈에서 읽기는 각각 확인합니다
Float User.ImpactStrength를 선언하는 것만으로 Spawn Count가 바뀌지는 않습니다. Count 식이 실제로 이 User 변수를 읽어야 하며, Blueprint의 이름·Float 타입·Target 컴포넌트가 일치해야 합니다. 예를 들어 첫 Burst가 기본값 1을 이미 읽어 100개를 요청한 뒤 값을 0.6으로 바꿨다면, 그 변경은 이미 요청한 첫 Burst를 60개로 되돌리지 않습니다. 이 사례는 ‘첫 Burst가 값을 읽은 뒤’라는 조건이며, Activate 호출과 첫 시뮬레이션이 같은 순간이라는 가정을 하지 않습니다. 먼저 설정하고 Activate하면 이 초기값 경쟁을 피할 수 있습니다.
직접 해 보기: 총알 충격 스파크
Niagara 시스템 준비
기본 Sprite 시스템을 복제해 NS_ImpactSparks를 만듭니다. 연속 Spawn Rate를 제거하고 Emitter State를 Self/Once로 설정합니다. 수명 종료 입자가 모두 마무리되면 시스템도 완료되는 설정을 사용합니다.
이 실습은 Emitter State의 유한 Loop Duration과 Inactive Response=Complete를 확인해, 새 입자 생성이 끝난 후 남은 입자도 수명을 마치도록 정합니다. Particle Lifetime이 0.5초 이하라는 조건만으로 반복 중인 Emitter/System까지 완료되지는 않습니다. Auto Destroy는 Niagara 컴포넌트의 완료 후 회수 정책이며, 발사체 Destroy Actor의 대체 노드가 아닙니다.
Float User.ImpactStrength를 만들고 기본값을 1로 둡니다. Emitter Update의 Spawn Burst Instantaneous에서 시간 0에 RoundToInt(Clamp(ImpactStrength, 0, 1) × 100)개를 생성합니다. Spawn Count는 정수이며 0이면 생성하지 않는 의도적인 경우입니다.
Particle Spawn의 Initialize Particle에서 Lifetime 0.2~0.5초, Sprite Size 2~5 cm, Color (1,0.8,0,1)을 설정합니다. Add Velocity에서는 로컬 +Z 중심의 좁은 원뿔 방향에 속력 100 cm/s를 줍니다. 모든 방향으로 퍼지는 완전한 구면 분포는 시스템 회전을 바꿔도 표면 방향성이 드러나지 않습니다.
초기 속도 공간을 Local로 지정해 시스템의 +Z 회전을 반영하고, 입자는 생성 후 월드에 남도록 Emitter Local Space는 끕니다. Particle Update에 Particle State, Gravity Force, Drag 5, Solve Forces and Velocity를 둡니다.
Sprite Renderer에 프로젝트의 Additive/Unlit 스파크 머티리얼을 할당합니다. Particle Color RGB와 Alpha가 연결되어야 합니다. 특정 M_Fire_SubUV 에셋이 기본 설치에 있다고 가정하지 않습니다.
발사체 Blueprint
발사체가 없다면 Sphere Collision을 루트로, Projectile Movement의 Updated Component를 해당 Sphere로 구성합니다. 이동 속도와 벽을 차단하는 collision preset을 정하고, 이동 방식에 맞는 Hit 이벤트 발생 설정을 확인합니다.
BP_BulletProjectile의 Sphere에서 On Component Hit 이벤트를 추가합니다. 이 실습은 blocking Hit를 사용합니다. Overlap은 위치·법선·충격량이 같은 방식으로 제공되는 대체 이벤트가 아닙니다.
중복 Hit를 막는 처리 Bool을 먼저 검사하고 한 번 처리한 뒤에는 다시 스폰하지 않게 합니다. Hit 구조체를 Break Hit Result로 나누어 Impact Point와 Impact Normal을 얻습니다.
처리 Bool이 false인 경로에 들어오면 다른 효과 호출에 앞서 true로 바꿉니다. 이후 Spawn이 실패하더라도 이번 충돌을 처리한 상태는 유지합니다. 시각 효과 실패를 이유로 Bool을 다시 끄면 같은 Hit가 또 와서 게임플레이 처리까지 중복될 수 있습니다. 이 실습의 Bool은 이 발사체 인스턴스 안의 중복을 막는 용도입니다.
미리 저장한 충돌 전 발사체 속력 또는 게임에서 정의한 충격 강도를 Map Range Clamped로 0~1로 변환합니다. 예를 들어 0~3000 cm/s를 0~1로 매핑할 수 있습니다. Swept 이동의 Normal Impulse가 0일 수 있고 충돌 후 속도는 이미 바뀌었을 수 있으므로 항상 충격량 핀만 사용하지 않습니다.
속력은 저장한 Velocity 벡터의 길이이며 X 성분 하나가 아닙니다. (-1800,0,0) cm/s로 움직여도 속력은 양수 1800 cm/s=18 m/s이고 강도는 1800/3000=0.6입니다. 이 0~1 값은 시각 효과의 제어값입니다. 질량·충돌 시간 등을 사용한 물리적 충격량이나 피해량을 이 비율만으로 계산했다고 해석하지 않습니다.
Spawn System at Location의 System Template에 NS_ImpactSparks를 넣고 Location에는 Impact Point, Rotation에는 Make Rot From Z(Impact Normal)을 연결합니다. Scale은 1, Auto Activate는 false, Auto Destroy는 true, Pooling Method는 None으로 시작합니다.
Return Value가 유효한지 확인합니다. 유효하면 그 컴포넌트를 Target으로 Set Niagara Variable (Float)를 호출해 User.ImpactStrength를 전달하고 Activate합니다. 유효하지 않을 경우에도 게임플레이의 충돌 처리는 진행되어야 합니다.
효과 처리 뒤 Destroy Actor로 발사체를 파괴합니다. 컴파일·저장 후 발사 경로에서 테스트하고 강도 0, 0.5, 1에 대해 생성 수 0, 50, 100을 예상 기준으로 비교합니다. 발사체를 먼저 파괴한 뒤 잠재 실행 경로에 의존하지 않습니다.
예시: 저장한 충돌 전 속력으로 첫 Burst 계산하기
충돌 전 속력이 1800 cm/s이고 0~3000을 0~1로 매핑하면 User.ImpactStrength는 0.6입니다. 유효한 비활성 반환 컴포넌트에 이를 먼저 전달하고 Activate하면 문제의 Burst 식은 60개를 요청합니다. 충돌 뒤 0이 된 속력을 읽어 0개로 바꾸는 경로와 다릅니다. 같은 발사체의 Hit 알림이 다시 와도 처리 Bool이 이미 켜져 있으면 두 번째 효과를 생성하지 않습니다.
별도로 속력 3600 cm/s를 기록했지만 Spawn 반환값이 무효라고 가정합니다. 계산상 요청할 강도와 Count는 얼마이고, 실제 생성된 입자까지 100개라고 적어도 될까요? 발사체 정리와 게임플레이 처리가 계속돼야 하는지도 설명하세요.
계산값과 유효한 생성 경로를 구별하기
매핑 결과는 상한 1로 제한되고 Count 식은 100입니다. 그러나 무효 반환값에는 User 설정·Activate를 하지 않으므로 이 실패 경로에서 100개가 생성됐다고 기록하지 않습니다. 게임의 충돌 처리를 마치고 발사체도 정리합니다. 효과 생성은 피해 판정 성공의 전제 조건이 아닙니다.
실패 지점 분리
효과가 보이지 않으면 Hit 발생 여부 → Spawn 반환값 → User 이름/타입 → Burst와 활성화 순서 → 머티리얼·Bounds 순서로 확인합니다. 잘못된 방향은 Impact Normal, 시스템의 로컬 +Z, 초기 속도 공간을 비교합니다. 효과가 남으면 개별 Lifetime뿐 아니라 Emitter/System 완료와 Auto Destroy를 확인합니다.
유효한 컴포넌트에서 강도 0을 전달해 Count=0이 된 것은 설정한 식의 정상 결과입니다. 반환값이 무효인 실패와 구별하세요. 반대로 Count=60이라는 계산은 Burst 요청 기준이며, 화면에서 60개가 모두 보였다는 관측은 아닙니다. 머티리얼·Bounds·Scalability의 컬링 조건을 별도로 확인합니다. 생성 수와 화면의 픽셀 수를 같은 검증 항목으로 기록하지 않습니다.
이 흐름은 Blueprint 사건이 시스템을 생성하는 방식입니다. Niagara 내부 Event Handler가 Blueprint의 임의 페이로드를 자동 수신하는 구조와 혼동하지 않습니다. 반복되는 많은 충격에는 내장 풀링이나 Data Channels를 별도로 비교하되 반환된 컴포넌트의 수명 규칙을 지킵니다.
연습: 첫 Burst와 실패 경로 추적하기
- 충돌 전 저장한 Velocity=(-1800,0,0) cm/s입니다. 위의 0~3000 매핑과 Count 식을 사용합니다. 속력을 cm/s·m/s로, User 강도와 요청 Count를 구하세요. X 성분을 그대로 강도 계산에 넣으면 왜 다른 결과가 되나요?
- 반환 컴포넌트가 유효하고 User 강도 0을 먼저 설정한 경우와, 계산된 강도는 1이지만 Spawn 반환값이 무효인 경우를 비교하세요. 각 경로에서 Set/Activate 여부와 ‘요청할 Count 식’·‘실제 생성 관측’을 구별해 적으세요.
- 실수로 기본값 1을 읽는 첫 Burst가 이미 실행되어 100개를 요청한 뒤 User 값을 0.6으로 바꿨습니다. 첫 요청이 60개로 바뀌나요? 이 실습에서 어떤 실행 순서를 사용해야 그 문제를 피할 수 있나요?
- 같은 발사체 인스턴스의 처리 Bool은 false로 시작하고 Hit 알림이 두 번 왔습니다. 첫 알림에서 Bool을 먼저 true로 바꾼 뒤 Spawn 반환값은 무효였습니다. 게임플레이 처리와 발사체 정리를 한 번 진행한다는 정책입니다. Spawn 시도·Set/Activate·게임플레이 처리는 각각 몇 번인가요? 시각 효과 실패 때문에 Bool을 false로 되돌려도 되나요?
속력·요청 값·이미 처리한 사건 풀이
- 벡터 길이는 1800 cm/s=18 m/s, 강도는 0.6, Count는 60입니다. X 성분 -1800을 그대로 매핑하면 하한으로 제한되어 0이 되지만, 이동 방향이 음수라고 속력까지 음수인 것은 아닙니다.
- 유효한 경로는 강도 0을 Set한 뒤 Activate하며 Count 식은 0입니다. 무효 경로의 식은 100이지만 컴포넌트에 Set/Activate하지 않으며 100개가 실제 생성됐다고 기록할 수 없습니다. 어느 쪽에서도 계산만으로 렌더링 관측을 대신하지 않습니다.
- 이미 읽어 요청한 첫 100개를 그 뒤의 변수 변경으로 60개로 되돌리지 않습니다. Auto Activate=false로 생성→유효성 확인→User 강도 설정→Activate 순서로 첫 Burst가 필요한 초기값을 읽게 합니다.
- Spawn 시도는 첫 알림의 1번, Set/Activate는 0번, 게임플레이 처리와 정리는 각각 1번입니다. 두 번째 알림은 Bool이 true여서 처리 경로를 건너뜁니다. 실패한 것은 시각 효과 생성이므로 이미 처리한 사건의 Bool을 되돌려 게임플레이를 중복 처리하지 않습니다.