Configurar o Houdini para cloud rendering

O Houdini na nossa render farm é um ambiente multi-motor construído em torno do pipeline moderno USD-first. O Karma XPU é o caminho recomendado pela SideFX para novos projetos no Houdini 20.5 e é o motor principal na nossa página de destino . O Karma CPU e o Mantra continuam disponíveis para trabalho legado; os motores de terceiros — Redshift, Arnold, V-Ray para Houdini, Octane — são suportados para estúdios com pipelines estabelecidos nesses motores. Esta página abrange o empacotamento de projetos (que no Houdini significa HDAs e caches de simulação, não apenas texturas), o fluxo de trabalho de ativos Solaris/USD, notas por motor, o fluxo de envio e a resolução de problemas específicos do Houdini que vemos com mais frequência nos tickets de suporte.

Uma nota sobre licenciamento antes de começar: operamos instalações Houdini na render farm sob utilização render-only, que permite executar o Houdini em nós de trabalho de renderização para renderização offline de projetos de clientes. A Super Renders Farm não é parceira SideFX — a utilização render-only é o enquadramento legal que permite a renderização na render farm de cenas Houdini sem ocupar uma licença SideFX do conjunto de licenças do estúdio. Não é necessário transferir a licença Houdini, e os metadados de nível de projeto do lado do artista (Indie, Core, FX) não determinam o arranjo de licença do nó de trabalho. O nó de trabalho utiliza o licenciamento da render farm.

Para posicionamento de alto nível — versões Houdini suportadas, adequação de hardware, exemplos de preços — a página de destino dedicada em é a referência canónica. A página que está a ler é o documento de fluxo de trabalho: o que fazer no Houdini antes de clicar em Enviar.

Versões suportadas

O Houdini 19.5, 20.0 e 20.5 estão pré-instalados em todos os nós de trabalho da render farm. Seguimos o calendário de lançamentos da SideFX e disponibilizamos novas compilações principais no prazo de quatro semanas após a disponibilidade pública. As atualizações de ponto (por exemplo, Houdini 20.5.410 vs. 20.5.487) são rastreadas continuamente; se o projeto estiver bloqueado a um número de compilação específico por um problema de compatibilidade de nós, mencione a compilação nas notas do trabalho no envio e correspondemos o nó de trabalho.

Tanto os ficheiros de cena Houdini FX (.hip) como Houdini Indie (.hipnc) carregam no nó de trabalho e renderizam sob o arranjo de utilização render-only da render farm. O nível do lado do artista (Indie vs. Core/FX) não se propaga para a licença do nó de trabalho — o nó de trabalho usa qualquer nível que a render farm disponibilize para renderização. Os ficheiros Houdini Apprentice renderizam mas produzem saída com marca de água por acordo com os termos de licença não comercial da SideFX; para trabalho de produção pago, guarde a cena a partir de uma licença não-Apprentice antes do envio. As licenças de educação seguem a mesma regra.

Uma nota sobre o ritmo de lançamentos do Houdini: a SideFX lança versões principais a cada 12–18 meses e atualizações de ponto com maior frequência. O Karma XPU em particular melhorou substancialmente entre o 19.5, 20.0 e 20.5 — as funcionalidades que eram fallback de CPU no 19.5 (volumes pesados, certas redes de shaders) são nativas no XPU em 20.5. Se o projeto depende de uma funcionalidade do Karma XPU que foi lançada numa compilação específica, bloqueie a compilação nas notas do trabalho em vez de deixar o nó de trabalho escolher a mais recente disponível.

Empacotar o projeto Houdini

Um projeto Houdini é mais do que o ficheiro de cena .hip (ou .hipnc). Tipicamente também inclui: HDAs (Houdini Digital Assets — formato .hda ou o mais antigo .otl), ficheiros de cache de simulação (.bgeo, .bgeo.sc, .vdb, .abc), camadas e referências de ativos USD (.usd, .usda, .usdc), mapas de textura e qualquer geometria externa importada de File ou Alembic SOPs. A renderização cloud tem êxito quando cada dependência que a cena referencia está presente no nó de trabalho; falha quando algo resolve localmente através de um caminho exclusivo da estação de trabalho mas não tem onde resolver na render farm.

As convenções de caminho do Houdini são construídas sobre variáveis de ambiente — mais comummente $HIP (resolve para o diretório que contém o ficheiro .hip), $HIPNAME (o nome base do ficheiro de cena), e $JOB (a raiz do projeto, definida via variável de ambiente). Para cloud rendering, a convenção fiável é caminhos relativos a $HIP em todo o lado. Os passos de empacotamento abaixo aplicam essa convenção do início ao fim:

