Utilitários avançados: Render Node Template, Troubleshoot Machine, Simular Caminho Local, acesso API

A Super Renders Farm disponibiliza quatro utilitários avançados para estúdios que necessitam de mais do que o fluxo padrão de upload-submissão-download pela web: Render Node Template (definir uma pilha de software reproduzível para os workers que renderizam o trabalho), Troubleshoot Machine (iniciar uma VM de depuração acessível por RDP que corresponde ao ambiente do nó de renderização), Simular Caminho Local (preservar caminhos absolutos para projetos que resolvem recursos por caminho codificado) e a superfície de acesso API (atualmente limitada — consulte §Acesso API para a situação atual). Esta página é o manual de referência para os quatro — quando usar cada um, como o mecanismo subjacente funciona na nossa render farm, os passos exatos para configurar ou invocar cada um, e os modos de falha mais frequentes no suporte.

Se é a primeira vez que se utiliza a render farm e se pretende o fluxo de upload padrão, o é o ponto de partida certo. Se se está a depurar um trabalho falhado, a página cobre os padrões de erro mais frequentes. Os utilitários aqui documentados destinam-se a casos em que o fluxo padrão não se adapta — tipicamente estúdios de grande dimensão com pipelines estabelecidas, projetos com requisitos incomuns de caminho de recursos, ou sessões de depuração pontuais em que se precisa de ver exatamente o que o worker de renderização vê.

Qual utilitário usar — tabela de orientação

Uma breve orientação antes das secções por utilitário:

| Se necessitar de… | Usar | |---|---| | Fixar qual versão de DCC, versões de plugin e licenças de plugin são executadas nos workers atribuídos ao trabalho | Render Node Template | | Ligar a um worker de renderização real via Microsoft Remote Desktop, corrigir uma cena no local e depois submetê-la como trabalho real | Troubleshoot Machine | | Renderizar um projeto que usa caminhos absolutos (C:\projetos\… ou D:\texturas\…) e não pode ser re-endereçado para caminhos relativos | Simular Caminho Local | | Submeter trabalhos programaticamente a partir de um script ou ferramenta de pipeline | Acesso API (consulte o marcador de posição — o caminho atual é o Client App ou o plugin DCC) |

É possível combinar estes utilitários. Um Render Node Template pode ser combinado com Simular Caminho Local no mesmo trabalho. A Troubleshoot Machine respeita tanto o Render Node Template ativo como qualquer configuração de Simular Caminho Local, pelo que o ambiente de depuração corresponde ao ambiente de renderização de produção. Os quatro utilitários foram concebidos para funcionar em conjunto.

Render Node Template

O Render Node Template é o mais poderoso dos quatro utilitários e o mais antigo. Permite especificar o ambiente de software exato que os workers de renderização devem ter antes de processar o trabalho: qual versão do 3ds Max, qual build do V-Ray, quais plugins estão instalados e licenciados, e quaisquer ficheiros de configuração personalizados que precisem de estar no worker antes do início da renderização. Uma vez definido, o template é reutilizável em vários trabalhos — cada submissão marcada com esse template é executada numa pilha de worker idêntica.

Que problema resolve

Por defeito, a Super Renders Farm pré-instala uma pilha de software cuidadosamente selecionada em cada worker de renderização — versões recentes de DCC e os motores de renderização e plugins mais comuns, calibrados para as cargas de trabalho mais frequentes. Para 80% dos trabalhos, este é o padrão correto; o worker já tem o software que a cena necessita. Mas há duas situações em que o padrão fica aquém:

• Fixação de versão. O estúdio padronizou no 3ds Max 2024 + V-Ray 6.10.05 + uma build específica do Forest Pack, e não pode arriscar que um worker use uma versão pontual mais recente que introduza diferenças de amostragem ou ruído entre fotogramas da mesma animação.
• Plugins de nicho. Usa-se um plugin (ou uma versão de plugin) que não está na pilha padrão da render farm — por exemplo, uma versão menos comum do Phoenix FD, uma ponte ZBrush da Pulze, ou uma build especial de funcionalidades Corona.

