Houdini Cloud Rendering: guia técnico aprofundado de simulações VFX para Pyro, FLIP, Vellum, destruição e Crowds

As cenas de Houdini têm uma forma particular de gerar resultados muito antes de produzirem fotogramas. Uma simulação FLIP que demora nove horas a ser armazenada em cache localmente, um Pyro plume cozido ao longo de 240 fotogramas, um solve de Vellum cloth que enche um disco scratch de 4 TB — e isso antes de um único sample de Karma aterrar na passagem de beauty. Para os FX TDs e artistas de lookdev com quem trabalhamos, o obstáculo raramente é a renderização em si. É a simulação, o cache e a gestão de versões que consome a semana — e então «o render» torna-se aquilo que tem de caber na tarde de sexta-feira.

Essa lacuna — entre a simulação concluída e os fotogramas entregues — é onde vivem as decisões de cloud rendering. Operamos a Super Renders Farm desde 2017, com a equipa a realizar renderização distribuída para trabalho de produção FX intensivo desde 2010. As perguntas que ouvimos dos FX TDs de Houdini quase nunca são «devemos usar cloud rendering?». São: «será que o meu cache de Pyro sobrevive à transferência?» e «se mover o meu bake de Vellum para a farm, os substeps continuarão estáveis?». A resposta depende do que a simulação está a fazer — por isso este artigo está organizado por tipo de simulação e não por etapa de workflow.

O que se segue é um manual de otimização por tipo de simulação. Para a configuração do workflow completo — preparação de cenas, caminhos $HIP e $JOB, resolução de ativos USD, fixação de versões de plugins — consulte o nosso guia de configuração de render farm Houdini. Para uma comparação de fornecedores de render farms Houdini geridas em termos de preço, hardware e suporte de renderers, consulte a nossa comparação de render farms Houdini. Este guia aprofundado assume que a cena está pronta para upload e foca-se nos controlos específicos de cada tipo de simulação que determinam se a simulação sobrevive à viagem até uma frota de workers, e o que regressa dela.

Por que as simulações Houdini sobrecarregam uma render farm de forma diferente

A maior parte do conteúdo sobre render farms enquadra a carga de trabalho como «fotogramas por hora» — uma cena fixa renderizada N vezes em N workers. Esse modelo serve para uma passagem de lookdev estática em Karma ou Redshift. Não serve para uma simulação Houdini, porque em Houdini a «cena» não está finalizada até que o cache de simulação esteja finalizado. Um Pyro plume, um volume FLIP, um pré-roll de Vellum cloth — são estados intermédios, não estado de cena. A farm tem de receber esse estado intermédio pré-cozido, ou reconstruí-lo a partir de um ficheiro .hip que o worker acabou de receber — e esses dois caminhos têm perfis de custo muito diferentes.

O limite de uma única máquina na maioria dos solvers Houdini é a restrição operativa. A coerência de substeps do DOPnet — o requisito de que o fotograma N depende do fotograma N-1 no mesmo contexto do solver — significa que os solves de Pyro, FLIP, Vellum e RBD não são, na sua maioria, paralelizáveis entre nós de workers a meio da simulação. O PDG distribui wedges e trabalho SOP independente de fotogramas; o ciclo de solve interno geralmente não se ramifica. Implicação prática: uma simulação ou cabe num worker e na workstation, ou não corre na farm de todo. A farm ganha em paralelismo do lado da renderização, não do lado da simulação.

Na nossa render farm, o lado CPU executa nós Dual Intel Xeon E5-2699 V4 com 96–256 GB RAM (mais de 20.000 núcleos no total), que é o tier relevante para a reconstrução de cache e passagens de simulação/renderização CPU; o lado GPU executa placas RTX 5090 com 32 GB VRAM cada, que é o tier que Karma XPU e Redshift consomem na fase de renderização. A fase de simulação e a fase de renderização terminam em frotas diferentes, razão pela qual o preço em trabalho Houdini é quase sempre um elemento de duas linhas — CPU GHz-hora para a reconstrução de cache (se necessário), GPU node-horas para a renderização.

Os pontos de entrada de linha de comandos canónicos são hbatch (execução clássica de cenas Houdini) e husk (referência de linha de comandos husk — renderização de stage Solaris/USD). A maioria da automatização do lado da farm corre através de um destes, com o .hip carregado uma vez e re-executado por intervalo de fotogramas (hbatch) ou renderizado contra um stage USD pré-cozido (husk). Por tipo de simulação, a questão é: enviamos um cache cozido e executamos husk, ou enviamos o .hip e deixamos o hbatch reconstruir?

