Ray tracing vs path tracing: a diferença explicada

Introdução

Ray tracing vs path tracing não é uma disputa entre duas técnicas rivais: o path tracing é um tipo de ray tracing. O ray tracing clássico segue um conjunto pequeno e fixo de raios (para espelhos, através de vidro, em direção a cada luz), enquanto o path tracing segue muitos percursos de ressalto aleatórios por pixel e faz a média deles, o que explica por que capta a luz indireta suave de forma tão convincente e por que exige tanto mais capacidade de cálculo.

É esse custo que importa em produção. Quando um frame demora 40 minutos em vez de 4, ou regressa cheio de ruído, a causa costuma estar no path tracing: quantas amostras exige, quantos ressaltos segue e como o ruído restante é limpo. Este guia explica as duas ideias, mostra como Arnold, Cycles, Karma, V-Ray e Redshift as aplicam e o que isso significa para o tempo de renderização.

O foco é deliberadamente a renderização offline, frame a frame, para cinema, animação, visualização e trabalho de produto. A forma como os jogos levaram o ray tracing para os gráficos em tempo real está na nossa história do ray tracing em tempo real nos jogos, e a divisão mais ampla entre renderização interativa e renderização final está em renderização em tempo real vs offline. Para perceber o que faz um motor de renderização antes de avançar, comece por o que é a renderização.

Diagrama lado a lado: o ray tracing clássico envia um raio de câmara que se divide em raios fixos de reflexão, refração e sombra, enquanto o path tracing envia muitos percursos de ressalto aleatórios por pixel e faz a média deles

Ray tracing: definição

O ray tracing simula a luz a trabalhar ao contrário: em vez de seguir a luz desde um candeeiro até, por acaso, chegar a uma câmara, o motor de renderização dispara um raio da câmara através de cada pixel e pergunta o que ele atinge. A ideia é antiga. O artigo da Wikipédia sobre ray tracing em computação gráfica (consultado a 19 de outubro de 2026) atribui a Arthur Appel a primeira utilização publicada, em 1968, um método não recursivo hoje geralmente chamado ray casting.

A versão que a maioria das pessoas tem em mente quando fala de «ray tracing» veio de Turner Whitted, cujo algoritmo recursivo foi apresentado no SIGGRAPH em 1979 e publicado em 1980. Quando um raio de câmara atinge uma superfície, o motor de renderização gera novos raios em direções específicas e previsíveis:

um raio de sombra em direção a cada luz, para testar se algo a bloqueia,
um raio de reflexão na direção do espelho, se a superfície for refletora,
um raio de refração através da superfície, se for transparente.

Cada um destes pode gerar os seus próprios raios, formando uma árvore ramificada que termina a uma profundidade definida. O resultado é determinista, bom em reflexos nítidos, refração limpa e sombras duras, e fraco em tudo o que depende de luz a chegar de muitas direções em simultâneo: sombras suaves, desfocagem de brilho, color bleeding e a luz do dia a esvanecer-se para o fundo de uma sala.

Esses efeitos são o que o setor chama iluminação global, e o ray tracing clássico, por si só, não a calcula. Durante muito tempo, os motores de renderização de produção trataram-na com sistemas adicionais como caches de irradiância, photon maps e final gather, cada um com as suas definições e artefactos.

Path tracing: definição

O path tracing foi introduzido e batizado por Jim Kajiya no seu artigo de 1986 sobre a equação de renderização, segundo o artigo da Wikipédia sobre path tracing (consultado a 19 de outubro de 2026). Estima essa equação por amostragem aleatória.

Um raio sai da câmara através de um pixel e atinge uma superfície. Em vez de se dividir num conjunto fixo de raios filhos, escolhe uma única direção nova ao acaso, ponderada pelo material (um espelho envia-o quase exatamente numa direção, uma parede de estuque mate pode enviá-lo quase para qualquer lado). O raio volta a ressaltar, e outra vez, até chegar a uma luz, sair da cena ou atingir um limite de ressaltos. Essa cadeia única e sem ramificações de ressaltos é um percurso, e traz de volta uma estimativa da quantidade de luz que chega ao pixel por esse caminho.

