Houdini 클라우드 렌더링: Pyro, FLIP, Vellum, 파괴, Crowds 시뮬레이션 VFX 심층 가이드

Houdini 씬은 프레임을 생성하기 훨씬 전에 결과물을 만들어내는 특성이 있습니다. 로컬에서 캐시하는 데 9시간이 걸리는 FLIP 시뮬레이션, 240프레임에 걸쳐 베이크된 Pyro 연기, 4TB 스크래치 디스크를 가득 채우는 Vellum 클로스 솔브 — 그리고 이 모든 것이 Karma 샘플 하나가 뷰티 패스에 착지하기 전의 이야기입니다. 저희와 함께 작업하는 FX TD와 룩뎁 아티스트에게 있어 병목은 렌더링 자체가 아닌 경우가 대부분입니다. 시뮬레이션, 캐시, 버전 관리가 한 주를 잠식하고, 그러다 보면 '렌더링'은 금요일 오후에 끼워 넣어야 할 작업이 됩니다.

이 간극 — 시뮬레이션이 완료된 시점과 프레임이 전달되는 시점 사이 — 이 바로 클라우드 렌더링 결정이 이루어지는 곳입니다. 저희는 2017년부터 Super Renders Farm을 운영해 왔으며, 팀은 2010년부터 FX 집약적 프로덕션 작업을 위한 분산 렌더링을 수행해 왔습니다. Houdini FX TD에게서 듣는 질문은 거의 항상 "클라우드 렌더링을 해야 할까요?"가 아닙니다. 오히려 "Pyro 캐시가 전송을 버텨낼까요?"와 "Vellum 베이크를 팜으로 옮기면 서브스텝이 안정적으로 유지될까요?"입니다. 그 답은 시뮬레이션이 무엇을 하느냐에 달려 있습니다 — 그래서 이 글은 워크플로 단계가 아닌 시뮬레이션 유형별로 구성되어 있습니다.

이어지는 내용은 시뮬레이션 유형별 최적화 매뉴얼입니다. 엔드투엔드 워크플로 설정 — 씬 준비, $HIP 및 $JOB 경로, USD 에셋 해석, 플러그인 버전 고정 — 에 대해서는 Houdini 클라우드 렌더팜 설정 가이드를 참조하십시오. 가격, 하드웨어, 렌더러 지원 측면에서 관리형 Houdini 렌더팜 벤더 비교는 Houdini 렌더팜 비교 가이드를 참조하십시오. 이 심층 가이드는 씬이 업로드 준비 완료 상태임을 가정하며, 시뮬레이션 자체가 워커 플릿까지의 여정을 버텨낼지 — 그리고 무엇이 돌아오는지 — 를 결정하는 시뮬레이션 유형별 설정값에 집중합니다.

Houdini 시뮬레이션이 클라우드 렌더팜에 다른 부하를 주는 이유

대부분의 렌더팜 콘텐츠는 작업량을 '프레임/시간'으로 표현합니다 — N개의 워커에서 N번 렌더링되는 고정된 씬. 이 모델은 Karma나 Redshift의 정적 룩뎁 패스에는 맞습니다. Houdini 시뮬레이션에는 맞지 않습니다. Houdini에서 '씬'은 시뮬레이션 캐시가 완성될 때까지 완성되지 않기 때문입니다. Pyro 연기, FLIP 볼륨, Vellum 클로스 프리롤 — 이것들은 씬 상태가 아닌 중간 상태입니다. 팜은 이 중간 상태를 미리 베이크된 형태로 받거나, 워커가 방금 수신한 .hip 파일에서 재구성해야 하며, 이 두 경로는 비용 프로파일이 매우 다릅니다.

대부분의 Houdini 솔버에서 단일 머신 한계가 핵심 제약입니다. DOPnet 서브스텝 코히런스 — 프레임 N이 동일한 솔버 컨텍스트에서 프레임 N-1에 의존해야 한다는 요건 — 는 Pyro, FLIP, Vellum, RBD 솔브가 대부분 시뮬레이션 중간에 워커 노드 간에 병렬화될 수 없음을 의미합니다. PDG는 웨지와 프레임 독립적인 SOP 작업을 분산시킵니다. 실제적 함의: 시뮬레이션은 하나의 워커와 워크스테이션에 들어맞거나, 팜에서 전혀 실행되지 않습니다. 팜은 시뮬레이션 측 병렬성이 아닌 렌더링 측 병렬성에서 이깁니다.