Pyro: caches de fumo, fogo e explosão à escala cloud

O Pyro é o solver de fumo, fogo e explosões de Houdini — um modelo de combustão de sparse grid construído sobre o Pyro Solver DOPnet, que escreve volumes .vdb por fotograma. A combustão produz campos de temperatura, densidade, combustível, velocidade e divergência, e a grelha de vóxeis é o principal controlo do tamanho do cache: reduzir o tamanho do vóxel para metade multiplica aproximadamente por 8 os custos de memória e disco (escala cúbica). Para contexto técnico completo, consulte a documentação SideFX Pyro.

Estratégia de cache. Cozer quase sempre em .vdb (OpenVDB sparse) em vez de .bgeo.sc, porque os campos Pyro são sparse por natureza — a maioria dos vóxeis é ar vazio. O armazenamento narrow-band do OpenVDB elimina vóxeis mortos do disco. A contagem de substeps importa aqui: Pyro solve bem com 1–2 substeps para plumes de movimento lento, 4–8 substeps para combustão rápida ou ondas de choque. Substep mais alto na farm significa que o worker gasta mais CPU por fotograma. Fixar a contagem de substeps no DOPnet, não depender do comportamento predefinido da farm.

O tamanho do vóxel, o esquema de advecção (Semi-Lagrangian vs. Trilinear vs. MacCormack) e os parâmetros do modelo de combustão estabelecem juntos o tamanho .vdb por fotograma. Um Pyro plume de complexidade média a 0,05 de tamanho de vóxel, 240 fotogramas, fica tipicamente no intervalo de 20–60 GB no total. Verificar o tamanho do cache por fotograma antes de carregar — a largura de banda no upload é frequentemente o obstáculo, não a renderização.

Considerações da cloud render farm. O Pyro renderiza em GPU através de Karma XPU ou renderização de volumes Redshift, ambos consomem .vdb de forma nativa. A simulação em si é limitada pela CPU e acelerada por OpenCL, mas a aceleração OpenCL ajuda principalmente a velocidade de bake na workstation, não a simulação paralela de fotogramas do lado da farm. Padrão prático: cozer localmente, carregar a sequência .vdb, renderizar na frota GPU.

# Renderizar um Pyro plume em cache através de husk num stage USD,
# com Karma XPU no nó GPU e volume samples aumentados.
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"

A invocação do husk contra um stage USD que referencia a sequência .vdb em cache permite ao worker GPU desenhar o volume sem resolver novamente. Aumentar volumesamples do valor predefinido de Karma 4 para 8 reduz o ruído em plumes densos ao custo de aproximadamente 1,5–2x o tempo de renderização. Usar 16 para shots hero, deixar em 4 para pré-vis.

FLIP: líquidos, reconstrução de superfície, narrow-band

O FLIP — Fluid Implicit Particle solver — combina representações de partículas e grelhas para simular água, líquidos viscosos e escoamento de superfície livre. A saída são duas coisas: um cache de partículas (sequência packed .bgeo.sc) e, opcionalmente, uma malha de superfície reconstruída (também .bgeo.sc). Ambas vão para a farm, o que significa que uma render farm FLIP quase sempre duplica a sua pegada em disco em comparação com Pyro em complexidade equivalente.

Estratégia de cache. Separar o cache de partículas e a malha de superfície em dois diretórios de cache distintos — as partículas cozem primeiro, a malha reconstrói-se a partir das partículas numa rede SOP a jusante. Esta divisão permite re-fazer a malha sem re-simular, o que importa quando a tensão superficial ou a separação de partículas precisa de uma segunda passagem. Uma simulação FLIP de complexidade média a 200 fotogramas com separação de partículas de 0,02 fica frequentemente entre 80–200 GB do lado das partículas e 20–40 GB do lado da malha. FLIP narrow-band — onde apenas as partículas próximas da superfície são armazenadas com densidade total — reduz o cache de partículas em 60–80 % em shots onde o volume profundo não é visível. Ativar quando a câmara não olha através da água.

A rigidez de viscosidade e as restrições CFL estabelecem a contagem de substeps. As simulações de água com viscosidade 0 correm tipicamente com 1–2 substeps; mel ou metal fundido com alta viscosidade frequentemente precisam de 5–10 substeps para permanecer estáveis. A violação CFL produz explosões de partículas, que numa farm são muito mais dispendiosas do que numa workstation porque não são visíveis até o render terminar.

