# Ray Tracing in One Weekend: A Free C++ Book Series You Build a Renderer With

> The raytracing.github.io repository is the web home of a three-book C++ series that walks you from a blank file to a working path tracer. It is a teaching text with reference source, not a library, and the source is deliberately not the tutorial.

**RayTracing/raytracing.github.io** — Main Web Site (Online Books)

- Repository: https://github.com/RayTracing/raytracing.github.io
- Website: https://raytracing.github.io/
- Stars: 10,673 · Forks: 1,010
- Language: HTML
- License: CC0-1.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/raytracing-raytracing-github-io

## What Ray Tracing in One Weekend Is, and What It Refuses to Be

This repository is the online home of the Ray Tracing in One Weekend book series: three books, In One Weekend, The Next Week, and The Rest of Your Life, published free on the web and formatted for both screen and print. The README states the goal plainly: the books are available to the public for free directly from the web, and PRINTING.md covers printing your own copies or getting PDFs.

The intended reader is someone who wants to write a ray tracer, not someone who wants to call one. The README is explicit that the repository is not meant to act as its own tutorial, and that the source is provided so you can compare your work while progressing through the book. That single sentence defines the whole project. You are expected to type your own implementation, hit a wrong-colored sphere, and diff against the reference. If you clone src/ and build it, you get working binaries, but you skip the part the authors designed the series around.

The language choice is stated too: the book is written in C++ and uses some modern features of C++11, chosen for broad understandability rather than as a model of good C++. That is worth taking at face value. The code you write along the way is pedagogical, not a foundation to build a product on.

## How the Three Books Chain Together and Where the Reference Source Lives

The series is cumulative. In One Weekend gets a minimal renderer producing an image; The Next Week expands it with more materials and scene machinery; The Rest of Your Life goes into the math behind the sampling. Each book has its own corresponding source tree under src/, and the README notes that src/<book>/ contains the final source code for each book. Final is the operative word: these are end states, not chapter-by-chapter checkpoints.

The repository layout is small and flat by design. books/ holds the three books in HTML plus supporting material, images/ holds every figure and can be used to compare your results, style/ holds the CSS for the books and the site, and src/ holds the source. The README calls this organization simple and self-evident at a glance, and it is. There is no build system beyond a top-level CMakeLists.txt, no package manifest, no runtime dependency to resolve.

That structure tells you what kind of project this is. It is a publication with a code appendix attached, served from the release branch through GitHub Pages at https://raytracing.github.io/. The books are the product. The binaries are a reference artifact.

## Building the Reference Renderers with CMake

The README gives the build steps directly. From the root of the project directory, configure and build a debug version of every executable:

```bash
$ cmake -B build
$ cmake --build build
```

You should see CMake configure a build directory and then compile the targets. The README notes you should rerun cmake -B build whenever you change your project CMakeLists.txt, for example after adding a new source file.

To build one program instead of all of them, pass --target with one of inOneWeekend, theNextWeek, theRestOfYourLife, or any of the demonstration programs:

```bash
$ cmake --build build --target inOneWeekend
```

With no --target option, CMake builds every target. The README recommends building and running the Release configuration, especially before the final render, for the fastest results, unless you need the debug information the default debug build carries. The invocations differ by platform. On Windows, cmake --build build --config Release places binaries under build\Release and --config Debug under build\Debug. On Linux and macOS the README uses separate build trees:

```bash
$ cmake -B build/Release -DCMAKE_BUILD_TYPE=Release
$ cmake --build build/Release
```

Windows users who prefer a GUI get a numbered walkthrough in the README: point CMake at the copied directory, create and select a build folder, click Configure, pick your Visual Studio generator, then Generate, and open the resulting .sln in Visual Studio. The README then says that if the project is successfully cloned and built, you can use your operating system's native terminal to print the image to file. The README is truncated before the exact run command, so check the book text itself for the output invocation.

## The First Honest Limitation: the Source Is an Answer Key, Not a Starting Point

The most common way to use this repository wrong is to clone it, build it, run it, and conclude you have learned ray tracing. The README preempts that: the source is provided so you can compare your work, and it strongly recommends reading and following along with the book, ideally developing your own implementation as you go. A reader who only builds the reference binaries has compiled someone else's renderer.

The second limitation is scope. The series is a CPU path tracer written in C++11, and the README says the language and features were chosen for broad understandability, not to represent ideal or optimized C++ code. If your goal is a GPU renderer, a real-time pipeline, or an API to embed in an application, this is the wrong tool. There is no library to link, no headers to include, no published interface. The code exists to be read and reimplemented.