Defina a pasta do projeto. Quando guardar um novo projeto, o Houdini define $HIP para o diretório que contém o ficheiro .hip. Verifique na shell Python com hou.text.expandString('$HIP') — o caminho deve corresponder ao local onde reside o ficheiro de cena.
Use a estrutura de subpastas padrão. $HIP/cache/ para simulações, $HIP/geo/ para geometria Alembic e externa, $HIP/tex/ para texturas, $HIP/hda/ para ativos digitais, $HIP/usd/ para camadas e referências USD, $HIP/render/ para saída. Todos os caminhos nos File SOPs, File COPs, saídas ROP e referências de textura da cena devem usar $HIP/... em vez de caminhos absolutos com letra de unidade.
Verifique que os caminhos resolvem. Ficheiro → Atualizar Tudo. O Houdini reporta quaisquer referências de ficheiros não resolvidas na Consola. Da shell Python, hou.fileReferences() devolve a lista completa de referências externas — analise qualquer uma que comece com D:\, Y:\, uma partilha UNC como \\servidor\, ou qualquer caminho que o nó de trabalho não possa alcançar.
Cozinhe as simulações em disco. A render farm não executa simulações como parte do trabalho de renderização — as simulações são trabalho da estação de trabalho, e a render farm renderiza contra ficheiros de cache pré-cozidos. Cozinhe todas as redes DOP (fluidos FLIP, Pyro, tecido Vellum, Bullet RBD, grãos), solvers de partículas e quaisquer outras saídas de simulação para ficheiros .bgeo.sc ou .vdb em $HIP/cache/ antes do envio. O File Cache SOP com "Guardar em Disco" é o fluxo de trabalho padrão.
Incorpore ou inclua HDAs. Se a cena usar HDAs personalizados de uma biblioteca de estúdio, incorpore-os no .hip (menu Ativo → Guardar Tipo de Operador → "Incorporado") ou inclua os ficheiros .hda/.otl em $HIP/hda/ para que o nó de trabalho os possa carregar a partir da pasta do projeto. As bibliotecas HDA partilhadas pelo estúdio em unidades de rede não são acessíveis a partir do nó de trabalho.
Aplainar ou agrupar camadas USD. Se a cena usar Solaris/LOPs, ou cozinhe o estágio USD num único ficheiro USD composto via o USD ROP antes de enviar, ou inclua toda a árvore de diretórios $HIP/usd/ para que cada camada resolva no nó de trabalho. As regras de resolução de ativos USD estão documentadas em detalhe na secção seguinte.
Archive toda a pasta $HIP. Use .tar, .tar.gz ou .7z. Não aceitamos uploads .zip para projetos Houdini (as convenções de nomes de ficheiros do Houdini por vezes contêm caracteres que se partem dentro de arquivos .zip Windows nos nós de trabalho Linux).

Um ponto problemático específico do Houdini: os campos "Pre-Render Script" e "Post-Render Script" nos nós ROP por vezes referenciam scripts Python específicos da estação de trabalho — as ferramentas de pipeline do estúdio, um caminho local de configuração Houdini, uma chamada hou.ui.displayMessage que abre um diálogo para o qual o nó de trabalho não tem ecrã. A renderização cloud falha silenciosamente ou fica à espera de input que nunca chegará. Audite quaisquer callbacks Python ou HScript pré-renderização antes do envio; desative ou torne portáteis por caminho quaisquer códigos que toquem em caminhos locais, chamadas de interface, ou hou.system() shells para binários da estação de trabalho. Prefira logging print() a callbacks interativos.

Solaris, camadas USD e resolução de ativos

Se a cena estiver criada no Solaris (a rede LOPs /stage), a camada de resolução de ativos USD adiciona uma dimensão extra ao envio cloud que não está presente em cenas OBJ/SOP. O resolver USD do Houdini segue as regras padrão de resolução de ativos USD: as referências numa camada são resolvidas contra o caminho identificador da camada, caminhos de pesquisa configurados via houdini.env ou o plugin de resolver de ativos, e quaisquer arcos de composição que o estágio usa (referências, sublayers, payloads).

Para envio cloud, dois padrões funcionam de forma fiável:

Aplainar o estágio. Use o nó USD ROP com "Guardar em Disco" e a opção "Aplainar Estágio" ativa. O resultado é um único ficheiro .usd composto (ou .usdc para binário) que contém todo o estágio com todas as referências resolvidas. Este é o padrão mais simples — o nó de trabalho lê um ficheiro, sem indireção de resolver — mas perde-se a estrutura em camadas que torna o USD valioso para colaboração.
Agrupar a árvore completa de ativos. Coloque todas as camadas USD em $HIP/usd/ e use referências relativas a $HIP nas sublayers, referências e payloads. O nó de trabalho resolve $HIP para a raiz do upload, pelo que os ficheiros de camada na mesma posição relativa carregam corretamente.

Uma subtileza: o LOP "Asset Reference" do Solaris e o Reference SOP em contextos /obj serializam o caminho de referência tal como escrito. Se escreveu D:\ativos_estudio\robot_personagem.usd num Reference LOP, o nó de trabalho não tem D:\ e a referência falha. Reescreva a referência como $HIP/usd/robot_personagem.usd (ou ${SRF_ASSETS}/robot_personagem.usd com um mapeamento de variável de ambiente documentado que a render farm respeite). Quanto mais simples for o caminho, mais fiavelmente viaja.