Um percurso é uma estimativa fraca; mil percursos pelo mesmo pixel, em média, são uma boa estimativa. Isto é a amostragem de Monte Carlo de percursos de luz. Como cada percurso pode ressaltar em qualquer coisa, o path tracing calcula luz indireta, sombras suaves, reflexos de brilho, cáusticas (em princípio) e color bleeding como um único processo unificado, sem uma cache separada para cada efeito.

A contrapartida é o ruído. Enquanto não houver percursos suficientes na média, os pixels vizinhos discordam entre si e a imagem fica granulada. É essa contrapartida que se vê na fatura da renderização.

A diferença num relance

	Ray tracing clássico (estilo Whitted)	Path tracing
O que acontece em cada impacto	Raios filhos fixos: sombra, reflexão, refração	Uma direção nova escolhida ao acaso por percurso
Raios por pixel	Uma árvore pequena e previsível	Muitos percursos independentes, em média
Resultado	Determinista, sem ruído	Estimativa estatística, com ruído até convergir
Luz indireta e color bleeding	Não calculados sem sistemas adicionais	Calculados de forma nativa
Sombras suaves, desfocagem de brilho	Exigem raios adicionais ou truques	Resultam da própria amostragem
Principal controlo de qualidade	Profundidade dos raios	Amostras por pixel e limites de ressaltos
Perfil de custo	Mais barato, limitado	Caro, cresce com o objetivo de qualidade

Um resumo útil: o ray tracing é a ferramenta (disparar um raio e descobrir o que ele atinge) e o path tracing é uma estratégia para usar essa ferramenta na resolução do problema completo da iluminação. Todo o path tracer moderno assenta em ray tracing. Nem todo o ray tracer é um path tracer.

Porque é que o path tracing produz ruído e porque é cara a limpeza

O ruído numa imagem renderizada com path tracing não é um defeito: cada pixel é a média de amostras aleatórias, e essa média oscila até haver amostras suficientes. O artigo da Wikipédia sobre integração de Monte Carlo (consultado a 19 de outubro de 2026) indica que o erro da estimativa diminui com 1/√N, em que N é o número de amostras. Em termos de renderização: para reduzir o ruído visível para metade, são necessárias cerca de quatro vezes mais amostras por pixel. Para o reduzir de novo para metade, dezasseis vezes o valor original. Se o tempo de renderização escalar aproximadamente com o número de amostras, o que acontece na maior parte do frame, limpar o último resquício de grão é a parte mais cara de toda a renderização.

Quatro blocos de ruído com 16, 64, 256 e 1.024 amostras por pixel, mostrando o ruído visível a reduzir-se para metade a cada aumento de quatro vezes nas amostras

Algumas cenas são mais difíceis do que outras, e os motivos são previsíveis:

Fontes de luz pequenas ou escondidas. A luz do dia através de uma frincha estreita significa que poucos percursos aleatórios chegam a encontrar a luz, pelo que a estimativa converge devagar.
Materiais de brilho e refrativos. Metal escovado, vidro fosco e líquidos são difíceis de amostrar com eficiência.
Muitos ressaltos. Interiores de paredes brancas dependem de vários ressaltos; reduzir o limite acelera o processo, mas escurece os cantos.
Volumes e subsurface scattering. Fumo, nevoeiro e pele acrescentam dispersão dentro do material, multiplicando o trabalho por percurso.
Motion blur e profundidade de campo. Cada amostra escolhe também um instante no tempo e um ponto na lente, pelo que são necessárias mais amostras.

A resolução define quantos pixels precisam de resposta; a iluminação decide quantas amostras cada pixel exige até a sua resposta ficar limpa.

Como os motores de renderização de produção usam hoje o path tracing

A maioria dos motores de renderização de produção offline assenta hoje em path tracing, mas nem todos da mesma maneira. A distinção útil é entre fazer path tracing de todos os ressaltos e fazer path tracing do primeiro ressalto com uma cache para os restantes.

