Houdini Cloud Rendering: Hướng Dẫn Chuyên Sâu VFX Simulation cho Pyro, FLIP, Vellum, Destruction và Crowds

Các scene Houdini thường tạo ra output từ rất lâu trước khi có frame đầu tiên. Một FLIP simulation cần chín giờ để cache local, một Pyro plume baked trên 240 frame, một Vellum cloth solve lấp đầy 4 TB scratch disk — và đó là trước khi bất kỳ Karma sample nào đổ vào beauty pass. Với các FX TD và lookdev artist mà chúng tôi làm việc cùng, nút thắt cổ chai hiếm khi nằm ở bản thân việc render. Chính simulation, cache và việc quản lý các version mới là thứ ngốn cả tuần làm việc, và rồi "render" lại trở thành thứ phải nhồi nhét vào chiều thứ Sáu.

Khoảng cách đó — giữa sim hoàn tất và frame được giao — chính là nơi các quyết định về cloud rendering tồn tại. Chúng tôi đã vận hành Super Renders Farm từ năm 2017, với đội ngũ chạy distributed rendering cho công việc sản xuất nặng FX từ năm 2010. Những câu hỏi chúng tôi nghe từ các Houdini FX TD gần như không bao giờ là "có nên dùng cloud render không?" Họ hỏi "Pyro cache của tôi có sống sót qua quá trình transfer không?" và "Nếu chuyển Vellum bake lên farm, substep có còn ổn định không?" Câu trả lời phụ thuộc vào sim đang làm gì — đó là lý do bài viết này được tổ chức theo từng loại simulation thay vì theo giai đoạn workflow.

Phần tiếp theo là hướng dẫn tối ưu hóa theo từng loại sim. Về setup workflow đầu cuối — chuẩn bị scene, đường dẫn $HIP và $JOB, USD asset resolution, ghim phiên bản plugin — xem hướng dẫn setup Houdini cloud render farm của chúng tôi. Về so sánh các managed Houdini farm theo giá cả, phần cứng và hỗ trợ renderer, xem bài so sánh head-to-head các Houdini render farm. Bài viết chuyên sâu này giả định scene đã sẵn sàng upload và tập trung vào các thông số theo từng loại sim quyết định việc simulation có sống sót qua chuyến đi đến worker fleet hay không, và những gì trả về từ đó.

Tại sao Houdini sim tạo áp lực khác biệt lên cloud farm

Hầu hết nội dung về render farm đóng khung workload là "frames per hour" — một scene cố định được render N lần trên N worker. Mô hình đó phù hợp với lookdev pass tĩnh trên Karma hay Redshift. Nó không phù hợp với Houdini sim, vì trong Houdini "scene" chưa được hoàn thiện cho đến khi sim cache được hoàn thiện. Một Pyro plume, một FLIP volume, một Vellum cloth pre-roll — đây là trạng thái trung gian, không phải trạng thái scene. Farm phải nhận trạng thái trung gian đó dưới dạng đã baked sẵn, hoặc tái tạo từ file .hip mà worker vừa nhận, và hai con đường đó có profile chi phí rất khác nhau.

Giới hạn single-machine trên hầu hết Houdini solver là ràng buộc chủ đạo ở đây. DOPnet substep coherence — yêu cầu frame N phụ thuộc vào frame N-1 trong cùng solver context — có nghĩa là Pyro, FLIP, Vellum và RBD solve phần lớn không thể song song hóa trên các worker node giữa chừng sim. PDG phân tán các wedge và công việc SOP độc lập với frame; vòng lặp solve cơ bản thường không fan out. Hàm ý thực tế: sim hoặc vừa với một worker và workstation, hoặc hoàn toàn không chạy được trên farm. Farm thắng ở tính song song phía render, không phải phía sim.

