Lancer de rayons vs path tracing : quelle différence en rendu 3D ?

Introduction

Opposer le lancer de rayons (ray tracing) au path tracing est une fausse opposition : le path tracing est une forme de lancer de rayons. Le lancer de rayons classique suit un petit ensemble fixe de rayons (vers les miroirs, à travers le verre, vers chaque lumière), tandis que le path tracing suit de nombreux trajets de rebonds aléatoires par pixel et en fait la moyenne, ce qui lui permet de restituer de façon si convaincante la lumière indirecte douce, et explique pourquoi il demande tellement plus de calcul.

Ce coût est ce qui compte en production. Quand une image prend 40 minutes au lieu de 4, ou revient parsemée de bruit, la cause est généralement le path tracing : le nombre d'échantillons qu'il demande, le nombre de rebonds qu'il suit et la façon dont le bruit restant est nettoyé. Ce guide explique les deux notions, montre comment Arnold, Cycles, Karma, V-Ray et Redshift les appliquent, et ce que cela implique pour le temps de rendu.

Il se limite volontairement au rendu offline, image par image, pour le cinéma, l'animation, la visualisation et le produit. La façon dont les jeux vidéo ont amené le lancer de rayons au temps réel est traitée dans notre historique du lancer de rayons en temps réel dans les jeux, et la séparation plus large entre rendu interactif et rendu final est expliquée dans rendu temps réel vs rendu offline. Si vous souhaitez d'abord comprendre les bases de ce que fait un moteur de rendu, commencez par ce qu'est le rendu.

Schéma côte à côte : le lancer de rayons classique envoie un rayon de caméra qui se divise en rayons fixes de réflexion, de réfraction et d'ombre, tandis que le path tracing envoie de nombreux trajets de rebonds aléatoires par pixel et en fait la moyenne

Le lancer de rayons, défini

Le lancer de rayons simule la lumière en la remontant à l'envers : au lieu de suivre la lumière depuis une lampe jusqu'à ce qu'elle atteigne par hasard une caméra, le moteur de rendu tire un rayon depuis la caméra à travers chaque pixel et regarde ce qu'il touche. L'idée est ancienne. L'article de Wikipedia sur le lancer de rayons en infographie (consulté le 19 octobre 2026) attribue à Arthur Appel la première utilisation publiée en 1968, une méthode non récursive qu'on appelle aujourd'hui généralement le ray casting.

La version à laquelle la plupart des gens pensent quand ils disent « lancer de rayons » vient de Turner Whitted, dont l'algorithme récursif a été présenté au SIGGRAPH en 1979 et publié en 1980. Lorsqu'un rayon de caméra touche une surface, le moteur de rendu génère de nouveaux rayons dans des directions précises et prévisibles :

• un rayon d'ombre vers chaque lumière, pour tester si quelque chose la bloque,
• un rayon de réflexion dans la direction du miroir, si la surface est réfléchissante,
• un rayon de réfraction à travers la surface, si elle est transparente.

Chacun d'eux peut engendrer ses propres rayons, ce qui construit un arbre de branches qui s'arrête à une profondeur définie. Le résultat est déterministe, efficace pour les reflets nets, la réfraction propre et les ombres dures, mais médiocre pour tout ce qui dépend d'une lumière arrivant de nombreuses directions à la fois : ombres douces, flou des reflets brillants, transfert de couleur et lumière du jour qui s'atténue au fond d'une pièce.

Ces effets sont ce que l'industrie appelle l'illumination globale, et le lancer de rayons classique seul ne la calcule pas. Les moteurs de production l'ont longtemps gérée avec des systèmes supplémentaires comme les caches d'irradiance, les photon maps et le final gather, chacun avec ses propres réglages et ses propres artefacts.

Le path tracing, défini

Le path tracing a été introduit et nommé par Jim Kajiya dans son article de 1986 sur l'équation du rendu, d'après l'article de Wikipedia sur le path tracing (consulté le 19 octobre 2026). Il estime cette équation par échantillonnage aléatoire.