O Render Node Template permite declarar a pilha de forma explícita. A render farm encaminha então o trabalho para workers que já correspondem ao template declarado, ou provisiona novos workers para corresponder antes de atribuir o trabalho. De qualquer forma, a garantia de fixação de versão é de ponta a ponta.

Como funciona na nossa render farm

Um Render Node Template é um registo de configuração com nome associado à conta. Contém:

• O DCC e a versão — por exemplo 3ds Max 2024.2.2.
• O motor de renderização e a versão — por exemplo V-Ray 6.10.05.
• Uma lista de plugins com versões — por exemplo Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• Um canal de licença — quais as licenças (Chaos, Maxon, Otoy, AXYZ Design) que devem estar disponíveis para o worker através da nossa infraestrutura de licenciamento centralizado. A maioria dos plugins está coberta de raiz; se o template referenciar um plugin que ainda não alojamos, o suporte sinaliza-o e disponibiliza-se o próprio ficheiro de licença.
• Payloads de ficheiros opcionais — ficheiros de configuração, predefinições ou bibliotecas de shaders que devem ser colocados numa localização conhecida no worker antes do início da renderização.

Quando se submete um trabalho e se marca com um template, o scheduler da render farm compara o template com o conjunto atual de workers. Se houver workers correspondentes disponíveis, o trabalho é despachado imediatamente. Se não houver workers correspondentes disponíveis, o scheduler provisiona um worker novo de acordo com o template — o que normalmente demora alguns minutos a mais do que um trabalho com a pilha padrão, que é a principal compensação.

Criar um Render Node Template

O editor de templates está acessível a partir do painel de conta em "Render Node Templates" (ou semelhante — o rótulo exato da interface pode variar entre versões do painel; se a entrada não for visível, contactar o suporte para que seja disponibilizada na conta).

Passos:

1. Iniciar sessão em superrendersfarm.com e abrir a secção Render Node Templates do painel.
2. Criar um novo template e dar-lhe um nome descritivo — tipicamente um código de projeto ou um rótulo padrão de estúdio como studio-archviz-2024-vray6. O nome é livre; a render farm usa-o apenas para correspondência.
3. Escolher o DCC e a versão. O menu pendente lista todas as versões de DCC atualmente alojadas. Se a versão necessária não estiver listada, o template não pode ser criado sem uma conversa com o suporte — algumas versões antigas foram descontinuadas.
4. Escolher o motor de renderização e a versão. A mesma restrição aplica-se — o menu pendente reflete a pilha atual da render farm.
5. Adicionar plugins um de cada vez. Para cada plugin: selecionar o nome do plugin do catálogo, escolher a versão e confirmar o canal de licença. Os plugins fora do catálogo requerem uma conversa com o suporte para adicionar — normalmente um esforço único se o plugin for suficientemente comum para alojar a licença.
6. Anexar quaisquer payloads de ficheiros. Carregar os ficheiros de configuração ou predefinições necessários no worker. A render farm armazena-os juntamente com o template e copia-os para o diretório de trabalho do worker antes do início da renderização.
7. Guardar e validar. O painel executa uma passagem de validação face ao conjunto atual de workers e reporta "workers correspondentes disponíveis" (despacho imediato no primeiro trabalho) ou "sem correspondências atuais — workers serão provisionados no primeiro uso" (ligeiro atraso no arranque no primeiro trabalho).

O template está agora disponível para seleção em qualquer submissão de trabalho posterior.

Usar um template na submissão

Ao submeter um trabalho de renderização — via upload web, Client App ou plugin de submissão DCC — o formulário de submissão inclui um menu pendente "Render Node Template". Deve selecionar-se o template criado. O trabalho herda toda a declaração de pilha; não é necessário especificar novamente o DCC, o motor de renderização ou as versões de plugin no formulário de submissão.

Duas notas operacionais:

• Template + prioridade Express combinam-se. É possível submeter um trabalho com template com prioridade Express. O scheduler tenta encontrar um worker disponível que corresponda a ambas as restrições; se não estiver disponível, provisiona um. Os trabalhos com template Express normalmente têm uma janela de despacho ligeiramente mais longa do que os trabalhos com pilha padrão Express, mas a diferença de preço é a mesma.
• Template + Simular Caminho Local combinam-se. Se o projeto também requer caminhos absolutos, configurar Simular Caminho Local na submissão normalmente (consulte §Simular Caminho Local). O template controla o ambiente de software; Simular Caminho Local controla a disposição do sistema de ficheiros. São preocupações ortogonais.

Editar e versionar templates

Um template é mutável — é possível editar a fixação de versão, adicionar ou remover plugins, ou substituir payloads de ficheiros. Mas editar um template afeta todos os trabalhos futuros que o utilizam; os trabalhos já em curso despachados continuam com a versão do template que capturaram na submissão.

Para estúdios que precisam de controlo de versão estrito entre revisões de template, um padrão comum é clonar e depois editar: ao precisar de atualizar versões de plugin, clonar o template existente para studio-archviz-2024-vray6-r2, fazer as alterações aí, e atualizar os scripts de submissão do projeto para apontar para o novo template. O template antigo fica intacto para quaisquer projetos em curso que dependam da sua pilha exata.

Modos de falha comuns

• "Sem workers correspondentes — o provisionamento demora 5-10 minutos." Isto não é um erro, apenas um aviso. O primeiro trabalho com template após uma alteração de pilha provisiona novos workers. Os trabalhos subsequentes com o mesmo template são despachados imediatamente porque os workers já estão prontos.
• "Licença de plugin indisponível para o template." O plugin especificado não está no catálogo de licenças alojadas. Contactar o suporte — para plugins comuns normalmente adicionamos o licenciamento alojado em poucos dias úteis; para plugins de nicho, pode ser necessário fornecer um ficheiro de licença com a submissão.
• "Versão do motor de renderização já não suportada." As versões mais antigas de DCC ou motor de renderização são periodicamente retiradas da pilha ativa. O editor de templates indica isso ao guardar; a correção é atualizar o template para uma versão suportada ou clonar e editar para uma build atual.
• "Trabalho despachado mas a pilha do worker não corresponde ao template." Raro, mas vale a pena conhecer. Se isso acontecer, o trabalho falha a verificação de sanidade pré-renderização e a render farm recoloca-o automaticamente num worker com correspondência confirmada. Não se paga pela tentativa de despacho falhada.

Troubleshoot Machine

A Troubleshoot Machine é a contrapartida de diagnóstico do caminho de renderização de produção. Em vez de submeter um trabalho real e aguardar que falhe com uma mensagem de erro, inicia-se uma Troubleshoot Machine — uma VM Windows que corresponde à pilha de software do nó de renderização — e liga-se a ela via Microsoft Remote Desktop Connection. Vê-se exatamente o que o worker de renderização veria, pode abrir-se o ficheiro de cena, identificar o que está a falhar, corrigi-lo no local, guardar a cena corrigida de volta ao armazenamento e depois submeter um trabalho de produção real com confiança.

Que problema resolve

A maioria das falhas de renderização enquadra-se em dois tipos: problemas a nível de cena (um plugin em falta, uma referência de recurso corrompida, uma configuração do motor de renderização incompatível com a versão no worker) e problemas a nível de ambiente (uma licença não disponível, um plugin que não carrega, uma incompatibilidade de caminho). Ambos são difíceis de diagnosticar remotamente — o único sinal que se obtém de um trabalho de produção falhado é o registo de renderização, que é frequentemente pouco informativo.

A Troubleshoot Machine elimina o ciclo de diagnóstico. Em vez de submeter → falhar → ler registo → adivinhar → resubmeter → falhar → adivinhar → resubmeter, inicia-se uma Troubleshoot Machine, vê-se o erro real na interface gráfica do DCC, corrige-se uma vez, e submete-se um trabalho real que funciona.

Como funciona na nossa render farm

