What Is Volumetric Rendering? Volume Shaders Explained, from Clouds to Explosions

Author: Arndt von Koenigsmarck · Technical review by Sergen Eren · Last reviewed August 2026

Most objects in computer graphics are empty shells. A rendered car, a character, even a mountain is usually just a thin surface wrapped around nothing, because for solid things the surface is all the camera ever sees. But nature is full of things that are not solid at all. Clouds, fog, smoke, fire, dust in a beam of light: you can see into them and through them, and light behaves differently at every point inside them. Rendering these phenomena is the job of volumetric rendering, and the tool that describes how they look is the volume shader. This article explains both, first the ideas and the physics, then the concrete practice inside Redshift, Maxon’s GPU accelerated render engine.

Volumetric rendering, also called volume rendering, is the technique of computing images from three dimensional grids of data instead of surfaces. Where a normal 3D model is defined by polygons that describe its outer shell, a volume is defined by voxels, tiny cells that fill a region of space, each storing values such as density or temperature. The renderer looks at what happens to light as it travels through all of those cells, which is why a volume can be wispy at its edge, dense at its core, and glowing in the middle, all at once.

The contrast with surface rendering is the easiest way to grasp it. When a ray of light hits a polygon surface, the renderer evaluates the material at exactly one point and is done. When a ray enters a volume, there is no single point to evaluate. The ray keeps traveling, and every stretch of the journey can absorb light, scatter light, or add light. A pixel is a colored square in a 2D image; a voxel is its 3D sibling, a value in a spatial grid. That one extra dimension is the entire story of volumetric rendering, including why it looks so good and why it costs so much. 

A volume shader is the material for things that occupy space. Instead of describing a surface, it tells the render engine how the medium at every point inside a volume interacts with light. Almost every modern engine builds this description from the same three ingredients, and Redshift’s documentation offers a memorable analogy to surface materials for each of them:

• Scattering is the volume’s counterpart to a diffuse color. It defines how much light bounces off the microscopic particles inside the medium and in which color, which is what makes clouds white and smoke grey.

• Absorption is the counterpart to transparency. It defines how much light the medium swallows, which is what makes thick smoke dark and dense volumes opaque.

• Emission is the counterpart to incandescence or self illumination. It lets the medium give off light of its own, which is what makes fire and explosions glow from within.

Every cloud, fog bank, or fireball you have seen in a film is some blend of these three behaviors, usually driven by data from a simulation. In Redshift this role is filled by the Standard Volume shader, a physically based volume material for clouds, smoke, fire, and explosions. One small disambiguation for anyone who arrived here from a search engine: there is also a well known GPU stress test called “Volume Shader BM” that borrows the term. That is a benchmark, not a material. This article is about the real thing. 

Physicists call fog, smoke, and clouds participating media, because the space itself participates in the lighting instead of leaving light alone until it hits a surface. As a ray travels through such a medium, four things can happen. Light can be absorbed and turned into heat. Light can be scattered out of the ray’s path, which dims the ray. Light can be scattered into the ray’s path from elsewhere, which brightens it. And the medium can emit new light itself. The combined dimming effect of absorption and out scattering is called extinction, and the fraction of light that survives a stretch of the journey is called transmittance. Volume shader parameters are, at heart, artist friendly handles on exactly these quantities.

One more concept does a surprising amount of work: the Phase Function, which is the volumetric equivalent of how a surface material distributes reflected light. It answers the question of which direction light continues after it scatters. Smoke particles scatter light roughly equally in all directions, which is called Isotropic Scattering. Water droplets in clouds overwhelmingly fling light forward, along its original direction of travel. This Forward Scattering is why a cloud between you and the sun has a brilliant silver lining, and why backlit fog glows. Render engines model this with the Henyey-Greenstein phase function, a classic that dates back to a 1941 astrophysics paper, using a single anisotropy value from minus one (Back Scattering) through zero (Isotropic Scattering) to plus one (Forward Scattering). For clouds specifically, Redshift additionally offers the newer Jendersie-d’Eon model, which approximates the true Mie scattering of water droplets and captures a more realistic forward peak than Henyey-Greenstein can. 