Un rayon quitte la caméra à travers un pixel et touche une surface. Au lieu de se diviser en un ensemble fixe de rayons enfants, il choisit une seule nouvelle direction au hasard, pondérée par le matériau (un miroir l'envoie presque exactement dans une seule direction, un mur en plâtre mat peut l'envoyer presque n'importe où). Le rayon rebondit à nouveau, et encore, jusqu'à atteindre une lumière, quitter la scène ou atteindre une limite de rebonds. Cette chaîne unique de rebonds, sans ramification, est un trajet (path), et elle ramène une estimation de la quantité de lumière qui atteint le pixel par cet itinéraire.

Un seul trajet donne une mauvaise estimation ; mille trajets passant par le même pixel, moyennés, en donnent une bonne. C'est l'échantillonnage de Monte Carlo des trajets de lumière. Comme chaque trajet peut rebondir sur n'importe quoi, le path tracing calcule la lumière indirecte, les ombres douces, les reflets brillants, les caustiques (en principe) et le transfert de couleur comme un seul processus unifié, sans cache distinct pour chaque effet.

La contrepartie, c'est le bruit. Tant qu'un nombre suffisant de trajets n'a pas été moyenné, les pixels voisins ne s'accordent pas entre eux, et l'image paraît granuleuse. C'est cette contrepartie qui se retrouve sur votre facture de rendu.

La différence en un coup d'œil

Un raccourci utile : le lancer de rayons est l'outil (tirer un rayon et trouver ce qu'il touche), et le path tracing est une stratégie pour utiliser cet outil afin de résoudre tout le problème d'éclairage. Tout path tracer moderne repose sur le lancer de rayons. Tous les moteurs de lancer de rayons ne sont pas des path tracers.

Pourquoi le path tracing produit du bruit, et pourquoi le nettoyer coûte cher

Le bruit d'une image rendue en path tracing n'est pas un bug : chaque pixel est la moyenne d'échantillons aléatoires, et cette moyenne fluctue tant qu'ils ne sont pas assez nombreux. L'article de Wikipedia sur l'intégration de Monte Carlo (consulté le 19 octobre 2026) indique que l'erreur de l'estimation décroît en 1/√N, où N est le nombre d'échantillons. En termes de rendu : pour diviser par deux le bruit visible, il faut environ quatre fois plus d'échantillons par pixel. Pour le diviser encore par deux, il en faut seize fois plus que le nombre initial. Si le temps de rendu évolue à peu près comme le nombre d'échantillons, ce qui est le cas pour la majeure partie de l'image, éliminer les derniers grains est la partie la plus coûteuse de l'ensemble du rendu.

Quatre vignettes de bruit à 16, 64, 256 et 1 024 échantillons par pixel, montrant que le bruit visible est divisé par deux à chaque multiplication par quatre du nombre d'échantillons

Certaines scènes sont plus difficiles que d'autres, pour des raisons prévisibles :

• Sources lumineuses petites ou cachées. Quand la lumière du jour passe par une fente étroite, peu de trajets aléatoires trouvent la lumière, donc l'estimation converge lentement.
• Matériaux brillants et réfractifs. Le métal brossé, le verre dépoli et les liquides sont difficiles à échantillonner efficacement.
• Nombreux rebonds. Les intérieurs aux murs blancs reposent sur plusieurs rebonds ; réduire la limite accélère le rendu mais assombrit les angles.
• Volumes et diffusion sous-surfacique. La fumée, le brouillard et la peau ajoutent de la diffusion à l'intérieur du matériau, ce qui multiplie le travail par trajet.
• Flou de mouvement et profondeur de champ. Chaque échantillon choisit aussi un instant dans le temps et un point sur l'objectif, donc il faut davantage d'échantillons.

La résolution fixe le nombre de pixels qui doivent recevoir une réponse ; l'éclairage décide du nombre d'échantillons dont chaque pixel a besoin avant que sa réponse soit propre.

Comment les moteurs de production utilisent le path tracing aujourd'hui

La plupart des moteurs de rendu de production offline sont désormais construits autour du path tracing, mais pas tous de la même manière. La distinction utile oppose le path tracing de chaque rebond au path tracing du premier rebond, avec un cache pour le reste.

Arnold. La documentation d'Arnold d'Autodesk (consultée le 19 octobre 2026) le décrit comme un moteur de ray/path tracing Monte Carlo non biaisé et physiquement réaliste, et précise qu'il évite les algorithmes de cache tels que le photon mapping et le final gather. La qualité se règle surtout par le nombre d'échantillons : une image plus propre demande plus d'échantillons, et plus d'échantillons demandent plus de temps.