Considerações da cloud render farm. O tempo de upload do cache é o custo dominante para uma render farm FLIP na cloud. Um cache de partículas de 100 GB num uplink de cliente de 100 Mbps demora aproximadamente 2,5 horas antes de o primeiro fotograma de render poder começar. Num uplink de 1 Gbps, o mesmo cache carrega em ~15 minutos — a diferença é frequentemente o que decide se o FLIP na cloud é operacional para um shot. Auditar o tamanho do cache antes de carregar.

# Sonda Hython — executar a partir de uma workstation ou worker para calcular
# o tamanho do cache por fotograma antes de pagar largura de banda de upload
# numa simulação FLIP de múltiplos TB. Usar como verificação prévia.
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} fotogramas, {total/1e9:.2f} GB total, "
      f"{(total/frames)/1e6:.1f} MB/fotograma méd.")

Se a média por fotograma exceder 500 MB e o total exceder 100 GB, aceitar a janela de upload ou rever a separação de partículas, narrow-band e o limiar da malha de superfície antes de transferir.

Vellum: cloth, soft body, serialização de restrições

O Vellum é o framework de dinâmica baseada em posição do Houdini — cloth, soft body, cabelo, grãos, fluidos numa formulação de posição restringida. A saída é um cache .bgeo.sc por fotograma, mas ao contrário do Pyro ou do FLIP, os caches Vellum transportam estado de restrição para além das posições dos pontos. O grafo de restrições (pin, stretch, bend, attach-to-static) tem de serializar corretamente ou o worker da farm resolve novamente com restrições quebradas. Consulte a documentação do solver Vellum para a matriz de tipos de restrição.

Estratégia de cache. Armazenar em cache após o Vellum Solver DOPnet, antes de qualquer limpeza SOP a jusante. Usar o Vellum I/O SOP em vez de um File Cache genérico, porque o Vellum I/O preserva atributos de restrição (__constraintnetwork, restlength, stiffness) que um cache genérico vai remover. O pré-roll importa: o cloth precisa de 20–40 fotogramas de assentamento antes de o intervalo de fotogramas da câmara começar, e o pré-roll tem de estar no cache ou o worker renderizará o fotograma 1 com cloth não assentado. A maioria dos rigs de produção Vellum cozem o pré-roll nos fotogramas -20 a 0 do cache.

A contagem de substeps é a causa mais comum de falhas Vellum do lado da farm. Os substeps predefinidos do Vellum Solver (5) funcionam para drapeados lentos e cloth básico de personagens, mas movimento rápido, rácios de extensão elevados e redes de pin apertadas frequentemente precisam de 10–20 substeps para permanecer estáveis. Fixar a contagem de substeps explicitamente no DOPnet — deixar o worker da farm usar o seu predefinido é onde a estabilidade entre fotogramas tende a quebrar, porque os caches cozidos na workstation com substep 10 não correspondem aos caches reconstruídos pelo worker com substep 5.

Considerações da cloud render farm. O Vellum é limitado pela CPU, single-threaded por solver (com multi-thread limitado na resolução de restrições), e o tamanho do cache é modesto — normalmente 5–20 GB por shot — por isso o obstáculo de upload é menos agudo do que o FLIP. O custo dominante numa farm é o tempo de reconstrução se o .hip for enviado em vez de um cache cozido. Um cache Vellum de 4 GB (fato de complexidade média) demora tipicamente 30–90 minutos a cozer num único worker E5-2699. Se cozer localmente primeiro e carregar o cache, a farm vê apenas o custo de renderização.

# Cozer em lote um solve de Vellum cloth para .bgeo.sc com uma
# substituição explícita de substeps. As contagens de substeps predefinidas
# são onde a estabilidade do lado da farm tende a quebrar em cloth de qualidade de produção.
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"

A substituição -v vellum_substeps=10 fixa a contagem de substeps independentemente do que o parâmetro DOPnet guardado do .hip diz. Esta é a cobertura mais segura contra a deriva de estabilidade Vellum do lado da farm.

Destruição: RBD, Bullet, redes de restrição

A destruição em Houdini significa dinâmica de corpos rígidos — RBD Solver, Bullet e as redes de restrição que colam, fixam ou quebram geometria fraturada. O formato de cache é primitivas packed .bgeo.sc, onde cada prim packed representa um fragmento fraturado e a rede de restrição é armazenada como um .bgeo.sc separado por fotograma. Fraturar antes da simulação — feito em SOPs, não em DOPs — e apenas a geometria pós-fratura mais a rede de restrição vai para o solver.