저희 렌더팜의 CPU 측은 96–256GB RAM의 Dual Intel Xeon E5-2699 V4 노드(합산 20,000+ 코어)로 구성되어 있으며, 이는 캐시 재구성과 CPU 시뮬/렌더 패스에 관련된 티어입니다. GPU 측은 각 32GB VRAM의 RTX 5090 카드로, 렌더 단계에서 Karma XPU와 Redshift가 소비하는 티어입니다. 시뮬 단계와 렌더 단계는 다른 플릿에 할당되므로, Houdini 작업의 요금은 거의 항상 두 항목 — 캐시 재구성(필요 시)을 위한 CPU GHz-시간, 렌더링을 위한 GPU 노드-시간 — 으로 구성됩니다.

표준 커맨드라인 진입점은 hbatch(클래식 Houdini 씬 실행)와 husk(husk 커맨드라인 레퍼런스 — Solaris/USD 스테이지 렌더링)입니다. 대부분의 팜 측 자동화는 이 중 하나를 통해 실행되며, .hip는 한 번 업로드되고 프레임 범위별로 재실행(hbatch)되거나 미리 베이크된 USD 스테이지 기준으로 렌더링(husk)됩니다. 시뮬레이션 유형별 질문은 이것입니다: 베이크된 캐시를 전송하고 husk를 실행할 것인가, 아니면 .hip를 전송하고 hbatch가 재구성하도록 할 것인가?

Pyro: 클라우드 규모의 연기, 화염, 폭발 캐시

Pyro는 Houdini의 연기, 화염, 폭발 솔버입니다 — Pyro Solver DOPnet 위에 구축된 스파스 그리드 연소 모델로, 프레임당 .vdb 볼륨을 씁니다. 연소는 온도, 밀도, 연료, 속도, 발산 필드를 생성하며, 복셀 그리드가 캐시 크기의 주요 제어 요소입니다. 복셀 크기를 절반으로 줄이면 메모리와 디스크 비용이 약 8배 증가합니다(큐빅 스케일링). 전체 기술 컨텍스트는 SideFX Pyro 문서를 참조하십시오.

캐시 전략. .bgeo.sc보다는 거의 항상 .vdb(OpenVDB sparse)로 베이크하십시오. Pyro 필드는 본질적으로 스파스하기 때문입니다 — 대부분의 복셀은 빈 공기입니다. OpenVDB의 내로우 밴드 저장 방식은 죽은 복셀을 디스크에서 제거합니다. 서브스텝 수가 중요합니다: Pyro는 느리게 움직이는 플룸에서는 1–2 서브스텝, 빠른 연소나 충격파에서는 4–8 서브스텝으로 깔끔하게 솔브됩니다. 팜에서 서브스텝이 높을수록 워커는 프레임당 더 많은 CPU를 소비합니다. DOPnet에서 서브스텝 수를 고정하고 팜 기본 동작에 의존하지 마십시오.

복셀 크기, 어드벡션 방식(Semi-Lagrangian vs. Trilinear vs. MacCormack), 연소 모델 파라미터가 함께 프레임당 .vdb 크기를 결정합니다. 복셀 크기 0.05, 240프레임의 중간 복잡도 Pyro 플룸은 일반적으로 총 20–60GB 범위에 해당합니다. 업로드 전에 프레임당 캐시 크기를 사전 점검하십시오 — 업로드 대역폭이 렌더링보다 병목이 되는 경우가 많습니다.

클라우드 렌더팜 고려사항. Pyro는 Karma XPU 또는 Redshift 볼륨 렌더링을 통해 GPU에서 렌더링되며, 두 방식 모두 .vdb를 네이티브로 소비합니다. 시뮬레이션 자체는 CPU 바운드이며 OpenCL 가속이 가능하지만, OpenCL 가속은 주로 워크스테이션 베이크 속도를 높이는 데 도움이 됩니다(각 프레임이 여전히 이전 프레임에 의존하므로 팜 측 병렬 프레임 시뮬레이션에는 도움이 제한적). 실용적 패턴: 로컬에서 베이크하고, .vdb 시퀀스를 업로드하고, GPU 플릿에서 렌더링합니다.