Arnold. A documentação do Arnold da Autodesk (consultada a 19 de outubro de 2026) descreve-o como um motor de ray/path tracing de Monte Carlo, não enviesado e fisicamente correto, e afirma que evita algoritmos de cache como photon mapping e final gather. A qualidade é controlada sobretudo através do número de amostras: um frame mais limpo exige mais amostras, e mais amostras exigem mais tempo.

Cycles. O Cycles, do Blender, é um path tracer, e as suas definições de amostragem (manual do Blender 5.2 LTS, consultado a 19 de outubro de 2026) mostram bem o conjunto de ferramentas moderno: um número máximo de percursos traçados por pixel, um limiar de ruído que deixa de amostrar regiões assim que estão suficientemente limpas (amostragem adaptativa), um limite de tempo opcional e uma escolha de denoisers.

Karma. A própria documentação do Karma da SideFX (documentação do Houdini 22.0, consultada a 19 de outubro de 2026) descreve-o como o path tracer fisicamente correto do Houdini.

V-Ray. A Chaos divide o trabalho entre um motor de iluminação global primário e outro secundário. No V-Ray GPU para 3ds Max, a página de Global Illumination em GPU da Chaos (consultada a 19 de outubro de 2026) afirma que o motor primário é sempre Brute Force (amostragem pura por path tracing do primeiro ressalto), com Brute Force ou Light Cache para os ressaltos secundários. A Light Cache é uma aproximação pré-calculada dos ressaltos seguintes, que troca um pouco de precisão por uma grande poupança em amostras.

Redshift. A documentação de iluminação global do Redshift da Maxon (consultada a 19 de outubro de 2026) descreve o Brute Force como o motor de GI mais preciso e mais lento, com ruído quando o número de raios é baixo, e oferece uma Irradiance Point Cloud como motor secundário que torna o Brute Force primário mais rápido e limpo em iluminação difícil, à custa de algum armazenamento.

Este último padrão, path tracing para o ressalto que mais se vê e uma cache para o resto, explica por que as palavras «enviesado» (biased) e «não enviesado» (unbiased) surgem nas conversas sobre motores de renderização. A média de um motor não enviesado converge para a resposta fisicamente correta à medida que as amostras aumentam. Um motor enviesado aceita uma diferença pequena e sistemática (de uma cache, de um clamp ou de um limite de ressaltos) em troca de convergir muito mais cedo. Nenhum dos dois está errado. Em animação, as caches exigem cuidado, porque uma cache calculada frame a frame pode cintilar; em imagens estáticas, são muitas vezes o caminho mais rápido para uma imagem limpa.

Denoising: menos amostras, o mesmo prazo

Se reduzir o ruído para metade custa quatro vezes mais amostras, o atalho óbvio é parar mais cedo e filtrar o ruído que sobra. É isso que fazem os denoisers modernos.

Os dois denoisers que a maioria dos artistas encontra são o Intel Open Image Denoise e o NVIDIA OptiX. A Intel descreve o Open Image Denoise (consultado a 19 de outubro de 2026) como uma biblioteca de código aberto de filtros de denoising para imagens renderizadas com ray tracing. A página de amostragem do Cycles citada acima lista ambos como opções, indica que o OptiX só está disponível em GPUs NVIDIA e descreve a definição automática como preferindo o Open Image Denoise ao OptiX.

Os denoisers são treinados para distinguir o ruído de amostragem do detalhe real, mas têm efeitos secundários:

Perda de detalhe fino. Texturas finas, cabelo e geometria delgada podem ser suavizados se tiverem entrado poucas amostras.
Cintilação temporal. Um denoiser que trabalha em cada frame em separado pode produzir resultados ligeiramente diferentes em frames consecutivos, o que se lê como oscilação na animação.
Passes de composição. Se o denoising for aplicado ao beauty pass mas não aos AOV (ou o inverso), os passes deixam de somar corretamente na composição.

A regra prática é aplicar o denoising a um frame que já esteja razoavelmente convergido, não a um que seja sobretudo ruído. Um denoiser reduz o número de amostras necessárias. Não as substitui.

