Bem-vindo à Super Renders Farm

Bem-vindo à documentação da Super Renders Farm. Aqui reunimos toda a informação prática necessária para renderizar projetos na nossa render farm — desde a preparação da cena e o envio do primeiro trabalho, passando pela resolução de problemas de qualidade de renderização, a compreensão do modelo de preços e a gestão das operações diárias de cloud rendering.

Esta página de boas-vindas é a versão resumida: o que fazemos, o que significa cloud rendering no nosso contexto, o hardware por detrás das renderizações, como a documentação está organizada, por onde começar conforme as necessidades do momento e como nos contactar quando a documentação não for suficiente. Se tiver apenas cinco minutos antes de enviar a primeira renderização, leia esta página e avance para o .

O que fazemos

A Super Renders Farm é uma render farm cloud totalmente gerida. O utilizador faz o upload da cena, nós renderizamos na nossa infraestrutura e o utilizador faz o download do resultado. Em operação desde 2010 (entidade legal desde 2017), servimos atualmente clientes em mais de 50 países — principalmente estúdios de archviz, equipas de VFX, casas de animação, freelancers de motion design e estúdios de visualização de produto.

"Totalmente gerida" é o elemento que nos distingue dos fornecedores de infraestrutura como serviço. Na nossa render farm:

• Não é necessário aceder remotamente às máquinas de renderização via desktop.
• Não é necessário instalar motores de renderização ou plugins.
• Não é necessário gerir licenças de software manualmente.
• Não é necessário configurar nós de trabalho, partilhas de ficheiros ou prioridades de fila.

Tratamos da configuração dos nós, do encaminhamento de licenças, da resolução de caminhos de ativos, do agendamento da fila e do controlo de versão dos motores. A interação com a render farm resume-se a: upload → envio → download. Para uma leitura mais aprofundada sobre o que significa ser totalmente gerida na prática — e como isso se compara ao aluguer de máquinas numa cloud pública — consulte .

Suportamos os principais DCCs utilizados em produção 3D: 3ds Max, Maya, Cinema 4D, Blender, Houdini, After Effects e NukeX. Suportamos também os motores de renderização que correm sobre eles — V-Ray, Corona, Arnold, Redshift, Octane e Cycles. Parcerias oficiais com a Maxon (Cinema 4D, Redshift, Red Giant, Universe), a Chaos (V-Ray, Corona, Vantage, Phoenix FD) e a AXYZ design (animação de multidões Anima) garantem licenciamento verificado para esses motores na nossa render farm, pelo que não é necessário trazer ou transferir licenças próprias para os títulos suportados.

Para um resumo numa única linha que pode incluir num briefing de projeto: "A Super Renders Farm executa a cena em nós CPU e GPU geridos, com os principais DCCs e motores de renderização licenciados ao nível da farm — o utilizador faz o upload, nós renderizamos, o utilizador faz o download."

O que é cloud rendering

O cloud rendering transfere o trabalho computacional de renderização de cenas 3D da estação de trabalho local para máquinas remotas que operam em paralelo. Em vez de uma estação de trabalho a processar 5.000 fotogramas ao longo de um fim de semana, dezenas de nós dividem a fila e concluem a mesma carga de trabalho em horas.

Dois modelos principais existem neste mercado:

• Render farms IaaS — o utilizador aluga a máquina base em faturação horária, instala o DCC e o motor de renderização, configura os caminhos de ativos e as licenças, e orquestra a fila de forma autónoma. Este modelo oferece acesso direto à consola e maior controlo, em troca de tempo de configuração e responsabilidade operacional (o utilizador gere as falhas, paga pelas horas inativas e fornece as licenças).
• Render farms totalmente geridas — o operador gere a pilha de software, o encaminhamento de licenças, o agendamento da fila e a resolução de problemas ao nível dos nós. O utilizador submete trabalhos e faz o download dos resultados. Este modelo é mais rápido para começar e tem menos variáveis do lado do utilizador, em troca de menor acesso direto ao ambiente de renderização e uma estrutura de custos diferente (paga-se pelo processamento consumido, não pelas horas de máquina alugadas).