# USD 스테이지에서 husk를 통해 캐시된 Pyro 플룸을 렌더링,
# GPU 노드에서 Karma XPU를 사용하고 볼륨 샘플을 높임.
husk --renderer karma \
     --frame 1 --frame-count 240 --frame-inc 1 \
     --verbose 3a \
     --output "$HIP/render/pyro_plume.\$F4.exr" \
     --settings xpu \
     --override "/Render/rendersettings:karma:volumesamples=8" \
     "$HIP/stage/pyro_plume_volumes.usd"

캐시된 .vdb 시퀀스를 참조하는 USD 스테이지를 대상으로 하는 husk 호출은 GPU 워커가 재솔브 없이 볼륨을 그릴 수 있게 합니다. volumesamples를 Karma 기본값 4에서 8로 올리면 밀도 높은 플룸의 노이즈가 약 1.5–2배 렌더 시간 비용으로 감소합니다. 히어로 샷에는 16을 사용하고, 프리비스에는 4로 유지하십시오.

FLIP: 액체, 표면 재구성, 내로우 밴드

FLIP — Fluid Implicit Particle 솔버 — 는 파티클과 그리드 표현을 결합하여 물, 점성 액체, 자유 표면 흐름을 시뮬레이션합니다. 결과물은 두 가지입니다: 파티클 캐시(.bgeo.sc packed 시퀀스)와 선택적으로 재구성된 표면 메시(역시 .bgeo.sc). 둘 다 팜으로 전송되므로 FLIP은 동일한 복잡도에서 Pyro에 비해 디스크 풋프린트가 거의 항상 두 배가 됩니다.

캐시 전략. 파티클 캐시와 표면 메시를 두 개의 별도 캐시 디렉토리로 분리하십시오 — 파티클이 먼저 베이크되고, 메시는 다운스트림 SOP 네트워크에서 파티클로부터 재구성됩니다. 이 분리 방식은 재시뮬레이션 없이 리메싱을 가능하게 합니다. 파티클 분리 0.02의 중간 복잡도 200프레임 FLIP 시뮬레이션은 파티클 측에서 80–200GB, 메시 측에서 20–40GB가 되는 경우가 많습니다. 내로우 밴드 FLIP — 표면 근처의 파티클만 전체 밀도로 저장 — 은 카메라가 물을 투시하지 않는 샷에서 파티클 캐시를 60–80% 줄입니다.

점성 강성과 CFL 제약이 서브스텝 수를 결정합니다. 점성 0의 물 시뮬레이션은 일반적으로 1–2 서브스텝으로 실행되며, 고점성의 꿀이나 용융 금속은 안정성을 유지하기 위해 종종 5–10 서브스텝이 필요합니다. CFL 위반은 파티클 폭발을 생성하는데, 팜에서는 렌더링이 완료될 때까지 보이지 않으므로 워크스테이션보다 훨씬 비쌉니다.

클라우드 렌더팜 고려사항. 캐시 업로드 시간이 클라우드 렌더팜에서 FLIP의 주요 비용입니다. 100Mbps 클라이언트 업링크로 100GB 파티클 캐시를 전송하면 첫 번째 렌더 프레임이 시작되기까지 약 2.5시간이 걸립니다. 1Gbps 업링크에서는 동일한 캐시가 약 15분 안에 업로드됩니다 — 이 차이가 클라우드 FLIP이 해당 샷에 운용 가능한지를 결정하는 경우가 많습니다. 업로드 전에 캐시 크기를 감사하십시오.

# Hython 프로브 — 다중 TB FLIP 시뮬레이션에 업로드 대역폭 비용을 지불하기 전에
# 프레임당 캐시 크기를 계산하기 위해 워크스테이션 또는 워커에서 실행.
# 사전 점검 게이트로 활용.
import os, hou
cache_dir = hou.expandString("$HIP/cache/flip/v003")
total = 0
frames = 0
for f in sorted(os.listdir(cache_dir)):
    if f.endswith(".bgeo.sc"):
        size = os.path.getsize(os.path.join(cache_dir, f))
        total += size
        frames += 1
print(f"{frames}프레임, 총 {total/1e9:.2f}GB, "
      f"프레임당 평균 {(total/frames)/1e6:.1f}MB")