Ao pedir uma Troubleshoot Machine, a render farm provisiona uma VM Windows nova que corresponde à pilha atual do nó de renderização para o DCC especificado (e qualquer Render Node Template ativo, se existir). A VM monta o armazenamento SRF Spaces como a unidade S: — pelo que os ficheiros de projeto já carregados aparecem exatamente como apareceriam num worker de renderização de produção. A ligação é feita via RDP a partir da estação de trabalho local.

A VM tem um orçamento de tempo — tipicamente medido em minutos, debitado dos créditos de renderização a uma taxa documentada (verificar no painel a taxa atual; esta muda ocasionalmente). Quando a sessão termina, desliga-se e submete-se um trabalho de produção do mesmo projeto ou liberta-se a VM.

Iniciar uma sessão Troubleshoot Machine

Passos:

1. No painel, navegar para "Troubleshoot Machine" (ou a entrada equivalente do painel — o nome pode variar entre versões).
2. Selecionar o DCC que corresponde ao projeto. A VM será provisionada com esse DCC pré-instalado e a corresponder ao Render Node Template declarado, se existir.
3. Confirmar o orçamento de tempo. O painel mostra o custo em créditos por minuto; compromete-se com uma duração máxima de sessão e pode ser prolongada durante a sessão se necessário.
4. Aguardar o provisionamento. Normalmente demora alguns minutos — está a ser preparada uma VM nova com a pilha de software.
5. Receber os detalhes de ligação RDP. O painel fornece um nome de anfitrião, nome de utilizador e palavra-passe (ou um ficheiro RDP para descarregar). No Windows, fazer duplo clique no ficheiro RDP para ligar; no macOS, usar o Microsoft Remote Desktop da App Store.
6. Ligar. A sessão está agora no worker. A unidade S: contém os ficheiros de projeto do SRF Spaces.

Usar a sessão

Uma vez ligado, o fluxo de trabalho é o mesmo que se estivesse na estação de trabalho do worker de renderização:

• Abrir o ficheiro de cena a partir de S:. O DCC arranca na versão especificada pelo template ou no padrão da render farm para esse DCC.
• Reproduzir a falha. O que quer que estivesse a falhar em produção — uma pré-visualização de renderização, um erro de script, uma referência de recurso — deve reproduzir-se aqui. Investigar usando as próprias ferramentas de diagnóstico do DCC.
• Corrigir a cena. Revincular recursos em falta, alterar definições de renderização, reparar referências de plugin, ou o que o diagnóstico exigir.
• Guardar de volta em S:. Guardar a cena corrigida em S:\SuperRendersOutput\ ou noutra pasta no SRF Spaces. O guardado é persistente — quando a sessão Troubleshoot Machine termina, a cena corrigida permanece no armazenamento.
• (Opcional) Submeter um trabalho real a partir do interior da VM. O plugin de submissão SuperRenders do DCC está instalado dentro da Troubleshoot Machine; é possível submeter um trabalho de renderização de produção a partir do interior da VM, depois desligar e deixar a render farm renderizar normalmente.

Quando terminar, desligar do RDP e terminar a sessão a partir do painel. A VM é destruída; quaisquer ficheiros guardados em S: permanecem no SRF Spaces.

Modos de falha comuns

• "Não é possível ligar ao RDP — ligação expirou." Verificar se a rede local ou VPN permite RDP de saída (porta 3389). Algumas redes empresariais bloqueiam o tráfego RDP de saída. Nesse caso, pedir à equipa de TI para colocar o nome de anfitrião da Troubleshoot Machine na lista de permissões.
• "Credenciais RDP rejeitadas." Descarregar novamente o ficheiro RDP a partir do painel — as credenciais são específicas da sessão e podem expirar se a sessão for pausada por demasiado tempo.
• "A unidade S: está vazia ou os ficheiros não aparecem." A unidade mapeia para o SRF Spaces — se os ficheiros não aparecerem, ou o upload para o SRF Spaces ainda não tinha sido concluído quando a VM foi provisionada, ou está a consultar a pasta errada. O mount padrão é tipicamente S:\<id-da-conta>\.
• "A correção funcionou na Troubleshoot Machine mas o trabalho de produção ainda falha." O mais frequente é porque o trabalho de produção foi submetido com um Render Node Template diferente (ou pilha padrão) do que o da sessão Troubleshoot Machine. Verificar se a seleção do template na submissão de produção corresponde à configuração da Troubleshoot Machine.