Uma segunda subtileza: as bibliotecas de ativos USD podem ter a sua própria indireção de versioning. Um estágio Solaris que referencia ativos USD compilados contra USD 23.x pode não carregar de forma limpa num nó de trabalho com USD 22.x incluído numa compilação Houdini mais antiga. A matriz de versões Houdini-e-USD importa — se a biblioteca de ativos foi criada para a versão USD do Houdini 20.5, renderize em nós de trabalho Houdini 20.5.

Gestão de HDA

Os Houdini Digital Assets (HDAs, por vezes ainda vistos com a extensão mais antiga .otl) são redes de nós reutilizáveis empacotadas como ficheiros de ativo autónomos. São comuns em pipelines de produção, particularmente para ativos procedurais — edifícios, vegetação, sistemas de multidão, solvers personalizados — que são criados separadamente dos planos individuais e partilhados entre cenas.

Três padrões para tratamento de HDA na render farm:

Incorporar o HDA no ficheiro .hip. Menu Ativo → Gestor de Tipos de Operador → clique com o botão direito no HDA → "Guardar como Incorporado." O HDA está agora armazenado dentro do .hip e viaja com a cena. Este é o padrão mais seguro para trabalhos pontuais ou para HDAs que cria especificamente para um único plano.
Agrupar HDAs em $HIP/hda/. Coloque todos os ficheiros .hda/.otl numa subpasta do projeto e, em Houdini → Editar → Preferências → Localizações de Ficheiros, certifique-se que $HIP/hda/ faz parte do caminho de pesquisa OTL (alternativamente, defina HOUDINI_OTLSCAN_PATH para incluir $HIP/hda/ no houdini.env). O nó de trabalho lê HDAs desta localização ao carregar a cena.
Referenciar HDAs a partir de uma biblioteca partilhada do estúdio. Se o estúdio usa uma biblioteca HDA partilhada numa unidade de rede (por exemplo, \\estudio-fs\houdini\hda\), essa biblioteca não é acessível a partir do nó de trabalho. Copie os HDAs relevantes para $HIP/hda/ antes do envio, ou incorpore-os no .hip.

Antes do envio, liste os HDAs carregados na cena a partir da shell Python:

text

for hda in hou.hda.loadedFiles():
    print(hda)

Cada caminho na saída tem de resolver em $HIP ou ser um HDA padrão SideFX fornecido com o Houdini (esses estão pré-instalados em todos os nós de trabalho). Qualquer HDA de terceiros que resida fora de $HIP não será encontrado.

Gestão de ficheiros de cache

Os ficheiros de cache são tipicamente a maior categoria individual num upload de projeto Houdini — simulações FLIP, caches Pyro, cozimentos de tecido Vellum, exportações Alembic e volumes VDB podem cada um chegar a dezenas ou centenas de gigabytes. Dois padrões reduzem o tempo de upload sem comprometer a renderização:

Comprima os caches no momento do cozimento. .bgeo.sc (bgeo comprimido, comprimido com blosc) é significativamente menor do que .bgeo para a mesma geometria e é o padrão moderno para File Cache SOPs. Para ficheiros VDB, o volume já está comprimido dentro do contentor OpenVDB, mas os arquivos .tar.gz comprimem bem os metadados de diretório envolventes.
Use $HIP/cache/ de forma consistente. O File Cache SOP do Houdini tem como padrão $HIP/cache/{nome_do_nó}/$F4.bgeo.sc, que é o padrão correto para cenas portáteis para a render farm. Evite caminhos de cache absolutos como D:\sim_cache\ — o nó de trabalho não tem D:\ e a renderização começará, registará avisos "não é possível encontrar o ficheiro de cache" e produzirá geometria vazia onde a simulação deveria estar.

Para simulações muito grandes — caches FLIP ou Pyro de múltiplos terabytes que excedem um upload pelo browser — use SFTP em vez do formulário de upload web. O documento abrange o fluxo de trabalho SFTP, a retomabilidade de arquivo e os limiares práticos para mudar do upload web para SFTP.

Uma nota de fluxo de trabalho para estúdios que fazem cache na estação de trabalho mas renderizam na render farm: se o diretório de cache estiver num SSD local rápido e o ficheiro de projeto usar $HIP/cache/, o cache move-se com o projeto no upload — não é necessário remapeamento manual. Se o padrão da estação de trabalho for fazer cache numa unidade de rede partilhada e o .hip referenciar essa unidade diretamente, será necessário copiar os caches para $HIP/cache/ e atualizar os caminhos do File Cache SOP, ou definir uma variável de ambiente $JOB no nó de trabalho que espelhe a partilha de rede da estação de trabalho (menos fiável; a abordagem de caminho relativo é preferida).