프레임당 평균이 500MB를 초과하고 총합이 100GB를 초과하면, 업로드 창을 수용하거나 전송 전에 파티클 분리, 내로우 밴드, 표면 메시 임계값을 재검토하십시오.

Vellum: 클로스, 소프트 바디, 제약 직렬화

Vellum은 Houdini의 위치 기반 다이나믹스 프레임워크입니다 — 제약 위치 공식화에 기반한 클로스, 소프트 바디, 헤어, 그레인, 유체. 출력은 프레임당 .bgeo.sc 캐시이지만, Pyro나 FLIP과 달리 Vellum 캐시는 포인트 위치 외에 제약 상태를 포함합니다. 제약 그래프(핀, 스트레치, 벤드, attach-to-static)가 깔끔하게 직렬화되어야 하며, 그렇지 않으면 팜 워커가 손상된 제약으로 재솔브합니다. 제약 유형 매트릭스는 Vellum 솔버 문서를 참조하십시오.

캐시 전략. Vellum Solver DOPnet 이후, 다운스트림 SOP 정리 이전에 캐시하십시오. 일반 File Cache 대신 Vellum I/O SOP를 사용하십시오. Vellum I/O는 일반 캐시가 제거할 제약 속성(__constraintnetwork, restlength, stiffness)을 보존하기 때문입니다. 프리롤이 중요합니다: 클로스는 카메라 프레임 범위가 시작되기 전에 20–40프레임의 정착이 필요하며, 프리롤이 캐시에 있어야 합니다. 대부분의 Vellum 프로덕션 리그는 캐시의 -20~0프레임에 프리롤을 베이크합니다.

서브스텝 수가 팜 측 Vellum 실패의 가장 흔한 원인입니다. Vellum Solver 기본 서브스텝(5)은 느린 드레이프와 기본 캐릭터 클로스에는 작동하지만, 빠른 동작, 높은 스트레치 비율, 타이트한 핀 네트워크는 안정성을 유지하기 위해 종종 10–20 서브스텝이 필요합니다. DOPnet에서 서브스텝 수를 명시적으로 고정하십시오 — 팜 워커의 기본값을 사용하게 하는 것이 프레임 간 안정성이 무너지는 지점입니다.

클라우드 렌더팜 고려사항. Vellum은 CPU 바운드이고 솔버당 단일 스레드이며(제약 해석에서 제한적 멀티스레드), 캐시 크기는 작습니다 — 일반적으로 샷당 5–20GB — 따라서 업로드 병목은 FLIP보다 덜 심각합니다. 베이크된 캐시 대신 .hip를 전송하는 경우 팜의 주요 비용은 재구성 시간입니다. 4GB Vellum 캐시(중간 복잡도 의상)는 단일 E5-2699 워커에서 베이크하는 데 일반적으로 30–90분이 걸립니다. 로컬에서 먼저 베이크하고 캐시를 업로드하면 팜은 렌더링 비용만 부담합니다.

# 명시적 서브스텝 오버라이드로 Vellum 클로스 솔브를 .bgeo.sc로 배치 베이크.
# 기본 서브스텝 수가 프로덕션 품질 클로스의 팜 측 안정성이 무너지는 지점입니다.
hbatch -c "render -f 1 240 -i 1 \
  -v vellum_substeps=10 \
  -v cache_format=bgeo.sc \
  /obj/cloth_sim/dop_cache_OUT" \
  -d "/obj/cloth_sim/dopnet1" \
  "$HIP/scenes/cloth_main_v007.hip"

-v vellum_substeps=10 오버라이드는 .hip의 저장된 DOPnet 파라미터에 관계없이 서브스텝 수를 고정합니다. 이것이 팜 측 Vellum 안정성 드리프트에 대한 가장 안전한 단일 보호 수단입니다.

파괴: RBD, Bullet, 제약 네트워크

Houdini에서 파괴는 강체 다이나믹스를 의미합니다 — RBD 솔버, Bullet, 그리고 부서진 지오메트리를 접착, 고정 또는 분리하는 제약 네트워크. 캐시 형식은 .bgeo.sc packed primitive로, 각 packed prim은 부서진 조각을 나타내고 제약 네트워크는 프레임당 별도 .bgeo.sc로 저장됩니다. 시뮬레이션 전에 지오메트리를 분할하십시오 — SOPs에서, DOPs가 아닌 — 그리고 후분할 지오메트리와 제약 네트워크만 솔버로 전송됩니다.