Trên farm của chúng tôi, phía CPU chạy các node Dual Intel Xeon E5-2699 V4 với 96–256 GB RAM (tổng cộng 20.000+ nhân), đây là tier phù hợp cho cache rebuild và các pass sim/render CPU; phía GPU chạy card RTX 5090 với 32 GB VRAM mỗi card — tier mà Karma XPU và Redshift tiêu thụ ở giai đoạn render. Giai đoạn sim và giai đoạn render đổ vào các fleet khác nhau, đó là lý do giá cho công việc Houdini hầu như luôn là hai dòng riêng — CPU GHz-hours cho cache rebuild (nếu cần), GPU node-hours cho render.

Các entry point dòng lệnh chuẩn là hbatch (thực thi scene Houdini kinh điển) và husk (husk command-line reference — render Solaris/USD stage). Hầu hết tự động hóa phía farm chạy qua một trong hai lệnh này, với file .hip được upload một lần và thực thi per-frame range (hbatch) hoặc render đối chiếu với USD stage đã baked sẵn (husk). Theo từng loại sim, câu hỏi là: ta ship cache đã baked và chạy husk, hay ship file .hip để hbatch rebuild?

Pyro: Smoke, Fire, Explosion Cache ở quy mô cloud

Pyro là solver khói, lửa và vụ nổ của Houdini — mô hình đốt cháy sparse-grid được xây dựng trên Pyro Solver DOPnet, ghi volume .vdb mỗi frame. Quá trình đốt cháy tạo ra các trường temperature, density, fuel, velocity và divergence, và lưới voxel là thông số kiểm soát chính về kích thước cache: giảm voxel size đi một nửa sẽ tăng bộ nhớ và dung lượng đĩa lên khoảng 8 lần (tỉ lệ lập phương). Để có tài liệu kỹ thuật đầy đủ, xem tài liệu SideFX Pyro.

Chiến lược cache. Hầu như luôn bake sang .vdb (OpenVDB sparse) thay vì .bgeo.sc, vì các trường Pyro vốn dĩ thưa thớt — hầu hết voxel là không khí rỗng. Lưu trữ narrow-band của OpenVDB loại bỏ các voxel chết khỏi đĩa. Số substep quan trọng ở đây: Pyro solve sạch ở 1–2 substep cho plume di chuyển chậm, 4–8 substep cho đốt cháy nhanh hoặc shockwave. Substep cao hơn trên farm có nghĩa worker tốn nhiều CPU hơn mỗi frame; substep thấp hơn có nghĩa ít tốn hơn nhưng sim có thể mất coherence trên chuyển động nhanh. Ghim số substep trong DOPnet, không dựa vào hành vi mặc định của farm.

Kích thước voxel, advection scheme (Semi-Lagrangian vs Trilinear vs MacCormack) và các tham số mô hình đốt cháy cùng nhau xác định kích thước .vdb mỗi frame. Một Pyro plume có độ phức tạp trung bình ở voxel size 0,05, 240 frame, thường rơi vào khoảng 20–60 GB tổng. Kiểm tra kích thước cache mỗi frame trước khi upload — bandwidth cho upload thường là nút thắt, không phải render.

Lưu ý khi dùng cloud farm. Pyro render trên GPU qua Karma XPU hoặc Redshift volume rendering, cả hai đều tiêu thụ .vdb natively. Bản thân sim bị ràng buộc CPU và có thể tăng tốc bằng OpenCL, nhưng tăng tốc OpenCL chủ yếu giúp tốc độ bake trên workstation, không phải sim song song theo frame trên farm (vì mỗi frame vẫn phụ thuộc vào frame trước). Pattern thực tế: bake local, upload sequence .vdb, render trên GPU fleet.

# Render một Pyro plume đã cache qua husk trên USD stage,
# với Karma XPU trên GPU node và volume samples được tăng lên.
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"

Lệnh husk đối chiếu với USD stage tham chiếu sequence .vdb đã cache cho phép GPU worker vẽ volume mà không cần re-solve. Tăng volumesamples từ mặc định 4 lên 8 của Karma giảm noise trên plume dày đặc với chi phí tăng thời gian render khoảng 1,5–2 lần. Dùng 16 cho hero shot, để ở 4 cho pre-vis.