Simular Caminho Local

Simular Caminho Local é o menor dos quatro utilitários em âmbito, mas o que resolve a maior categoria de projetos "não renderiza na cloud". Algumas cenas DCC resolvem recursos por caminho absoluto codificado — C:\projetos\estudio\minha-cena\texturas\madeira_01.tx, por exemplo — em vez de caminho relativo. Quando essa cena é carregada para uma render farm, o motor de renderização não encontra as texturas porque o caminho absoluto não existe no worker. Simular Caminho Local faz com que o caminho absoluto exista.

Que problema resolve

A solução simples para esta categoria de problema é re-endereçar a cena antes da submissão — mudar todas as referências de recursos de absoluto para relativo — mas para alguns fluxos de trabalho isso não é prático:

• Cenas Anima (o plugin de pessoas animadas AXYZ Design) escrevem caminhos absolutos para ficheiros de cache de personagens no momento de guardar a cena; o re-endereçamento manual quebra a vinculação de cache.
• Renderização de cache 4K do Corona Image Editor escreve caminhos absolutos que o motor de renderização espera encontrar novamente no mesmo caminho em tempo de renderização.
• Fluxos de trabalho de exportação do Substance / Substance Painter podem incorporar caminhos absolutos para fontes de textura.
• Referências Alembic escrevem por vezes caminhos absolutos dependendo das definições de exportação do DCC.
• Projetos de arquivo antigos em que re-endereçar todas as referências de recursos não é prático, e o estúdio apenas pretende que o projeto seja renderizado como está.

Para estes casos, Simular Caminho Local informa a render farm: quando este trabalho for executado, recriar o caminho absoluto no worker para que o motor de renderização encontre os seus recursos onde a cena os espera.

Como funciona na nossa render farm

Ao carregar um projeto com Simular Caminho Local ativado, o SuperRenders Client App (ou o upload web, com a definição correta) preserva a estrutura de caminho absoluto original no upload. No worker de renderização, a render farm cria a árvore de diretórios correspondente no mesmo caminho absoluto antes do início da renderização — pelo que se o ficheiro de cena referenciar D:\estudio-2024\projeto-x\texturas\madeira.tx, o worker tem um D:\estudio-2024\projeto-x\texturas\madeira.tx real em tempo de renderização e a cena resolve corretamente.

O mecanismo é mais fiável quando combinado com a opção "Auto keep local path" do SuperRenders Client App, que preserva o caminho absoluto automaticamente no upload. Para o upload web, a estrutura de caminho é definida manualmente na estrutura de pastas do SRF Spaces antes de carregar os ficheiros.

Configurar Simular Caminho Local

Existem dois caminhos para esta funcionalidade:

Via SuperRenders Client App (recomendado):

1. No Client App, antes de adicionar ficheiros a um upload, abrir as definições de upload.
2. Ativar "Auto keep local path" (o rótulo exato pode variar ligeiramente entre versões do Client App — procurar a caixa de verificação de preservação de caminho).
3. Adicionar os ficheiros do projeto. O Client App lê o caminho absoluto de cada ficheiro conforme é adicionado e preserva-o na árvore de upload.
4. Confirmar a árvore de caminhos na pré-visualização do upload. Deve ser possível ver a estrutura completa de caminho absoluto espelhada no SRF Spaces.
5. Carregar normalmente. A estrutura de caminhos é transferida juntamente com os ficheiros.
6. Na submissão, ativar "Simulate Local Path" no trabalho — o painel ou o formulário de submissão do Client App tem uma caixa de verificação ou menu pendente para isso. A render farm recriará o caminho absoluto no worker.

Via upload web (manual):