캐시 전략. 두 개의 캐시가 중요합니다: 분할된 지오메트리(정적, 하나의 프레임)와 프레임당 동적 트랜스폼 상태. 시뮬레이션 동안 트랜스폼만 캐시하고, 렌더링 시 Packed Disk Primitive 워크플로를 통해 적용하십시오. 이렇게 하면 무거운 지오메트리(종종 5–50GB의 부서진 조각)와 저렴한 동적 상태(일반적으로 프레임당 10–50MB)가 분리됩니다. 지오메트리는 한 번 업로드되고, 동적 캐시는 샷별로 업로드됩니다.

제약 네트워크 직렬화가 함정입니다. RBD 제약(glue, hard, soft, cone-twist)은 Vellum I/O 등가물인 RBD I/O SOP이 올바르게 처리하지만 일반 File Cache는 그렇지 않은 __constraintnetwork 속성을 포함합니다. 제약 측에는 RBD I/O를 사용하고, 트랜스폼에는 표준 packed prim 캐시를 사용하십시오.

클라우드 렌더팜 고려사항. RBD 시뮬레이션은 랜덤 시드가 고정된 경우 결정론적입니다. 기본 동작 — $F 기반 시드, 시간 기반 시드, 또는 설정되지 않은 시드 — 은 다른 워커에서 다른 분할 패턴을 생성합니다. 한 워커가 캐시를 재구성하고 다른 워커가 예상 패턴(예: 워크스테이션 캐시에서 미리 구축된 컴프 설정)에 대해 렌더링하는 팜에서, 시드 드리프트는 렌더링이 완료된 후에만 나타나는 눈에 띄는 불일치를 생성합니다. 베이크 전에 모든 랜덤 시드를 고정하십시오.

# 결정론적 RBD 베이크 — RBD_SEED를 고정하여 동일한 프레임 범위를 렌더링하는
# 두 워커가 동일한 분할 캐시를 생성하도록 합니다.
# 이 없이는 분할 솔브가 워크스테이션과 팜 사이에서 비동기화되어
# 컴프 시간 불일치로 나타날 수 있습니다.
hbatch -c "set -g \$RBD_SEED 42; \
  render -f 1 200 \
  -v packed_prims=1 \
  /obj/destruction/dop_constraint_OUT" \
  "$HIP/scenes/destruction_v012.hipnc"

Bullet vs. RBD 솔버: Bullet은 대량의 조각(1,000개 이상)에서 더 빠르며 중간 품질 파괴에 적합하고, RBD 솔버는 히어로 샷 다이나믹스, 스택 붕괴, 제약 기반 설정에 더 정확하지만 프레임당 솔브 비용이 약 3–5배 더 높습니다. 팜에서 Bullet은 샷이 히어로가 아닌 한 실용적인 기본값입니다.

Crowds: 에이전트, LOD, 래그돌 핸드오프

Houdini Crowds는 에이전트 시뮬레이션 프레임워크입니다 — 모션 클립 라이브러리, 동작 상태, LOD 변형이 있는 에이전트 집단. 캐시는 다른 시뮬레이션 유형보다 복잡합니다: 에이전트 캐시(.bclip.sc 모션 클립), 군중 트랜스폼 캐시(프레임당 .bgeo.sc), 렌더링 시 해석되는 에이전트 prim packed prim 참조. 각 에이전트는 렌더링 시 Solaris 변형 세트를 통해 교체되는 자체 LOD 계층을 가집니다.

캐시 전략. 군중 시뮬레이션을 .bgeo.sc 트랜스폼 캐시로 베이크하십시오(에이전트별 트랜스폼과 모션 클립 인덱스를 담은 프레임당 하나의 파일). 에이전트 지오메트리 — 실제 메시 데이터 — 는 프레임당 베이크되지 않고 참조되는 별도 .bclip.sc 라이브러리에 있습니다. 이 분리가 군중 렌더링이 실용적인 이유입니다: 천 명의 에이전트 샷은 프레임당 200MB 트랜스폼 캐시를 가질 수 있지만, 디스크에서 참조되는 에이전트 지오메트리는 총 2GB뿐입니다.