Estratégia de cache. Dois caches são importantes: a geometria fraturada (estática, um fotograma) e o estado dinâmico de transformação por fotograma. Armazenar em cache apenas as transformações durante a simulação, depois aplicá-las no momento da renderização através do workflow de Packed Disk Primitive. Isto separa a geometria pesada (frequentemente 5–50 GB de peças fraturadas) do estado dinâmico barato (tipicamente 10–50 MB por fotograma). A geometria carrega uma vez; o cache dinâmico carrega por shot.

A serialização da rede de restrição é a armadilha. As restrições RBD (glue, hard, soft, cone-twist) transportam um atributo __constraintnetwork que o equivalente Vellum I/O — o RBD I/O SOP — trata corretamente, mas um File Cache genérico não o fará. Usar RBD I/O para o lado das restrições; usar o cache padrão de prim packed para as transformações.

Considerações da cloud render farm. As simulações RBD são deterministas se as sementes aleatórias estiverem fixadas. O comportamento predefinido — sementes controladas por $F, sementes de hora do dia, ou sementes não definidas — produz padrões de fratura diferentes em workers diferentes. Numa farm onde um worker reconstrói o cache e outro renderiza contra um padrão esperado (por exemplo, uma configuração de composição pré-construída num cache de workstation), a deriva de sementes produz discrepâncias visíveis que só aparecem depois de o render terminar. Fixar todas as sementes aleatórias antes do bake.

# Bake determinista de RBD — fixar RBD_SEED para que dois workers
# a renderizar o mesmo intervalo de fotogramas produzam caches de fratura idênticos.
# Sem isto, os solves de fratura podem dessincronizar entre workstation
# e farm, aparecendo como discrepâncias na composição.
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: o Bullet é mais rápido para grandes contagens de peças (1.000+ fragmentos) e aceitável para destruição de qualidade média; o RBD Solver é mais preciso para dinâmicas de shot hero, colapso de pilhas e configurações controladas por restrições, com um custo de solve por fotograma aproximadamente 3–5x maior. Numa farm, o Bullet é o predefinido prático a não ser que o shot seja hero.

Crowds: agentes, LOD, handoff de ragdoll

O Houdini Crowds é o framework de simulação de agentes — populações de agentes com bibliotecas de clips de movimento, estados de comportamento e variantes LOD. O cache é mais complexo do que outros tipos de simulação: caches de agentes (clips de movimento .bclip.sc), caches de transformação de crowd (.bgeo.sc por fotograma) e referências packed prim de agentes que se resolvem no momento da renderização. Cada agente tem a sua própria hierarquia LOD, trocada no momento da renderização através de conjuntos de variantes de Solaris.

Estratégia de cache. Cozer a simulação de crowd num cache de transformação .bgeo.sc (um ficheiro por fotograma com a transformação por agente mais o índice de clip de movimento). A geometria do agente — os dados de malha reais — vive numa biblioteca .bclip.sc separada que é referenciada, não cozida por fotograma. Esta divisão é a razão pela qual os renders de crowd são tratáveis: um shot com mil agentes pode ter um cache de transformação de 200 MB por fotograma mas apenas 2 GB de geometria de agente no total, referenciada a partir do disco.

O cache de clips de movimento é importante porque os crowds animam por mistura de clips, não por keyframes por fotograma. A biblioteca de clips tem de estar no worker antes de a renderização começar. Cozer a biblioteca de clips uma vez, carregar para o armazenamento persistente do worker, depois os uploads por shot são apenas o cache de transformação.

O handoff de ragdoll — onde um agente passa de animação controlada por clips para física controlada por RBD — precisa de tratamento especial na farm. O cache de estado de ragdoll é separado do cache de transformação de crowd, e o fotograma de handoff tem de ser determinista, o que significa fixar sementes e fotogramas de início de ragdoll explicitamente. Caso contrário, workers diferentes produzem trajetórias de ragdoll diferentes.

Considerações da cloud render farm. Os crowds renderizam em Karma (CPU e XPU) através de stages de Solaris, com variantes LOD de agentes resolvidas no momento da renderização. A troca de LOD no momento da renderização significa que é possível alterar o LOD por shot sem re-simular — os agentes de alto-LOD renderizam para shots hero, os de baixo-LOD para shots amplos, sem tocar no cache.

