
O que são AOV em renderização? Render passes, nomenclatura e saída explicados
Visão geral
Introdução
O que são AOV em renderização? AOV significa Arbitrary Output Variable: uma imagem separada que um renderizador grava ao lado da imagem final, contendo um dos ingredientes dessa imagem, como a iluminação difusa, a distância à câmara ou a direção para a qual cada superfície está virada. Os artistas falam também em render passes, render elements ou multipasses, consoante o software. É uma só ideia com vários nomes.
Uma breve desambiguação, porque a sigla circula noutros meios. No comércio online, AOV costuma significar valor médio de encomenda (average order value) e, na linguagem de câmaras, pode significar ângulo de visão. Este artigo trata apenas do significado em renderização.
Os AOV existem porque um frame final é difícil de alterar depois de o renderizador ter fundido tudo, e voltar a renderizar um frame demorado para corrigir uma só coisa é caro. Guardados em separado, esses ingredientes permitem a quem faz a composição ajustá-los em minutos. Este guia aborda o que contêm os passes mais comuns, como o Arnold, o V-Ray, o Redshift, o Cycles e o Corona os nomeiam e ativam, quando é que um único EXR multicamada compensa face a muitos ficheiros e o que os AOV mudam quando os frames são renderizados numa render farm.
A configuração do denoiser específica do Arnold está em How to Denoise AOVs Effectively, a gestão de cor em ACES Color Management Explained e a visão mais ampla de como uma cena se transforma num frame em What Is Rendering? A Complete Guide.
O que é um AOV, em termos simples
O guia do utilizador do Arnold, da Autodesk (consultado a 10 de novembro de 2026), define os AOV como uma forma de renderizar qualquer componente arbitrário de uma rede de shading para imagens diferentes. A documentação do Redshift, da Maxon (consultada a 10 de novembro de 2026), descreve-os do lado dos dados: os AOV são os diferentes tipos de informação por píxel que o renderizador consegue produzir. Uma renderização normal dá uma cor por píxel; um AOV dá outra grandeza por píxel, guardada como imagem própria ou como camada dentro de um ficheiro.
Essas grandezas dividem-se em duas famílias.
Componentes de iluminação. Dividem a imagem naquilo que a luz e o material produziram: difusa, especular, transmissão, emissão e assim por diante. O guia do Arnold refere que basta somar esses AOV para reconstruir o AOV beauty, e é por isso que quem faz composição gosta deles: cada parte pode ser corrigida isoladamente e a soma continua a igualar o frame.
Passes de dados. Contêm factos sobre a cena e não luz: distância à câmara, direção da superfície, identidade do objeto, movimento entre frames. A documentação do Redshift chama-lhes AOV utility, e o V-Ray arquiva-os nos tipos de elemento de geometria e utility.
O compromisso está enunciado de forma clara no guia do Arnold: mais AOV dão mais controlo na composição, mas também mais trabalho de manuseamento, e ocupam mais memória e espaço em disco, sobretudo combinados com light groups.
Cinco passes de iluminação (difusa direta, difusa indireta, especular, transmissão e emissão) a alimentar uma única caixa rotulada beauty, a soma dos passes
Passes beauty e passes utility
Os nomes variam consoante o motor (a secção seguinte trata disso), mas o conteúdo é consistente.
| Passe | O que contém | Uso típico na composição |
|---|---|---|
| Beauty | A imagem completa, já iluminada | A camada de base; todos os outros passes são avaliados em relação a ela |
| Difusa (direta e indireta) | Luz dispersa por superfícies mate, separada consoante a forma como chegou | Reajustar a luz das superfícies sem mexer nos reflexos |
| Especular ou reflexão | Realces e reflexos tipo espelho | Reforçar ou suavizar os realces |
| Transmissão ou refração | Luz que atravessa vidro e água | Ajustar o vidro separadamente do que está atrás |
| Emissão | Luz emitida por superfícies luminosas | Acrescentar ou moldar o brilho |
| Albedo | Cor da superfície sem iluminação nem sombras | Apoio ao denoising e limpeza |
| Z ou profundidade | Distância à câmara, por píxel | Profundidade de campo, nevoeiro e atmosfera |
| Normais | A direção para a qual cada superfície está virada | Reiluminação e efeitos sensíveis às arestas |
| Vetores de movimento | Movimento de cada píxel no espaço do ecrã | Motion blur aplicado na composição |
| Object ID, material ID, Cryptomatte | A que objeto ou material pertence um píxel | Seleções e máscaras sem voltar a renderizar |
| Light groups ou light select | A imagem iluminada apenas por luzes escolhidas | Reequilibrar candeeiros individuais |
Algumas destas definições vêm diretamente do fabricante. No guia do Arnold, Z é a profundidade dos pontos de shading vistos da câmara, P é a sua posição no espaço do mundo, N é a normal suave no espaço do mundo e ID é um número aleatório derivado do nome da forma. O AOV de vetor de movimento é um vetor 2D para o movimento no espaço do ecrã, e o guia acrescenta que é preciso definir um obturador instantâneo para a câmara, o tipo de pormenor que custa uma tarde inteira quando descoberto por tentativa e erro.
Como os principais motores os nomeiam e ativam
Cada motor expõe a mesma ideia através do seu próprio vocabulário e painel. Isto é um mapa, não um manual: os caminhos de menu mudam entre aplicações anfitriãs e versões, pelo que convém consultar a documentação da versão exata em uso.
| Motor | Como lhes chama | Onde se ativam | Convém saber |
|---|---|---|---|
| Arnold | AOVs | O separador AOVs das definições de renderização (o Arnold for Maya lista AOV disponíveis e ativos) | AOV integrados como profundidade, posição, normais, ID, componentes de iluminação e vetor de movimento estão sempre disponíveis |
| V-Ray | Render elements, também chamados render passes | O separador Render Elements das definições de renderização | Dezenas de tipos de elemento agrupados em beauty, matte, geometria e utility |
| Redshift | AOVs | A lista de AOV nas definições de renderização | Agrupados em integrados, utility e personalizados; o Cryptomatte é um AOV próprio |
| Cycles (Blender) | Render passes | Properties, View Layer, Passes | Passes de dados, passes de luz, Cryptomatte e light groups |
| Corona | Render elements (3ds Max), multipasses (Cinema 4D) | As definições de render element ou multipass da aplicação anfitriã | Inclui Virtual Beauty e passes matte, além de um elemento Cryptomatte |
O pormenor por trás de cada linha, com fontes consultadas a 10 de novembro de 2026:
Arnold. A página de AOV do Arnold for Maya indica que cada AOV assenta em três nós: o próprio AOV, um driver e um filtro. Indica também que a opção Output Denoising AOVs grava diffuse_albedo, Z e N, o que no Maya exige atualmente EXR com Merge AOVs ativado.
V-Ray. A página de render elements do V-Ray for Maya descreve os render elements como uma forma de decompor as renderizações em componentes como cor difusa, reflexos, sombras e mattes. Contém também o pormenor que apanha muita gente: o V-Ray só grava os elementos em ficheiros se ativar uma das saídas de ficheiro de imagem raw do V-Ray ou a opção Separate render channels.
Redshift. A introdução aos AOV da Maxon enumera AOV integrados (reflexos, refrações, iluminação global), AOV utility (profundidade, vetores de movimento, posição no mundo) e AOV personalizados definidos pelo utilizador, com os light groups a estender os integrados. O nome de cada ficheiro de AOV é o prefixo de nome de ficheiro partilhado mais um sufixo, o que será importante mais adiante para a nomenclatura.
Cycles. A página Passes do manual do Blender enumera passes de dados (como Depth, Position, Normal, Vector, UV e índices de objeto e de material) e passes de luz (difusa, glossy e transmissão divididas em direta, indireta e cor, além de emissão, ambiente e oclusão ambiente), e depois Cryptomatte e light groups.
Corona. A página de funcionalidades do Corona, da Chaos, indica que o Corona oferece muitos render elements no 3ds Max e multipasses no Cinema 4D, incluindo Virtual Beauty e passes matte, e descreve um render element Cryptomatte que gera canais de renderização guardados num ficheiro OpenEXR multicanal.
Cryptomatte e light groups: dois casos especiais
Dois tipos de passe alteram a quantidade de dados que um frame transporta.
Cryptomatte cria mattes de ID automaticamente a partir dos nomes de objetos e materiais já presentes na cena. O Redshift, o Cycles e o Corona listam-no, como nas secções anteriores. Na prática, um passe Cryptomatte acrescenta vários canais a cada frame. O nosso guia de EXR-IO e Cryptomatte explica como usar esses mattes no Photoshop, pelo que os passos de composição não se repetem aqui.
Light groups renderizam a cena como se apenas certas luzes estivessem acesas, uma imagem por grupo. O manual do Blender descreve um light group como um passe Combined limitado, em que a cena é iluminada apenas por determinadas luzes. Os grupos dão controlo por candeeiro na composição e multiplicam o número de imagens, porque os passes de iluminação podem ser divididos de novo por grupo. É este o caso que o aviso do Arnold sobre memória e disco tem em mente. Convém acrescentar grupos para os candeeiros que se espera reequilibrar, e não para todas as luzes da cena.
EXR multicamada versus ficheiros separados
Depois de escolhidos os AOV, a decisão seguinte é como são guardados.
| Questão | Um EXR multicamada por frame | Um ficheiro por passe |
|---|---|---|
| Ficheiros por frame | Um só, com cada passe como camada | Um por passe, pelo que dez passes significam dez ficheiros por cada frame |
| Manter os passes sincronizados | Todos os passes de um frame viajam juntos | Cada sequência tem de se manter completa e alinhada por frame |
| Abrir na composição | Uma leitura, depois separar as camadas | Uma leitura por sequência |
| Definições por passe | Um só conjunto de opções de ficheiro | Cada passe pode usar a sua própria compressão, quando o motor o permite |
| Utilização típica | Pipelines de VFX e de composição | Pipelines simples ou ferramentas que não leem ficheiros em camadas |
Os motores diferem na forma de lá chegar. No Arnold, Merge AOVs ativa EXR multicanal, e a documentação do Maya refere que AOV EXR multipart e não fundidos podem usar tipos de compressão diferentes. No Redshift, todos os AOV com o mesmo prefixo personalizado são guardados no mesmo ficheiro EXR quando se trabalha com EXR multicamada. No V-Ray for Maya, a saída dos elementos depende da opção de ficheiro de imagem raw ou de Separate render channels, como referido acima.
Duas vias a comparar ficheiros separados, em que um frame produz quatro ficheiros EXR separados, com um EXR multicamada, em que o mesmo frame produz um ficheiro com quatro camadas
Na maior parte do trabalho de composição, um ficheiro multicamada por frame é mais fácil de transportar e mais difícil de estragar. O artigo VFX Compositing and Cloud Rendering explica o que uma composição faz com esses ficheiros, incluindo a memória de que precisa, e o artigo Render Farm for Motion Design mostra a entrega de EXR multi-part ao After Effects.
Escolher que AOV renderizar
Marcar todas as opções é compreensível e geralmente errado. Uma abordagem funcional:
- Perguntar à composição no que vai mexer. Um plano que só precisa de nevoeiro baseado em profundidade não precisa de doze passes de iluminação.
- Manter sempre o beauty. É a verificação de que os passes continuam a somar.
- Acrescentar passes de dados para tarefas específicas. Profundidade para desfocagem ou nevoeiro, vetores de movimento para blur, Cryptomatte para seleções, normais ou posição para reiluminação.
- Tratar os dados de denoising como categoria à parte. A opção Output Denoising AOVs do Arnold grava diffuse_albedo, Z e N, e o Cycles lista passes Denoising Data. Alimentam um denoiser e não são passes criativos; a configuração específica do Arnold está no guia do denoiser.
- Testar primeiro um frame. Confirmar na composição que todos os passes estão presentes e reconstroem o beauty.
O modo como os passes de iluminação são geridos em cor pertence ao pipeline de cor, que o artigo sobre ACES explica.
O que os AOV mudam quando os frames são renderizados numa render farm
Uma render farm distribui os frames por muitas máquinas, e os AOV não alteram isso. Alteram a quantidade que cada frame produz e o que tem de ser trazido de volta no fim.
Tamanho de saída por frame. Cada passe é mais um conjunto de canais por píxel. O OpenEXR guarda um canal de vírgula flutuante de meia precisão em 2 bytes e um de precisão total em 4. Tome-se um frame hipotético de 1920 x 1080, que tem 2.073.600 píxeis. Uma imagem RGBA apenas com beauty, em meia precisão, ocupa 8 bytes por píxel, cerca de 16,6 MB sem compressão. Suponha-se agora beauty mais 12 AOV de três canais mais um canal de profundidade de precisão total: 84 bytes por píxel, cerca de 174 MB por frame, aproximadamente dez vezes mais. Em 240 frames, são cerca de 4,0 GB contra 41,8 GB. A compressão EXR reduz os ficheiros reais, numa medida que depende da imagem, pelo que estes valores devem ser lidos como proporções e não como previsões.
Tamanho de saída por frame de 1920 x 1080: apenas beauty são 8 bytes por píxel, 16,6 MB por frame, 4,0 GB para 240 frames; beauty mais 12 AOV RGB mais profundidade são 84 bytes por píxel, 174 MB por frame, 41,8 GB para 240 frames, sem compressão e hipotético
Transferência e armazenamento. Concluir uma renderização não é o fim do trabalho; os ficheiros têm de chegar ao seu disco. Os resultados na Super Renders Farm podem ser descarregados a partir da interface web ou obtidos automaticamente pela SuperRenders Client App. Uma sequência dez vezes maior demora proporcionalmente mais a transferir e exige proporcionalmente mais disco local.
Disponibilidade de motores e aplicações anfitriãs. Renderizamos tarefas de Arnold, V-Ray, Redshift, Corona e Cycles, e os fluxos de trabalho de AOV descritos acima aplicam-se a cada um. O Redshift renderiza em nós GPU. Algumas combinações de aplicação anfitriã e motor, como Redshift for Blender, V-Ray for Blender e Arnold for Houdini, são disponibilizadas a pedido, pelo que convém contactar-nos para confirmar antes de carregar uma cena que dependa de uma delas. O funcionamento dos créditos e das tarifas está na página de preços.
Convenções de nomenclatura para a composição apanhar tudo
Alguns problemas com AOV são problemas de nomenclatura e não de renderização. Quem abre uma sequência na composição quer todos os passes localizáveis e todos os frames alinhados e, no Redshift, por exemplo, o prefixo escolhido é a espinha dorsal do nome de cada ficheiro de AOV. Uma convenção que sobrevive às passagens de testemunho:
| Elemento | Exemplo | Porquê |
|---|---|---|
| Plano e versão no prefixo | shot010_v003 | Mantém as versões separadas e ordenáveis |
| Nome do passe como sufixo | _beauty, _depth | O passe lê-se no nome do ficheiro |
| Preenchimento de frame com comprimento fixo | .1001.exr | As sequências ordenam-se bem e as ferramentas detetam o intervalo |
| Uma pasta por versão | shot010/v003/ | Uma nova renderização nunca sobrescreve a aprovada |
| Caracteres simples | letras, dígitos, sublinhado | Espaços e símbolos quebram scripts e religações |
Convém colocar a convenção no modelo de cena e usá-la também nas renderizações de teste locais, para que um frame devolvido por uma render farm tenha exatamente o mesmo nome de um renderizado na estação de trabalho e a composição não precise de religações.
Erros comuns com AOV e como os detetar
As armadilhas do V-Ray, do Merge AOVs e dos vetores de movimento foram abordadas acima. Há mais três que surgem em qualquer motor.
| Sintoma | Causa provável | Correção |
|---|---|---|
| Profundidade ou normais parecem cortadas ou com bandas | Passes de dados gravados num formato de 8 bits como JPEG ou PNG, que não consegue guardar valores em vírgula flutuante | Gravar os passes de dados em EXR |
| A composição não encontra passes ou os frames não estão alinhados | Prefixos, sufixos ou preenchimento de frame inconsistentes | Aplicar uma só convenção de nomenclatura a todos os passes |
| Descargas e uso de disco muito acima do previsto | Cada frame transporta uma lista longa de passes, possivelmente com light groups | Reduzir a lista ao que a composição usa |
Resumo: uma lista de verificação de AOV
- AOV significa Arbitrary Output Variable: uma imagem extra por píxel, gravada ao lado do beauty.
- Os passes de iluminação reconstroem o beauty; os passes de dados descrevem a cena.
- Os nomes e painéis diferem consoante o motor, pelo que se deve verificar a documentação da versão em uso.
- Preferir um EXR multicamada por frame, renderizar apenas os passes que a composição vai usar e dimensionar a saída antes de submeter.
- Usar uma só convenção de nomenclatura localmente e na render farm, e testar um frame antes da sequência.
FAQ
Q: O que significa AOV em renderização? A: AOV significa Arbitrary Output Variable. É uma imagem extra, ou camada de imagem, que um renderizador grava ao lado da renderização beauty, contendo uma grandeza por píxel como iluminação difusa, profundidade, normais ou um ID de objeto.
Q: Os AOV são o mesmo que render passes? A: Na prática, sim. O Arnold e o Redshift dizem AOVs, o V-Ray diz render elements, o Blender Cycles diz render passes e o Corona usa render elements no 3ds Max e multipasses no Cinema 4D.
Q: Qual é a diferença entre passes beauty e passes utility? A: Os passes beauty ou de iluminação, como difusa, especular e emissão, contêm luz e podem ser somados para reconstruir a imagem final. Os passes utility ou de dados, como profundidade, normais, posição, vetores de movimento e IDs, contêm informação da cena em vez de luz e servem para efeitos e seleções na composição.
Q: Devo guardar os AOV num EXR multicamada ou em ficheiros separados? A: Para composição, um EXR multicamada por frame costuma ser mais simples, porque todos os passes de um frame viajam juntos e não se podem dessincronizar. Os ficheiros separados fazem sentido quando uma ferramenta não lê ficheiros em camadas ou quando se pretende compressão diferente por passe.
Q: Os AOV tornam as renderizações mais lentas ou maiores? A: Maiores, sim: a documentação do Arnold indica que mais AOV ocupam mais memória e espaço em disco, sobretudo com light groups. O efeito no tempo de renderização varia consoante o motor e o passe, pelo que convém cronometrar um frame de teste com e sem os passes extra antes de submeter uma sequência.
Q: É possível renderizar AOV numa render farm? A: Sim. Os frames são renderizados como habitualmente e cada um grava os passes ativados. Na nossa render farm, renderizamos tarefas de Arnold, V-Ray, Redshift, Corona e Cycles, e algumas combinações de aplicação anfitriã e motor são disponibilizadas a pedido, pelo que convém contactar-nos para confirmar antes de carregar uma cena que dependa de uma delas. Convém executar primeiro um frame de teste e verificar se todos os passes regressam.
Q: AOV em renderização é o mesmo que AOV em comércio eletrónico? A: Não. Em renderização significa Arbitrary Output Variable. No comércio online costuma significar valor médio de encomenda (average order value) e, em fotografia, uma sigla semelhante pode referir-se ao ângulo de visão. Partilham as letras e mais nada.
About Alice Harper
Blender and V-Ray specialist. Passionate about optimizing render workflows, sharing tips, and educating the 3D community to achieve photorealistic results faster.