1. No SRF Spaces (o browser de ficheiros web dentro do painel de conta), usar o botão "Create Folder" para recriar a estrutura de caminho absoluto manualmente. Por exemplo, se o projeto referenciar D:\estudio-2024\projeto-x\, criar uma pasta D: (literalmente, como nome de pasta), depois uma subpasta estudio-2024, depois projeto-x, e assim por diante.
2. Carregar os ficheiros para a árvore de caminhos recriada. Cada ficheiro fica no caminho absoluto correspondente dentro do SRF Spaces.
3. Na submissão, ativar "Simulate Local Path" no trabalho. A render farm lerá a estrutura de caminhos do SRF Spaces e replicará no worker.

O caminho de upload web é mais manual mas funciona corretamente quando configurado. O Client App é mais rápido e menos propenso a erros para estúdios que fazem isto regularmente.

Notas operacionais

• Letras de unidade. No worker de renderização, a unidade simulada (por exemplo D: se o projeto usar D:\…) é um ponto de montagem lógico, não uma unidade física. O ponto de montagem é criado no início do trabalho e removido no final; não é persistente.
• Limites de comprimento de caminho. O Windows tem limites históricos de comprimento de caminho (cerca de 260 caracteres para aplicações legadas). Se os caminhos absolutos forem muito longos, alguns DCCs podem falhar ao carregar ficheiros mesmo após a configuração de Simular Caminho Local. A correção é encurtar os caminhos ao nível do projeto ou ativar o suporte a caminhos longos no DCC, o que a maioria das versões atuais suporta.
• Composição com outros DCCs. Simular Caminho Local pode ser combinado com um Render Node Template e com a Troubleshoot Machine — a árvore de caminhos simulados aparece de forma idêntica nos três contextos.

Modos de falha comuns

• "Recurso ainda em falta depois de ativar Simular Caminho Local." A causa mais comum é que o upload não preservou efetivamente o caminho. Abrir o SRF Spaces no painel web e confirmar que a estrutura de caminho absoluto existe. Se não existir, fazer novamente o upload com "Auto keep local path" ativado no Client App.
• "A renderização começa mas a textura errada é carregada." Por vezes uma cena tem vários recursos com o mesmo nome de ficheiro em caminhos diferentes; se a simulação de caminho estiver incompleta, o motor de renderização pode recorrer a um ficheiro diferente com o mesmo nome. Verificar se a estrutura completa de caminhos está preservada no SRF Spaces.
• "O motor de renderização reporta acesso negado no caminho simulado." Isto significa normalmente que o caminho envolve um nome de diretório reservado do Windows (con, aux, prn, etc.) que não pode ser criado como uma pasta normal. Re-endereçar o projeto para evitar o nome reservado.

Acesso API

O acesso programático à submissão da Super Renders Farm está no roteiro. Uma API REST pública para submissão de trabalhos, sondagem de estado e recuperação de saída está a ser concebida; neste momento, não estão disponíveis endpoints de API públicos para integração direta.

Para necessidades atuais de submissão programática, os caminhos suportados são:

• O SuperRenders Client App — o Client App de ambiente de trabalho () pode ser conduzido a partir de scripts no Windows e macOS via a sua superfície de linha de comandos (onde disponível) ou por automatização de arrastar ficheiros para o diretório de upload. Para estúdios com ferramentas de automatização de pipeline estabelecidas, o Client App é o ponto de integração de melhores práticas atual.
• O plugin de submissão DCC — o plugin por DCC (3ds Max, Maya, Cinema 4D) integra-se com o próprio ambiente de scripting do DCC (MAXScript, Python, etc.) e pode ser conduzido a partir de scripts de pipeline que já são executados dentro do DCC.

Quando a API pública estiver disponível, esta secção será substituída pela referência completa da API (autenticação, endpoints, limites de taxa, exemplos de SDK). Para estúdios que estão bloqueados numa API pública para a sua integração de pipeline, contactar o suporte para partilhar o caso de uso — o roteiro é informado por requisitos reais de pipeline.

Referências cruzadas

