> ## Content Index
> Fetch the complete content index at: https://contextualguides.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Rendering Overview
- URL: https://contextualguides.com/rendering-overview/
- Published: 2026-08-30T23:54:06.000Z
- Updated: 2026-09-05T16:30:35.000Z
- Description: An overview of how OctaneRender actually renders
- Author: Scott Benson
- Tags: rendering, tutorial, path-tracing, #octane-guides, #beginner, #series-Octane Overview, #site-content, #pinned

## About This Guide

This is part of a conceptual, DCC-agnostic series on how OctaneRender works. This guide explores the "render" part of OctaneRender.

### PDF

This guide is also available in [📄 PDF format here](https://contextualguides.com/content/files/2026/08/rendering-overview.pdf)

## Intro and Overview

Rendering in the 3D world is taking all the objects, lights, materials, and settings, and running them through a set of light calculations in order to produce a pixel-based image that we can display on our screens.

All the way back in the first guide in this series, this statement was made:

> "OctaneRender is a spectral, (mostly) unbiased, physically-based path tracer."

All of these concepts were chosen to produce the most realistic renders possible within the limits of the hardware available. Let's unpack it:

## Path Tracer

There are several rendering methods in the 3D world, but the one that's known as "path tracing" yields the most realistic results. 

![OG066 101 Path Tracing](https://storage.ghost.io/c/e9/6d/e96d8ca7-ad24-4dc4-b744-c7db76c18621/content/images/2026/08/OG066-101-Path-Tracing.jpg)In the real world, light rays are emitted from all the light sources around us (the sun, lamps, bioluminescent mushrooms, etc). These rays bounce around all the objects in our environment, and some of them make their way to our photosensitive eyes which process them and send them to our brains to register as an image. This happens a lot of times in a row, and all those images allow us to register motion so we can react accordingly, interact with things and try not to die.

This is very inefficient. Whoever or whatever is responsible for setting up this system is constantly wasting a massive amount of energy blasting out these rays in all directions from light sources all over the universe, most of which never reach our eyes. 

We can do better.

Path tracing reverses this system. Rather than starting at the light sources, it fires rays out of *the camera* into the scene which **trace** the **paths** that light rays would have taken back to the source. This means it only has to deal with rays that would have hit the camera, rather than waste processing power on the lazy slacker rays that can't even be bothered to show up to contribute to our image.

OctaneRender still has to calculate *a lot* of these rays to start resolving an image (which is why we have powerful hardware to do just this), but at least it's not near-infinite amounts of calculations like reality which must have trust fund money to throw at its server farms to be that wasteful.

## Mostly Unbiased

![OG066 102 Biased](https://storage.ghost.io/c/e9/6d/e96d8ca7-ad24-4dc4-b744-c7db76c18621/content/images/2026/08/OG066-102-Biased.jpg)

"Unbiased" in the render engine world means that it doesn't take shortcuts when doing physical calculations. Each and every light ray calculation will eventually produce the correct result, *given enough time and resources thrown at it.*

The main advantage to this is that we don't have to fiddle with too many knobs and switches to get realistic results. This allows us to spend more time iterating on the artistic intent of the render rather than dinking around with adding stuff back in until it looks good enough.

The disadvantage? Well, reality might have time and resources to burn, but we have other things to do and weren't gifted with a massive, free server farm just for us (unfair), so we can't aim for perfection. That's where the "mostly" comes in.

We have controls exposed to add some bias and trade a little accuracy of the calculations for a lot of speed, and that's what a large part of optimizing the settings is all about (once we get past the hard part of not feeding it trash values).

## Spectral

This one's a little tricky to understand without spending six months deep-researching and writing four guides on color management (who would do [*that*?](https://contextualguides.com/og036-color-spaces-overview/)). The essence of it is this, though:

Most render engines do color calculations based on RGB values. This is the standard in the industry, and it produces fantastic results for non-photoreal images and really good results for photoreal ones.

![OG066 103 Spectral](https://storage.ghost.io/c/e9/6d/e96d8ca7-ad24-4dc4-b744-c7db76c18621/content/images/2026/08/OG066-103-Spectral.jpg)

That wasn't good enough for the fine folks at Otoy though. Realism's the goal, they've already committed to an unbiased engine, so why not go all-in and work the way real light does? Visible light doesn't intrinsically have red, green, and blue values, that's the cones in our eyes interpreting it that way. It works on wavelengths across a radiation spectrum.

This is what "spectral" means in this case. It's not some spooky ghost floating around, it's not some shimmery rainbow effect, it just means that OctaneRender's internal calculations are based on wavelengths across the visible light spectrum.

Using spectral data to do the actual calculations is a lot of Octane's secret sauce and why it looks so good out of the box. The rest of the computer graphics world doesn't work like this though, so OctaneRender has to take RGB values from picked colors and images, convert them to spectral data, do the calcs, and then convert the result back to RGB in the right format to hand off to other systems.

## Physically-based

- The mechanism itself - the path tracer - is rooted in real-world physics.
- The spectral data it uses for the calculations is based on the physics of light.
- The mostly unbiased part is physically correct.

So OctaneRender can be said to be *physically-based*. 

The framework is all there to work with realistic values, so it's on us to provide them. That's why Tenet #1 is Tenet #1\. If we give OctaneRender realistic (or at least plausible) values, it will produce realistic results. If we stray too far from this, we have ourselves a little problem, because it's less forgiving than other engines.

That said, once we know what we're doing, we can break it on purpose and get some really fun and artistic effects, but we should really learn how to drive it on an open highway before taking it out on an icy mountain road to do some drifting.

## Kernels

Stripped down to its core, the main chunk of code that a render engine like OctaneRender uses to do these calculations is called a "kernel." Some engines gloss over this term, but OctaneRender keeps it front and center. Octane currently has five kernels to pick from (four that affect how the render looks, and info channels which is extra utility data that's way out of scope for this guide). They all work on similar principles with the same lights, materials, and values, but some introduce more bias than others.

**PMC** is a beast. It's heavy, slow, and fiddly, but it produces the closest thing to an ideal a realistic render engine can strive for, assuming you have a ton of time to give it. Its superpower (and kryptonite) is unbiased caustics calculations. That's what makes the output look so good and take so long. This means we have to think long and hard about whether it's worth the hit in speed to get that particular result. 

**Path Tracing (PT)** is the daily driver. It strikes the best balance between speed and accuracy and is suitable for most renders. Its shortcoming is that it's not great at caustics, but most of the time that's ok and worth the tradeoff for the large speed boost.

**Photon Tracing** is a middle ground between Path Tracing and PMC. It has all the great unbiased *non-caustics* calcs of Path Tracing, but adds on a layer of biased caustics on top so it gets closer to the true beauty of PMC without having to spend hours waiting for it. 

**Direct Light (DL)** is a stripped-down, more biased, quick and dirty kernel. It's built for raw speed. DL is essentially Path Tracing without all the high-falootin' fancy expensive calculations. It's great for non-photoreal scenes and really fast lookdev. It's capable of giving us some decently realistic results if we push it (and the scene is set up just so), but at that point we may as well switch over to PT.

![OG066 104 Kernels Glass](https://storage.ghost.io/c/e9/6d/e96d8ca7-ad24-4dc4-b744-c7db76c18621/content/images/2026/08/OG066-104-Kernels-Glass.jpg)In the example above, we can see that Direct Light provides no caustics at all. Path Tracing has substandard caustics. Photons Tracing has better caustics, and was far faster to resolve this scene than either Path Tracing (2x faster) or PMC (20x faster). The tradeoff is quality, though - PMC's glass looks a bit better and the caustics are more realistic. As a single, still image, it may be worth the 19 extra minutes it took to render using PMC, but if multiple frames are involved, it's probably not.

![OG066 105 Kernels Wood](https://storage.ghost.io/c/e9/6d/e96d8ca7-ad24-4dc4-b744-c7db76c18621/content/images/2026/08/OG066-105-Kernels-Wood.jpg)When we move to wood which doesn't have much in the way of caustics, the story is very different. With this material, Path Tracing actually resolved a little faster than Photon Tracing by a few seconds, and far faster than PMC (5x). There's almost no visual difference between these three, so Path Tracing would be the way to go here.

## Wrap Up

Now we finally know what all the jargon means in the description of the engine, what it's tuned for, and how to treat it right so it treats us right. Next up is a topic that makes even the most experienced 3D artist quake with fear (or rage): The fun world of color management!