A Super Renders Farm pertence à segunda categoria. As diferenças não são abstratas: se tiver um prazo apertado, um projeto que necessita de um motor de renderização e três plugins, e não tiver um pipeline TD a tempo inteiro na equipa, o modelo gerido elimina a variância de configuração que frequentemente consome as primeiras 24 horas de uma semana de entrega. Se já operar uma equipa de pipeline com controlo de versão de DCC, scripts de instalação de plugins e servidores de licenças, uma render farm IaaS pode oferecer mais controlo do que uma render farm gerida.

Para uma análise mais aprofundada sobre como funciona o cloud rendering, uma framework para avaliar qualquer render farm cloud e uma comparação dos principais fornecedores, consulte o guia dedicado: .

O nosso hardware

A composição da nossa frota importa porque determina para que tipos de trabalhos somos mais adequados. Não listamos contagens de máquinas (uma "máquina" é uma unidade de comparação deficiente — um único nó GPU com oito cartões RTX não equivale a um único nó CPU). Em vez disso, descrevemos a frota em termos que se mapeiam diretamente para o que o trabalho utilizará.

• Capacidade de renderização CPU: mais de 20.000 cores CPU em toda a nossa render farm. Os nós de trabalho executam processadores dual Intel Xeon E5-2699 V4 com 96–256 GB de RAM por nó. Esta é a espinha dorsal das nossas operações — os trabalhos CPU de V-Ray, Corona e Arnold representam cerca de 70% do nosso volume de renderização. Interiores de archviz, passes de animação de personagens e projetos de motion design de longa duração normalmente recorrem a estes nós.
• Capacidade de renderização GPU: máquinas GPU dedicadas com NVIDIA RTX 5090 e 32 GB de VRAM cada. Executamos trabalhos Redshift, Octane e V-Ray GPU nesta frota. O limite de 32 GB de VRAM é suficientemente alto para a maioria das cenas de produção (incluindo Forest Pack denso e deslocamento complexo), mas não é ilimitado — consulte o documento de para resolução de overflow de VRAM caso seja excedido.
• Rede e armazenamento partilhado: todos os nós de trabalho partilham uma camada de armazenamento de alto débito. A resolução de caminhos de ativos é efetuada no momento do envio, pelo que projetos com muitas referências ligadas (Forest Pack, RailClone, XGen, ficheiros IES, configurações OCIO, caches tx) funcionam sem necessidade de depuração de caminhos UNC da parte do utilizador. A camada de envio traduz automaticamente os caminhos locais para caminhos locais da farm — este é um dos elementos fundamentais da gestão total.
• Licenciamento de motores de renderização: as licenças V-Ray, Corona, Arnold, Redshift, Octane e Cycles estão agrupadas ao nível da render farm. O trabalho obtém uma licença disponível no momento do envio. Não é necessário transferir a própria licença, nem se pagam taxas de licença adicionais para além dos créditos de renderização (o preço por GHz cobre processamento e licenciamento do motor em conjunto).

Para uma leitura mais aprofundada sobre as diferenças de preços entre GPU e CPU, e como estimar um trabalho antes de o enviar, consulte o e os artigos sobre custos ligados a partir daí.

Como esta documentação está organizada

Estruturámos esta documentação em torno de quatro pontos de entrada práticos, mais uma referência autónoma. A navegação à esquerda reflete o mesmo agrupamento.