# Renderizar um stage de crowd Solaris com LOD de agente selecionado
# na invocação do husk. O Karma respeita variantes prim de agentes
# para troca de LOD sem reconstruir a simulação de crowd.
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"

A substituição lodVariant:value=mid seleciona o conjunto de variantes de agente mid-LOD no momento da renderização. Trocar para low para passagens de fundo distantes e high para primeiro plano hero sem re-executar a simulação de crowd. Esta é a maior poupança de custo por shot em renderização de crowd na cloud — o LOD no momento da renderização permite que um cache sirva todos os shots de uma sequência.

Limites honestos: quando a farm não é a ferramenta certa

Uma cloud render farm não é a resposta para todos os problemas de simulação Houdini, e ser explícito sobre isso evita que shots acabem na farm porque ninguém fez a pergunta a montante.

A simulação distribuída é largamente inviável. Os solvers Pyro, FLIP, Vellum e RBD são na sua maioria limitados a uma única máquina pela coerência de substeps do DOPnet. O PDG pode distribuir wedges e trabalho SOP independente de fotogramas, mas o ciclo de solve interno geralmente não pode ramificar-se entre nós de workers a meio da simulação. Se a simulação não cabe numa máquina — e o worker da farm é tipicamente um Dual Xeon E5-2699 V4 com 96–256 GB RAM, não radicalmente diferente de uma workstation de gama alta — mover para a farm não resolve o problema.

Cálculo da largura de banda de upload do cache. Um cache FLIP de 100 GB num uplink de cliente de 100 Mbps demora aproximadamente 2,5 horas antes de o primeiro fotograma de render começar. Os uploads de cache são tempo de relógio de parede que se paga antes de qualquer renderização acontecer. O uplink Gigabit ajuda; a largura de banda da workstation do cliente frequentemente não.

O trade-off GPU vs. CPU na simulação está resolvido, mas não da forma que os utilizadores esperam. O Pyro e o FLIP têm caminhos OpenCL que aceleram os solves de substeps na workstation. A vantagem do lado da farm é a renderização paralela de fotogramas da simulação em cache, não a simulação paralela de fotogramas. Enquadrar de forma diferente: GPU na farm significa aceleração de renderização através de Karma XPU ou Redshift; CPU na farm significa reconstrução de cache se for enviado um .hip em vez de um cache.

Latência de iteração no ajuste de simulação do lado cloud. Se se ajustar um parâmetro de densidade de Pyro e for necessário re-simular, carrega-se novamente o .hip modificado, re-cozinha-se no worker e depois renderiza-se. O ciclo na farm é frequentemente 4–8x o ciclo local para trabalho intensivo em simulação. Armazenar em cache na workstation se esta conseguir manter a resolução; a farm ganha no lado da renderização, não no lado da iteração.

Disponibilidade de tokens de licença para o Houdini Engine. A utilização de render-only numa farm gerida cobre os workers de renderização Houdini, mas as licenças do Houdini Engine (para pipelines procedurais com HDA intensivos, workflows de ativos de jogo) são um tipo de seat separado. Confirmar com a farm se os tokens Engine estão agrupados e como a concorrência é tratada antes de submeter cenas dependentes de Engine. Quando a farm é a ferramenta certa mas a questão se torna qual farm, a nossa comparação de render farms Houdini cobre cinco fornecedores geridos com base em critérios específicos de Houdini.

Resumo das recomendações de workflow

Por tipo de simulação, a decisão de armazenar em cache localmente vs. cozer na farm cai geralmente assim. Pyro: cozer localmente, carregar .vdb, renderizar GPU. FLIP: cozer localmente se o uplink suportar o tamanho do cache, caso contrário considerar a reconstrução hbatch no worker. Vellum: quase sempre cozer localmente — os caches são pequenos, os tempos de reconstrução não são triviais. Destruição: cozer localmente com sementes fixadas, carregar o cache de transformação (não a geometria completa por fotograma). Crowds: cozer o cache de transformação localmente, carregar uma vez com a biblioteca de agentes, renderizar com variantes LOD por shot.

A árvore de decisão pela qual guiamos os novos clientes Houdini na nossa página de Houdini cloud render farm cobre a matriz de renderers ao nível do comprador; este artigo cobriu os controlos de otimização ao nível FX-TD por baixo. O preço CPU na nossa tarifa publicada é $0,004/GHz-hora — relevante ao dimensionar uma reconstrução de cache de vários dias contra uma alternativa de workstation. A matriz de renderers na nossa render farm suporta Karma XPU e Karma CPU, Mantra, Redshift, Arnold, V-Ray para Houdini e Octane.

