Ray Tracing vs Path Tracing: What Is the Difference in 3D Rendering?

Introduction

Ray tracing vs path tracing is not a contest between two rival techniques: path tracing is a kind of ray tracing. Classic ray tracing follows a small, fixed set of rays (to mirrors, through glass, towards each light), while path tracing follows many random bounce paths per pixel and averages them, which is why it captures soft indirect light so convincingly and why it costs so much more compute.

That cost is what matters in production. When a frame takes 40 minutes instead of 4, or comes back speckled with noise, the cause is usually the path tracing: how many samples it takes, how many bounces it follows, and how the leftover noise is cleaned up. This guide explains both ideas, shows how Arnold, Cycles, Karma, V-Ray and Redshift apply them, and what that means for render time.

It deliberately stays on offline, frame-by-frame rendering for film, animation, visualization and product work. How games brought ray tracing to real-time graphics is covered in our history of real-time ray tracing in games, and the wider split between interactive and final-frame rendering is in real-time vs offline rendering. If you want the basics of what a renderer does before going further, start with what rendering is.

Side-by-side diagram: classic ray tracing sends one camera ray that splits into fixed reflection, refraction and shadow rays, while path tracing sends many random bounce paths per pixel and averages them

Ray Tracing, Defined

Ray tracing simulates light by working backwards: instead of following light from a lamp until it happens to reach a camera, the renderer shoots a ray from the camera through each pixel and asks what it hits. The idea is old. Wikipedia's article on ray tracing in computer graphics (read 19 October 2026) credits Arthur Appel with the first published use in 1968, a non-recursive method now usually called ray casting.

The version most people mean by "ray tracing" came from Turner Whitted, whose recursive algorithm was presented at SIGGRAPH in 1979 and published in 1980. When a camera ray hits a surface, the renderer spawns new rays in specific, predictable directions:

• a shadow ray towards each light, to test whether something blocks it,
• a reflection ray in the mirror direction, if the surface is reflective,
• a refraction ray through the surface, if it is transparent.

Each of those can spawn its own rays, building a branching tree that stops at a set depth. The result is deterministic, good at sharp reflections, clean refraction and hard shadows, and poor at anything that depends on light arriving from many directions at once: soft shadows, glossy blur, colour bleeding and daylight falling off into the back of a room.

Those effects are what the industry calls global illumination, and classic ray tracing on its own does not compute it. Production renderers long handled it with extra systems such as irradiance caches, photon maps and final gather, each with its own settings and artefacts.

Path Tracing, Defined

Path tracing was introduced and named by Jim Kajiya in his 1986 paper on the rendering equation, according to Wikipedia's path tracing article (read 19 October 2026). It estimates that equation by random sampling.

A ray leaves the camera through a pixel and hits a surface. Instead of splitting into a fixed set of child rays, it picks one new direction at random, weighted by the material (a mirror sends it almost exactly one way, a matte plaster wall can send it almost anywhere). The ray bounces again, and again, until it reaches a light, leaves the scene, or hits a bounce limit. That single, unbranching chain of bounces is one path, and it carries back one estimate of how much light reaches the pixel along that route.

One path is a poor estimate; a thousand paths through the same pixel, averaged, are a good one. That is Monte Carlo sampling of light paths. Because every path can bounce off anything, path tracing computes indirect light, soft shadows, glossy reflections, caustics (in principle) and colour bleeding as one unified process, without a separate cache for each effect.

The trade-off is noise. Until enough paths have been averaged, neighbouring pixels disagree with each other, and the image looks grainy. That trade-off is the part that shows up on your render bill.

The Difference at a Glance

A useful shorthand: ray tracing is the tool (shooting a ray and finding what it hits), and path tracing is one strategy for using that tool to solve the full lighting problem. Every modern path tracer is built on ray tracing. Not every ray tracer is a path tracer.

Why Path Tracing Produces Noise, and Why Cleaning It Up Is Expensive

The noise in a path-traced image is not a bug: each pixel is an average of random samples, and that average wobbles until there are enough of them. Wikipedia's article on Monte Carlo integration (read 19 October 2026) gives the error of the estimate as decreasing with 1/√N, where N is the number of samples. In rendering terms: to halve the visible noise, you need roughly four times as many samples per pixel. To halve it again, sixteen times the original. If render time scales roughly with sample count, which it does for most of the frame, cleaning up the last bit of grain is the most expensive part of the whole render.

Four noise tiles at 16, 64, 256 and 1,024 samples per pixel, showing visible noise halving with each four-fold increase in samples

Some scenes are harder than others, and the reasons are predictable:

• Small or hidden light sources. Daylight through a narrow gap means few random paths ever find the light, so the estimate converges slowly.
• Glossy and refractive materials. Brushed metal, frosted glass and liquids are hard to sample efficiently.
• Many bounces. White-walled interiors rely on several bounces; cutting the limit speeds things up but darkens corners.
• Volumes and subsurface scattering. Smoke, fog and skin add scattering inside the material, multiplying the work per path.
• Motion blur and depth of field. Each sample also picks a moment in time and a point on the lens, so more samples are needed.

Resolution sets how many pixels need answers; the lighting decides how many samples each pixel needs before its answer is clean.

How Production Renderers Use Path Tracing Today

Most offline production renderers are now built around path tracing, but not all in the same way. The useful distinction is between path tracing every bounce and path tracing the first bounce with a cache for the rest.

Arnold. Autodesk's Arnold documentation (read 19 October 2026) describes it as an unbiased, physically based Monte Carlo ray/path tracing engine, and states that it avoids caching algorithms such as photon mapping and final gather. Quality is controlled mostly through sample counts: a cleaner frame takes more samples, and more samples take more time.

Cycles. Blender's Cycles is a path tracer, and its sampling settings (Blender 5.2 LTS manual, read 19 October 2026) show the modern toolkit clearly: a maximum number of paths traced per pixel, a noise threshold that stops sampling regions once they are clean enough (adaptive sampling), an optional time limit, and a choice of denoisers.

Karma. SideFX's own Karma documentation (Houdini 22.0 docs, read 19 October 2026) calls it Houdini's physically based path tracer.

V-Ray. Chaos splits the job into a primary and a secondary global illumination engine. In V-Ray GPU for 3ds Max, Chaos's GPU Global Illumination page (read 19 October 2026) states that the primary engine is always Brute Force (pure path-traced sampling of the first bounce), with either Brute Force or Light Cache for the secondary bounces. Light Cache is a pre-computed approximation of later bounces, which trades a little accuracy for a large saving in samples.

Redshift. Maxon's Redshift global illumination documentation (read 19 October 2026) describes Brute Force as the most accurate and slowest GI engine, noisy at low ray counts, and offers an Irradiance Point Cloud as a secondary engine that makes primary Brute Force faster and cleaner in difficult lighting, at the cost of some storage.

That last pattern, path tracing for the bounce you see most and a cache for the rest, is why the words "biased" and "unbiased" turn up in renderer discussions. An unbiased renderer's average converges on the physically correct answer as samples increase. A biased one accepts a small, systematic difference (from a cache, a clamp or a bounce limit) in exchange for converging much sooner. Neither is wrong. For animation, caches need care, because a cache computed per frame can flicker; for stills, they are often the quickest way to a clean image.

Denoising: Fewer Samples, Same Deadline

If halving noise costs four times the samples, the obvious shortcut is to stop earlier and filter out the remaining noise. That is what modern denoisers do.

The two denoisers most artists meet are Intel Open Image Denoise and NVIDIA OptiX. Intel describes Open Image Denoise (read 19 October 2026) as an open source library of denoising filters for images rendered with ray tracing. The Cycles sampling page cited above lists both as options, notes that OptiX is available only on NVIDIA GPUs, and describes the automatic setting as preferring Open Image Denoise over OptiX.

Denoisers are trained to tell sampling noise from real detail, but they have side effects:

• Lost fine detail. Fine textures, hair and thin geometry can be smoothed away if too few samples went in.
• Temporal flicker. A denoiser that works on each frame separately can produce slightly different results on consecutive frames, which reads as shimmer in animation.
• Compositing passes. If you denoise the beauty pass but not the AOVs (or the other way round), the passes stop adding up cleanly in compositing.

The practical rule is to denoise a frame that is already reasonably converged, not one that is mostly noise. A denoiser reduces the number of samples you need. It does not replace them.

What Path Tracing Means for Render Time

Render time for a path-traced job is a product of a few numbers: frames, pixels per frame, samples per pixel, and how hard each sample is for that scene.

A hypothetical example, for illustration only. A ten-second shot at 24 frames per second is 240 frames. Suppose each frame needs 16 minutes on one machine at the sample count that makes it clean. That is 64 machine-hours. Now the client asks for less grain in the shadows. If halving the noise means four times the samples, and time scales with samples, the same shot is now around 256 machine-hours. A good denoiser can claw much of that back, which is why sample count and denoiser are decided together on a test frame.

Render time arithmetic for a path-traced shot: 240 frames times 16 minutes per frame equals 64 machine-hours, and four times the samples to halve noise gives about 256 machine-hours

Three habits keep that arithmetic under control:

1. Measure on a representative frame. The hardest frame in the shot (the one with the most glass, volume or motion blur) is the one to test, not the first.
2. Use adaptive sampling and a noise threshold where the renderer offers one, so clean areas such as sky and flat walls stop sampling early.
3. Spend samples where the eye goes. Raise samples for the specific lights or materials that stay noisy, not for the whole frame.