모션 클립 캐싱이 중요합니다. 군중은 프레임별 키프레임이 아닌 클립을 혼합하여 애니메이션화되기 때문입니다. 클립 라이브러리는 렌더링이 시작되기 전에 워커에 있어야 합니다. 클립 라이브러리를 한 번 베이크하고, 워커의 영구 저장소에 업로드하면, 샷별 업로드는 트랜스폼 캐시만 됩니다.

래그돌 핸드오프 — 에이전트가 클립 기반 애니메이션에서 RBD 기반 물리로 전환되는 것 — 는 팜에서 특별한 처리가 필요합니다. 래그돌 상태 캐시는 군중 트랜스폼 캐시와 분리되며, 핸드오프 프레임은 결정론적이어야 합니다 — 시드와 래그돌 시작 프레임을 명시적으로 고정해야 합니다. 그렇지 않으면 다른 워커들이 다른 래그돌 궤적을 생성합니다.

클라우드 렌더팜 고려사항. Crowds는 Solaris 스테이지를 통해 Karma(CPU 및 XPU)에서 렌더링되며, 에이전트 LOD 변형은 렌더링 시 해석됩니다. 렌더링 시 LOD 교체는 재시뮬레이션 없이 샷별 LOD를 변경할 수 있음을 의미합니다 — 히어로 샷에는 고-LOD 에이전트, 와이드 샷에는 저-LOD, 캐시 변경 없이.

# husk 호출 시 에이전트 LOD가 선택된 Solaris 군중 스테이지를 렌더링.
# Karma는 군중 시뮬레이션 재구성 없이 LOD 교체를 위한 에이전트 prim 변형을 지원합니다.
husk --renderer karma --settings xpu \
     --frame 1 --frame-count 240 \
     --output "$HIP/render/crowd.\$F4.exr" \
     --override "/World/crowd:variantSet:lodVariant:value=mid" \
     "$HIP/stage/crowd_main.usd"

lodVariant:value=mid 오버라이드는 렌더링 시 mid-LOD 에이전트 변형 세트를 선택합니다. 원거리 배경 패스에는 low로, 히어로 전경에는 high로 군중 시뮬레이션을 재실행하지 않고 교체하십시오. 이것이 클라우드 군중 렌더링에서 가장 큰 단일 샷 비용 절감책입니다 — 렌더링 시 LOD는 하나의 캐시가 시퀀스의 모든 샷을 처리할 수 있게 합니다.

솔직한 한계: 팜이 올바른 도구가 아닐 때

클라우드 렌더팜이 모든 Houdini 시뮬레이션 문제의 답은 아니며, 이를 명확히 하는 것이 아무도 업스트림 질문을 하지 않았기 때문에 샷이 팜에 가는 것을 방지합니다.

분산 시뮬레이션은 대부분 불가능합니다. Pyro, FLIP, Vellum, RBD 솔버는 대부분 DOPnet 서브스텝 코히런스에 의해 단일 머신에 바운드됩니다. PDG는 웨지와 프레임 독립적인 SOP 작업을 분산시킬 수 있지만, 내부 솔브 루프는 일반적으로 시뮬레이션 중간에 워커 노드 간에 분산될 수 없습니다. 시뮬레이션이 하나의 머신에 들어맞지 않는다면 — 팜 워커는 일반적으로 96–256GB RAM의 Dual Xeon E5-2699 V4로, 고사양 워크스테이션과 크게 다르지 않습니다 — 팜으로 이동해도 문제가 해결되지 않습니다.

캐시 업로드 대역폭 계산. 100Mbps 클라이언트 업링크로 100GB FLIP 캐시를 전송하면 첫 번째 렌더 프레임이 시작되기까지 약 2.5시간이 걸립니다. 캐시 업로드는 렌더링이 시작되기 전에 지불하는 시간입니다. 기가비트 업링크가 도움이 됩니다.

GPU vs. CPU 시뮬레이션 트레이드오프는 해결되었지만, 사용자들이 기대하는 방식이 아닙니다. Pyro와 FLIP은 워크스테이션에서 서브스텝 솔브를 가속하는 OpenCL 경로를 가집니다. 팜 측 이점은 캐시된 시뮬레이션의 병렬 프레임 렌더링이지, 병렬 프레임 시뮬레이션이 아닙니다. 재구성: 팜의 GPU는 Karma XPU 또는 Redshift를 통한 렌더 가속을 의미하고, 팜의 CPU는 캐시 대신 .hip를 전송하는 경우 캐시 재구성을 의미합니다.