O que o path tracing significa para o tempo de renderização

O tempo de renderização de um trabalho com path tracing é o produto de alguns números: frames, pixels por frame, amostras por pixel e a dificuldade de cada amostra para essa cena.

Um exemplo hipotético, apenas para ilustração. Um plano de dez segundos a 24 frames por segundo são 240 frames. Imagine que cada frame precisa de 16 minutos numa só máquina, com o número de amostras que o deixa limpo. São 64 horas-máquina. Agora o cliente pede menos grão nas sombras. Se reduzir o ruído para metade significa quatro vezes mais amostras, e o tempo escala com as amostras, o mesmo plano passa a rondar as 256 horas-máquina. Um bom denoiser consegue recuperar grande parte disso, e é por isso que o número de amostras e o denoiser se decidem em conjunto num frame de teste.

Aritmética do tempo de renderização de um plano com path tracing: 240 frames vezes 16 minutos por frame são 64 horas-máquina, e quatro vezes mais amostras para reduzir o ruído para metade dão cerca de 256 horas-máquina

Três hábitos mantêm essa aritmética sob controlo:

Medir num frame representativo. O frame mais difícil do plano (o que tem mais vidro, volume ou motion blur) é o que se deve testar, não o primeiro.
Usar amostragem adaptativa e um limiar de ruído sempre que o motor de renderização os ofereça, para que zonas limpas como o céu e paredes lisas deixem de ser amostradas cedo.
Gastar amostras onde o olhar vai. Aumentar as amostras das luzes ou dos materiais específicos que continuam com ruído, não do frame inteiro.

A lista completa das definições que afetam o tempo de renderização, desde limites de ressaltos a tamanhos de texturas, está no nosso guia de otimização do tempo de renderização. Saber se essas amostras correm mais depressa em processadores ou em placas gráficas depende do motor de renderização e da cena, tema tratado em renderização em GPU vs renderização em CPU.

Executar trabalhos com path tracing numa render farm

Cada frame de uma sequência com path tracing é renderizado de forma independente, pelo que 240 frames distribuídos por muitas máquinas ficam prontos no tempo de poucos, enquanto a computação total, que é o que uma farm cobra, se mantém igual. Se a ideia de farm for nova, o nosso guia sobre o que é uma render farm explica o modelo.

Na Super Renders Farm, que é uma render farm totalmente gerida, a cena é carregada e a farm trata do software e das licenças de renderização, pelo que não há sessão de ambiente de trabalho remoto nem nada para instalar. A maior parte do trabalho que vemos é renderizada em CPU (V-Ray e Corona no 3ds Max, Arnold no Maya, Cycles no Blender, Karma e Mantra no Houdini), o que corre nos nossos nós de CPU.

O path tracing em GPU corre nos nossos nós de GPU, cada um com 2x placas NVIDIA RTX 5090 e 32 GB de VRAM por placa. A memória é por placa e não é partilhada entre as duas, pelo que um frame em GPU tem de caber em 32 GB. O Redshift renderiza apenas em nós de GPU. O Redshift para Cinema 4D, Maya e Houdini, e o Cycles em GPU, correm aí sem pedido de configuração; o hardware de GPU e os motores suportados estão listados na nossa página da render farm GPU na nuvem. Se uma cena não couber na memória de uma placa, um path tracer em CPU é geralmente o caminho mais seguro para esse trabalho.

Os preços atuais estão na página de preços; deixámos os números fora deste texto explicativo porque mudam, e porque o número de amostras que escolher altera o custo final mais do que qualquer valor por hora. As novas contas recebem 25 $ em créditos de renderização gratuitos, que podem ser gastos num frame de teste representativo antes de avançar com uma sequência, e a nossa equipa de suporte está disponível 24/7 por chat em direto.

Equívocos comuns

«Path tracing e ray tracing são tecnologias concorrentes.» Não são. O path tracing é um método construído sobre o ray tracing. Um motor de renderização de produção descrito hoje como ray tracer é normalmente um path tracer por baixo.

