클라우드 렌더팜에서의 Houdini Karma XPU: 2026년 기술 가이드
개요
소개
Karma XPU는 점점 더 많은 Houdini 스튜디오가 표준으로 채택하고 있는 렌더러입니다. 이유는 충분합니다. SideFX 자체 프로덕션 렌더러이며, Solaris와 USD 내에 네이티브로 내장되어 있고, CPU와 GPU를 동시에 활용하는 하이브리드 실행 방식 덕분에 룩 개발(look-dev) 작업이 거의 인터랙티브한 느낌을 줍니다. 단일 워크스테이션에서 사용할 때는 매우 편리합니다. 하지만 Karma XPU 씬을 워크스테이션에서 렌더팜으로 옮겨 수백 프레임을 렌더링하려 할 때 문제가 시작됩니다.
렌더팜 규모에서 Karma XPU는 단순히 빠른 Karma CPU가 아니라 전혀 다른 엔진처럼 동작하기 시작합니다. VRAM이 단순한 권장 사항이 아닌 절대적인 한계로 작용합니다. 인터랙티브하게 정상적으로 실행되던 시뮬레이션은 캐싱 없이는 분산 처리가 전혀 불가능합니다. 렌더러가 무거운 프레임에서 조용히 CPU 모드로 폴백(fallback)되어, 인접 프레임보다 6배나 오래 걸리는 이유를 알 수 없게 될 수도 있습니다. 이것들은 버그가 아닙니다. 부하 상태에서 아키텍처의 특성이 드러나는 것입니다.
저희는 수년간 Houdini 작업을 위한 분산 렌더링을 운영해왔으며, Karma XPU는 Redshift, Mantra, Arnold, V-Ray for Houdini, Octane과 함께 저희 Houdini 클라우드 렌더팜에서 사용 가능한 엔진 중 하나입니다. 이 가이드는 기술적 심층 분석입니다. Karma XPU가 실제로 무엇인지, Karma CPU 및 Mantra와의 차이점, 렌더팜에서 헤드리스로 렌더링할 때 달라지는 점, 시뮬레이션 캐싱이 선행되어야 하는 이유, 그리고 특정 샷에서 Karma XPU와 Redshift 중 어떤 것을 선택해야 하는지를 다룹니다. 단계별 씬 준비 체크리스트가 필요하다면 저희 Houdini 설정 가이드를 참조하십시오. 이 글은 독자가 이미 Solaris에 익숙하다고 가정합니다.
Karma XPU를 확장하기 어려운 이유
Karma XPU에 대해 먼저 이해해야 할 것은 "XPU"가 렌더러가 아니라 실행 모드라는 점입니다. Karma는 단일 USD 렌더 델리게이트(render delegate)이며, XPU는 CPU 코어와 NVIDIA GPU에 동시에 작업을 분배하여 두 장치가 동일한 이미지에 샘플을 기여하는 경로입니다. Karma CPU는 GPU가 꺼진 동일한 델리게이트입니다. 이 설계는 워크스테이션에서는 우아하지만 렌더팜에서는 네 가지 이유로 다루기 까다롭습니다.
첫째, GPU 경로는 OptiX 위에서 실행되므로 지오메트리, 텍스처, 가속 구조를 GPU VRAM에 로드합니다. 씬이 VRAM에 맞을 경우 완전한 하이브리드 속도 향상을 얻을 수 있습니다. 그렇지 않으면 Karma XPU는 일부 GPU 렌더러처럼 데이터를 스트리밍하는 대신 CPU 실행으로 폴백하는 경향이 있습니다. 렌더링은 완료되지만 예상 속도의 극히 일부에 불과하며, 일반적인 작업 로그에서는 이에 대한 경고가 전혀 표시되지 않습니다.
둘째, XPU는 경쟁 엔진들보다 출시가 늦었습니다. Houdini 20.0이 첫 번째 프로덕션 안정성 마일스톤이었고 20.5에서 기능 범위가 크게 확장되었지만, 아직 일부 기능은 Karma CPU가 더 유리합니다. 샷에서 해당 기능 중 하나를 사용하는 경우 렌더링의 일부가 조용히 CPU 경로로 내려갈 수 있습니다.
셋째, 버전 고정(version pinning)이 생각보다 훨씬 중요합니다. 특정 Houdini 포인트 릴리즈에서 제작된 씬은 동일한 릴리즈를 실행하는 렌더팜 노드에서 렌더링해야 합니다. Karma의 인터페이스는 20.0, 20.5, 21 라인 사이에서 충분히 변경되었기 때문에 크로스-버전 렌더링을 당연히 여길 수 없습니다.
넷째, 처음에는 반드시 한 번씩 문제가 되는 부분인데, 시뮬레이션은 프레임이 아닙니다. 렌더팜에 Pyro나 FLIP 셋업을 그냥 던져서 분산 처리가 될 것이라고 기대할 수 없습니다. 이에 대해서는 아래에서 별도로 다루겠습니다.
Karma XPU vs Karma CPU vs Mantra
Houdini에는 세 가지 렌더러가 기본 포함되어 있으며, 어떤 것을 선택하느냐가 모든 렌더팜 작업의 첫 번째 실질적인 결정입니다. 이들은 서로 호환되지 않습니다.
Mantra는 레거시 엔진입니다. USD보다 훨씬 이전에 만들어졌으며, Houdini 고유의 씬 서술 파이프라인에서 작동하고 MaterialX 대신 VEX 기반(CVEX) 셰이더를 사용합니다. SideFX는 이를 제거하지 않았으며 여전히 완전히 기능하지만, 새로운 기능이 추가되지 않습니다. 앞으로의 방향은 분명히 Karma입니다. Mantra는 두 가지 상황에서 여전히 역할을 합니다. 재구축 비용이 높은 VEX 셰이더 라이브러리가 깊게 쌓인 파이프라인, 그리고 Karma에 아직 깔끔한 대응이 없는 마이크로폴리곤 또는 디스플레이스먼트 동작이 그것입니다. 셰이더가 CVEX로 작성되어 있다면 Karma로 변환되지 않으며, 그것만으로도 샷을 Mantra에 유지시킬 수 있습니다.
Karma CPU는 기준 경로입니다. USD 네이티브이며, 전체 Karma 기능 세트를 구현하고, 프레임이 "어떻게 보여야 하는지"에 대한 기준을 제공합니다. GPU 개입 없이 CPU 코어 전반에 걸쳐 멀티스레드로 실행됩니다. 대형 CPU 플릿이 있는 렌더팜에서는 실질적으로 매우 효과적입니다. VRAM 한계를 완전히 우회하여 GPU 메모리에 편안하게 들어가지 않는 씬에 대한 합리적인 선택이 됩니다.
Karma XPU는 하이브리드 가속 경로입니다. CPU와 NVIDIA GPU가 동시에 동일한 프레임을 트레이싱하며, MaterialX 셰이딩과 Karma CPU와 동일한 USD 네이티브 기반을 사용합니다. GPU와 CPU를 결합하면 어떤 CPU 전용 경로보다 빠르게 인터랙티브 룩 개발과 VRAM 내 최종 프레임을 렌더링하며, 새로운 Solaris 파이프라인의 자연스러운 기본값입니다. 한계는 Karma CPU의 기능 서브셋이라는 점입니다. 남아 있는 대부분의 차이는 특수한 볼륨, 셰이딩, AOV 엣지 케이스에 관한 것으로, SideFX는 릴리즈마다 이를 좁혀가고 있습니다. 실용적인 규칙은 시퀀스를 XPU에 맡기기 전에 XPU와 CPU 모두에서 비교 프레임을 렌더링하는 것입니다. XPU와 CPU의 결과가 다를 때 CPU가 정답이기 때문입니다.
CPU와 GPU가 동시에 단일 프레임에 샘플을 기여하는 Houdini Karma XPU의 하이브리드 렌더링 구조 다이어그램.
| 항목 | Mantra | Karma CPU | Karma XPU |
|---|---|---|---|
| 씬 기반 | USD 이전 (네이티브 파이프라인) | USD / Solaris | USD / Solaris |
| 컴퓨팅 | CPU | CPU | CPU + NVIDIA GPU |
| 셰이딩 | VEX / CVEX | MaterialX | MaterialX |
| 기능 완성도 | 고정 (신규 기능 없음) | 기준 (전체) | CPU의 서브셋, 발전 중 |
| VRAM 한계 | 없음 | 없음 | 있음 — GPU 메모리 제한 |
| 적합한 용도 | 레거시 VEX 파이프라인 | 무거운 씬, 기준 검증 | USD 네이티브 룩 개발 + VRAM 내 최종 프레임 |
클라우드 렌더팜에서 Karma XPU를 헤드리스로 실행하기
인터랙티브 모드에서는 Solaris 뷰포트의 버튼을 눌러 렌더링합니다. 렌더팜에서는 그 버튼이 husk라는 커맨드라인 프로그램입니다. SideFX의 독립형 USD 렌더러로, 완전한 인터랙티브 Houdini 세션을 시작하지 않고 구성된 USD 스테이지를 로드하여 렌더링하는 경량 프로세스입니다. Houdini와 함께 제공되며 렌더팜에서 Karma를 렌더링하는 표준 방식입니다. 제출 방식은 본질적으로 다음과 같습니다.
husk --renderer Karma \
--frame 1001 --frame-count 50 \
--output /project/render/shot_010.$F4.exr \
/project/usd/shot_010.usd
각 렌더팜 노드는 동일한 USD 스테이지에 대해 서로 다른 프레임 범위로 husk를 실행하며, 이것이 프레임 단위 분산 처리가 작동하는 방식입니다. 스테이지 자체는 모든 지오메트리, 라이트, 카메라, 머티리얼을 참조하는 완전히 구성된 .usd/.usdc 파일입니다. AOV는 커맨드라인 플래그가 아닙니다. 이들은 Render Settings와 Render Var LOP에서 스테이지로 구운 USD Render Var 프림(prim)이므로, husk는 라이브 Houdini 네트워크 없이도 이를 읽습니다. 뷰티, 알파, 노멀, 알베도 등 모든 것이 USD 안에 포함됩니다.
렌더팜 특유의 몇 가지 메커니즘을 알아두면 좋습니다. Karma는 **체크포인팅(checkpointing)**을 지원하여 노드 오류 시 재시작 대신 재개할 수 있도록 샘플 간격으로 중간 렌더 상태를 기록합니다. 수천 샘플의 단일 히어로 프레임에는 유용하지만, 각 프레임을 다시 렌더링하는 비용이 낮은 중간 샘플 애니메이션에는 덜 유용합니다. **디노이징(Denoising)**은 GPU의 OptiX 디노이저 또는 CPU의 Intel OIDN을 통해 실행됩니다. 많은 노드에서 프레임 간 시간적 일관성이 중요할 때 저희는 OIDN을 선호합니다. 어떤 머신이 프레임을 처리했든 동일한 결과를 생성하기 때문입니다.
라이선스에 대해 직접적으로 말씀드리겠습니다. 자주 묻는 질문이기 때문입니다. Karma는 Redshift, Arnold, V-Ray, Octane처럼 별도로 라이선스가 필요한 플러그인이 아닙니다. Houdini 자체에 번들로 제공됩니다. 저희는 작업을 렌더링하기 위해 렌더 전용 사용 방식으로 Houdini와 Karma를 실행합니다. 저희는 SideFX 파트너가 아니며 Houdini 라이선스를 재판매하지 않습니다. 렌더팜이 풀 매니지드(fully managed)이므로, 고객께서는 노드에 원격 접속하거나 Houdini를 직접 설치하거나 라이선스를 관리할 필요가 없습니다. 씬과 캐시된 데이터를 업로드하면 노드의 렌더링 측 라이선스는 서비스 운영의 일환으로 처리됩니다. Houdini 스택의 상용 엔진의 경우 Redshift, Arnold, V-Ray, Octane 라이선스가 렌더 요금에 포함됩니다.
Super Renders Farm Houdini 스택
단 하나의 엔진만 실행하는 렌더팜은 모든 샷을 동일한 트레이드오프로 처리할 수밖에 없습니다. Houdini 작업은 좀처럼 그런 방식에 맞지 않기 때문에, 저희 Houdini 클라우드 렌더팜은 전체 세트를 실행합니다. Karma (XPU 및 CPU 모드 모두), Mantra, Redshift, Arnold, V-Ray for Houdini, Octane. 이 범위의 의미는 스튜디오 단위가 아닌 샷 단위로 적합한 엔진을 선택할 수 있다는 것입니다. USD 네이티브 룩 개발 패스에는 Karma XPU, VRAM에 들어가지 않는 볼륨 히어로 프레임에는 Karma CPU, 속도가 우선인 시퀀스에는 Redshift, 레거시 셰이더 셋업에는 Mantra입니다.
하드웨어는 Houdini 작업과 동일한 CPU/GPU 구분을 따릅니다. 저희 CPU 플릿은 20,000개 이상의 CPU 코어를 보유하고 있으며, 이곳에서 실제 프로덕션 렌더링의 대부분이 이루어집니다. 업계 전반적으로, 그리고 저희 렌더팜에서도 CPU 렌더링이 여전히 더 큰 비중을 차지합니다. 이 CPU 용량 덕분에 Karma CPU와 Mantra를 시퀀스 규모로 실용적으로 사용할 수 있으며, 프레임이 GPU에 비해 너무 무거울 때 Karma XPU를 보조합니다. GPU 작업을 위해 저희 전용 GPU 머신은 **NVIDIA RTX 5090 카드(32 GB VRAM)**를 탑재하고 있습니다. Karma XPU에 있어서 이 32 GB가 가장 중요한 수치입니다. VRAM이 GPU에서 XPU 가속이 중단되기 전에 씬이 얼마나 복잡해질 수 있는지의 실질적인 한계이기 때문입니다. 4K UDIM 텍스처 세트, 조밀한 인스턴스 환경, 고해상도 VDB는 각각 이 예산을 빠르게 소모할 수 있으며, 카드가 클수록 렌더링이 조용히 CPU로 내려가기 전까지 더 나아갈 수 있습니다. GPU 바인딩 작업을 전반적으로 고려 중이라면 저희 RTX 5090 GPU 렌더링 노트에서 카드에 대한 더 깊은 내용을, GPU 렌더팜 페이지에서 전체 플릿에 대한 내용을 확인하십시오.
Karma XPU와 GPU VRAM 다이어그램: 32 GB VRAM에 맞는 씬은 하이브리드 CPU+GPU 속도로 렌더링되고, VRAM을 초과하는 씬은 CPU로 폴백됩니다.
요금은 하드웨어를 따릅니다. CPU 렌더링은 GHz-시간당 요금이 부과되고 GPU 렌더링은 OctaneBench-시간당 요금이 부과됩니다. 따라서 Karma CPU 시퀀스와 Redshift 시퀀스는 실제 작업을 설명하는 단위로 요금이 책정됩니다. Karma XPU는 두 장치를 모두 사용할 수 있으므로, GPU 노드에서 실행되고 VRAM 내에 유지될 때 GPU 시간으로 청구되며 CPU 기여분이 함께 포함된다고 가장 간단하게 이해하시면 됩니다. 이것이 VRAM 한계를 존중해야 하는 또 다른 이유입니다.
시뮬레이션 캐싱: 건너뛸 수 없는 단계
모든 렌더팜에서 Houdini를 렌더링할 때 가장 중요한 개념이자, 잘못 이해할 경우 하루를 낭비할 가능성이 가장 높은 내용입니다. 프레임은 독립적으로 병렬 처리가 가능하지만, 시뮬레이션은 그렇지 않습니다.
렌더링된 애니메이션의 1042번 프레임은 1041번 프레임이 먼저 존재할 필요가 없습니다. 두 프레임을 동시에 별도의 머신에서 렌더링할 수 있습니다. 이 독립성이 바로 렌더팜이 동작하는 전제입니다. 시뮬레이션은 정반대입니다. Pyro 시뮬레이션의 1042번 프레임은 1041번의 연기 상태에서, 1041번은 1040번에서, 첫 번째 프레임까지 거슬러 올라가 계산됩니다. 시뮬레이션의 중간 부분을 앞부분 없이 계산할 수 없습니다. 렌더팜에 원시 시뮬레이션을 넘기면 분산 처리할 것이 아무것도 없습니다.
해결책은 결정론적이고 절충의 여지가 없습니다. 먼저 시뮬레이션을 완료하고 디스크에 캐시한 다음, 렌더팜에서 캐시를 렌더링합니다. 시뮬레이션은 한 대의 머신(또는 전용 시뮬레이션 박스)에서 순차적으로 실행되어 모든 프레임 결과를 디스크에 기록합니다. 이제 정적이고 프레임 독립적인 데이터인 캐시 파일이 렌더팜에서 렌더링하는 대상입니다. 렌더 노드는 절대 재시뮬레이션하지 않습니다. 사전 계산된 지오메트리와 볼륨을 읽고 다른 애니메이션과 마찬가지로 프레임을 병렬로 트레이싱합니다.
시뮬레이션은 한 머신에서 순차적으로 해결된 후 VDB 또는 bgeo로 디스크에 캐시되고, 렌더팜에서 프레임별로 병렬 렌더링되는 파이프라인 다이어그램.
캐시 대상은 솔버에 따라 다릅니다.
| 시뮬레이션 | 솔버 | 캐시 형식 | 비고 |
|---|---|---|---|
| 연기 / 불 | Sparse Pyro | .vdb | 업계 표준 희소 볼륨; 렌더 스테이지에 직접 읽혀짐 |
| 액체 | FLIP | .bgeo.sc 파티클 → 메시 표면 | 캐시된 파티클에서의 메싱은 프레임별 독립적이므로 별도로 팜 처리 가능 |
| 천 / 그레인 / 소프트바디 | Vellum | .bgeo.sc | 히어로 천 캐시는 빠르게 커짐 — 스토리지 처리량에 주의 |
| 리지드 바디, 군중, 인스턴스 | RBD / Agents | .bgeo.sc 또는 USD | USD (PointInstancer)가 Karma에 가장 깔끔하게 전달됨 |
주목할 만한 세부 사항이 있습니다. 시뮬레이션 자체와 그 후속 작업 사이에는 실질적인 차이가 있습니다. FLIP 서페이싱, 즉 캐시된 파티클을 렌더 메시로 전환하는 작업은 이전 프레임이 아닌 각 프레임 자체의 파티클에만 의존합니다. 따라서 이 단계는 병렬 처리가 가능하며, 기반 시뮬레이션이 불가능했음에도 불구하고 별도의 패스로 렌더팜에 넘길 수 있습니다. Houdini 20 이상 파이프라인에서 점점 더 일반화되는 패턴은 지오메트리를 직접 USD로 캐시하는 것입니다. 이렇게 하면 husk가 렌더 시 노드에서 SOP-to-USD 변환 단계 없이 네이티브로 읽을 수 있습니다.
이것이 PDG/TOPs가 진가를 발휘하는 영역입니다. PDG는 Houdini의 의존성 인식 태스크 그래프로, 렌더팜 렌더링에 필요한 정확한 관계를 모델링합니다. "이 시뮬레이션을 캐시하고, 캐시가 존재하면 그로부터 이 프레임들을 렌더링한다"는 것입니다. File Cache TOP은 시뮬레이션 캐시를 출력 의존성으로 생성하고, 다운스트림 렌더 태스크는 이를 기다렸다가 프레임별로 팬아웃(fan-out)합니다. PDG는 스케줄러 노드를 통해 캐싱과 husk 렌더를 모두 렌더팜을 통해 구동할 수 있으므로, 진지한 Houdini 렌더팜 파이프라인의 핵심이 된 이유입니다.
경험에서 비롯된 실용적인 참고 사항입니다. 천 및 고해상도 액체 캐시는 프레임당 기가바이트 규모에 이를 수 있으며, 수십 개의 노드가 공유 스토리지에서 동일한 시퀀스를 동시에 가져올 때 컴퓨팅이 아닌 읽기 처리량이 병목이 됩니다. 저희는 하드 사이즈 상한 없이 업로드를 지원하며 (업로드당 300 GB 미만을 권장하며, 이를 초과하면 SFTP 또는 클라이언트 앱 사용), .tar, .tar.gz, .7z 아카이브를 허용합니다. .zip은 허용되지 않습니다. 무거운 캐시 시퀀스는 업로드 전에 .tar.gz로 다시 패킹하십시오. 렌더링된 출력물은 작업 완료 후 45일간 사용 가능하며, 전체 시퀀스를 다운로드하기에 충분한 시간입니다.
Karma XPU 작업 처음부터 끝까지 제출하기
모든 단계를 합치면, 깔끔한 Karma XPU 렌더팜 작업은 예측 가능한 순서로 진행됩니다.
Karma XPU 작업을 클라우드 렌더팜에 제출하는 6단계 워크플로우: 시뮬레이션 캐시, USD 스테이지 내보내기, 업로드, 엔진 선택, 프레임 분산, 디노이즈 및 다운로드.
- 모든 시뮬레이션을 캐싱합니다. Pyro는 VDB로, FLIP와 Vellum은
.bgeo.sc또는 USD로 캐싱합니다. 캐시가 완료되었고 프레임이 연속적인지 확인합니다. 누락된 중간 프레임은 오류가 아닌 렌더링의 구멍으로 나타납니다. - 구성된 USD 스테이지를 내보냅니다. Render Settings와 Render Var 프림이 구워지고, 워크스테이션 로컬 드라이브가 아닌 렌더 노드에서 접근 가능하도록 모든 에셋 경로가 해결되어야 합니다.
- 프로젝트를 패킹합니다. 씬, 캐시, 텍스처, OCIO 설정을 포함하여 업로드합니다. 렌더팜이 풀 매니지드(fully managed)이므로 로그인할 노드도, 설치할 Houdini도 없습니다.
- 엔진을 선택합니다. VRAM 내 룩 개발 및 최종 패스에는 Karma XPU; 32 GB를 초과할 것으로 알고 있는 프레임에는 Karma CPU; 속도가 우선인 경우 Redshift를 사용합니다.
- 프레임을 분산합니다. 렌더팜이 프레임 범위를 노드에 분배하며 각 노드는 자신의 슬라이스에 대해
husk를 실행합니다. 관리가 아닌 진행 상황을 모니터링합니다. - 디노이즈하고 다운로드합니다. 45일 이내에 EXR 파일을 가져옵니다 (OIDN을 구성한 경우 적용됨).
이 모든 과정에서 반복되는 실패 모드는 에셋 해결입니다. USD는 해당 레이어를 기준으로 하는 상대 경로 또는 절대 경로로 경로를 해결하며, 로컬 워크스테이션 드라이브를 가리키는 절대 경로는 렌더 노드에서 누락된 텍스처나 지오메트리를 생성합니다. 종종 하드 오류 없이 에셋이 있어야 할 곳에 블랙으로 나타납니다. 공유 프로젝트 루트를 기준으로 경로를 해결하고, 컬러가 흐트러지지 않도록 작업 전반에 걸쳐 OCIO 설정을 일관되게 유지하고, 노드에 제공되지 않은 플러그인이 필요하지 않도록 내보내기 전에 커스텀 HDA 의존성을 USD로 플래튼하십시오. 클라우드 렌더링이 이런 종류의 작업을 분산하는 방법에 대한 더 넓은 기초 지식은 저희 클라우드 렌더팜 개요를 참조하십시오.
Karma XPU vs Redshift 선택 기준
Karma XPU와 Redshift 모두 GPU 렌더팜에서 Houdini를 렌더링할 수 있으며, 어느 것이 "더 나은지"의 문제가 아닙니다. 샷과 파이프라인이 무엇을 필요로 하는지의 문제입니다. 두 엔진은 서로 다른 철학에서 탄생했습니다. Karma XPU는 물리 기반이며, USD 네이티브이고, MaterialX 셰이딩을 사용하며, Houdini와 동일한 벤더가 만들었습니다. Redshift는 10년 이상의 프로덕션 역사를 가진 성숙한, 주로 편향적(biased) GPU 렌더러로 Houdini 플러그인을 보유하고 있으며, 렌더팜에서의 두드러진 특성은 씬이 너무 커질 때 VRAM에서 시스템 RAM과 NVMe로 원활하게 넘어가는 강력한 아웃-오브-코어(out-of-core) 시스템입니다. Karma XPU가 VRAM 오버플로우 시 CPU로 폴백하는 경향이 있는 반면, Redshift는 예측 가능한 성능 패널티로 GPU에서 계속 렌더링합니다. 이 때문에 32 GB 카드로도 Redshift에서는 32 GB를 훨씬 초과하는 텍스처를 가진 씬을 구동할 수 있습니다.
이 차이점이 대부분의 결정을 이끕니다.
| Karma XPU 선택 기준 | Redshift 선택 기준 |
|---|---|
| 파이프라인이 USD / Solaris 네이티브인 경우 | 순수 GPU 속도가 우선인 경우 |
| 셰이더가 MaterialX인 경우 | 씬이 VRAM 집약적인 경우 (대형 VDB, 대형 텍스처 세트) |
| 물리 기반 라이트 트랜스포트 원하는 경우 (GI 캐시 깜박임 없음) | VRAM 한계를 초과하는 아웃-오브-코어 안정성이 필요한 경우 |
| 전체 SideFX 스택으로 표준화하는 경우 | 팀이 이미 Redshift 셰이더와 룩 개발을 보유한 경우 |
| 렌더러 비용이 중요한 경우 (Karma는 Houdini에 포함) | C4D / Maya / Houdini 전반에서 하나의 룩을 원하는 경우 |
다른 엔진들이 나머지 공간을 채웁니다. Arnold는 복잡한 서브서페이스, 헤어, 볼륨이 있는 무거운 VFX 작업이나 파이프라인이 이미 Arnold 특유의 셰이더에 의존하는 경우에 선택합니다. HtoA 버전을 렌더팜 노드에 맞게 고정하고 텍스처를 .tx로 사전 변환하십시오. V-Ray for Houdini는 이미 3ds Max와 Maya 전반에 V-Ray로 표준화된 스튜디오가 DCC 전반에 걸쳐 하나의 일관된 룩을 원할 때 적합합니다. GPU 비교에 대해서는 저희 Redshift 페이지를 참조하십시오. Octane은 이미 스펙트럼 기반의 노드 기반 생태계에 있는 팀에 적합하며 OctaneBench-시간당 요금으로 명확하게 청구됩니다. 엔진이 아닌 제공업체별 비교를 원한다면 저희 Houdini 렌더팜 비교를 참조하십시오.
렌더팜에서의 Karma XPU에 특화된 주의 사항이 있습니다. 하나의 시퀀스에도 가벼운 프레임(GPU 가속)과 무거운 프레임(조용히 CPU 바인딩)이 함께 있을 수 있어 하나의 균일한 작업처럼 보이는 것에서도 렌더링 시간이 크게 달라질 수 있습니다. 해결책은 전체 범위를 확정하기 전에 가장 무거운 프레임에서 사전 메모리 점검(pre-flight memory check)를 실시하는 것입니다. 32 GB VRAM을 초과할 경우, 렌더러가 시퀀스 중간에 결정하게 두는 대신 CPU 플릿의 Karma CPU와 Redshift 아웃-오브-코어 경로 중 하나를 의도적으로 선택하십시오. 엔진 자체 외에도 표준 렌더팜 주의 사항이 여전히 적용됩니다. Houdini 버전을 고정하고, 노드별 기본값에 의존하는 대신 디노이저 구성을 명시적으로 유지하고, 모든 에셋 경로가 노드에서 해결되는지 확인하십시오.
공식 렌더러 세부 정보는 SideFX에서 Karma와 husk 커맨드라인 렌더러 모두에 대한 상세한 문서를 제공합니다. 첫 대형 제출 전에 읽어볼 것을 권장합니다.
FAQ
Q: Karma XPU와 Karma CPU의 차이점은 무엇입니까? A: 두 가지 실행 모드로 실행되는 동일한 USD 네이티브 Karma 렌더러입니다. Karma CPU는 CPU 코어에서만 실행되며 완전한 기준 품질 기능 세트를 구현합니다. Karma XPU는 NVIDIA GPU를 추가하여 CPU와 GPU에서 함께 렌더링하여 속도를 높이지만, 현재 Karma CPU 기능의 서브셋만 지원하며 GPU VRAM에 의해 제한됩니다. 실용적인 습관은 XPU 출력이 이상해 보일 때 Karma CPU에서 프레임을 확인하는 것입니다. CPU가 기준이기 때문입니다.
Q: 클라우드 렌더팜에서 Karma를 렌더링하려면 SideFX 또는 Houdini 라이선스가 필요합니까? A: 풀 매니지드 렌더팜에서는 고객 측에서 필요하지 않습니다. Karma는 Redshift나 Octane처럼 별도로 라이선스가 부여되는 것이 아니라 Houdini에 번들로 제공됩니다. 저희는 작업을 렌더링하기 위해 렌더 전용 사용 방식으로 Houdini를 실행하며, 저희는 SideFX 파트너가 아니며 Houdini 라이선스를 재판매하지 않습니다. 씬과 캐시를 업로드하면 노드의 렌더링 측 라이선스는 관리형 서비스의 일환으로 처리됩니다.
Q: 렌더팜에서 렌더링하기 전에 시뮬레이션을 캐싱해야 하는 이유는 무엇입니까?
A: 시뮬레이션은 순차적이고 프레임은 그렇지 않기 때문입니다. 각 시뮬레이션 프레임은 이전 프레임의 상태에 따라 달라지므로 시뮬레이션은 반드시 한 머신에서 순서대로 해결되어야 합니다. 반면 렌더 프레임은 독립적이며 수백 개의 노드에서 동시에 실행될 수 있습니다. 완료된 시뮬레이션을 디스크에 캐싱(Pyro는 VDB, FLIP와 Vellum은 .bgeo.sc 또는 USD)하면 재시뮬레이션 없이 렌더팜이 병렬로 렌더링할 수 있는 정적 데이터가 됩니다.
Q: Karma XPU는 GPU VRAM을 초과하는 씬을 어떻게 처리합니까? A: 시스템 메모리에서 아웃-오브-코어로 스트리밍하는 Redshift와 달리, Karma XPU는 씬이 VRAM에 맞지 않을 때 CPU 실행으로 폴백하는 경향이 있습니다. 렌더링은 완료되지만 GPU 가속이 없어지고 프레임이 훨씬 오래 걸릴 수 있습니다. 로그에서 명확한 표시가 없습니다. 무거운 씬의 경우 폴백이 시퀀스 중간에 발생하도록 두는 것보다 CPU 플릿의 Karma CPU나 Redshift 아웃-오브-코어 경로를 의도적으로 선택하는 것이 좋습니다.
Q: Karma XPU가 Redshift보다 빠릅니까? A: 샷에 따라 다릅니다. Redshift는 고도로 최적화된, 주로 편향적(biased) GPU 렌더러로, 특히 아웃-오브-코어 시스템이 GPU에서 작업을 유지하는 VRAM 집약적인 씬에서 일반적으로 더 빠릅니다. Karma XPU는 물리 기반이며 완전히 USD 네이티브로, Solaris 파이프라인과 MaterialX 셰이딩에 더 적합합니다. 동등한 노이즈를 위해 더 많은 샘플이 필요하더라도 마찬가지입니다. 속도만으로 결정하지 않습니다. 파이프라인 적합성과 VRAM 여유가 일반적으로 결정 요인입니다.
Q: husk는 무엇이며 직접 사용해야 합니까?
A: husk는 SideFX의 독립형 커맨드라인 USD 렌더러로, 실제로 렌더팜 노드에서 Karma를 렌더링하는 프로그램입니다. 전체 Houdini 세션 없이 구성된 USD 스테이지를 로드하는 경량 프로세스입니다. 관리형 렌더팜에서는 직접 호출할 필요가 없습니다. 씬을 제출하면 렌더팜이 노드 전반에 걸쳐 프레임별로 husk를 실행합니다. 이것의 존재를 알면 완전히 해결된 클린 USD 내보내기가 왜 그렇게 중요한지 이해하는 데 도움이 됩니다.
Q: PDG/TOPs가 렌더팜에서 Karma 렌더를 구동할 수 있습니까?
A: 가능합니다. PDG는 시뮬레이션 캐싱과 그로부터의 렌더링 사이의 의존성을 모델링하며, 스케줄러 노드가 File Cache 단계와 다운스트림 husk 렌더를 렌더팜을 통해 모두 디스패치할 수 있습니다. 진지한 Houdini 파이프라인이 "먼저 캐싱하고, 그 다음 프레임별로 렌더를 팬아웃한다"를 표현하는 표준 방식이며, 작업의 순차적 부분과 병렬 부분을 올바른 순서로 자동으로 유지합니다.
Q: Karma XPU 외에 어떤 Houdini 렌더러를 사용할 수 있습니까? A: 저희 Houdini 스택은 XPU 및 CPU 모드 모두에서 Karma를 실행하며, 추가로 Mantra, Redshift, Arnold, V-Ray for Houdini, Octane을 실행합니다. 이 범위 덕분에 샷에 맞는 엔진을 선택할 수 있습니다. USD 네이티브 룩 개발에는 Karma XPU, VRAM 집약적인 히어로 프레임에는 Karma CPU, 속도와 아웃-오브-코어를 위해서는 Redshift, 레거시 VEX 셰이더에는 Mantra, 이미 그것에 의존하는 파이프라인에는 Arnold, V-Ray 또는 Octane을 사용합니다.
About Alice Harper
Blender and V-Ray specialist. Passionate about optimizing render workflows, sharing tips, and educating the 3D community to achieve photorealistic results faster.
