Niagara Data Channels 읽기: 충돌 이펙트를 모으면 무엇이 줄어들까

탄착이나 발자국처럼 짧은 이펙트가 같은 공간에 계속 생기는 장면을 생각해 봅니다. 이때 줄이고 싶은 것은 입자 수일 수도 있지만, 같은 Niagara System을 반복해서 띄우는 비용일 수도 있습니다. Niagara Data Channels 자료에서 제가 먼저 보고 싶은 지점은 바로 이 구분입니다. 화면에 남길 표현과 시스템을 운영하는 단위를 따로 생각하게 해주기 때문입니다.

이 글은 Epic의 공식 문서 네 편을 AI의 도움으로 읽고 정리한 기술자료 읽기입니다. 운영자가 Unreal에서 직접 실행한 실험이나 성능 측정은 포함하지 않습니다. 문서에 적힌 구조와, 그 구조를 도입하기 전에 확인하고 싶은 조건을 구분해서 살펴보겠습니다.

데이터를 나누는 기능과 시스템을 모으는 사용법

Niagara Data Channels Overview는 NDC를 정해진 payload를 가진 데이터 흐름으로 설명합니다. 게임 코드와 Niagara, 또는 서로 다른 Niagara System이 정보를 주고받는 통로입니다. 충돌 효과를 한데 모으는 것은 이 통로를 활용하는 대표적인 사용법이지, Data Channel 자체가 충돌 전용 기능이라는 뜻은 아닙니다.

개별 탄착마다 시스템을 생성하는 대신, 전달된 충돌 정보를 기존의 공유 시뮬레이션이 받아 입자를 만드는 구조를 생각할 수 있습니다. 가령 위치와 표면 방향, 효과의 종류를 payload로 설계한다면, 발생 사실을 알리는 쪽과 실제 표현을 만드는 쪽의 역할이 나뉩니다. 이 필드 구성은 이해를 위한 예시이며 모든 채널에 그대로 요구되는 표준 형식은 아닙니다.

여기서 “하나로 모은다”는 표현을 레벨 전체의 시스템이 반드시 하나가 된다는 뜻으로 읽으면 곤란합니다. 문서는 island마다 이벤트를 듣는 listener system을 설명합니다. 따라서 먼저 확인할 것은 이벤트가 어느 공간 단위에 들어가고, 그 단위를 어떤 시스템이 담당하는가입니다. 이벤트를 공유한다고 화면의 입자가 자동으로 줄어드는 것도 아닙니다.

Pooling과 공유 시뮬레이션은 줄이는 비용이 다르다

처음에는 이미 Pooling을 쓰고 있다면 NDC가 더 필요한지 궁금했습니다. Scalability and Best Practices를 함께 읽으면 두 접근의 관심사가 다르다는 점이 보입니다. Pooling은 사용이 끝난 컴포넌트를 재사용해 반복 할당과 가비지 컬렉션 비용을 줄입니다. 문서는 재활성화의 부담까지 사라지는 것은 아니라고 설명합니다.

살펴볼 방식	먼저 달라지는 부분	별도로 확인할 부분
개별 시스템과 Pooling	이미 할당한 컴포넌트의 재사용	동시에 활성인 인스턴스 수와 재활성화 부담
기존 시스템에 이벤트 전달	새 인스턴스 대신 공유 시뮬레이션에서 입자 생성	공간 분할, 이벤트 전달과 수명 관리

이 표는 어느 쪽이 항상 빠르다는 순위가 아닙니다. 제가 구분하고 싶은 것은 “빈 컴포넌트를 다시 꺼내 쓰기”와 “이미 일하는 시스템에 일을 더 보내기”입니다. 프로젝트가 반복 생성 비용 때문에 느린지, 활성 인스턴스를 계속 운영하는 비용 때문에 느린지에 따라 먼저 비교할 대상도 달라집니다.

GPU 시뮬레이션을 선택했다는 사실만으로 인스턴스 쪽의 CPU 부담을 지웠다고 볼 수도 없습니다. 같은 문서는 GPU 입자라도 System과 Emitter 스크립트는 CPU에서 실행된다고 설명합니다. 반대로 시스템을 묶었다는 이유만으로 투명 입자가 많이 겹치는 화면의 병목까지 해결됐다고 판정할 근거도 없습니다. 이번 자료만으로 전체 프레임의 개선 폭을 제시하지 않는 이유입니다.

시스템 수가 줄어도 컬링의 세밀함은 다시 봐야 한다

Scalability 문서에서 눈에 남은 것은 인스턴스 수와 컬링을 함께 설명하는 대목입니다. 인스턴스가 많아지면 게임 스레드의 일이 늘어나지만, 작은 인스턴스 여러 개는 더 세밀한 단위로 컬링할 수 있습니다. 적은 수의 큰 인스턴스로 묶는 선택에는 이 교환조건이 따라옵니다.