The full list of settings that move render time, from bounce limits to texture sizes, is in our render time optimization guide. Whether those samples run faster on processors or graphics cards depends on the renderer and the scene, which is covered in GPU rendering vs CPU rendering.

Running Path-Traced Jobs on a Render Farm

Every frame of a path-traced sequence renders independently, so 240 frames spread across many machines finish in the time of a few, while the total compute, which is what a farm bills for, stays the same. If the idea of a farm is new, our guide to what a render farm is explains the model.

On Super Renders Farm, which is a fully managed farm, you upload the scene and the farm handles the software and render licences, so there is no remote desktop session and nothing to install. Most of the work we see renders on CPU (V-Ray and Corona on 3ds Max, Arnold on Maya, Cycles on Blender, Karma and Mantra on Houdini), which runs on our CPU nodes.

GPU path tracing runs on our GPU nodes, each with 2x NVIDIA RTX 5090 cards and 32 GB of VRAM per card. Memory is per card and is not pooled across the two cards, so a GPU frame has to fit in 32 GB. Redshift renders on GPU nodes only. Redshift for Cinema 4D, Maya and Houdini, and Cycles on GPU, run there without a setup request; the GPU hardware and supported engines are listed on our GPU cloud render farm page. If a scene does not fit in one card's memory, a CPU path tracer is usually the safer route for that job.

Current rates are on the pricing page; we have kept numbers out of this explainer because they change, and because the sample count you settle on moves the final cost more than any hourly figure. New accounts receive $25 free render credits, which you can spend on a representative test frame before committing a sequence, and our support team is on 24/7 live chat.

Common Misunderstandings

"Path tracing and ray tracing are competing technologies." They are not. Path tracing is a method built on ray tracing. A production renderer described as a ray tracer today is usually a path tracer underneath.

"More samples always means a better image." Past the point where noise is invisible at the delivery resolution, extra samples only add render time. That point is what adaptive sampling and noise thresholds are designed to find.

"Biased means wrong." Biased techniques such as caches converge sooner and are routine in production. The right choice depends on the shot, especially on whether it is a still or an animation.

"GPU path tracing is always quicker." It is often quicker per frame, but only if the scene fits in the card's memory and the renderer supports every feature the scene uses. Large archviz scenes and heavy volumes frequently render more reliably on CPU.

FAQ

Q: What is the difference between ray tracing and path tracing? A: Classic ray tracing follows a fixed set of rays from each hit point (towards lights, in the mirror direction and through transparent surfaces) and produces a deterministic, noise-free result without indirect light. Path tracing follows many random bounce paths per pixel and averages them, which computes indirect light, soft shadows and colour bleeding naturally but produces noise until enough samples have been averaged.

Q: What is path tracing in simple terms? A: Path tracing sends a ray from the camera into the scene and lets it bounce in a random direction at every surface until it finds light, then repeats that many times per pixel and averages the results. It was introduced by Jim Kajiya in his 1986 paper on the rendering equation and is the basis of most offline production renderers today.

Q: Is path tracing a type of ray tracing? A: Yes. Path tracing uses ray tracing to find what each ray hits, then applies Monte Carlo sampling to decide where the next ray goes. Every path tracer is a ray tracer, but not every ray tracer is a path tracer.

Q: Why are path-traced renders noisy? A: Each pixel is an average of random samples, and that average is uncertain until there are enough of them. The error falls in proportion to one over the square root of the sample count, so halving the noise takes roughly four times the samples and, for most scenes, roughly four times the render time.

Q: Do V-Ray, Arnold, Cycles and Redshift use path tracing? A: Yes, in different ways. Arnold, Cycles and Karma are path tracers that control quality mainly through samples. V-Ray and Redshift offer a Brute Force engine that path traces the first bounce and can pair it with a cache for later bounces (Light Cache in V-Ray, the Irradiance Point Cloud in Redshift), which converges sooner at the cost of a small bias.

Q: Does denoising replace higher sample counts? A: Not entirely. Denoisers such as Intel Open Image Denoise and NVIDIA OptiX let you stop at fewer samples, but they are most effective on frames that are already reasonably clean. Too few samples can cost fine detail in stills and cause flicker in animation.

Q: Is path tracing faster on GPU or CPU? A: It depends on the renderer and the scene. GPU path tracing is often quicker per frame when the scene fits in the card's memory, while CPU path tracing handles very large scenes, heavy volumes and features a GPU engine does not support. On our farm, GPU nodes carry 2x RTX 5090 with 32 GB per card, not pooled across cards.

Q: Can a render farm speed up path tracing? A: A farm does not reduce the compute a frame needs, but it renders many frames at the same time, so a sequence finishes in a fraction of the wall-clock time. The total machine time, which depends heavily on the sample count you choose, is what determines the cost.