FAQ

Q: Qual é a melhor definição de compressão .bgeo.sc para a largura de banda de upload na cloud? A: Para caches de partículas FLIP, o .bgeo.sc padrão (compressão packed sparse) já é quase ótimo para upload — o formato foi concebido para isso. O maior ganho individual de largura de banda está a montante: ativar narrow-band FLIP quando a câmara não olha através do volume profundo, o que pode reduzir o tamanho do cache de partículas em 60–80 % antes de a compressão sequer correr. Para caches Vellum e RBD, o .bgeo.sc é igualmente já ótimo; os ganhos vêm de armazenar em cache apenas o que muda (transformações, não geometria completa por fotograma), não de alterar o formato.

Q: Posso executar simulações Pyro ou FLIP distribuídas em múltiplos workers cloud? A: Não, não para o ciclo de solve interno. Pyro, FLIP, Vellum e RBD dependem todos da coerência de substeps do DOPnet — o fotograma N depende do fotograma N-1 no mesmo contexto do solver — por isso o solve não se pode ramificar entre nós de workers a meio da simulação. O PDG pode distribuir wedges (varrimentos de parâmetros) e trabalho SOP independente de fotogramas, mas o solver real corre numa máquina. A vantagem da farm no trabalho de simulação é a renderização paralela de fotogramas do cache cozido, não a simulação paralela de fotogramas.

Q: Devo armazenar o Vellum em cache na workstation ou na farm? A: Quase sempre na workstation. Os caches Vellum são modestos (tipicamente 5–20 GB por shot), os tempos de bake na workstation são geríveis (30–90 minutos para um fato de complexidade média numa única CPU), e o cache carrega barato. Deixar o worker da farm reconstruir um cache Vellum a partir do .hip significa pagar GHz-hora de CPU do lado do worker que teria gasto localmente gratuitamente. A exceção: cenários de revisão de shot onde se ajusta o .hip e a mudança de substep invalida o cache; nesses casos, a reconstrução na farm é razoável.

Q: O Karma XPU suporta renderização de volumes de ficheiros Pyro .vdb em cache num worker cloud? A: Sim. O Karma XPU consome volumes OpenVDB de forma nativa através de stages de Solaris, e uma invocação husk contra um stage USD que referencia a sequência .vdb em cache renderiza o volume sem resolver novamente. O worker GPU desenha o volume diretamente; a simulação não tem de estar presente no worker. Aumentar karma:volumesamples do valor predefinido 4 para 8 para volumes de qualidade de produção, 16 para shots hero — o custo é aproximadamente 1,5–2x o tempo de renderização por duplicação.

Q: Como mantenho as simulações de destruição RBD deterministas em workers cloud? A: Fixar todas as sementes aleatórias no DOPnet antes do bake — RBD_SEED, sementes de fratura e quaisquer sementes controladas por $F ou por hora do dia. Sem fixação de sementes, a mesma cena RBD cozida em dois workers diferentes produz padrões de fratura diferentes, o que aparece como discrepâncias de composição quando uma referência renderizada na workstation e um final renderizado na farm não correspondem. Definir a semente como variável global na invocação hbatch (set -g $RBD_SEED 42) e verificar que o DOPnet a lê.

Q: Preciso de licenças do Houdini Engine para renderizar simulações de crowd numa cloud render farm? A: Depende de como a pipeline de crowd está construída. Uma simulação de crowd que cozinha num cache de transformação .bgeo.sc e renderiza através de Karma contra o cache não precisa de Engine — o tier de licença de render-only trata disso. Uma simulação de crowd que executa HDAs no momento da renderização (geração procedural de agentes, ativos procedurais instanciados) pode precisar de seats de Engine. Confirmar com a farm se os tokens Engine estão agrupados e como a concorrência é tratada. Na nossa render farm, o modelo de licença de render-only permite renderizar Karma XPU na frota GPU e renderers CPU na frota CPU sem restrições de seat de Engine; pipelines de crowd com HDA intensivos devem ser discutidas durante a configuração do shot.

Leitura relacionada

• Houdini Cloud Render Farm
• Guia de configuração de Houdini Cloud Render Farm para 2026
• Comparação de render farms Houdini 2026
• Guia de custo de render farm por fotograma

Recursos externos

• Documentação SideFX Houdini
• Documentação SideFX Pyro
• Documentação SideFX Vellum
• Referência de linha de comandos Husk