For readers who want to look under the hood, here is how Redshift’s developers themselves describe the Standard Volume shader. Internally it is a close relative of the Random Walk Subsurface Scattering in Redshift’s OpenPBR and Standard Surface materials. Subsurface Scattering simulates light wandering through a finite, uniform medium like skin or wax; the Standard Volume shader applies the same thinking to a heterogeneous medium whose density varies at every voxel. The parameters map onto each other almost one to one: the Subsurface Color corresponds to the Volume’s Scatter Color, the Subsurface Radius corresponds to the Transparency Color, and the Subsurface Scale corresponds to the Volume’s Depth control (see next figure).

During rendering, Redshift ray marches through the volume, sampling voxel by voxel as the ray traverses the medium. The density grid it samples is simply a scalar description of how many particles exist at each voxel versus empty space, independent of any color. The scatter color is the albedo of those suspended particles, the color of light they reflect back. The anisotropy controls send that scattered light forward, backward, or evenly in all directions, using Henyey-Greenstein by default or Jendersie-d’Eon for cloud like water media.

The transparency color is the most interesting part. It is an artist friendly encoding of the mean free path, the average distance each wavelength of light travels through the medium before being extinguished. The red, green, and blue values each represent the travel distance of their wavelength, and the Depth parameter multiplies these 0 to 1 values into real distances, measured in centimeters and aware of your scene scale. Because different wavelengths are absorbed at different rates, light that travels far enough through such a medium ends up tinted with the opposite of the transparency color, once the other wavelengths have been exhausted. This is exactly the physics that makes deep water blue, and it is why a subtle transparency tint gives volumes a natural, organic depth that a flat scatter color cannot. 

Marching through voxels answers how a renderer reads a volume, but the real cost lives in how often light changes direction inside it. If the engine simulates only one bounce, called single scattering, thin media like light haze look fine, but a dense cloud renders dark and lifeless. Real clouds are bright because photons bounce dozens or hundreds of times inside them before escaping; a thick cumulus cloud reflects up to 90 percent of the light that hits it. Simulating this multiple scattering means following each ray through many additional bounces, and every added bounce multiplies work. That is the honest reason volume rendering has a reputation for being slow, and it is also where GPU rendering and clever approximations, which Part 2 covers, earn their keep. Modern engines soften the cost further with denoising, although volumes are notoriously harder to denoise than surfaces, because the helper data that guides a denoiser, such as surface normals, simply does not exist inside a cloud. 

Volumes need a way to travel between the software that simulates them and the engine that renders them, and the industry settled this question years ago with OpenVDB. Originally developed at DreamWorks Animation, open sourced in 2012, honored with an Academy Award for technical achievement, and now maintained under the Academy Software Foundation, OpenVDB is the de facto standard for storing volumetric data. The Redshift documentation offers a perfect one line summary: “OpenVDB files are to volume rendering what EXR files are to HDR images.” Where an EXR stores pixels, a VDB stores voxels, and it stores them sparsely, so the vast empty space around a wispy smoke plume costs almost nothing on disk or in memory.

Inside a VDB file, voxel data is organized into named grids, which Redshift calls channels in shading contexts. The names are conventions rather than rules, but the usual suspects are density, a unitless value describing how many particles fill each voxel and therefore where the volume has substance, temperature for the heat that drives fire emission, velocity for motion blur, and occasionally a color grid for pre painted volumes. Channel names are case sensitive in Redshift, which has cost many artists a confused minute. Where do VDB files come from? Simulation tools such as Houdini, the real time fluid simulator EmberGen, and Cinema 4D’s built in Pyro system all export them, and there are excellent free sources for practicing, including the famous Walt Disney Animation Studios cloud data set and free VDB packs from JangaFX. 

Redshift splits volume rendering into a small set of tools, and knowing which one to reach for is half the workflow. Heterogeneous volumes, meaning anything with varying density such as clouds, smoke, fire, and explosions, are loaded through the Redshift Volume object, which reads a VDB file or an animated VDB sequence and shows a bounding box or a point cloud preview in the viewport. The look of that volume is then defined by the Standard Volume material. Homogeneous volumes, meaning uniform media such as atmospheric haze and fog, do not need voxel data at all: the Redshift Environment object fills the scene, or a height limited layer of it, with a scattering medium. This is also the tool for volumetric lighting, the beloved god rays that make light shafts visible in dusty air. Finally, a dedicated Clouds object generates entire procedural skies, with a fast mode that renders the cloud deck as a clever background and a fully volumetric mode in which a skyscraper or an aircraft can pierce the cloud layer and be lit by it. 