클라우드 측 시뮬레이션 조정에서의 이터레이션 지연. Pyro 밀도 파라미터를 조정하고 재시뮬레이션이 필요한 경우, 수정된 .hip를 다시 업로드하고 워커에서 재캐시한 후 렌더링합니다. 팜에서의 사이클은 시뮬레이션 집약적인 작업에서 로컬 사이클보다 종종 4–8배 더 깁니다. 워크스테이션이 해당 해상도를 처리할 수 있다면 워크스테이션에서 캐시하십시오.

Houdini Engine의 라이센스 토큰 가용성. 관리형 팜에서의 렌더 전용 사용은 Houdini 렌더 워커를 포함하지만, Houdini Engine 라이센스(HDA 집약적 절차적 파이프라인, 게임 에셋 워크플로용)는 별도의 seat 유형입니다. Engine 종속 씬을 제출하기 전에 Engine 토큰이 풀링되어 있는지와 동시성이 어떻게 처리되는지 팜에 확인하십시오. 팜이 올바른 도구이지만 어느 팜인지가 질문이 될 때, 저희의 Houdini 렌더팜 비교 가이드는 Houdini 특정 기준에 따라 다섯 개의 관리형 제공업체를 다룹니다.

워크플로 권장사항 요약

시뮬레이션 유형별로, 로컬 캐시 vs. 팜 베이크 결정은 일반적으로 다음과 같습니다. Pyro: 로컬 베이크, .vdb 업로드, GPU 렌더링. FLIP: 업링크가 캐시 크기를 지원하면 로컬 베이크, 그렇지 않으면 워커에서 hbatch 재구성 고려. Vellum: 거의 항상 로컬 베이크 — 캐시가 작고 재구성 시간이 적지 않습니다. 파괴: 시드 고정 후 로컬 베이크, 트랜스폼 캐시 업로드(프레임당 전체 지오메트리 아님). Crowds: 트랜스폼 캐시 로컬 베이크, 에이전트 라이브러리와 함께 한 번 업로드, 샷별 LOD 변형으로 렌더링.

저희 Houdini 클라우드 렌더팜 랜딩 페이지에서 새 Houdini 클라이언트를 안내하는 결정 트리는 구매자 수준에서 렌더러 매트릭스를 다루며, 이 글은 그 아래의 FX-TD 수준 최적화 조정값을 다루었습니다. 저희 공개 요금의 CPU 가격은 $0.004/GHz-시간 — 다중 일 캐시 재구성 비용을 워크스테이션 대안과 비교할 때 관련됩니다. 저희 렌더팜의 렌더러 매트릭스는 Karma XPU와 Karma CPU, Mantra, Redshift, Arnold, V-Ray for Houdini, Octane을 지원합니다.

FAQ

Q: 클라우드 업로드 대역폭을 위한 최선의 .bgeo.sc 압축 설정은 무엇입니까? A: FLIP 파티클 캐시의 경우, 기본 .bgeo.sc(packed sparse 압축)는 이미 업로드에 최적화되어 있습니다 — 이 형식은 그것을 위해 설계되었습니다. 가장 큰 단일 대역폭 이득은 업스트림에 있습니다: 카메라가 깊은 볼륨을 투시하지 않을 때 내로우 밴드 FLIP을 켜면, 압축이 실행되기 전에 파티클 캐시 크기를 60–80% 줄일 수 있습니다. Vellum과 RBD 캐시의 경우, .bgeo.sc는 마찬가지로 이미 최적화되어 있으며, 이득은 형식을 변경하는 것이 아닌 변화하는 것만(프레임당 전체 지오메트리가 아닌 트랜스폼) 캐싱하는 데서 옵니다.