FLIP: Liquids, Surface Reconstruction, Narrow-Band

FLIP — Fluid Implicit Particle solver — kết hợp biểu diễn particle và grid để mô phỏng nước, chất lỏng nhớt và free-surface flow. Output gồm hai phần: cache particle (sequence .bgeo.sc dạng packed) và tùy chọn surface mesh đã được reconstruct (cũng là .bgeo.sc). Cả hai đều đến farm, nghĩa là FLIP hầu như luôn nhân đôi dung lượng đĩa so với Pyro ở độ phức tạp tương đương.

Chiến lược cache. Tách cache particle và surface mesh thành hai thư mục cache riêng — particle bake trước, mesh được reconstruct từ particle trong downstream SOP network. Việc tách này cho phép re-mesh mà không cần re-sim, điều quan trọng khi surface tension hoặc particle separation cần pass thứ hai. Một FLIP sim 200 frame độ phức tạp trung bình ở particle separation 0,02 thường rơi vào 80–200 GB phía particle và 20–40 GB phía mesh. Narrow-band FLIP — nơi chỉ các particle gần bề mặt được lưu ở mật độ đầy đủ — cắt giảm cache particle 60–80% trong các shot mà camera không nhìn xuyên qua nước. Bật tính năng này khi camera không nhìn vào phần sâu của chất lỏng.

Độ nhớt và ràng buộc CFL xác định số substep. Sim nước ở viscosity 0 thường chạy ở 1–2 substep; mật ong hay kim loại nóng chảy ở viscosity cao thường cần 5–10 substep để duy trì ổn định. Vi phạm CFL tạo ra particle explosion, trên farm còn tốn kém hơn trên workstation nhiều vì bạn không thấy chúng cho đến khi render hoàn tất.

Lưu ý khi dùng cloud farm. Thời gian upload cache là chi phí chủ đạo của FLIP trên cloud farm. Cache particle 100 GB qua đường truyền upload 100 Mbps của client mất khoảng 2,5 giờ trước khi frame render đầu tiên có thể bắt đầu. Với đường truyền 1 Gbps, cache tương tự upload trong ~15 phút — sự khác biệt này thường quyết định cloud FLIP có khả thi cho một shot hay không. Kiểm tra kích thước cache trước khi upload.

# Hython probe — chạy từ workstation hoặc worker để tính
# kích thước cache mỗi frame trước khi trả bandwidth upload cho
# FLIP sim nhiều TB. Dùng như pre-flight gate.
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} frames, {total/1e9:.2f} GB total, "
      f"{(total/frames)/1e6:.1f} MB/frame avg")

Nếu trung bình mỗi frame vượt quá 500 MB và tổng vượt quá 100 GB, hãy chấp nhận cửa sổ upload hoặc xem xét lại particle separation, narrow-band và ngưỡng surface mesh trước khi transfer.

Vellum: Cloth, Soft Body, Constraint Serialization

Vellum là framework position-based dynamics của Houdini — cloth, soft body, tóc, hạt, chất lỏng theo công thức constrained-position. Output là cache .bgeo.sc mỗi frame, nhưng khác với Pyro hay FLIP, cache Vellum mang trạng thái constraint ngoài vị trí điểm. Đồ thị constraint (pin, stretch, bend, attach-to-static) phải serialize sạch hoặc worker farm sẽ re-solve với constraint bị vỡ. Xem tài liệu Vellum solver để biết ma trận loại constraint.

Chiến lược cache. Cache sau Vellum Solver DOPnet, trước bất kỳ SOP cleanup downstream nào. Dùng Vellum I/O SOP thay vì File Cache thông thường, vì Vellum I/O bảo toàn các constraint attribute (__constraintnetwork, restlength, stiffness) mà cache thông thường sẽ xóa bỏ. Pre-roll quan trọng: cloth cần 20–40 frame để ổn định trước khi phạm vi frame camera bắt đầu, và pre-roll phải có trong cache hoặc worker sẽ render frame 1 với cloth chưa ổn định. Hầu hết Vellum production rig bake pre-roll vào các frame -20 đến 0 của cache.