O que verificar antes do envio

Uma breve lista de verificação pré-envio para qualquer envio Houdini:

O nó ROP ativo está corretamente definido. Contexto de saída → Renderizar. O ROP selecionado no momento do envio determina qual o motor que o nó de trabalho invoca. ROPs incompatíveis (por exemplo, selecionar um Karma ROP para uma cena cuja iluminação foi criada para Mantra) são a causa mais comum de tickets "a renderização parece completamente diferente".
O intervalo de fotogramas corresponde às definições do ROP. O intervalo de fotogramas armazenado no ROP (parâmetros f1, f2, f3) é o que o nó de trabalho usa, não o intervalo de reprodução da linha de tempo ou o fotograma atual do viewport. Confirme que o intervalo de fotogramas do ROP é o que pretende renderizar.
O caminho de saída usa tokens relativos a $HIP. $HIP/render/$F4.exr é a predefinição segura para EXR multicamada com quatro dígitos de preenchimento. Evite caminhos absolutos com letra de unidade na expressão de saída do ROP.
Todos os File SOPs e referências de textura resolvem. Ficheiro → Atualizar Tudo. Corrija quaisquer erros "Impossível ler" na Consola antes do envio — o nó de trabalho também os reportará, mas ao custo de um fotograma de renderização desperdiçado.
Os HDAs estão incorporados ou em $HIP/hda/. Verifique fechando completamente a cena e reabrindo-a a partir de uma sessão Houdini diferente; se os HDAs falharem ao carregar localmente, o nó de trabalho também falhará ao carregá-los.
Os caches estão cozidos. Execute um cozimento manual de cache em cada File Cache SOP via Renderizar → Guardar em Disco antes do envio. Não confie no "Auto-Cozimento na Mudança de Fotograma" — cozinhe explicitamente e confirme que os ficheiros de cache existem nos caminhos $HIP/cache/... esperados.
As camadas USD (se Solaris) estão agrupadas ou aplainadas. Inclua a árvore $HIP/usd/ completa ou escreva um USD composto aplainado via o USD ROP.
Não há scripts pré-renderização ou pós-renderização interativos. Audite os callbacks Python do ROP e os Pre-Frame Scripts para quaisquer chamadas de interface, shells ou caminhos específicos da estação de trabalho.

Notas específicas por motor

Karma XPU (recomendado)

O Karma XPU é o motor híbrido CPU+GPU da SideFX, promovido a status pronto para produção no Houdini 20.5 e o caminho padrão para novos projetos Houdini. É o motor principal na nossa página de destino Houdini e o caminho que a maioria dos novos clientes na render farm adota.

Notas de configuração:

Camada de nós de trabalho: Corre na nossa camada de nós GPU RTX 5090 (32 GB de VRAM por cartão) para a parte GPU da renderização, com fallback para CPU para qualquer funcionalidade que o caminho de código XPU ainda não suporte.
Limitações de VRAM: 32 GB de VRAM por nó de trabalho. O Karma XPU é mais eficiente em VRAM do que os motores GPU puros porque pode descarregar partes da renderização (volumes em particular) para memória CPU quando a VRAM é limitada — mas cenas USD muito densas com volumes de alta resolução ainda beneficiam de manter-se dentro do envelope de 32 GB.
Integração do pipeline USD. O Karma é o motor concebido para o pipeline USD baseado em Solaris. Se o projeto usar /stage (contexto Solaris LOPs), o Karma é a escolha natural de motor e o nó de trabalho resolve as referências de ativos USD da mesma forma que resolve as referências File SOP — os caminhos relativos a $HIP ganham.
AOVs. Configurados por produto de renderização no prim Render Settings no estágio USD. O EXR multicanal é o formato de saída predefinido e o que recomendamos para pipelines VFX (preserva todos os AOVs num único ficheiro por fotograma).
Amostragem. As amostras de path-tracing do Karma são configuradas por prim Render Settings. Calibre localmente num único fotograma antes de enviar uma sequência — a convergência de amostras XPU é diferente da CPU, e a calibração traduz-se diretamente para o nó de trabalho.
Motion blur. O Karma XPU suporta motion blur de geometria e motion blur de janela de obturador. Confirme que a definição de obturador de motion-blur no prim de câmara USD corresponde ao que o prim Render Settings espera — o tratamento de obturador Solaris e a amostragem de motion-blur Karma nem sempre concordam por princípio, e o sintoma é "a renderização parece bem mas o motion blur está ausente ou duplicado."

Karma CPU

O Karma CPU é a variante puramente CPU do Karma. Com todas as funcionalidades e estável desde o Houdini 19; o fallback natural para cenas que excedem a VRAM GPU ou dependem de funcionalidades ainda não implementadas no caminho de código XPU.

Notas de configuração:

Camada de nós de trabalho: Camada de nós CPU (nós Dual Intel Xeon E5-2699 V4, 96–256 GB de RAM por nó, mais de 20.000 cores CPU agregados em toda a frota).
Quando usar em vez do Karma XPU: geometria muito pesada (>50M polígonos), renderização volumétrica densa que ultrapassa os 32 GB de VRAM, shaders OSL personalizados que ainda não têm equivalente XPU, ou projetos que misturam passes de simulação intensivos em CPU no mesmo envio.
Mesma integração Solaris/USD que o Karma XPU. A configuração de produto de renderização e AOV é idêntica; apenas o backend de processamento difere.

Mantra (legado)

O Mantra é o motor pré-Karma do Houdini — o motor de micropolígonos da SideFX que antecede o pipeline USD-first. A SideFX sinalizou que o Mantra não é o caminho futuro; o Karma é. O Mantra permanece na compilação Houdini para compatibilidade retroativa com projetos criados antes de o Karma ser viável.

Notas de configuração:

Camada de nós de trabalho: Camada de nós CPU.
Desempenho. O Mantra é geralmente mais lento por fotograma do que o Karma CPU para cenas equivalentes e não tem o caminho de aceleração GPU que o Karma XPU oferece. Os novos projetos devem usar o Karma.
Quando usar. Quando o ficheiro de projeto está bloqueado ao Mantra (uma produção de longa duração que começou antes de o Karma ser viável, ou uma funcionalidade de shader específica do Mantra sem equivalente Karma). Para novo trabalho em 2026, use o Karma por predefinição.

Redshift para Houdini

O Redshift para Houdini corre na nossa camada de nós GPU RTX 5090. O Redshift é a escolha para estúdios com pipelines Redshift estabelecidos — frequentemente estúdios Maya ou Cinema 4D a expandir para o Houdini para FX que pretendem partilhar bibliotecas de shaders entre DCCs.

Notas de configuração:

Enquadramento de licença. O Redshift na nossa render farm funciona sob a nossa licença de . O Redshift é agora um produto Maxon, e a nossa parceria Maxon cobre o Redshift em todos os DCCs que suportamos (C4D, Houdini, Maya).
Memória out-of-core. Ativa por predefinição. Alarga a memória efetiva de cena para além do limite de 32 GB de VRAM por nó de trabalho, importante para cenas densas que de outra forma teriam OOM na GPU.
Funcionalidades específicas do Houdini. O Redshift integra-se diretamente com os tipos de primitivos de volume do Houdini (VDB, caches Pyro) — não é necessário passo de exportação especial para renderização de volumes. O ROP do Redshift expõe parâmetros nativos do Houdini para ray bias, amostragem e configuração AOV.
Fixação de versão. O Redshift lança no seu próprio ciclo 3.x, independente do ritmo de lançamentos do Houdini. As versões principais do Redshift (3.0 → 3.5 → 4.0 quando for lançado) não são garantidamente compatíveis retroativamente — uma cena guardada com Redshift 3.5.18 pode não carregar de forma limpa num nó de trabalho a executar Redshift 3.0.x. Note a compilação Redshift no momento do registo da cena e confirme a compatibilidade do nó de trabalho antes de enviar uma sequência completa.

Arnold para Houdini

O Arnold para Houdini (por vezes chamado HtoA, atualmente no ciclo de lançamento Arnold 7.x) corre na nossa camada de nós CPU. É a escolha para estúdios com pipelines Arnold partilhados Maya/Houdini, onde o lookdev é criado num DCC e os FX no outro, mas a camada de shader e renderização é unificada.

Notas de configuração:

Enquadramento de licença. O Arnold na nossa render farm funciona sob licenciamento de nó de renderização Autodesk.
AOVs. O sistema AOV do Arnold no Houdini funciona da mesma forma que no Maya. Configure por ROP e escreva para EXR multicanal ou ficheiros por AOV; o padrão transversal a DCCs é consistente.
Fixação de versão. As versões HtoA seguem o ritmo de lançamentos do Arnold (HtoA 6.x para Houdini 19.5/20.0; HtoA 7.x para Houdini 20.5/21.0 quando for lançado). Os saltos HtoA principais (6 → 7) nunca devem ser assumidos compatíveis — confirme que o nó de trabalho tem pelo menos a versão menor com que a cena foi guardada.

V-Ray para Houdini

O V-Ray para Houdini corre na nossa camada de nós CPU. A adoção no Houdini é marcadamente inferior à do 3ds Max ou Maya, mas a integração é suportada para estúdios com pipelines centrados no V-Ray.

Notas de configuração:

Enquadramento de licença. O V-Ray na nossa render farm funciona sob a nossa licença de .
Ativos VRayProxy. Suportados. Inclua os ficheiros .vrmesh em $HIP/geo/ para que o nó de trabalho possa resolvê-los.
Especificidades do Houdini. O ROP do V-Ray para Houdini expõe as mesmas definições de renderização que o V-Ray no 3ds Max — tipo de amostrador, elementos de renderização (AOVs), formato de saída. O mapeamento de parâmetros transversal a DCCs está documentado na referência V-Ray para Houdini da Chaos.