The third is that the reference trees are final states. The README does not document per-chapter diffs or checkpoints, so if you fall behind mid-book, the src/ tree for that book will not tell you which lines belong to which section. Comparing your work means comparing whole programs, not incremental patches. That is a real friction point for self-study, and the repository does not offer a workaround.

## Trying It in Another Language, and What That Costs You

The README points to a list of implementations in other languages, maintained in the repository, and says the series has a long history of them across different operating systems. It invites readers to add their own. That is a genuine strength of the project: the algorithms in the books are not C++-specific, and porting them is a common way to learn both the rendering math and a new language at once.

The cost is that the reference source stops being a direct comparison. If you port to Rust or Go or Python, the src/ trees no longer match your code line for line, and you lose the fastest debugging loop the book offers, which is diffing your output against the images/ figures. The README does say images/ can be used to compare your results, and that comparison survives a port: the rendered image is the ground truth regardless of the language producing it.

What does not survive is the build guidance. The CMake instructions and the --target names inOneWeekend, theNextWeek and theRestOfYourLife apply only to the C++ trees. A port needs its own toolchain, and the repository does not document one.

## Maintenance, Releases and the CC0 Licence Question

The repository is not archived, and the last push was on 2026-08-10. The most recent release listed is v4.0.2 from 2025-04-25, following v4.0.1 in 2024-08-31 and v4.0.0 in 2024-07-26. The README describes the release branch as the latest released and live assets, the branch GitHub Pages serves, and points ongoing work at the dev-patch, dev-minor and dev-major branches, with CHANGELOG.md kept up to date so you can browse what is new in each. If you want to know what is changing, the changelog and those branches are the places to look, not the release branch.

Upgrade cost is unusually low for a project this size. There is no dependency graph to reconcile, no runtime to keep patched. Moving from one 4.0.x version to the next means re-reading the affected chapters and adjusting your own code, since the books themselves are the artifact that changes. If you are following along in your own implementation, a book revision can invalidate work you have already done, which is the real upgrade cost here.

The licence is CC0-1.0. That is a public domain dedication rather than a permissive software licence, and it covers the repository as stated. It does not, by itself, tell you how the status of the code samples interacts with anything you build from them. This is not legal advice; if you plan to redistribute a derivative renderer commercially, read COPYING.txt in the repository root and get your own answer.

## Conclusion

Adopt this series if you want to understand a path tracer by writing one in C++11 yourself, and treat the src/ trees as an answer key rather than a codebase to vendor. Skip it if you need a production renderer, a GPU pipeline, or a library you can link against; the books target CPU rendering and the README says the C++ is not meant to represent ideal or optimized code. Before starting, open PRINTING.md if you want PDFs or print copies, and check CHANGELOG.md against the release branch, since the README points ongoing work at the dev-patch, dev-minor and dev-major branches instead.

## FAQ

### What does ray tracing actually do in the Ray Tracing in One Weekend series?

The series builds a path tracer that shoots rays into a scene and computes the color each ray returns, producing an image. The books walk through that process in C++ across three volumes, from a minimal renderer to more advanced sampling.

### Is ray tracing good on or off?

This question does not apply to the project. Ray Tracing in One Weekend is a book series that teaches you to write a CPU path tracer in C++, not a real-time ray tracing toggle in a game or driver.

### What is ray tracing and how does it work according to Ray Tracing in One Weekend?

The three books take a reader from a blank C++ file to a working renderer, covering ray-scene intersection, materials and sampling along the way. The README states the source is provided so you can compare your work while following the book, not as a standalone tutorial.

### Is ray tracing NVIDIA only in Ray Tracing in One Weekend?

No. The series is written in C++11 and the README describes CPU-oriented reference code built with CMake, with no GPU vendor requirement stated. The README also points to a list of implementations in other languages and operating systems.

## Sources

- [License: CC0-1.0](https://github.com/RayTracing/raytracing.github.io/blob/release/LICENSE)
- [Project website](https://raytracing.github.io/)
- [RayTracing/raytracing.github.io on GitHub](https://github.com/RayTracing/raytracing.github.io)
- [README](https://github.com/RayTracing/raytracing.github.io/blob/release/README.md)
- [Releases](https://github.com/RayTracing/raytracing.github.io/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/raytracing-raytracing-github-io