Q: 여러 클라우드 워커에서 분산 Pyro 또는 FLIP 시뮬레이션을 실행할 수 있습니까? A: 아니요, 내부 솔브 루프에 대해서는 불가능합니다. Pyro, FLIP, Vellum, RBD는 모두 DOPnet 서브스텝 코히런스에 의존합니다 — 프레임 N은 동일한 솔버 컨텍스트에서 프레임 N-1에 의존합니다 — 따라서 솔브는 시뮬레이션 중간에 워커 노드 간에 분산될 수 없습니다. PDG는 웨지(파라미터 스윕)와 프레임 독립적인 SOP 작업을 분산시킬 수 있지만, 실제 솔버는 하나의 머신에서 실행됩니다. 시뮬레이션 작업에서 팜의 이점은 베이크된 캐시의 병렬 프레임 렌더링이지, 병렬 프레임 시뮬레이션이 아닙니다.

Q: Vellum을 워크스테이션에서 캐시해야 합니까, 아니면 팜에서 캐시해야 합니까? A: 거의 항상 워크스테이션에서 캐시하십시오. Vellum 캐시는 작습니다(일반적으로 샷당 5–20GB), 워크스테이션 베이크 시간은 관리 가능합니다(단일 CPU에서 중간 복잡도 의상 30–90분), 캐시 업로드 비용도 저렴합니다. 팜 워커가 .hip에서 Vellum 캐시를 재구성하게 하면 로컬에서 무료로 소비했을 워커 측 CPU GHz-시간을 지불하는 것입니다. 예외: .hip를 조정하고 서브스텝 변경이 캐시를 무효화하는 샷 수정 시나리오의 경우, 팜 재구성이 합리적입니다.

Q: Karma XPU는 클라우드 워커에서 캐시된 Pyro .vdb 파일의 볼륨 렌더링을 지원합니까? A: 네. Karma XPU는 Solaris 스테이지를 통해 OpenVDB 볼륨을 네이티브로 소비하며, 캐시된 .vdb 시퀀스를 참조하는 USD 스테이지를 대상으로 하는 husk 호출은 재솔브 없이 볼륨을 렌더링합니다. GPU 워커는 볼륨을 직접 그립니다. karma:volumesamples를 기본값 4에서 8로 올리면 프로덕션 품질 볼륨이, 16이면 히어로 샷이 됩니다 — 비용은 2배마다 약 1.5–2배의 렌더 시간입니다.

Q: 클라우드 워커에서 RBD 파괴 시뮬레이션을 결정론적으로 유지하려면 어떻게 해야 합니까? A: 베이크 전에 DOPnet의 모든 랜덤 시드를 고정하십시오 — RBD_SEED, 분할 시드, 모든 $F 기반 또는 시간 기반 시드. 시드 고정 없이 두 다른 워커에서 베이크된 동일한 RBD 씬은 다른 분할 패턴을 생성하며, 이는 워크스테이션 렌더링 참조와 팜 렌더링 최종본이 일치하지 않을 때 컴프 시간 불일치로 나타납니다. hbatch 호출에서 시드를 전역 변수로 설정하고(set -g $RBD_SEED 42) DOPnet이 이를 읽는지 확인하십시오.

Q: 클라우드 렌더팜에서 군중 시뮬레이션을 렌더링하기 위해 Houdini Engine 라이센스가 필요합니까? A: 군중 파이프라인이 어떻게 구성되어 있는지에 따라 다릅니다. .bgeo.sc 트랜스폼 캐시로 베이크하고 캐시 기준으로 Karma를 통해 렌더링하는 군중 시뮬레이션은 Engine이 필요하지 않습니다 — 렌더 전용 라이센스 티어가 처리합니다. 렌더링 시 HDA를 실행하는 군중 시뮬레이션(절차적 에이전트 생성, 인스턴스화된 절차적 에셋)은 Engine seat가 필요할 수 있습니다. Engine 토큰이 풀링되어 있는지와 동시성이 어떻게 처리되는지 팜에 확인하십시오. 저희 팜에서는 렌더 전용 라이센스 모델이 Engine seat 제약 없이 GPU 플릿에서 Karma XPU를, CPU 플릿에서 CPU 렌더러를 렌더링할 수 있게 합니다. HDA 집약적 군중 파이프라인은 샷 설정 중에 논의해야 합니다.

관련 기사

• Houdini Cloud Render Farm
• 2026 Houdini 클라우드 렌더팜 설정 가이드
• Houdini 렌더팜 헤드투헤드 비교 2026
• 렌더팜 프레임당 비용 가이드

외부 리소스

• SideFX Houdini 문서
• SideFX Pyro 문서
• SideFX Vellum 문서
• Husk 커맨드라인 레퍼런스