One practical constraint deserves a plain statement: volumes must fit entirely into GPU memory. They are the one asset class excluded from Redshift’s out of core system, so a gigantic VDB that exceeds available VRAM will abort the render rather than slow it down. Keeping simulations only as high resolution as the shot demands is not just a speed decision, it is a memory budget.

The Standard Volume material has two personalities. Used on its own, with grid names typed into its channel fields, it runs a specially optimized fast path and behaves like a classic, easy volume shader with well tuned presets for clouds, smoke, and flames. Used with input nodes attached, it becomes fully programmable, letting you drive density, color, and temperature with procedural noises, remap grids, and even displace voxels for extra detail. For a first session, the built in fields are all you need, and four groups of settings do most of the work:

• Volume channel and Density. The channel field names the VDB grid that defines the volume’s shape, almost always density. The Density parameter multiplies it and sets the overall thick or thin character of the medium. Type the grid name exactly; channels are case sensitive.

• Scatter. Color and Scale set what the volume reflects and how brightly. The Anisotropy Mode chooses the phase function: Henyey-Greenstein with its minus one to plus one slider is the all rounder and the right choice for isotropic smoke, while Jendersie-d’Eon is the cloud specialist that models light passing through water droplets.

• Transparency. The Transparency Color and Depth implement the per wavelength travel distances described in Part 1. Darker means thicker, brighter means thinner, and any color tints the volume with its opposite at depth, shadows included. Subtle saturation goes a long way here; set Depth in relation to the real world size of your volume, since it is measured in centimeters.

• Emission. For fire and explosions, point the emission channel at the temperature grid and choose Blackbody mode, which converts temperatures into physically correct colors and intensities on the Kelvin scale, from deep red around 3,000 K to white and blue white beyond 9,000 K. The alternative Color mode hands you a gradient instead, the classic black to red to yellow flame ramp, for art directed fire that ignores physics on purpose. 

Part 1 established that dense volumes come alive only with multiple scattering, and Redshift exposes this as a render setting called Volume Trace Depth, together with a requirement worth memorizing: volumetric multiple scattering works with Brute Force global illumination. Raising the trace depth from its default transforms a cloud from a grey mass into a luminous, believable object, at exponentially growing render cost. Forward scattering clouds benefit enormously from more depth; isotropic smoke shows diminishing returns much earlier; emissive fire gains beautiful internal light spill as its glow illuminates the smoke around it.

Redshift also offers three shortcuts that experienced artists reach for before cranking the trace depth. The first is Extinction Falloff, which approximates the effect of hundreds of additional bounces by gently reducing extinction with each real bounce. Its default value of 0.2 is a deliberate sweet spot, and in the documentation’s own cloud test it produced a brighter, more realistic result while rendering faster than the same scene without it. The second is Anisotropy Falloff, its natural companion, which lowers the anisotropy a little with every bounce so that deeper rays scatter more and more isotropically. This mimics a classic insight from radiative transfer known as van de Hulst’s similarity principle: in highly multiple scattering media, different combinations of scattering albedo and anisotropy produce a nearly indistinguishable appearance as long as the bulk transport properties stay the same. Since evaluating anisotropic scattering is expensive, relaxing it over the bounces both simulates high order scattering and makes the volume cheaper to render. The third is Shadow Density Scale, a classic cheat that lets light penetrate deeper into the volume without changing its silhouette, faking the brightening effect of multiscatter at a fraction of the cost. A well balanced volume usually combines a moderate trace depth with these helpers rather than brute forcing depth alone. 

If you work in Cinema 4D, you do not need external software to produce volume data, because the built in Pyro system simulates smoke, fire, and explosions natively. The workflow is pleasantly short. Any object with a Pyro Emitter tag starts producing a simulation, and the Pyro Output object collects its channels, typically density, temperature, and velocity (an introduction to Pyro simulations can be found here in the Cinema 4D documentation). From there you can render directly, or cache the simulation to a VDB sequence and load it back through a Redshift Volume object, which the documentation recommends as the memory friendly route for production. The shading side is almost automatic: the bundled Pyro Volume presets for the Redshift Standard Volume shader arrives with the density grid wired to scattering and the temperature grid wired to blackbody emission, which are precisely the two connections that turn raw simulation data into rendered smoke and fire. Motion Blur is the one step artists tend to forget. Because a VDB sequence is a series of frozen snapshots, Redshift reads motion from the velocity grid; enter velocity into the Volume object’s Velocity field and raise the Velocity Scale until the blur matches the energy of the simulation, and do not be shy, values far beyond 1,000 are normal.