크로스 플랫폼 호환성 기본 이해

현대 게임은 단일 플랫폼만 겨냥하기보다 PC, 콘솔, 모바일, VR/AR를 함께 고려하는 경우가 많습니다.

나이아가라 이펙트도 플랫폼별 하드웨어 특성과 성능 제약을 반영해 설계해야 합니다.

크로스 플랫폼 호환성(Cross-Platform Compatibility)을 이해해야 모든 대상 플랫폼에서 의도한 비주얼과 안정적인 성능을 동시에 확보할 수 있습니다.

이 절에서는 나이아가라 시스템을 다양한 플랫폼에 배포할 때 고려해야 할 기본적인 호환성 문제와 최적화 전략에 대해 알아보겠습니다.

---

플랫폼별 하드웨어 및 API 차이점

각 플랫폼은 CPU, GPU, 메모리 등의 하드웨어 사양이 다르고, 사용 가능한 그래픽스 API(Application Programming Interface)에도 차이가 있습니다.

이러한 차이점이 나이아가라 이펙트의 동작과 성능에 직접적인 영향을 미칩니다.

• 모바일 플랫폼 (iOS, Android)
  • 제약 사항: 낮은 GPU 성능, 제한된 메모리(VRAM), 낮은 CPU 클럭 속도, 발열 문제.
  • 영향: 복잡한 셰이더, 대량의 파티클, 복잡한 물리 시뮬레이션, 실시간 그림자, 라이트 렌더러 등은 성능 저하를 초래할 가능성이 높습니다. Translucent 오버드로우에 특히 취약합니다.
  • 주요 API: OpenGL ES (레거시), Vulkan, Metal.
• 콘솔 플랫폼 (PlayStation, Xbox, Switch)
  • 제약 사항: 기종별 하드웨어가 정해져 있으며 세대·휴대 모드·해상도에 따라 예산이 달라집니다. PC와의 단순 성능 서열보다 지원 기종별 실제 측정이 필요합니다.
  • 영향: PC처럼 자유롭지는 않지만, 충분히 복잡하고 시각적으로 풍부한 이펙트를 구현할 수 있습니다. 메모리 사용량과 GPU 최적화가 여전히 중요합니다.
  • 주요 API: 콘솔 공급자의 SDK와 엔진 RHI 지원에 따릅니다. 모든 콘솔이 DirectX·Vulkan·Metal을 공통으로 사용하지는 않습니다.
• PC 플랫폼
  • 제약 사항: 하드웨어 사양이 매우 다양합니다. 하이엔드 PC도 RHI·드라이버·렌더링 경로와 프레임 예산의 제약이 있으며, 구형 또는 저사양 PC를 고려해야 할 경우 성능 최적화가 필수입니다.
  • 영향: 가장 자유롭지만, 넓은 사용자층을 고려하여 스케일러빌리티(Scalability) 설정을 통해 저사양 PC에서도 원활하게 작동하도록 조절해야 합니다.
  • 주요 API: DirectX, Vulkan.
• VR/AR 플랫폼
  • 제약 사항: 장치의 목표 주사율(예: 72·90·120Hz)에 맞는 안정적인 프레임 시간이 필요합니다. 양안 렌더링은 비용을 늘리지만 멀티뷰·인스턴스 스테레오와 작업 공유 때문에 모든 비용이 정확히 두 배가 되지는 않습니다.
  • 영향: 오버드로우, 복잡한 셰이더, 대량 파티클, 고해상도 텍스처 사용에 극도로 민감합니다. 시차(Parallax)를 고려한 파티클 위치와 깊이감이 중요합니다.
  • 주의: 파티클이 플레이어의 눈 가까이에서 갑자기 나타나거나 사라지는 것은 멀미를 유발할 수 있습니다.

---

크로스 플랫폼 최적화의 기본 전략

다양한 플랫폼에서 나이아가라 이펙트의 호환성과 성능을 확보하기 위해서는 다음과 같은 전략들을 고려해야 합니다.

스케일러빌리티 (Scalability) 적극 활용

• 엔진 Effects 품질과 Niagara 품질 수준, Device Profile·Platform Set을 구분해 목표 장치별 규칙을 정합니다.
• 공용 Niagara Effect Type에서 거리·가시성·인스턴스 수와 예산 컬링을 설정하고 시스템별 필요한 오버라이드를 둡니다.
• 이미터의 플랫폼·품질 포함 여부와 Spawn Count Scale 등을 활용합니다. 거리에 따라 연속적으로 스폰율·수명을 바꾸려면 실제 거리 입력과 해당 모듈 바인딩을 별도로 구성합니다. 모든 모듈이 자동으로 거리 LOD를 갖지는 않습니다.

머티리얼 최적화