«Mais amostras significa sempre uma imagem melhor.» Depois do ponto em que o ruído deixa de ser visível na resolução de entrega, amostras extra só acrescentam tempo de renderização. Esse ponto é o que a amostragem adaptativa e os limiares de ruído foram concebidos para encontrar.

«Enviesado significa errado.» Técnicas enviesadas, como as caches, convergem mais cedo e são rotina em produção. A escolha certa depende do plano, sobretudo de ser uma imagem estática ou uma animação.

«O path tracing em GPU é sempre mais rápido.» Muitas vezes é mais rápido por frame, mas só se a cena couber na memória da placa e o motor de renderização suportar todas as funcionalidades que a cena usa. Cenas grandes de visualização arquitetónica e volumes pesados rendem frequentemente com mais fiabilidade em CPU.

FAQ

Q: Qual é a diferença entre ray tracing e path tracing? A: O ray tracing clássico segue um conjunto fixo de raios a partir de cada ponto de impacto (em direção às luzes, na direção do espelho e através de superfícies transparentes) e produz um resultado determinista e sem ruído, mas sem luz indireta. O path tracing segue muitos percursos de ressalto aleatórios por pixel e faz a média deles, o que calcula de forma natural a luz indireta, as sombras suaves e o color bleeding, mas produz ruído até haver amostras suficientes na média.

Q: O que é o path tracing, em termos simples? A: O path tracing envia um raio da câmara para a cena e deixa-o ressaltar numa direção aleatória em cada superfície até encontrar luz, repetindo depois isto muitas vezes por pixel e fazendo a média dos resultados. Foi introduzido por Jim Kajiya no seu artigo de 1986 sobre a equação de renderização e é a base da maioria dos motores de renderização de produção offline atuais.

Q: O path tracing é um tipo de ray tracing? A: Sim. O path tracing usa ray tracing para descobrir o que cada raio atinge e depois aplica amostragem de Monte Carlo para decidir para onde vai o raio seguinte. Todo o path tracer é um ray tracer, mas nem todo o ray tracer é um path tracer.

Q: Porque é que as imagens renderizadas com path tracing têm ruído? A: Cada pixel é a média de amostras aleatórias, e essa média é incerta até haver amostras suficientes. O erro diminui na proporção de um sobre a raiz quadrada do número de amostras, pelo que reduzir o ruído para metade exige cerca de quatro vezes mais amostras e, na maioria das cenas, cerca de quatro vezes mais tempo de renderização.

Q: O V-Ray, o Arnold, o Cycles e o Redshift usam path tracing? A: Sim, de maneiras diferentes. O Arnold, o Cycles e o Karma são path tracers que controlam a qualidade sobretudo através das amostras. O V-Ray e o Redshift oferecem um motor Brute Force que faz path tracing do primeiro ressalto e que pode ser combinado com uma cache para os ressaltos seguintes (Light Cache no V-Ray, Irradiance Point Cloud no Redshift), o que converge mais cedo à custa de um pequeno enviesamento.

Q: O denoising substitui números de amostras mais elevados? A: Não totalmente. Denoisers como o Intel Open Image Denoise e o NVIDIA OptiX permitem parar com menos amostras, mas são mais eficazes em frames que já estão razoavelmente limpos. Amostras a menos podem custar detalhe fino em imagens estáticas e causar cintilação em animação.

Q: O path tracing é mais rápido em GPU ou em CPU? A: Depende do motor de renderização e da cena. O path tracing em GPU é muitas vezes mais rápido por frame quando a cena cabe na memória da placa, enquanto o path tracing em CPU lida com cenas muito grandes, volumes pesados e funcionalidades que um motor de GPU não suporta. Na nossa farm, os nós de GPU têm 2x RTX 5090 com 32 GB por placa, sem memória partilhada entre as placas.

Q: Uma render farm consegue acelerar o path tracing? A: Uma farm não reduz a computação de que um frame precisa, mas renderiza muitos frames em simultâneo, pelo que uma sequência fica pronta numa fração do tempo real. O tempo total de máquina, que depende muito do número de amostras escolhido, é o que determina o custo.