Octane para Houdini

O Octane para Houdini corre na nossa camada de nós GPU RTX 5090. Usado principalmente por estúdios de motion design que ligam Houdini e Cinema 4D para saída estilizada.

Notas de configuração:

Enquadramento de licença. Licenciamento de nó de renderização Otoy.
Limitações de VRAM. As mesmas do Octane para C4D — 32 GB de VRAM por nó de trabalho, com um perfil de memória mais agressivo do que o Redshift (sem caminho out-of-core). As cenas que cabem em 24 GB no Redshift podem precisar de redução de textura ou decimação de geometria para caber em 32 GB no Octane.

Fluxo de envio

Três canais de envio funcionam para projetos Houdini na render farm:

Upload web + envio pelo painel. Archive a pasta $HIP como .tar.gz ou .7z, faça upload pelo website e depois configure o trabalho (motor, nó ROP, intervalo de fotogramas, formato de saída) e envie. Este é o caminho mais comum para trabalhos Houdini pontuais e projetos abaixo de ~50 GB de tamanho total de upload.
SFTP para projetos grandes. Os projetos Houdini com caches de simulação de múltiplos terabytes devem ir via SFTP para transferências retomáveis. Consulte para o fluxo de trabalho SFTP, credenciais e o limiar para mudar do upload web para SFTP.
Client App. A Client App da Super Renders Farm envolve upload, envio e auto-download numa aplicação de secretária. Útil para estúdios com envios recorrentes onde a mesma estrutura de projeto é rerenderizada com alterações de parâmetros. Consulte .

Um plugin de envio para Houdini que se integra diretamente com a interface do Houdini está em desenvolvimento mas ainda não está pré-instalado em todos os nós. Por agora, o fluxo de envio pelo painel web é o caminho recomendado. O percurso de envio transversal a DCCs — o que preencher, como definir o intervalo de fotogramas, onde encontrar os ficheiros de saída — está no .

Por baixo, o nó de trabalho invoca os pontos de entrada de renderização em lote do Houdini: hbatch para envios de ficheiros HIP a ROPs de contexto OBJ/SOP (Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane), e husk para envios de estágio USD ao Karma (CPU ou XPU). Geralmente não é necessário conhecer a invocação subjacente, mas se estiver a depurar nomenclatura de saída inesperada ou comportamento de intervalo de fotogramas, as definições ao nível do ROP são o que o nó de trabalho passa ao hbatch/husk via flags de linha de comando.

Resolução de falhas específicas do Houdini

Para resolução de problemas gerais transversal a DCCs (ativo em falta, renderização falhou no fotograma N, problemas comuns de formato de saída), consulte . Padrões de falha específicos do Houdini que vemos com mais frequência nos tickets de suporte:

"Unable to find HDA" ou HDA falha ao carregar com um marcador de nó desatualizado. O nó de trabalho não consegue localizar o ficheiro HDA que a cena referencia. Verifique que os HDAs estão incorporados no .hip (menu Ativo → Gestor de Tipos de Operador → "Guardar como Incorporado") ou presentes em $HIP/hda/ com o caminho de pesquisa configurado. Se referenciar HDAs de uma biblioteca partilhada do estúdio, copie-os para a pasta do projeto antes de enviar.
Ficheiro de cache não encontrado na renderização / geometria de simulação vazia. Verifique que os ficheiros de cache foram realmente cozidos em disco antes do envio — abra cada File Cache SOP e confirme que o separador "Saída" mostra ficheiros no caminho apresentado. Se o caminho usar uma letra de unidade absoluta (D:\sim_cache\flip.0001.bgeo.sc), mude para $HIP/cache/{nome_do_nó}/$F4.bgeo.sc e recozinhe. A verificação de 60 segundos antes do upload — Ficheiro → Atualizar Tudo, mais uma análise manual dos File Cache SOPs — previne a maior categoria individual de falhas de renderização Houdini que vemos.
As saídas de renderização estão completamente vazias / fotogramas a preto. Verifique o prim "Render Settings" do ROP (para Karma num estágio Solaris) ou a referência de câmara (para Mantra, Redshift, Arnold, V-Ray, Octane em ROPs de contexto /obj). A causa mais comum é uma câmara que está definida no viewport mas não referenciada no ROP — o nó de trabalho não tem viewport, pelo que a referência de câmara ao nível do ROP é autoritativa.
O Karma XPU falha imediatamente com "OptiX not available" ou "GPU not detected". Raro na nossa render farm porque a frota de nós GPU tem cobertura CUDA + driver OptiX confirmada. Se ocorrer, a causa mais comum é um nó de trabalho a meio de atualização ou um rollback de driver em curso; reenvie 5–10 minutos depois ou contacte o suporte se o problema persistir em múltiplos envios.
O script Python pré-renderização falha no nó de trabalho. Desative o script ou torne-o portátil por caminho. O Python personalizado que referencia caminhos de módulos específicos da estação de trabalho (as ferramentas de pipeline do estúdio), abre diálogos de interface, ou faz shell-out para binários locais via hou.system() não correrá num nó Linux sem cabeça.
As referências de ativos Solaris / USD partem-se. Os caminhos de resolver de ativos USD têm de ser relativos a $HIP, usar um contexto de resolver USD que o nó de trabalho possa carregar, ou ser aplainados num único USD composto via o USD ROP antes do envio. Os caminhos absolutos em camadas de referência USD são o modo de falha mais comum aqui.
Incompatibilidade de versão de plugin / cena falha ao carregar. A versão do plugin local difere da do nó de trabalho — mais frequentemente saltos HtoA 6 → 7 ou Redshift 3.0 → 3.5. Verifique a versão do plugin no momento do registo da cena (visível via o texto do cabeçalho do ficheiro HIP ou o carimbo de versão do menu ROP do plugin) e confirme que o nó de trabalho tem pelo menos essa versão menor. Os saltos de versão principal nunca devem ser assumidos compatíveis.
Incompatibilidade de versão Houdini (cena 20.5 num nó de trabalho 20.0). O formato de ficheiro HIP inclui metadados de versão; o Houdini mais antigo não consegue abrir cenas guardadas em versões mais novas. Confirme que o nó de trabalho tem Houdini ≥ a versão de registo da cena, ou guarde novamente a cena na versão alvo se absolutamente necessário.
A simulação OpenCL falha ao executar na renderização. As simulações OpenCL são trabalho de cozimento, não de renderização. Cozinhe em cache antes do envio. A render farm não executa simulações OpenCL em direto durante a renderização — isto é por design e aplica-se a FLIP, Pyro, Vellum e qualquer outro solver acelerado por OpenCL.
Desvio de configuração OCIO entre envio e nó de trabalho. Se a variável de ambiente OCIO local aponta para uma configuração específica do estúdio não presente no nó de trabalho, as cores renderizam sob a configuração predefinida do nó de trabalho e parecem diferentes. Inclua o ficheiro de configuração OCIO com o projeto, defina OCIO via a substituição de ambiente de envio, ou use a configuração ACES integrada do Houdini que o nó de trabalho também inclui.
Aviso "campo em falta" de cache Pyro/FLIP entre versões Houdini. O formato de ficheiro de cache muda ocasionalmente entre versões principais do Houdini; um cache mais antigo carregado num Houdini mais novo por vezes perde campos. Recache a simulação na versão Houdini alvo, ou confirme que o nó de trabalho usa a mesma compilação Houdini que escreveu o cache.

Referências cruzadas

— fluxo upload, envio, download (transversal a DCCs)
— como são calculados os custos de trabalhos Houdini (camadas GPU vs CPU)
— guia SFTP, formatos de arquivo, transferências de projetos grandes
— resolução de problemas transversal a DCCs
— wrapper de envio de secretária
— página de destino (matriz de motores, hardware, exemplos de preços)

FAQ

Q: Quais as versões do Houdini que a render farm suporta? A: O Houdini 19.5, 20.0 e 20.5 estão pré-instalados em todos os nós de trabalho. Seguimos o calendário de lançamentos da SideFX e disponibilizamos novas compilações principais no prazo de quatro semanas após a disponibilidade pública. Tanto os ficheiros de cena Houdini FX (.hip) como Houdini Indie (.hipnc) são suportados. Os ficheiros Houdini Apprentice renderizam mas produzem saída com marca de água por acordo com os termos de licença não comercial da SideFX — para trabalho de produção pago, guarde a partir de uma licença não-Apprentice antes do envio.

Q: É necessário transferir a licença Houdini para renderizar na render farm? A: Não. Operamos o Houdini sob utilização render-only, que permite executar o Houdini em nós de trabalho de renderização para renderização offline sem ocupar uma licença SideFX do conjunto de licenças do estúdio. A licença Houdini local permanece consigo. A Super Renders Farm não é parceira SideFX — a utilização render-only é o enquadramento legal que permite a renderização na render farm de cenas Houdini.

Q: Devo usar Karma XPU, Karma CPU ou Mantra para um novo projeto? A: Karma XPU para novos projetos em 2026 — é o caminho recomendado pela SideFX, corre na nossa camada GPU RTX 5090 e é significativamente mais rápido do que Karma CPU ou Mantra para a maioria das cenas. Use Karma CPU para cenas que excedem 32 GB de VRAM, dependem de volumes pesados que transbordam a GPU, ou usam shaders OSL personalizados ainda não suportados no XPU. Use Mantra apenas quando o ficheiro de projeto está bloqueado ao Mantra (uma produção de longa duração iniciada antes de o Karma ser viável, ou uma funcionalidade de shader específica do Mantra sem equivalente Karma). Para novo trabalho, use Karma por predefinição.