• Unlit 셰이딩 모델 우선: 대부분의 파티클은 Unlit 셰이딩 모델을 사용하는 것이 가장 효율적입니다. 조명 계산이 불필요하여 GPU 부하를 크게 줄입니다.
• 블렌드 모드와 화면 면적: Additive와 Translucent 모두 겹친 픽셀을 여러 번 셰이딩할 수 있습니다. 원하는 표현에 맞는 모드를 고르고, 스프라이트 면적·겹침·셰이더 비용을 줄입니다. 알파를 낮추는 것만으로 그리기 비용이 사라지지는 않습니다.
• 텍스처 해상도 및 압축: 플랫폼의 메모리 제약을 고려하여 텍스처 해상도를 적절히 낮추고, 최적의 압축 설정을 사용합니다. 대상 플랫폼의 압축 형식과 밉·스트리밍 예산을 확인합니다. 스트리밍을 무조건 끄면 상주 메모리가 증가할 수 있습니다.
• 셰이더 복잡도 줄이기: 머티리얼 그래프에서 불필요한 연산이나 복잡한 함수 호출을 피하여 셰이더 명령 수를 줄입니다.

파티클 수 및 계산량 관리

• 생성량 상한 설계: Spawn Rate·Burst·Lifetime과 동시 시스템 수를 제한합니다. 일정한 연속 생성에서는 정상 상태의 입자 수를 대략 Rate × Lifetime으로 예상할 수 있지만, 버스트와 수명 분포는 별도로 더합니다.
• 짧은 Lifetime: 파티클의 수명을 최대한 짧게 설정하여 동시에 활성화되는 파티클 수를 줄입니다.
• Collision 모듈 사용 주의: Collision 모듈은 비용이 높으므로, 반드시 필요한 경우에만 사용하고 지원되는 CPU trace/GPU Scene Depth·Distance Field 방식과 대상 장치 비용을 확인합니다. 충돌 후 kill이 필요한지 정하고, CPU trace를 무조건 더 싼 대안으로 취급하지 않습니다.
• 복잡한 모듈/스크립트 회피: Curl Noise, 복잡한 데이터 인터페이스, 매 프레임 높은 연산을 수행하는 커스텀 스크립트 등은 성능에 큰 영향을 미칠 수 있으므로 신중하게 사용하거나 더 단순한 대안을 찾습니다.

플랫폼별 기능 비활성화

• Light Renderer (라이트 렌더러): 모바일 및 낮은 사양의 콘솔에서는 Light Renderer를 비활성화하는 것이 일반적입니다. 동적 라이트 생성은 매우 비용이 높습니다.
• 그림자 (Shadows): 파티클에 그림자를 드리우는 Cast Shadows 옵션도 성능에 큰 영향을 미치므로, 모바일이나 저사양 플랫폼에서는 비활성화합니다.
• Depth of Field, Motion Blur 등 후처리 효과: 이펙트에 영향을 미치는 후처리 효과들도 플랫폼 성능을 고려하여 조절하거나 비활성화합니다.

테스트 및 프로파일링

• 실제 플랫폼에서 테스트: 개발 중인 PC에서만 이펙트를 확인하지 말고, 반드시 목표하는 모든 플랫폼에서 주기적으로 이펙트가 어떻게 보이는지, 성능은 어떤지 테스트해야 합니다.
• 플랫폼별 프로파일링 도구 활용: 언리얼 엔진의 stat 명령어, Unreal Insights, GPU Profiler를 기본으로 사용하고, 플랫폼 전용 도구까지 함께 확인해야 합니다. 플랫폼 SDK가 제공하는 CPU·GPU 도구를 사용하고, 에디터 측정과 실기기 패키지 결과를 구분합니다.

---

플랫폼 예산과 스케일러빌리티 기준선

아래 수치는 예산표 작성 방법을 보여 주는 가상 예시이며 Epic 권장값이나 측정 결과가 아닙니다. 목표 장치·해상도·장면·품질 단계와 전체 프레임 예산에서 FX에 배정할 몫을 정한 뒤 실제 값으로 교체합니다.

예산을 넘으면 측정된 병목에 맞춰 조절합니다. 시뮬레이션이 비싸면 생성량·모듈을, 픽셀 비용이 크면 화면 면적·겹침·머티리얼을, 인스턴스 비용이 크면 시스템 수·풀링·컬링을 먼저 비교합니다.

품질 단계가 달라져도 공격 방향·위험 범위·발동 시점 같은 게임 정보는 유지합니다. 대표 장면의 CPU/GPU 시간·메모리·긴 실행 후 발열을 함께 기록하고, 품질 전환 시 갑작스러운 소멸이나 한쪽 눈 잘림이 없는지 확인합니다.

공통 정책은 Niagara scalability와 모범 사례를 참고하되 지원 기능과 실제 예산은 목표 장치에서 확인합니다.