Cycles. Cycles, le moteur de Blender, est un path tracer, et ses réglages d'échantillonnage (manuel de Blender 5.2 LTS, consulté le 19 octobre 2026) montrent bien la boîte à outils moderne : un nombre maximal de trajets tracés par pixel, un seuil de bruit qui arrête l'échantillonnage des zones dès qu'elles sont assez propres (échantillonnage adaptatif), une limite de temps facultative et un choix de débruiteurs.

Karma. La documentation de Karma de SideFX (documentation de Houdini 22.0, consultée le 19 octobre 2026) le présente comme le path tracer physiquement réaliste de Houdini.

V-Ray. Chaos répartit le travail entre un moteur d'illumination globale primaire et un moteur secondaire. Dans V-Ray GPU pour 3ds Max, la page GPU Global Illumination de Chaos (consultée le 19 octobre 2026) indique que le moteur primaire est toujours Brute Force (échantillonnage en path tracing pur du premier rebond), avec soit Brute Force, soit Light Cache pour les rebonds secondaires. Light Cache est une approximation précalculée des rebonds suivants, qui sacrifie un peu de précision pour économiser beaucoup d'échantillons.

Redshift. La documentation de Maxon sur l'illumination globale de Redshift (consultée le 19 octobre 2026) décrit Brute Force comme le moteur de GI le plus précis et le plus lent, bruité à faible nombre de rayons, et propose un Irradiance Point Cloud comme moteur secondaire qui rend le Brute Force primaire plus rapide et plus propre dans les éclairages difficiles, au prix d'un certain espace de stockage.

Ce dernier schéma, du path tracing pour le rebond que l'on voit le plus et un cache pour le reste, explique pourquoi les mots « biaisé » et « non biaisé » reviennent dans les discussions sur les moteurs de rendu. La moyenne d'un moteur non biaisé converge vers la réponse physiquement correcte à mesure que les échantillons augmentent. Un moteur biaisé accepte une petite différence systématique (due à un cache, à un écrêtage ou à une limite de rebonds) en échange d'une convergence bien plus rapide. Aucun des deux n'a tort. Pour l'animation, les caches demandent de l'attention, car un cache calculé image par image peut scintiller ; pour les images fixes, ils sont souvent la voie la plus directe vers une image propre.

Débruitage : moins d'échantillons, même échéance

Si diviser le bruit par deux coûte quatre fois plus d'échantillons, le raccourci évident est de s'arrêter plus tôt et de filtrer le bruit restant. C'est ce que font les débruiteurs modernes.

Les deux débruiteurs que la plupart des artistes rencontrent sont Intel Open Image Denoise et NVIDIA OptiX. Intel présente Open Image Denoise (consulté le 19 octobre 2026) comme une bibliothèque open source de filtres de débruitage pour les images rendues en lancer de rayons. La page d'échantillonnage de Cycles citée plus haut propose les deux comme options, précise qu'OptiX n'est disponible que sur les GPU NVIDIA, et indique que le réglage automatique privilégie Open Image Denoise par rapport à OptiX.

Les débruiteurs sont entraînés à distinguer le bruit d'échantillonnage du détail réel, mais ils ont des effets secondaires :