Q: A render farm consegue executar simulações Houdini (Pyro, FLIP, Vellum, RBD)? A: Não — as simulações são trabalho da estação de trabalho. Cozinhe todos os caches de simulação para ficheiros .bgeo.sc ou .vdb localmente antes do envio. A render farm renderiza contra caches pré-cozidos; não executa simulação em direto como parte do trabalho de renderização. Este é o mesmo padrão que os fluxos de trabalho de simulação Blender ou Maya na maioria das render farms cloud geridas.

Q: O projeto usa o pipeline Solaris/USD do Houdini. Vai renderizar corretamente? A: Sim, com Karma (CPU ou XPU) como motor. O caminho concebido para Solaris é o Karma — ambos os motores consomem o estágio USD nativamente e a integração Solaris/Karma é o pipeline futuro recomendado pela SideFX. Para envio cloud, ou aplane o estágio USD num único ficheiro .usd composto via o USD ROP, ou inclua a árvore de diretórios $HIP/usd/ completa para que cada camada resolva no nó de trabalho. Os motores de terceiros (Redshift, Arnold) também podem renderizar cenas baseadas em USD se a integração Houdini o suportar — verifique localmente num único fotograma antes de enviar uma sequência completa.

Q: A cena usa HDAs personalizados da biblioteca partilhada do estúdio. A render farm irá encontrá-los? A: A render farm não encontrará HDAs na unidade de rede partilhada do estúdio (\\estudio-fs\hda\... ou equivalente). Incorpore os HDAs no .hip via menu Ativo → Gestor de Tipos de Operador → "Guardar como Incorporado," ou copie os ficheiros .hda/.otl para $HIP/hda/ antes de arquivar o projeto. Verifique com hou.hda.loadedFiles() da shell Python que cada HDA carregado resolve em $HIP ou é um ativo padrão SideFX.

Q: Como empacotar um projeto Houdini que usa caches de simulação? A: Cozinhe cada simulação para $HIP/cache/{nome_do_solver}/$F4.bgeo.sc (ou .vdb para volumes) localmente antes do envio. Verifique que os ficheiros de cache existem nos caminhos esperados via Ficheiro → Atualizar Tudo. Archive toda a pasta $HIP — incluindo a subpasta cache/ — como .tar.gz ou .7z. Para caches acima de algumas centenas de gigabytes, faça upload via SFTP em vez do formulário web. A render farm renderiza contra os caches cozidos; a simulação em si corre na estação de trabalho, não num nó de trabalho.

Q: Qual o tamanho máximo de upload de um projeto Houdini? A: Não há limite rígido de tamanho de upload, mas recomendamos manter um único upload pelo browser abaixo de ~50 GB. Acima disso, mude para SFTP para transferências retomáveis — consulte . A render farm já tratou de renderizações Houdini sim de múltiplos terabytes, todas carregadas via SFTP com a estrutura de diretórios adequada preservada.

Q: A renderização Mantra é muito mais lenta na render farm do que localmente. É esperado? A: A velocidade por fotograma do Mantra na nossa camada de nós CPU (Dual Xeon E5-2699 V4) é comparável a uma estação de trabalho de alta gama. Se estiver a ver tempos por fotograma significativamente mais lentos do que localmente, as causas mais prováveis são: uma configuração de amostragem diferente no nó de trabalho (o Mantra lê amostras do ROP — confirme que as definições ao nível do ROP correspondem), ou aceleração OpenCL local que não está ativa na camada apenas CPU do nó de trabalho. A correção estrutural é a migração: o Karma XPU na nossa camada GPU é significativamente mais rápido do que o Mantra para a maioria das cenas, e o Karma é o caminho que a SideFX recomenda.

Q: A render farm suporta o PDG/TOPs do Houdini para gestão distribuída de tarefas? A: O PDG é orquestração do lado da estação de trabalho; a render farm usa o seu próprio sistema de fila e atribuição de nós. O PDG pode ser usado localmente para criar e cozinhar ativos, depois enviar os trabalhos ROP finais para a render farm via o painel web ou a Client App. O envio direto orientado por PDG para render farms externas está no nosso roteiro, mas ainda não é um fluxo de trabalho de primeira classe.

Q: Como é calculado o custo para cloud rendering Houdini? A: O custo Houdini na render farm segue a camada de nós do motor — tarifas GPU para Karma XPU, Redshift e Octane; tarifas CPU para Karma CPU, Mantra, Arnold e V-Ray para Houdini. A complexidade por fotograma (contagem de amostras, contagem de AOVs, resolução de saída) impulsiona o custo por fotograma; a escolha do motor impulsiona a taxa por hora-nó. As simulações custam extra apenas se as executar na render farm (recomendamos o caching local e upload do cache). Para detalhes de preços, consulte ou estime na .

---

Configurar o Houdini para cloud rendering