Số substep là nguyên nhân phổ biến nhất gây ra lỗi Vellum phía farm. Vellum Solver mặc định substep (5) hoạt động cho drape chậm và cloth nhân vật cơ bản, nhưng chuyển động nhanh, tỉ lệ stretch cao và mạng pin chặt thường cần 10–20 substep để duy trì ổn định. Ghim số substep tường minh trong DOPnet — để worker farm dùng mặc định là nơi độ ổn định cross-frame dễ vỡ, vì cache được baked trên workstation ở substep 10 không khớp với cache được rebuild bởi worker ở substep 5.

Lưu ý khi dùng cloud farm. Vellum bị ràng buộc CPU, single-threaded mỗi solver (với multi-thread hạn chế trên constraint resolution) và kích thước cache khiêm tốn — thường 5–20 GB mỗi shot — nên nút thắt upload ít cấp thiết hơn FLIP. Chi phí chủ đạo trên farm là thời gian rebuild nếu .hip được ship thay vì cache đã baked. Cache Vellum 4 GB (trang phục độ phức tạp trung bình) thường mất 30–90 phút để bake trên một worker E5-2699. Nếu bake local trước và upload cache, farm chỉ thấy chi phí render.

# Batch-bake Vellum cloth solve sang .bgeo.sc với override
# substep tường minh. Số substep mặc định là nơi ổn định phía farm
# dễ vỡ trên cloth production-grade.
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"

Override -v vellum_substeps=10 ghim số substep bất kể tham số DOPnet đã lưu trong .hip là gì. Đây là biện pháp bảo vệ an toàn nhất chống lại drift ổn định Vellum phía farm.

Destruction: RBD, Bullet, Constraint Networks

Destruction trong Houdini nghĩa là rigid-body dynamics — RBD Solver, Bullet và các constraint network ghim, pin hoặc snap geometry bị vỡ. Định dạng cache là .bgeo.sc packed primitive, với mỗi packed prim đại diện cho một mảnh vỡ và constraint network được lưu là .bgeo.sc riêng biệt mỗi frame. Fracture phải được thực hiện upstream của sim — trong SOP, không phải DOP — và chỉ geometry sau fracture cộng constraint network mới đến solver.

Chiến lược cache. Hai cache quan trọng: geometry bị vỡ (tĩnh, một frame) và trạng thái transform per-frame động. Chỉ cache transform trong quá trình sim, sau đó áp dụng chúng lúc render qua workflow Packed Disk Primitive. Điều này tách geometry nặng (thường 5–50 GB mảnh vỡ) khỏi trạng thái động rẻ (thường 10–50 MB mỗi frame). Geometry upload một lần; cache động upload theo shot.

Constraint network serialization là điểm dễ mắc lỗi. Constraint RBD (glue, hard, soft, cone-twist) mang attribute __constraintnetwork mà RBD I/O SOP — tương đương Vellum I/O — xử lý đúng, nhưng File Cache thông thường thì không. Dùng RBD I/O cho phía constraint; dùng cache packed-prim chuẩn cho transform.

Lưu ý khi dùng cloud farm. Sim RBD là deterministic nếu random seed được ghim. Hành vi mặc định — seed theo $F, seed theo thời gian trong ngày, hoặc seed không được đặt — tạo ra pattern fracture khác nhau trên các worker khác nhau. Trên farm nơi một worker rebuild cache và worker khác render đối chiếu với pattern dự kiến (ví dụ: setup comp được xây dựng trên cache workstation), seed drift tạo ra mismatch hiển thị chỉ xuất hiện sau khi render hoàn tất. Ghim mọi random seed trước khi bake.

