
Ambient Occlusion: SSAO vs HBAO vs GTAO (Guia 2026)
Visão geral
Introdução
O ambient occlusion é um daqueles conceitos de renderização que toda a gente viu no ecrã durante mais de quinze anos e que quase ninguém consegue definir com clareza. Abra um menu de definições de um jogo e é provável que encontre uma opção "Ambient Occlusion" com variantes como SSAO, HBAO ou GTAO. Abra o Blender, Cinema 4D ou 3ds Max e encontrará um passe de AO enterrado nas definições de renderização. As capturas de ecrã parecem todas ligeiramente diferentes, o impacto no desempenho varia em ordens de grandeza e a documentação raramente explica as diferenças.
Na Super Renders Farm temos vindo a executar trabalhos de renderização distribuída em CPU e GPU desde 2010, e o ambient occlusion aparece em cerca de metade dos pedidos de suporte que recebemos para trabalhos de archviz e visualização de produto. O padrão é consistente: os artistas ou dependem excessivamente do AO como atalho para a iluminação global, ou desactivam-no completamente e ficam com geometria flutuante que parece desconexa do chão. Ambos os problemas têm solução assim que se compreende o que o AO está realmente a calcular.
Este guia explica o ambient occlusion a partir dos primeiros princípios, percorre os três algoritmos em tempo real que a maioria dos motores de renderização incluem em 2026 (SSAO, HBAO, GTAO), e analisa quando o bake de AO é rápido o suficiente para ser feito numa única estação de trabalho versus quando pertence a um render farm. Leia as FAQ no final para respostas rápidas às perguntas mais frequentes.
O que é realmente o Ambient Occlusion
O ambient occlusion é uma técnica de shading que aproxima a quantidade de luz ambiente que chega a cada ponto de uma superfície, verificando em que medida esse ponto está "ocluído" pela geometria próxima. Um canto onde uma parede encontra o chão recebe menos luz ambiente do que o centro aberto desse mesmo chão, porque o canto tem mais geometria a bloquear os raios que chegam do hemisfério superior. O AO escurece o canto. É esse o efeito.
A razão pela qual o AO se tornou tão ubíquo é económica. Uma solução completa de iluminação global — refletir a luz em cada superfície e integrá-la corretamente — é dispendiosa. O AO captura um componente específico da GI (a auto-sombra local da luz ambiente/do céu) de forma muito económica, amostrando raios apenas a uma curta distância do ponto sombreado. Na renderização offline, normalmente é preferível ter GI completa; o AO é então desativado ou utilizado como um realçador subtil de sombras de contacto. Na renderização em tempo real, o AO tem sido historicamente a única aproximação viável de sombras indiretas, razão pela qual todos os motores de jogo incluem pelo menos um algoritmo de AO.
Convém esclarecer alguns equívocos comuns:
- O AO não é uma sombra de uma fonte de luz. Escurece independentemente da posição das luzes, porque representa a oclusão de todo o hemisfério ambiente.
- O AO não é iluminação global. A GI real tem em conta a cor e o brilho da luz indireta por reflexão; o AO apenas escurece. Usar o AO como substituto da GI é uma causa comum de renders de archviz com aspeto baço.
- O AO não é automaticamente fisicamente correto. O resultado depende inteiramente do algoritmo e da distância máxima de raio definida. Aumente demasiado o raio e um interior limpo transforma-se numa caverna suja.
O manual do Blender aborda o nó de AO offline na sua documentação sobre o shader de Ambient Occlusion, que é uma referência útil para quem quiser ler a matemática real por detrás da amostragem.
SSAO vs HBAO vs GTAO: Três Algoritmos, Um Efeito
Os três algoritmos que se encontram nos motores de jogo de 2026 têm o mesmo objetivo visual, mas com compromissos diferentes entre velocidade, qualidade e estabilidade em função da direção de visualização.
| Algoritmo | Ano de introdução | O que amostra | Custo típico (1080p, GPU classe RTX) | Pontos fortes | Pontos fracos |
|---|---|---|---|---|---|
| SSAO (Screen-Space AO) | 2007 (Crytek, Crysis) | Amostras aleatórias no espaço de ecrã em torno de cada pixel, apenas depth-buffer | ~0,3–0,8 ms | Muito económico, incluído em todos os motores | Ruído, halos em silhuetas, cintilação dependente da vista |
| HBAO / HBAO+ (Horizon-Based AO) | 2008 (NVIDIA) | Percorre raios no depth buffer para encontrar o ângulo do horizonte em múltiplas direcções | ~0,8–1,5 ms | Mais suave que o SSAO, menos halos, consciente da geometria | Mais dispendioso, ainda em espaço de ecrã, pode não detectar oclusores fora do ecrã |
| GTAO (Ground-Truth AO) | 2016 (Activision/Intel) | Integra o cone de visibilidade analiticamente, derivado para corresponder ao AO com ray tracing offline | ~1,0–2,0 ms | Correspondência mais próxima ao AO com ray tracing, estável em movimento, falloff calibrado | Ligeiramente mais dispendioso que o HBAO, requer ajuste cuidado de raio e falloff |
O artigo original da NVIDIA sobre o Image-Space Horizon-Based Ambient Occlusion continua a ser a referência canónica para a família horizon-based, e o whitepaper da Activision sobre Practical Real-Time Strategies for Accurate Indirect Occlusion (GTAO) aborda a derivação do GTAO que a AMD e Intel adoptaram posteriormente.
Um modelo mental útil: o SSAO é um atalho rápido com artefactos visíveis; o HBAO é um atalho mais inteligente que tem conhecimento da geometria; o GTAO é calibrado em função de uma referência offline e é o que se deve utilizar quando se pode dar ao luxo de o usar. Em qualquer GPU moderna lançada nos últimos três ou quatro anos, os três são essencialmente gratuitos a 1080p — a escolha é sobre qualidade e estabilidade de movimento, não sobre frequência de fotogramas.
Existe uma família separada para o ray-traced AO (RTAO), que utiliza as unidades de hardware de ray tracing da GPU para disparar raios reais por pixel. O RTAO é o que se usa quando sobra orçamento de ray tracing após reflexos e sombras; é o que mais se aproxima da "verdade" em tempo real, mas ainda não é a predefinição na maioria dos motores devido ao custo em GPUs de gama mais baixa.
Ligar ou Desligar o Ambient Occlusion?
Esta é uma das pesquisas mais comuns sobre o tema ("ambient occlusion on or off") e a resposta depende do contexto.
Para jogos, o AO quase sempre vale a pena manter ativo. O ganho visual das sombras de contacto sob mobiliário, vegetação e personagens é significativo, e em hardware lançado desde a série RTX 20 o custo é de poucos milissegundos. A única situação em que desligá-lo ajuda é numa GPU mais antiga com um monitor de alta frequência de atualização, onde cada milissegundo conta.
Para pré-visualizações em tempo real em software DCC (Eevee, viewport do Cinema 4D, viewport do 3ds Max), o AO é útil para decisões de bloqueio e iluminação, mas não deve ser utilizado para juízos de imagem final. O AO no viewport é normalmente uma aproximação SSAO de baixa qualidade. Temos visto artistas tomar decisões de iluminação com base no AO do viewport que desaparecem na renderização final.
Para renderização offline final (Cycles, V-Ray, Corona, Arnold, Redshift), a resposta é mais matizada. Se a cena utiliza uma solução de GI completa — path tracing do Cycles, força bruta ou light cache do V-Ray, path tracer do Corona, GI do Arnold — o AO já está implicitamente contabilizado na iluminação indireta e adicionar um passe de AO explícito torna normalmente a imagem mais escura do que deveria. Se se trabalha num pipeline estilizado ou NPR onde a GI fisicamente precisa não é o objetivo, um passe de AO explícito pode acrescentar um escurecimento de contacto útil; faça o bake como elemento de renderização separado para poder ajustar a contribuição em compositing em vez de o integrar diretamente no beauty.
A resposta curta: mantenha-o ativo em jogos, desative-o como efeito de imagem final quando tem GI completa, e faça o bake como passe quando precisa de controlo estilizado.
Ambient Occlusion em Jogos vs Renderização Offline
Existe uma diferença estrutural entre o AO em motores em tempo real e o AO em renderizadores offline que vale a pena tornar explícita, porque explica grande parte da confusão.
O AO em tempo real opera no depth buffer. O motor já rasterizou a cena, tem profundidade por pixel (e normalmente normais), e o passe de AO percorre pixels vizinhos no espaço de ecrã para estimar a oclusão. Isto é rápido mas tem duas limitações estruturais: o que está fora do ecrã não contribui para a oclusão (por isso uma parede mesmo fora do frustum da câmara não vai escurecer o canto de um objeto visível), e o padrão de amostragem tem de ser cuidadosamente ajustado para evitar ruído e cintilação dependente da direção de visualização.
O AO offline opera na geometria real da cena. O renderizador dispara raios a partir de cada ponto de shading e mede a oclusão no espaço 3D real. É mais lento por amostra, mas produz resultados estáveis e de referência que não cintilam quando a câmara se move e não ignoram oclusores que estão fora do ecrã. A maioria dos renderizadores de produção expõe o AO offline como nó (Blender Cycles, Arnold) ou como passe de renderização (V-Ray, Corona, Redshift).
Quando um artista pergunta "porque é que o meu AO parece diferente no viewport versus a renderização final?", a resposta é quase sempre esta: o viewport está a executar AO em espaço de ecrã e a renderização final está a calculá-lo em espaço de mundo. São algoritmos diferentes que produzem imagens diferentes.
Para uma análise mais aprofundada do lado da GPU, a nossa página de render farm GPU na nuvem explica como configuramos hardware de classe RTX para cargas de trabalho de GPU tanto em tempo real como offline.
Porque o Bake de AO Atrasa a Produção
A questão de desempenho mais interessante para equipas de produção não é o AO em tempo real — que é essencialmente gratuito em 2026 — mas o bake de AO offline, que é onde os pipelines realmente abrandam.
Fazer o bake de AO significa pré-calcular o valor de AO para cada texel de um mapa UV e armazená-lo numa textura. É amplamente utilizado em pipelines de jogos (onde o mapa de AO com bake é amostrado em tempo de execução em vez de calcular o AO em direto) e em alguns fluxos de trabalho de archviz para iluminação estática. O custo depende de três coisas: complexidade da cena, resolução da textura e contagem de raios.
Abaixo apresenta-se uma tabela representativa de tempos de bake de trabalhos que executámos para clientes na frota da Super Renders Farm. Estes números são bakes de CPU no Blender Cycles no nosso nó de CPU padrão (Dual Intel Xeon E5-2699 v4, 44 núcleos, 256 GB RAM); os tempos numa única estação de trabalho serão consideravelmente mais longos.
| Tipo de cena | Contagem de polígonos | Resolução do mapa UV | Amostras por texel | Tempo por nó | Notas |
|---|---|---|---|---|---|
| Prop principal, baixa complexidade | ~50K | 2048² | 256 | 2–3 min | Bake trivial, estação de trabalho única é suficiente |
| Interior arquitectónico, sala única | ~500K | 4096² | 512 | 25–40 min | Limítrofe — depende do prazo |
| Exterior archviz completo com vegetação | ~5M | 4096² × 8 tiles | 512 | 4–6 horas | Difícil numa estação de trabalho, rápido num render farm |
| Ambiente de jogo, bake de nível completo | ~10M | 8 × 4096² atlases | 1024 | 10–18 horas | Bloqueia o artista um dia inteiro numa estação de trabalho |
| Batch de bake de biblioteca de assets cinemáticos | misto | misto | 512–1024 | 30–80 horas no total | Sequencial numa estação de trabalho, paralelo num render farm |
O ponto de equilíbrio na nossa experiência situa-se em torno dos 30 minutos para um único bake. Abaixo desse valor, o overhead de empacotar a cena, fazer upload e download do resultado supera o tempo poupado. Acima desse valor, especialmente quando um artista está parado à espera que o bake termine, distribuir o trabalho por várias máquinas é claramente vantajoso. Os bakers baseados em tiles (Blender, V-Ray, Arnold) paralelizam particularmente bem porque cada tile é um trabalho independente.
Vemos isto na Super Renders Farm mais frequentemente durante a fase de finalização de assets de uma produção: dezenas de props precisam de novos bakes de AO, os artistas estão bloqueados, e um render farm absorve a fila durante a noite. Para contexto de preços, consulte o nosso guia de preços de render farm e, para números de benchmark na frota, o benchmark de hardware de render farm com Cinebench 2026 aborda como os nossos nós de CPU se comparam em cargas de trabalho paralelas de CPU.
Ambient Occlusion nos Principais DCCs
Cada DCC principal implementa o AO de forma ligeiramente diferente, e os conselhos práticos variam por aplicação.
Blender expõe o AO em três locais: o toggle de AO do viewport Eevee (uma aproximação rápida no estilo SSAO/HBAO), o nó de AO do Cycles (para uso ao nível do shader, por exemplo máscaras de sujidade em materiais) e o passe de renderização de AO do Cycles (um passe de AO com ray tracing real gerado a par do beauty). O bake de AO do Cycles através do painel de Bake é o fluxo de trabalho utilizado pela maioria das equipas; a tabela de tempos de bake acima foi medida no Cycles. Para artistas que executam o Blender numa única estação de trabalho, a nossa página de render farm Blender na nuvem explica como os bakes de AO do Cycles escalam na nossa frota.
Cinema 4D oferece AO tanto no renderizador Standard/Physical como no Redshift. No Redshift, o AO é tipicamente utilizado como efeito de shader ou como passe de compositing em vez de substituto da GI. A página de render farm Cinema 4D na nuvem aborda a configuração específica do Redshift. A maioria dos utilizadores de C4D + Redshift que encontramos calcula o AO como elemento de renderização e combina-o no After Effects em vez de o integrar no beauty.
3ds Max com V-Ray tem um material VRayDirt dedicado e um elemento de renderização VRayExtraTex AO. A abordagem Dirt é mais flexível porque permite controlar o falloff, o desfoque e a oclusão invertida (cavidade) por material; a abordagem de elemento de renderização é mais rápida de configurar, mas menos ajustável. Para utilizadores de Corona no 3ds Max, o equivalente é o mapa CoronaAO.
Arnold (no Maya, Houdini ou 3ds Max) trata o AO como mais um problema de amostragem e expõe-no através do shader aiAmbientOcclusion e do AOV ambient_occlusion. Como o Arnold é um path tracer unidirecional com importância de amostragem forte, os bakes de AO convergem mais rapidamente do que nalguns outros renderizadores com contagens de amostras equivalentes.
O fio comum: em qualquer DCC, trate o AO como um passe separado que se compõe, e não como um substituto da GI no beauty render. Isto mantém o fluxo de trabalho flexível e permite alterar a contribuição do AO em pós-produção sem re-renderizar.
FAQ
Q: O que é o ambient occlusion em termos simples? A: O ambient occlusion é uma técnica de shading que escurece áreas onde a geometria bloqueia a chegada de luz ambiente a uma superfície — como o canto onde uma parede encontra o chão. Aproxima um componente específico da iluminação global de forma económica, razão pela qual todos os motores de jogo e renderizadores offline incluem uma implementação. Q: O ambient occlusion deve estar ativo ou desativo nos jogos? A: Ativo, em quase todos os casos. A melhoria visual das sombras de contacto sob mobiliário, personagens e vegetação é significativa, e em qualquer GPU lançada nos últimos anos o custo é bem abaixo de 2 ms por frame. A única situação em que desligá-lo ajuda é em hardware mais antigo onde se combate cada milissegundo. Q: Qual é a diferença entre SSAO, HBAO e GTAO? A: O SSAO é o algoritmo original em espaço de ecrã de 2007 — rápido mas com ruído e halos visíveis. O HBAO percorre raios pelo depth buffer para encontrar o ângulo do horizonte e produz resultados mais suaves. O GTAO é o mais recente dos três; é calibrado para corresponder ao AO com ray tracing offline e é o mais estável em movimento. Os três operam em espaço de ecrã e têm custos semelhantes em GPUs modernas. Q: O ambient occlusion é o mesmo que iluminação global? A: Não. A iluminação global tem em conta a cor e o brilho da luz indireta por reflexão entre superfícies. O ambient occlusion apenas escurece áreas com base na oclusão de geometria local, sem cor ou intensidade de fonte de luz envolvida. Usar o AO como substituto da GI é uma razão comum para renders de archviz com aspeto baço ou plano. Q: Quando é que o bake de ambient occlusion realmente necessita de um render farm? A: Quando o bake demora mais de cerca de trinta minutos por asset, quando há muitos assets a processar em paralelo, ou quando o artista está bloqueado à espera do resultado. Na frota da Super Renders Farm, a maioria das equipas de produção que vemos transfere os bakes para um render farm na fase de finalização de assets — tipicamente uma fila de dezenas de props que demoraria dias a fazer bake sequencialmente numa estação de trabalho, mas que fica completa durante a noite quando distribuída. Q: Porque é que o meu ambient occlusion parece diferente no viewport versus a renderização final? A: O viewport quase sempre usa uma aproximação em espaço de ecrã (uma variante rápida de SSAO ou HBAO), enquanto a renderização offline final calcula o AO no espaço de mundo usando raios de geometria real. São algoritmos diferentes que produzem imagens diferentes. Para decisões de iluminação final, faça uma renderização de pré-visualização com poucas amostras em vez de confiar no AO do viewport. Q: Posso usar o ambient occlusion como passe de renderização na renderização offline? A: Sim, e este é o fluxo de trabalho recomendado quando se precisa de controlo estilizado. Todos os principais renderizadores (Cycles, V-Ray, Corona, Arnold, Redshift) expõem o AO como elemento de renderização separado ou AOV. Faça o output a par do beauty render e combine os dois em compositing — dessa forma, pode ajustar a contribuição do AO sem re-renderizar a cena.
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.


