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

현대 게임은 단일 플랫폼만 겨냥하기보다 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·120 Hz)에 맞는 안정적인 프레임 시간이 필요합니다. 양안 렌더링은 비용을 늘리지만 멀티뷰·인스턴스 스테레오와 작업 공유 때문에 모든 비용이 정확히 두 배가 되지는 않습니다.
  • 영향: 오버드로우, 복잡한 셰이더, 대량 파티클, 고해상도 텍스처 사용에 극도로 민감합니다. 시차(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 시간·메모리·긴 실행 후 발열을 함께 기록하고, 품질 전환 시 갑작스러운 소멸이나 한쪽 눈 잘림이 없는지 확인합니다.

예시: 부분 예산과 전체 프레임을 동시에 확인하기

일정한 Rate 80개/초, Lifetime 1.5초, 실제 Rate에 곱한 Spawn Rate Scale 0.5를 적용했다고 가정합니다. 정상 상태의 연속 입자는 80 × 0.5 × 1.5 = 60개입니다. 아직 모두 살아 있는 Burst 20개가 더해지면 해당 순간 한 인스턴스의 모델은 80개, 동일한 인스턴스 세 개는 240개입니다. 별도 Burst·수명 분포·Kill·컬링이 있으면 그 조건을 따로 계산합니다.

90 FPS 장치의 전체 프레임 예산은 1000/90 ≈ 11.11 ms입니다. FX에 1.2 ms를 배정했고 주어진 기록이 Niagara GPU 1.0 ms, Frame 12 ms라면 FX 예산은 지켰어도 전체 프레임 시간은 90 FPS 목표 예산을 넘습니다. 같은 프레임의 Niagara 시간과 전체 GPU·Frame을 서로 독립 작업처럼 모두 더해 이중 계산하지 않습니다. 병목과 수집 범위를 대조한 뒤 다음 변경을 정합니다.

독립 확인에서는 Rate 60개/초, Scale 0.5, Lifetime 2초이고 살아 있는 Burst가 인스턴스당 10개, 동일한 인스턴스가 네 개입니다. 순간 총 입자 모델을 구하세요. 목표 120 FPS에서 Niagara 0.9 ms가 FX 예산 1.0 ms 안이고 Frame 8.5 ms라면 전체 목표도 통과했나요? 낮은 품질에서 경고 범위를 나타내는 입자를 모두 없애도 되는지도 답하세요.

생성 모델·전체 목표·게임 정보 보존을 함께 판단하기

한 인스턴스의 연속 입자는 60 × 0.5 × 2 = 60개이고 Burst를 합치면 70개, 네 개로 280개입니다. 120 FPS 전체 예산은 약 8.33 ms여서 Frame 8.5 ms는 넘습니다. FX 부분 예산 통과가 전체 목표 통과를 증명하지 않습니다. 낮은 품질에서도 위험 범위·방향·발동 시점은 다른 저비용 표현으로 전달해야 하며, 필요한 게임 정보를 없애는 것으로 성능 통과를 대신하지 않습니다. 수치와 기록은 선언한 연습 조건이고 장치 측정·권장 예산이 아닙니다.

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