• Introdução — welcome (esta página), quick-start-guide e pricing-and-credits. Leia estes primeiros se for novo na nossa render farm. O guia de início rápido aborda o fluxo upload-envio-download do início ao fim; o documento de preços explica como funcionam os créditos de renderização, o GHz-Hr e a calculadora de custos.
• Pipelines DCC — um documento por DCC suportado: setting-up-3dsmax, setting-up-maya, setting-up-cinema-4d, setting-up-blender, setting-up-houdini e setting-up-after-effects. Cada um aborda os mesmos seis tópicos na mesma ordem: instalação de plugin, convenções de empacotamento de projeto, opções de envio (website, Client App ou plugin DCC), versões de motores de renderização suportadas, orientação sobre formatos de saída e notas de compatibilidade conhecidas. Se trabalhar principalmente num DCC, guarde a página correspondente nos marcadores.
• Problemas Comuns e Referência — common-errors, troubleshoot-render-quality, upload-and-download, vray-optimization-guide e faq. Use estes documentos quando algo não renderizou conforme esperado, quando um upload falhou, ou quando pretender aprofundar um tópico específico como o reaproveitamento do light cache e do irradiance map do V-Ray.
• Ferramentas — tools-client-app, tools-plugin-installation e tools-utilities. Referência para a Client App SuperRenders (incluindo o caminho de migração Spaces), instaladores de plugins DCC e utilitários de apoio (predefinições de teste de renderização, compactadores de arquivo, leitores de log).

Mais uma referência autónoma: legal-and-policies. Esta página é a fonte canónica para os Termos de Serviço, Política de Privacidade, política de reembolso e os compromissos de tratamento de dados que se aplicam quando o utilizador faz o upload de um projeto para a nossa infraestrutura.

Atualizamos esta documentação à medida que a nossa render farm muda — quando uma nova versão de DCC é lançada, quando a frota de hardware muda, quando um motor de renderização suportado recebe um lançamento importante, quando uma funcionalidade da Client App como o Spaces fica disponível para todos. Cada documento tem um carimbo de "última atualização" no topo para que o utilizador saiba o que está atual.

Por onde começar

Se não souber qual documento abrir primeiro, os dois pontos de partida mais comuns cobrem quase toda a gente.

Começar por tarefa — há um projeto para renderizar agora.

1. Leia o . Percorre a criação de conta, preparação da cena, upload, envio, monitorização da fila e download num fluxo contínuo. A demonstração demora cerca de 10 minutos de leitura e 20–40 minutos de prática, dependendo do tamanho da renderização de teste.
2. Consulte antes de enviar um trabalho real. O sistema de créditos de renderização e a unidade GHz-Hr são simples depois de vistos uma vez; a permite estimar um trabalho em 30 segundos. Recomendamos realizar primeiro uma pequena renderização de teste e usar o custo medido para extrapolar o trabalho completo.
3. Se uma renderização falhar ou devolver um resultado inesperado, consulte . Os 10–15 problemas mais frequentes estão documentados aí com as etapas exatas de resolução.

Começar por DCC — querer saber como o software específico se comporta na nossa render farm.

1. Abra o documento setting-up-* relevante para o DCC em uso (3ds Max, Maya, Cinema 4D, Blender, Houdini ou After Effects). Cada documento setting-up-* é autónomo — não será necessário seguir uma cadeia de ligações cruzadas para renderizar o primeiro trabalho.
2. Cada documento setting-up-* aborda: instalação de plugin, convenções de empacotamento de projeto (o que incluir, o que omitir), opções de envio (upload pelo website, Client App ou plugin DCC) e notas de compatibilidade conhecidas para os motores de renderização nesse DCC.
3. Regresse ao para o fluxo universal upload-envio-download depois de configurar o DCC.

Se o projeto for híbrido (por exemplo, uma simulação Houdini em cache e renderizada através do Cinema 4D + Redshift), leia a página do DCC de simulação para orientação sobre caching e a página do DCC de renderização para o envio.

O que muda entre uma renderização em desktop e uma renderização na farm

Esta é a secção que mais frequentemente surpreende os utilizadores de cloud rendering pela primeira vez, pelo que a separámos:

• Os caminhos têm de resolver na farm. Qualquer referência por caminho absoluto (C:\textures\..., /Users/you/...) não será encontrada na farm. Use caminhos relativos dentro do projeto empacotado, ou recorra à função "empacotar projeto" do DCC (arquivo 3ds Max, Ficheiro > Arquivar Cena do Maya, pack external data do Blender, guardar com ativos do Cinema 4D). Cada documento setting-up-* tem o caminho exato do menu.
• Os plugins têm de corresponder à lista suportada. Os plugins que suportamos estão pré-instalados em cada nó de trabalho. Os plugins fora da lista falharão no momento do envio com um erro claro. A lista de plugins suportados por DCC está em cada página setting-up-* e é atualizada quando adicionamos ou removemos suporte.
• Os servidores de licenças são da farm. Não é necessário configurar servidores de licenças ou contagens de licenças flutuantes. A farm agrupa as licenças V-Ray, Corona, Arnold, Redshift, Octane e Cycles em nome do utilizador. Se surgir um erro de licença, a causa é quase sempre uma incompatibilidade de versão de plugin (não falta de licenças) — o documento de tem o procedimento exato de triagem.
• A memória GPU é finita. Uma cena que renderiza no cartão local de 24 GB pode falhar num cartão de farm de 32 GB se o cartão local estiver a usar fallback para memória do sistema. Documentamos a resolução de overflow de VRAM em e nas páginas de otimização específicas para cada DCC.
• A ordem da fila é FIFO dentro do nível de prioridade. O trabalho entra na fila no momento do envio. Se for necessário que um trabalho comece mais cedo, a Client App tem uma opção de prioridade (abordada em tools-client-app); não oferecemos mudança manual de posição na fila via chat.

Quando precisa de ajuda

Três caminhos de escalada, por ordem de preferência.

• Pesquise primeiro nesta documentação. A maioria das perguntas frequentes está abrangida nas , na página setting-up-* relevante para o DCC em uso, ou na referência de . A caixa de pesquisa no topo da documentação abrange todas as páginas e idiomas.
• Chat em direto em knowledge.superrendersfarm.com. Para questões de conta, faturação, renderizações em curso ou qualquer situação em que uma conversa seja mais rápida do que o email, o chat é o canal adequado. A nossa equipa responde durante o horário de trabalho e em minutos durante os períodos de pico. O widget de chat está disponível em todas as páginas da documentação (canto inferior direito).
• Email. Para parcerias, pipelines personalizados, NDAs, questões de reembolso ou faturação, ou qualquer situação que exija registo escrito, escreva para supportcenter@superrendersfarm.com. Use as etiquetas de assunto "Privacy request", "Legal inquiry", "Refund" ou "NDA" para que a mensagem seja encaminhada para a pessoa certa. Para pedidos de NDA especificamente, a explica o que podemos assinar e como funciona o processo.

Uma nota sobre o que não fazemos via chat: revisão de qualidade de renderização fotograma a fotograma, feedback de direção artística ou consultoria de pipeline de produção. Somos operadores da infraestrutura de renderização, não a equipa de produção do projeto. Dito isto, se o resultado de uma renderização parecer errado de forma que sugira um problema do lado da farm (artefacto ao nível do driver, versão incorreta do motor, falha do servidor de licenças), contacte o chat com um fotograma e um ID de trabalho — esse é exatamente o tipo de caso para o qual a fila de chat existe.

O que esta documentação não abrange

Para definir expectativas com honestidade: esta documentação abrange como utilizar a Super Renders Farm. Não abrange:

• Como modelar, iluminar, animar ou compor uma cena. Pressupõe-se que o utilizador já opera o DCC em que está a trabalhar; abordamos as partes que mudam quando se transfere a renderização da estação de trabalho local.
• Teoria de otimização por motor além das correções práticas que surgem na nossa render farm. O vray-optimization-guide abrange as definições específicas do V-Ray que alteram materialmente o tempo de renderização na nossa frota; a teoria de renderização mais profunda pertence à documentação do fornecedor do motor.
• Preços para compromissos personalizados (contratos anuais para grandes estúdios, pedidos de instalação de plugins personalizados, implantações espelhadas no local). Essas conversas acontecem via email — os documentos de preços abrangem os preços padrão de self-service.

Atualizamos esta documentação à medida que a nossa render farm muda — quando uma nova versão de DCC é lançada, quando a frota de hardware muda, quando um motor de renderização suportado recebe um lançamento importante. Cada documento tem um carimbo de "última atualização" no topo para que o utilizador saiba o que está atual, e o registo de alterações no fundo da página inicial dos documentos lista as edições materiais nos últimos 90 dias.

Bem-vindo. O caminho mais direto a partir daqui é o .