• Perte de détails fins. Les textures fines, les poils et la géométrie mince peuvent être lissés si trop peu d'échantillons ont été fournis.
• Scintillement temporel. Un débruiteur qui traite chaque image séparément peut produire des résultats légèrement différents d'une image à l'autre, ce qui se perçoit comme un scintillement en animation.
• Passes de compositing. Si vous débruitez la passe beauty mais pas les AOV (ou l'inverse), les passes ne s'additionnent plus proprement en compositing.

La règle pratique est de débruiter une image déjà raisonnablement convergée, pas une image qui n'est presque que du bruit. Un débruiteur réduit le nombre d'échantillons dont vous avez besoin. Il ne les remplace pas.

Ce que le path tracing implique pour le temps de rendu

Le temps de rendu d'un travail en path tracing est le produit de quelques nombres : le nombre d'images, les pixels par image, les échantillons par pixel, et la difficulté de chaque échantillon pour cette scène.

Un exemple hypothétique, à titre d'illustration uniquement. Un plan de dix secondes à 24 images par seconde représente 240 images. Supposons que chaque image demande 16 minutes sur une seule machine, au nombre d'échantillons qui la rend propre. Cela fait 64 heures-machine. Le client demande maintenant moins de grain dans les ombres. Si diviser le bruit par deux implique quatre fois plus d'échantillons, et que le temps évolue avec les échantillons, le même plan représente désormais environ 256 heures-machine. Un bon débruiteur peut en récupérer une grande partie, c'est pourquoi le nombre d'échantillons et le débruiteur se décident ensemble sur une image de test.

Calcul du temps de rendu d'un plan en path tracing : 240 images multipliées par 16 minutes par image donnent 64 heures-machine, et quatre fois plus d'échantillons pour diviser le bruit par deux donnent environ 256 heures-machine

Trois habitudes permettent de garder ce calcul sous contrôle :

1. Mesurez sur une image représentative. L'image la plus difficile du plan (celle qui comporte le plus de verre, de volume ou de flou de mouvement) est celle qu'il faut tester, pas la première.
2. Utilisez l'échantillonnage adaptatif et un seuil de bruit lorsque le moteur de rendu en propose un, afin que les zones propres, comme le ciel et les murs unis, cessent tôt d'être échantillonnées.
3. Dépensez les échantillons là où va le regard. Augmentez les échantillons pour les lumières ou les matériaux précis qui restent bruités, pas pour toute l'image.

La liste complète des réglages qui font varier le temps de rendu, des limites de rebonds à la taille des textures, se trouve dans notre guide d'optimisation du temps de rendu. Savoir si ces échantillons s'exécutent plus vite sur les processeurs ou sur les cartes graphiques dépend du moteur de rendu et de la scène, ce que traite rendu GPU vs rendu CPU.

Exécuter des travaux en path tracing sur une render farm

Chaque image d'une séquence en path tracing est rendue indépendamment : 240 images réparties sur de nombreuses machines se terminent donc dans le temps que prennent quelques images, alors que le calcul total, ce que facture une render farm, reste le même. Si le principe d'une render farm est nouveau pour vous, notre guide sur ce qu'est une render farm explique le modèle.

Sur Super Renders Farm, qui est une render farm entièrement gérée, vous envoyez la scène et la render farm s'occupe des logiciels et des licences de rendu : il n'y a ni session de bureau à distance, ni rien à installer. La plupart des travaux que nous voyons se rendent sur CPU (V-Ray et Corona sur 3ds Max, Arnold sur Maya, Cycles sur Blender, Karma et Mantra sur Houdini), ce qui s'exécute sur nos nœuds CPU.

Le path tracing GPU s'exécute sur nos nœuds GPU, chacun équipé de 2x NVIDIA RTX 5090 et de 32 Go de VRAM par carte. La mémoire est propre à chaque carte et n'est pas mutualisée entre les deux cartes : une image GPU doit donc tenir dans 32 Go. Redshift ne rend que sur les nœuds GPU. Redshift pour Cinema 4D, Maya et Houdini, ainsi que Cycles sur GPU, y tournent sans demande de configuration ; le matériel GPU et les moteurs pris en charge sont listés sur notre page de la GPU cloud render farm. Si une scène ne tient pas dans la mémoire d'une seule carte, un path tracer CPU est généralement la voie la plus sûre pour ce travail.

Les tarifs actuels figurent sur la page des tarifs ; nous avons volontairement laissé les chiffres hors de cette explication, car ils évoluent, et parce que le nombre d'échantillons que vous retenez influe davantage sur le coût final que n'importe quel tarif horaire. Les nouveaux comptes reçoivent 25 $ de Render Credits gratuits, que vous pouvez dépenser sur une image de test représentative avant de lancer une séquence, et notre équipe d'assistance est disponible 24/7 par chat en direct.

Idées reçues courantes

« Le path tracing et le lancer de rayons sont des technologies concurrentes. » Ils ne le sont pas. Le path tracing est une méthode construite sur le lancer de rayons. Un moteur de production décrit aujourd'hui comme un moteur de lancer de rayons est généralement un path tracer en dessous.

« Plus d'échantillons donne toujours une meilleure image. » Au-delà du point où le bruit est invisible à la résolution de livraison, des échantillons supplémentaires n'ajoutent que du temps de rendu. C'est ce point que l'échantillonnage adaptatif et les seuils de bruit sont conçus pour trouver.

« Biaisé veut dire faux. » Les techniques biaisées, comme les caches, convergent plus tôt et sont courantes en production. Le bon choix dépend du plan, en particulier selon qu'il s'agit d'une image fixe ou d'une animation.

« Le path tracing GPU est toujours plus rapide. » Il l'est souvent par image, mais seulement si la scène tient dans la mémoire de la carte et si le moteur de rendu prend en charge toutes les fonctions utilisées par la scène. Les grandes scènes de visualisation architecturale et les volumes lourds se rendent souvent de façon plus fiable sur CPU.

FAQ

Q: Quelle est la différence entre le lancer de rayons et le path tracing ? A: Le lancer de rayons classique suit un ensemble fixe de rayons à partir de chaque point d'impact (vers les lumières, dans la direction du miroir et à travers les surfaces transparentes) et produit un résultat déterministe, sans bruit, mais sans lumière indirecte. Le path tracing suit de nombreux trajets de rebonds aléatoires par pixel et en fait la moyenne, ce qui calcule naturellement la lumière indirecte, les ombres douces et le transfert de couleur, mais produit du bruit tant qu'assez d'échantillons n'ont pas été moyennés.

Q: Qu'est-ce que le path tracing, en termes simples ? A: Le path tracing envoie un rayon depuis la caméra dans la scène et le laisse rebondir dans une direction aléatoire sur chaque surface jusqu'à ce qu'il trouve de la lumière, puis répète l'opération de nombreuses fois par pixel et fait la moyenne des résultats. Il a été introduit par Jim Kajiya dans son article de 1986 sur l'équation du rendu et constitue la base de la plupart des moteurs de rendu de production offline actuels.

Q: Le path tracing est-il un type de lancer de rayons ? A: Oui. Le path tracing utilise le lancer de rayons pour trouver ce que touche chaque rayon, puis applique l'échantillonnage de Monte Carlo pour décider où part le rayon suivant. Tout path tracer est un moteur de lancer de rayons, mais tout moteur de lancer de rayons n'est pas un path tracer.

Q: Pourquoi les rendus en path tracing sont-ils bruités ? A: Chaque pixel est la moyenne d'échantillons aléatoires, et cette moyenne reste incertaine tant qu'ils ne sont pas assez nombreux. L'erreur diminue proportionnellement à un sur la racine carrée du nombre d'échantillons : diviser le bruit par deux demande donc environ quatre fois plus d'échantillons et, pour la plupart des scènes, environ quatre fois plus de temps de rendu.

Q: V-Ray, Arnold, Cycles et Redshift utilisent-ils le path tracing ? A: Oui, de façons différentes. Arnold, Cycles et Karma sont des path tracers qui règlent la qualité principalement par les échantillons. V-Ray et Redshift proposent un moteur Brute Force qui trace en path tracing le premier rebond et peut être associé à un cache pour les rebonds suivants (Light Cache dans V-Ray, l'Irradiance Point Cloud dans Redshift), ce qui converge plus tôt au prix d'un léger biais.

Q: Le débruitage remplace-t-il un nombre d'échantillons plus élevé ? A: Pas entièrement. Les débruiteurs comme Intel Open Image Denoise et NVIDIA OptiX permettent de s'arrêter à moins d'échantillons, mais ils sont plus efficaces sur des images déjà raisonnablement propres. Trop peu d'échantillons peut coûter des détails fins sur les images fixes et provoquer du scintillement en animation.

Q: Le path tracing est-il plus rapide sur GPU ou sur CPU ? A: Cela dépend du moteur de rendu et de la scène. Le path tracing GPU est souvent plus rapide par image lorsque la scène tient dans la mémoire de la carte, tandis que le path tracing CPU gère les très grandes scènes, les volumes lourds et les fonctions qu'un moteur GPU ne prend pas en charge. Sur notre render farm, les nœuds GPU embarquent 2x RTX 5090 avec 32 Go par carte, sans mutualisation entre les cartes.

Q: Une render farm peut-elle accélérer le path tracing ? A: Une render farm ne réduit pas le calcul dont une image a besoin, mais elle rend de nombreuses images en même temps, de sorte qu'une séquence se termine en une fraction du temps réel écoulé. C'est le temps machine total, qui dépend fortement du nombre d'échantillons choisi, qui détermine le coût.