#graphics #raytracing #pathtracer #principled #bsdf


A principled BSDF pathtracer with an abstracted backend. Perfect for rendering procedural content.

2 releases

Uses new Rust 2021

0.1.1 Nov 23, 2022
0.1.0 Nov 22, 2022

#150 in Graphics APIs

Download history 50/week @ 2022-11-19 6/week @ 2022-11-26

56 downloads per month

MIT license

769 lines

This is a port of the excellent GLSL_Pathtracer to Rust utilizing an abstracted, trait based backend. Perfect for rendering procedural content.

Rust Features

  • Multi threaded using rayon.
  • An abstracted backend via a scene description trait. Implement hit tests, lights and materials for your procedural content.
  • The pathtracer can be compiled to either f32 or f64. See the defines in the libs.rs. Default is f64 for now.


  • Support of mediums / volumetric objects.
  • Implement a denoiser.
  • Emitters are untested right now.
  • Only spherical analytical lights right now.
  • Implement a SDF based example scene.
  • Implement a mesh based example scene. PRs welcome.
  • Enhance the example renderer app with more options.
  • More testing.

How to use

// Create a color buffer
let mut buffer = ColorBuffer::new(800, 600);

// Create a scene and pass it to the path-tracer
let scene = Box::new(AnalyticalScene::new());
let mut pt = Tracer::new(scene);

// Render and accumulate one frame, repeat

You can copy the color buffer into an Vec<u8> by calling buffer.convert_to_u8(frame); or you can access the float pixels directly by accessing buffer.pixels.


Scenes contain objects, lights, the background and material definitions.

The scene trait is pretty small right now.

pub trait Scene : Sync + Send {

    fn new() -> Self where Self: Sized;

    /// Background color for the given ray
    fn background(&self, ray: &Ray) -> PTF3;

    /// Closest hit should return the state.hit_dist, state.normal and fill out the state.material as needed
    fn closest_hit(&self, ray: &Ray, state: &mut State, light: &mut LightSampleRec) -> bool;

    /// Used for shadow rays.
    fn any_hit(&self, ray: &Ray, max_dist: PTF) -> bool;

    /// Return the camera for the scene
    fn camera(&self) -> &Box<dyn Camera3D>;

    /// Return the number of lights in the scene
    fn number_of_lights(&self) -> usize;

    /// Return a reference for the light at the given index
    fn light_at(&self, index: usize) -> &AnalyticalLight;

The analytical example scene which creates the above screenshot can be found inside the renderer here.


The repository contains an example renderer which displays the ongoing rendering process. You can easily run it with cargo run --release. The renderer will be enhanced with additional features soon (write images to disk, display a frame counter etc).

CPU vs GPU: Motivation

I prefer to render SDFs on the CPU. Of course the GPU is faster and there are many great Shadertoy demos, however when the SDF complexity of a scene is user defined and you do not know the OS or GPU of the user, one of these things can happen:

  • Shaders take seconds to compile and depending on the platform can freeze your app while doing so.
  • Shaders can run so slow that they make your app hard to use.
  • In the worst case shaders can crash.

The CPU renders slower but does not need to compile shaders and render tasks can be nicely handled in the background without affecting the overall performance of the app.


~91K SLoC