그래서 충돌이 밀집한 한 지점만 보고 도입 여부를 정하고 싶지는 않습니다. 같은 수의 이벤트라도 한곳에 모였을 때와 넓게 흩어졌을 때를 따로 보겠습니다. 가까운 탄착 하나와 멀리 떨어진 탄착 여러 개가 같은 공유 영역에 포함될 때, 카메라가 일부만 보는 상황에서는 어떤 작업이 남는지도 질문해야 합니다. 이는 문서의 교환조건에서 도출한 비교 제안이며 실제 결과를 확인했다는 뜻은 아닙니다.

listener의 수명도 이 공간 판단과 이어집니다. Overview는 이벤트를 계속 받도록 Infinite Loop를 설정하고, 일정 시간 이벤트가 없으면 Complete if Unused로 시스템을 끝내는 구성을 설명합니다. 공유하는 단위가 언제 살아 있고 언제 정리되는지까지 살펴야 “필요한 만큼만 운영한다”는 판단을 할 수 있겠습니다. 현재 프로젝트에서 사용하는 모듈과 설정값은 해당 엔진 버전의 에셋에서 다시 확인할 부분입니다.

5.8 문서에서 읽은 개념을 현재 인터페이스와 맞추기

이번에 연 문서 페이지들은 Unreal Engine 5.8 문서로 표시됐습니다. 다만 Scalability 본문에는 5.4에서 도입할 기능을 설명하는 과거의 미래형 문장도 남아 있습니다. 페이지의 버전 표시만으로 모든 문장을 이번 버전의 새 변경 사항이라고 읽지 않으려 합니다. 개념 설명과 실제 API 확인을 나누는 편이 안전하겠습니다.

그래서 추가로 FNDCAccessContextInst API와 UNiagaraDataChannelLibrary API를 열었습니다. Access Context는 채널에 접근할 때 위치나 gameplay tag 같은 정보를 담아 내부 라우팅과 공간 분할에 영향을 줄 수 있는 구조로 설명됩니다. “공유 데이터”를 무조건 전역의 한 저장소로 상상하지 않게 해주는 부분입니다.

함수 목록에서는 SearchParameters를 받는 일부 읽기·쓰기 함수에 Legacy 표시가 있고, Access Context를 받는 WithContext 계열이 함께 보입니다. 예전 튜토리얼의 노드 이름을 찾을 때는 같은 이름이 있는지만 보기보다, 현재 프로젝트가 어느 인터페이스를 사용하는지부터 확인하겠습니다. 여기서는 실제 Blueprint를 연결하거나 특정 버전의 마이그레이션을 검증하지 않았습니다.

읽기 함수의 이전 프레임 선택과 쓰기 함수의 Blueprint·Niagara CPU·GPU 가시성 입력도 따로 존재합니다. 따라서 데이터를 썼다는 사실만으로 원하는 독자가 원하는 시점에 읽는다고 가정하지 않겠습니다. 입력값이 있다는 사실은 API로 확인되지만, 그것만으로 모든 구성의 지연이나 동기화 동작을 단정할 수는 없습니다.

제가 먼저 만들고 싶은 비교 조건

도입을 판단한다면 충돌 발생 기록을 고정한 작은 장면부터 비교하고 싶습니다. 개별 시스템을 Pooling으로 재사용하는 경우와 island 단위로 이벤트를 전달하는 경우에 발생 위치·시각·표현할 입자량·머티리얼·카메라 경로·대상 플랫폼을 맞추겠습니다. 그래야 표현을 단순하게 바꿔 얻은 차이를 시스템 구조의 이득으로 착각할 가능성을 줄일 수 있습니다.

확인할 질문도 “FPS가 올랐나” 하나로 끝내지 않겠습니다. 활성 인스턴스 수와 게임 스레드 쪽 작업이 어떻게 바뀌는지, 공유 영역을 크게 잡았을 때 화면 밖 작업이 더 남는지, 이벤트가 끊겼다 다시 들어올 때 listener가 의도대로 종료·재개되는지를 함께 보겠습니다. 이전 프레임 읽기를 선택했다면 충돌의 화면상 타이밍도 비교 대상입니다.

이 자료를 읽고 남은 관심은 NDC를 모든 이펙트에 적용하는 방법보다 반복되는 같은 종류의 이벤트를 어디까지 함께 운영할지에 있습니다. 발생이 드물거나 독립적인 수명 제어가 중요한 효과까지 같은 답을 적용할 이유는 아직 없습니다. 먼저 어떤 비용을 줄이려는지 적고, 그 대신 잃을 수 있는 공간 단위의 세밀함을 확인하는 순서로 접근하고 싶습니다.

다른 자료는 레퍼런스 모음에서 이어서 볼 수 있습니다.

읽은 자료와 확인 범위

• Epic Games — Niagara Data Channels Overview
• Epic Games — Scalability and Best Practices for Niagara
• Epic Games — FNDCAccessContextInst
• Epic Games — UNiagaraDataChannelLibrary

확인일은 2026년 10월 28일입니다. 열어 본 페이지들은 5.8 문서로 표시됐으며, 본문에 별도의 작성·수정일은 보이지 않아 발행 시점은 추정하지 않았습니다. 생성 이미지는 설명을 돕는 개념 일러스트이며, 이 글의 기술적 근거는 위 문서에 한정됩니다.