# RBD bake deterministic — ghim RBD_SEED để hai worker
# render cùng frame range tạo ra cache fracture giống hệt nhau.
# Không có điều này, fracture solve có thể desync giữa workstation
# và farm, hiện ra như mismatch lúc composite.
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 Solver: Bullet nhanh hơn cho số lượng mảnh lớn (1.000+ chunk) và chấp nhận được cho destruction chất lượng trung bình; RBD Solver chính xác hơn cho hero-shot dynamics, stack-collapse và setup constraint-driven, với chi phí solve per-frame cao hơn khoảng 3–5 lần. Trên farm, Bullet là mặc định thực tế trừ khi shot là hero.

Crowds: Agents, LOD, Ragdoll Handoff

Houdini Crowds là framework simulation agent — quần thể agent với thư viện motion clip, behavior state và LOD variant. Cache phức tạp hơn các loại sim khác: cache agent (.bclip.sc motion clip), cache transform crowd (.bgeo.sc mỗi frame) và tham chiếu packed-prim agent prim được resolve lúc render. Mỗi agent có LOD hierarchy riêng, được swap lúc render qua Solaris variant set.

Chiến lược cache. Bake crowd sim sang cache transform .bgeo.sc (một file mỗi frame, giữ transform per-agent cộng motion-clip index). Geometry agent — dữ liệu mesh thực sự — nằm trong thư viện .bclip.sc riêng biệt được tham chiếu, không bake mỗi frame. Việc tách này là lý do chính khiến crowd render có thể thực hiện được: một shot ngàn agent có thể có cache transform 200 MB mỗi frame nhưng chỉ 2 GB geometry agent tổng cộng, được tham chiếu từ đĩa.

Motion clip caching quan trọng vì crowd animate bằng cách blend clip, không phải keyframe per-frame. Thư viện clip phải có trên worker trước khi render bắt đầu. Bake thư viện clip một lần, upload lên storage persistent của worker, sau đó upload mỗi shot chỉ là cache transform.

Ragdoll handoff — khi agent chuyển từ animation do clip điều khiển sang physics do RBD điều khiển — cần xử lý đặc biệt trên farm. Cache trạng thái ragdoll tách biệt khỏi cache transform crowd, và frame handoff phải deterministic, nghĩa là ghim seed và ragdoll start frame tường minh. Nếu không, các worker khác nhau tạo ra trajectory ragdoll khác nhau.

Lưu ý khi dùng cloud farm. Crowd render trên Karma (CPU và XPU) qua Solaris stage, với LOD variant agent được resolve lúc render. Swap LOD lúc render có nghĩa bạn có thể thay đổi LOD theo shot mà không cần re-sim — agent high-LOD render cho hero shot, low-LOD cho wide shot, mà không cần chạm vào cache.

# Render Solaris crowd stage với LOD agent được chọn lúc gọi husk.
# Karma tôn trọng variant agent prim cho LOD swapping
# mà không cần rebuild crowd sim.
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"

Override lodVariant:value=mid chọn variant set agent mid-LOD lúc render. Đổi sang low cho pass background xa và high cho hero foreground mà không cần re-run crowd sim. Đây là cách tiết kiệm chi phí shot đơn lớn nhất trong cloud crowd rendering — LOD lúc render cho phép một cache phục vụ mọi shot trong một sequence.

Giới hạn thực tế: Khi farm không phải là công cụ đúng

Cloud farm không phải câu trả lời cho mọi vấn đề Houdini sim, và nói thẳng về điều đó giúp tránh việc shot bị đưa lên farm vì không ai đặt câu hỏi upstream.

Distributed simulation phần lớn không khả thi. Các solver Pyro, FLIP, Vellum và RBD phần lớn bị ràng buộc single-machine bởi DOPnet substep coherence. PDG có thể phân tán wedge và công việc SOP độc lập với frame, nhưng vòng lặp solve bên trong thường không thể fan out trên các worker node giữa chừng sim. Nếu sim của bạn không vừa với một máy — và worker farm thường là Dual Xeon E5-2699 V4 với 96–256 GB RAM, không khác nhiều so với workstation cao cấp — việc chuyển nó lên farm không giải quyết được vấn đề.