• — fluxo padrão de upload-submissão-download sem estes utilitários
• — instalação e uso da aplicação de ambiente de trabalho
• — fluxo de submissão baseado em browser
• — padrão de transferência para projetos grandes
• — como os créditos de renderização são debitados, incluindo os preços de sessão da Troubleshoot Machine
• — referência de resolução de problemas transversal a DCCs
• — comparação de métodos de upload
• , , — configuração de submissão por DCC que complementa estes utilitários

FAQ

Q: É necessário um Render Node Template para todos os trabalhos? A: Não. A maioria dos trabalhos é executada corretamente na pilha de software padrão da render farm — as versões mais comuns de DCC e motor de renderização com os plugins mais comuns. Um Render Node Template destina-se a casos em que é necessária fixação de versão ao longo de um projeto de longa duração, ou quando se usa um plugin que não está no catálogo padrão. Em caso de dúvida, a pilha padrão é quase sempre a escolha de arranque certa.

Q: Quanto custa uma sessão Troubleshoot Machine? A: As sessões Troubleshoot Machine são debitadas dos créditos de renderização a uma taxa por minuto mostrada no painel no início da sessão. A taxa muda ocasionalmente à medida que a infraestrutura de VM subjacente é atualizada; o painel é sempre a fonte autoritativa. Para uma sessão de diagnóstico típica de 30 minutos, esperar uma fração pequena do custo de um único trabalho de renderização completo.

Q: É possível usar Simular Caminho Local se o projeto estiver no macOS ou Linux? A: O ambiente de renderização do worker é Windows, pelo que os caminhos absolutos são simulados como caminhos Windows (forma D:\…). Se o projeto foi criado no macOS ou Linux com caminhos absolutos na forma /Users/… ou /home/…, a simulação de caminho ainda pode funcionar — a render farm cria um ponto de montagem lógico Windows que corresponde à cadeia de caminho que a cena espera — mas na prática os projetos criados em Mac/Linux normalmente usam caminhos relativos e não necessitam deste utilitário.

Q: O Render Node Template aumenta o tempo de renderização? A: O primeiro trabalho submetido com um novo template pode demorar alguns minutos mais a ser despachado enquanto a render farm provisiona workers correspondentes. Os trabalhos subsequentes com o mesmo template são despachados à velocidade da pilha padrão porque os workers correspondentes já estão prontos. O tempo líquido por trabalho quando o template está ativo é o mesmo que o da pilha padrão.

Q: É possível editar um Render Node Template enquanto um trabalho está em curso? A: Sim, mas o trabalho em curso continua com a versão do template que capturou na submissão. A edição afeta apenas as submissões futuras. Para projetos que necessitam de controlo de versão mais estrito, clonar o template para um novo nome e atualizar os scripts de submissão para apontar para o novo clone em vez de editar o template existente.

Q: A versão do DCC não aparece no menu pendente do Render Node Template. O que fazer? A: Contactar o suporte e indicar a versão necessária. Para DCCs comuns, normalmente aloja-se as versões atuais mais algumas versões anteriores; versões muito antigas podem ter sido retiradas da pilha ativa. Normalmente conseguimos integrar uma versão anterior em poucos dias, ou orientar para a versão suportada mais próxima que seja compatível com a cena.

Q: Existe uma API pública para submeter trabalhos a partir de um pipeline? A: Ainda não. Uma API REST pública está no roteiro. Atualmente, o caminho recomendado de submissão programática é o SuperRenders Client App (conduzido por scripts) ou o plugin de submissão por DCC (conduzido pelo ambiente de scripting nativo do DCC). Se o caso de uso de automatização de pipeline estiver bloqueado especificamente numa API pública, contactar o suporte — o roteiro é informado por requisitos reais de pipeline, e o contributo ajuda a priorizar.

Q: É possível executar uma Troubleshoot Machine com um Render Node Template? A: Sim — e este é o padrão recomendado quando se está a depurar um trabalho com template. A sessão Troubleshoot Machine lê o Render Node Template ativo no momento do provisionamento e provisiona a VM com a pilha de software correspondente. Vê-se exatamente o que o worker de produção veria, incluindo as versões de plugin com template.