Bài toán toán học về bandwidth upload cache. Cache FLIP 100 GB qua đường truyền upload 100 Mbps của client mất khoảng 2,5 giờ trước khi frame render đầu tiên bắt đầu. Upload cache là thời gian wall-clock bạn trả trước khi có bất kỳ rendering nào xảy ra. Gigabit uplink giúp ích; bandwidth workstation phía client thường thì không.

Trade-off GPU vs CPU sim đã có câu trả lời, nhưng không như người dùng mong đợi. Pyro và FLIP có đường dẫn OpenCL tăng tốc substep solve trên workstation. Phần thắng phía farm là render frame song song từ sim đã cache, không phải sim frame song song. Cần hiểu lại: GPU trên farm tương đương tăng tốc render qua Karma XPU hay Redshift; CPU trên farm tương đương rebuild cache nếu bạn ship .hip thay vì cache.

Độ trễ lặp khi điều chỉnh sim phía cloud. Nếu bạn chỉnh tham số Pyro density và cần re-sim, bạn phải upload lại .hip đã sửa, re-cache trên worker, rồi render. Chu kỳ trên farm thường dài 4–8 lần so với chu kỳ local cho công việc nặng sim. Cache trên workstation nếu workstation có thể giữ resolution đó; farm thắng về phía render, không phải phía lặp.

Tính sẵn có của license token cho Houdini Engine. Sử dụng render-only trên managed farm bao gồm Houdini render worker, nhưng Houdini Engine license (cho pipeline nặng HDA, workflow game asset) là loại seat riêng biệt. Xác nhận với farm xem Engine token có được gộp chung và xử lý concurrency như thế nào trước khi submit scene phụ thuộc Engine. Khi farm là công cụ đúng nhưng câu hỏi là farm nào, bài so sánh head-to-head các Houdini render farm của chúng tôi đề cập năm nhà cung cấp managed theo tiêu chí Houdini cụ thể.

Tóm tắt khuyến nghị workflow

Theo từng loại sim, quyết định cache-local hay bake-trên-farm thường rơi vào như sau. Pyro: bake local, upload .vdb, render GPU. FLIP: bake local nếu uplink hỗ trợ kích thước cache, nếu không thì xem xét hbatch rebuild trên worker. Vellum: hầu như luôn bake local — cache nhỏ, thời gian rebuild không nhỏ. Destruction: bake local với seed được ghim, upload cache transform (không phải full geometry mỗi frame). Crowds: bake cache transform local, upload một lần với thư viện agent, render với LOD variant theo shot.

Decision tree chúng tôi hướng dẫn client Houdini mới qua trên trang Houdini cloud render farm đề cập ma trận renderer ở mức người mua; bài viết này đề cập các thông số tối ưu hóa cấp FX-TD bên dưới. Giá CPU trên rate đã công bố của chúng tôi là $0,004/GHz-Hr — phù hợp khi so sánh chi phí cache rebuild nhiều ngày với phương án workstation. Ma trận renderer trên farm của chúng tôi hỗ trợ Karma XPU và Karma CPU, Mantra, Redshift, Arnold, V-Ray for Houdini và Octane.

FAQ

Q: Cài đặt nén .bgeo.sc tốt nhất cho bandwidth upload cloud là gì? A: Đối với FLIP particle cache, .bgeo.sc mặc định (nén sparse dạng packed) đã gần tối ưu cho upload — định dạng được thiết kế cho mục đích đó. Phần thắng bandwidth đơn lớn nhất nằm ở thượng nguồn: bật narrow-band FLIP khi camera không nhìn xuyên qua phần sâu của chất lỏng, có thể cắt giảm kích thước particle cache 60–80% trước khi nén thậm chí bắt đầu. Đối với cache Vellum và RBD, .bgeo.sc cũng đã tối ưu tương tự; phần thắng đến từ chỉ cache những gì thay đổi (transform, không phải full geometry mỗi frame), không phải từ việc thay đổi định dạng. Q: Tôi có thể chạy Pyro hay FLIP simulation phân tán trên nhiều cloud worker không? A: Không, không phải cho vòng lặp solve bên trong. Pyro, FLIP, Vellum và RBD đều dựa vào DOPnet substep coherence — frame N phụ thuộc vào frame N-1 trong cùng solver context — nên solve không thể fan out trên các worker node giữa chừng sim. PDG có thể phân tán wedge (parameter sweep) và công việc SOP độc lập với frame, nhưng solver thực sự chạy trên một máy. Phần thắng của farm với sim work là render frame song song từ cache đã baked, không phải simulation frame song song. Q: Tôi nên cache Vellum trên workstation hay trên farm? A: Hầu như luôn trên workstation. Cache Vellum nhỏ (thường 5–20 GB mỗi shot), thời gian bake workstation có thể quản lý được (30–90 phút cho trang phục độ phức tạp trung bình trên một CPU), và cache upload rẻ. Để worker farm rebuild cache Vellum từ .hip nghĩa là trả CPU GHz-hours cho phía worker mà bạn lẽ ra đã tốn local miễn phí. Ngoại lệ: kịch bản sửa shot khi bạn chỉnh .hip và thay đổi substep làm cache không còn hợp lệ; trong những trường hợp đó, rebuild trên farm là hợp lý. Q: Karma XPU có hỗ trợ render volume của file Pyro .vdb đã cache trên cloud worker không? A: Có. Karma XPU tiêu thụ OpenVDB volume natively qua Solaris stage, và lệnh husk đối chiếu với USD stage tham chiếu sequence .vdb đã cache sẽ render volume mà không cần re-solve. GPU worker vẽ volume trực tiếp; sim không cần có mặt trên worker. Tăng karma:volumesamples từ mặc định 4 lên 8 cho volume chất lượng production, lên 16 cho hero shot — chi phí tăng khoảng 1,5–2 lần thời gian render mỗi lần nhân đôi. Q: Làm thế nào để giữ RBD destruction sim deterministic trên các cloud worker? A: Ghim mọi random seed trong DOPnet trước khi bake — RBD_SEED, fracture seed và bất kỳ seed theo $F hay theo thời gian trong ngày nào. Không có seed pinning, cùng một scene RBD được baked trên hai worker khác nhau sẽ tạo ra pattern fracture khác nhau, hiện ra như mismatch lúc composite khi reference được render trên workstation và bản final được render trên farm không khớp. Đặt seed như biến global trong lệnh hbatch (set -g $RBD_SEED 42) và xác nhận DOPnet đọc nó. Q: Tôi có cần Houdini Engine license để render crowd sim trên cloud farm không? A: Tùy thuộc vào cách xây dựng crowd pipeline. Crowd sim bake sang cache transform .bgeo.sc và render qua Karma đối chiếu với cache không cần Engine — tier render-only license xử lý được. Crowd sim chạy HDA lúc render (tạo agent procedural, asset procedural được instance) có thể cần Engine seat. Xác nhận với farm xem Engine token có được gộp chung và xử lý concurrency như thế nào. Trên farm của chúng tôi, mô hình render-only license cho phép render Karma XPU trên GPU fleet và CPU renderer trên CPU fleet mà không bị ràng buộc Engine seat; pipeline crowd nặng HDA nên được thảo luận trong quá trình setup shot.

Bài đọc liên quan

• Houdini Cloud Render Farm
• Hướng Dẫn Setup Houdini Cloud Render Farm cho 2026
• So Sánh Head-to-Head Các Houdini Render Farm 2026
• Hướng Dẫn Chi Phí Render Farm Per Frame

Tài nguyên bên ngoài

• Tài liệu SideFX Houdini
• Tài liệu SideFX Pyro
• Tài liệu SideFX Vellum
• Husk Command-Line Reference