概述

多年来，我教过很多图形课程。我经常在光线追踪中执行这些操作，因为您被迫编写所有代码，但您仍然可以在没有 API 的情况下获得很酷的图像。我决定将我的课程笔记改编成操作方法，以便您尽快进入一个很酷的程序。它不会是一个功能齐全的光线追踪器，但它确实具有间接照明，这使得光线追踪成为电影中的主打产品。按照这些步骤操作，如果您感到兴奋并想要追求它，您生成的光线追踪器的架构将非常适合扩展到更广泛的光线追踪器。

当有人说“光线追踪”时，它可能意味着很多事情。从技术上讲，我将要描述的是一个路径追踪器，而且是一个相当通用的追踪器。虽然代码非常简单（让计算机完成工作！我想你会对你能制作的图像感到非常满意。

我将按照我编写的顺序引导您编写光线跟踪器，并提供一些调试技巧。到最后，您将拥有一个光线跟踪器，它可以生成一些出色的图像。您应该能够在周末完成此操作。如果你花更长的时间，不用担心。我使用 C++ 作为驱动语言，但您不需要这样做。但是，我建议您这样做，因为它快速、可移植，并且大多数生产电影和视频游戏渲染器都是用 C++ 编写的。请注意，我避免了 C++ 的大多数“现代功能”，但继承和运算符重载对于光线跟踪器来说太有用了，无法传递。

我没有在线提供代码，但代码是真实的，除了 vec3 类中的一些简单运算符外，我展示了所有代码。我非常相信输入代码来学习它，但是当代码可用时，我就会使用它，所以我只在代码不可用时才实践我所宣扬的。所以不要问！

我把最后一部分留了下来，因为我做了 180 次，这很有趣。一些读者最终会遇到细微的错误，当我们比较代码时，这些错误会有所帮助。因此，请键入代码，但您可以在 GitHub 上的 RayTracing 项目中找到每本书的完成源代码。

关于这些书籍的实现代码的说明 — 我们对包含代码的理念优先考虑以下目标：

• 
  代码应实现书中涵盖的概念。

• 
  我们使用 C++，但尽可能简单。我们的编程风格非常像 C，但我们利用了现代功能，使代码更易于使用或理解。

• 
  为了保持连续性，我们的编码风格尽可能地延续了原书中建立的风格。

• 
  行长度保持为每行 96 个字符，以保持代码库和书籍中的代码列表之间的行一致。

因此，该代码提供了一个基线实现，并有大量的改进供读者享受。有无数种方法可以优化和现代化代码;我们优先考虑简单的解决方案。

我们假设对向量（如点积和向量加法）有一点熟悉。如果您不知道这一点，请做一些回顾。如果您需要该评论，或者是第一次学习它，请查看 Morgan McGuire 的在线 Graphics Codex、Steve Marschner 和 Peter Shirley 的 Fundamentals of Computer Graphics 或 J.D. Foley 和 Andy Van Dam 的 Computer Graphics： Principles and Practice。

查看项目README文件，了解此项目、GitHub上的存储库、目录结构、构建和运行，以及如何进行或引用更正和贡献的信息。

有关其他项目相关资源，请参阅我们的延伸阅读 wiki 页面。

这些书籍已经过格式化，可以直接从您的浏览器打印出来。我们还在“资源”部分包含每本书的 PDF。

如果您想与我们沟通，请随时发送电子邮件至：

• 
  Peter Shirley，ptrshrl@gmail.com
• 
  史蒂夫·霍拉什 （Steve Hollasch），steve@hollasch.net
• 
  特雷弗·大卫·布莱克，trevordblack@trevord.black

最后，如果您在实施中遇到问题、有一般问题或想要分享自己的想法或工作，请参阅 GitHub 项目上的 GitHub Discussions 论坛。

感谢所有在这个项目中伸出援手的人。您可以在本书末尾的致谢部分找到它们。

让我们继续吧！

 输出图像

 PPM 图像格式

无论何时启动渲染器，都需要一种方法来查看图像。最直接的方法是将其写入文件。问题是，格式太多了。其中许多都很复杂。我总是从纯文本 ppm 文件开始。这是来自维基百科的一个很好的描述：

 
图 1：PPM 示例

#include <iostream>

int main() {

    // Image

    int image_width = 256;
    int image_height = 256;

    // Render

    std::cout << "P3\n" << image_width << ' ' << image_height << "\n255\n";

    for (int j = 0; j < image_height; j++) {
        for (int i = 0; i < image_width; i++) {
            auto r = double(i) / (image_width-1);
            auto g = double(j) / (image_height-1);
            auto b = 0.0;

            int ir = int(255.999 * r);
            int ig = int(255.999 * g);
            int ib = int(255.999 * b);

            std::cout << ir << ' ' << ig << ' ' << ib << '\n';
        }
    }
}

此代码中需要注意一些事项：

1. 
   像素以行的形式写出。

2. 
   每行像素都是从左到右写出的。

3. 
   这些行从上到下写出。

4. 
   按照惯例，每个红/绿/蓝分量在内部都由范围从 0.0 到 1.0 的实值变量表示。在我们打印它们之前，必须将它们缩放为 0 到 255 之间的整数值。

5. 
   红色从左到右从完全关闭（黑色）变为完全亮起（亮红色），绿色从顶部完全关闭（黑色）到底部完全亮起（亮绿色）。将红色和绿色光一起添加会变成黄色，因此我们应该期望右下角为黄色。

 创建图像文件

由于文件已写入标准输出流，因此您需要将其重定向到图像文件。通常，这是使用 > 重定向运算符从命令行完成的。

在 Windows 上，您将从运行以下命令的 CMake 获取调试版本：

cmake -B build
cmake --build build

然后像这样运行你新构建的程序：

build\Debug\inOneWeekend.exe > image.ppm

稍后，最好运行优化的构建以提高速度。在这种情况下，您将像这样构建：

cmake --build build --config release

并将运行优化的程序，如下所示：

build\Release\inOneWeekend.exe > image.ppm

上面的示例假定你正在使用 CMake 进行构建，使用与包含的源中的 CMakeLists.txt 文件相同的方法。使用您最熟悉的任何构建环境（和语言）。

在 Mac 或 Linux 上，发布版本，您可以像这样启动程序：

build/inOneWeekend > image.ppm

完整的构建和运行说明可以在 README 项目中找到。

打开输出文件（在我的 Mac 上的 ToyViewer 中，但如果你的查看器不支持，请在你最喜欢的图像查看器和 Google“ppm 查看器”中尝试）显示以下结果：

图 1：第一个 PPM 图像

万岁！这是图形“你好世界”。如果您的图像看起来不是那样的，请在文本编辑器中打开输出文件并查看它的外观。它应该像这样开始：

P3
256 256
255
0 0 0
1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 0 0
8 0 0
9 0 0
10 0 0
11 0 0
12 0 0
...

如果您的 PPM 文件不是这样，请仔细检查您的格式设置代码。如果它确实看起来像这样但无法渲染，则可能存在行尾差异或类似内容，这会使图像查看器感到困惑。为了帮助调试此问题，您可以在 Github 项目的 images 目录中找到一个文件 test.ppm。这应该有助于确保您的查看器能够处理 PPM 格式，并用作与生成的 PPM 文件的比较。

一些读者报告在 Windows 上查看他们生成的文件时出现问题。在这种情况下，问题通常是 PPM 以 UTF-16 形式写出，通常是从 PowerShell 写出的。如果您遇到此问题，请参阅讨论 1114 以获取有关此问题的帮助。

如果所有内容都显示正确，那么您就差不多解决了系统和 IDE 问题 — 本系列其余部分的所有内容都使用这种相同的简单机制来生成渲染图像。

如果您想生成其他图像格式，我是 stb_image.h 的粉丝，这是一个仅标题图像库，可在 GitHub 上获得，网址为 https://github.com/nothings/stb。

添加进度指示器

在继续之前，让我们在输出中添加一个进度指示器。这是跟踪长时间渲染进度的便捷方法，还可以识别由于无限循环或其他问题而停止的运行。

    for (int j = 0; j < image_height; ++j) {
        std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
        for (int i = 0; i < image_width; i++) {
            auto r = double(i) / (image_width-1);
            auto g = double(j) / (image_height-1);
            auto b = 0.0;

            int ir = int(255.999 * r);
            int ig = int(255.999 * g);
            int ib = int(255.999 * b);

            std::cout << ir << ' ' << ig << ' ' << ib << '\n';
        }
    }

    std::clog << "\rDone.                 \n";

现在，在运行时，您将看到剩余扫描线数量的运行计数。希望它运行得如此之快，以至于您甚至看不到它！别担心，您将来会有很多时间来观看我们扩展光线追踪器时缓慢更新的进度线。

 vec3 类

几乎所有的图形程序都有一些用于存储几何矢量和颜色的类。在许多系统中，这些矢量是 4D（3D 位置加上几何图形的齐次坐标，或 RGB 加上颜色的 alpha 透明度分量）。对于我们的目的，三个坐标就足够了。我们将对颜色、位置、方向、偏移量等使用相同的类 vec3。有些人不喜欢这样做，因为它不会阻止你做一些愚蠢的事情，比如从颜色中减去一个位置。他们有很好的观点，但是如果不是明显错误，我们将始终采取“减少代码”的路线。尽管如此，我们还是为 vec3 声明了两个别名：point3 和 color。由于这两种类型只是 vec3 的别名，因此如果您将颜色传递给需要 point3 的函数，则不会收到警告，并且没有什么可以阻止您将 point3 添加到颜色中，但它使代码更易于阅读和理解。

我们在新的 vec3.h 头文件的上半部分定义 vec3 类，并在下半部分定义一组有用的 vector utility 函数：

#ifndef VEC3_H
#define VEC3_H

#include <cmath>
#include <iostream>

class vec3 {
  public:
    double e[3];

    vec3() : e{0,0,0} {}
    vec3(double e0, double e1, double e2) : e{e0, e1, e2} {}

    double x() const { return e[0]; }
    double y() const { return e[1]; }
    double z() const { return e[2]; }

    vec3 operator-() const { return vec3(-e[0], -e[1], -e[2]); }
    double operator[](int i) const { return e[i]; }
    double& operator[](int i) { return e[i]; }

    vec3& operator+=(const vec3& v) {
        e[0] += v.e[0];
        e[1] += v.e[1];
        e[2] += v.e[2];
        return *this;
    }

    vec3& operator*=(double t) {
        e[0] *= t;
        e[1] *= t;
        e[2] *= t;
        return *this;
    }

    vec3& operator/=(double t) {
        return *this *= 1/t;
    }

    double length() const {
        return std::sqrt(length_squared());
    }

    double length_squared() const {
        return e[0]*e[0] + e[1]*e[1] + e[2]*e[2];
    }
};

// point3 is just an alias for vec3, but useful for geometric clarity in the code.
using point3 = vec3;


// Vector Utility Functions

inline std::ostream& operator<<(std::ostream& out, const vec3& v) {
    return out << v.e[0] << ' ' << v.e[1] << ' ' << v.e[2];
}

inline vec3 operator+(const vec3& u, const vec3& v) {
    return vec3(u.e[0] + v.e[0], u.e[1] + v.e[1], u.e[2] + v.e[2]);
}

inline vec3 operator-(const vec3& u, const vec3& v) {
    return vec3(u.e[0] - v.e[0], u.e[1] - v.e[1], u.e[2] - v.e[2]);
}

inline vec3 operator*(const vec3& u, const vec3& v) {
    return vec3(u.e[0] * v.e[0], u.e[1] * v.e[1], u.e[2] * v.e[2]);
}

inline vec3 operator*(double t, const vec3& v) {
    return vec3(t*v.e[0], t*v.e[1], t*v.e[2]);
}

inline vec3 operator*(const vec3& v, double t) {
    return t * v;
}

inline vec3 operator/(const vec3& v, double t) {
    return (1/t) * v;
}

inline double dot(const vec3& u, const vec3& v) {
    return u.e[0] * v.e[0]
         + u.e[1] * v.e[1]
         + u.e[2] * v.e[2];
}

inline vec3 cross(const vec3& u, const vec3& v) {
    return vec3(u.e[1] * v.e[2] - u.e[2] * v.e[1],
                u.e[2] * v.e[0] - u.e[0] * v.e[2],
                u.e[0] * v.e[1] - u.e[1] * v.e[0]);
}

inline vec3 unit_vector(const vec3& v) {
    return v / v.length();
}

#endif

我们在这里使用 double，但一些光线跟踪器使用 float。double 具有更高的精度和范围，但与 float 相比，其大小是 float 的两倍。如果您在有限的内存条件（如硬件着色器）中进行编程，则这种大小的增加可能很重要。任何一个都可以 - 遵循你自己的口味。

 颜色工具函数

使用新的 vec3 类，我们将创建一个新的 color.h 头文件，并定义一个实用程序函数，用于将单个像素的颜色写入标准输出流。

#ifndef COLOR_H
#define COLOR_H

#include "vec3.h"

#include <iostream>

using color = vec3;

void write_color(std::ostream& out, const color& pixel_color) {
    auto r = pixel_color.x();
    auto g = pixel_color.y();
    auto b = pixel_color.z();

    // Translate the [0,1] component values to the byte range [0,255].
    int rbyte = int(255.999 * r);
    int gbyte = int(255.999 * g);
    int bbyte = int(255.999 * b);

    // Write out the pixel color components.
    out << rbyte << ' ' << gbyte << ' ' << bbyte << '\n';
}

#endif

#include "color.h"
#include "vec3.h"

#include <iostream>

int main() {

    // Image

    int image_width = 256;
    int image_height = 256;

    // Render

    std::cout << "P3\n" << image_width << ' ' << image_height << "\n255\n";

    for (int j = 0; j < image_height; j++) {
        std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
        for (int i = 0; i < image_width; i++) {
            auto pixel_color = color(double(i)/(image_width-1), double(j)/(image_height-1), 0);
            write_color(std::cout, pixel_color);
        }
    }

    std::clog << "\rDone.                 \n";
}

您应该得到与以前完全相同的图片。

光线、简单相机和背景

 射线类

The one thing that all ray tracers have is a ray class and a computation of what color is seen along a ray. Let’s think of a ray as a function P(t)=A+tb$\mathbf{P}(t)=\mathbf{A}+t\mathbf{b}$. Here P$\mathbf{P}$ is a 3D position along a line in 3D. A$\mathbf{A}$ is the ray origin and b$\mathbf{b}$ is the ray direction. The ray parameter t$t$ is a real number (double in the code). Plug in a different t$t$ and P(t)$\mathbf{P}(t)$ moves the point along the ray. Add in negative t$t$ values and you can go anywhere on the 3D line. For positive t$t$, you get only the parts in front of A$\mathbf{A}$, and this is what is often called a half-line or a ray.

 
图 2：线性插值

#ifndef RAY_H
#define RAY_H

#include "vec3.h"

class ray {
  public:
    ray() {}

    ray(const point3& origin, const vec3& direction) : orig(origin), dir(direction) {}

    const point3& origin() const  { return orig; }
    const vec3& direction() const { return dir; }

    point3 at(double t) const {
        return orig + t*dir;
    }

  private:
    point3 orig;
    vec3 dir;
};

#endif

（对于不熟悉 C++ 的人，函数 ray：：origin（） 和 ray：:d irection（） 都返回对其成员的不可变引用。调用方可以直接使用引用，也可以根据需要创建可变副本。

将光线发送到场景中

现在我们准备好转折并制作光线跟踪器。光线跟踪器的核心是发送穿过像素的光线，并计算在这些光线方向上看到的颜色。涉及的步骤包括

1. 
   计算从“眼睛”穿过像素的光线，
2. 
   确定光线与哪些对象相交，以及
3. 
   计算最近交点的颜色。

首次开发光线跟踪器时，我总是使用一个简单的相机来启动和运行代码。

I’ve often gotten into trouble using square images for debugging because I transpose x$x$ and y$y$ too often, so we’ll use a non-square image. A square image has a 1∶1 aspect ratio, because its width is the same as its height. Since we want a non-square image, we'll choose 16∶9 because it's so common. A 16∶9 aspect ratio means that the ratio of image width to image height is 16∶9. Put another way, given an image with a 16∶9 aspect ratio,

举个实际例子，一个 800 像素宽 x 400 像素高的图像的长宽比为 2∶1。

图像的纵横比可以通过其宽度与高度的比率来确定。但是，由于我们考虑了给定的纵横比，因此设置图像的宽度和纵横比，然后使用它来计算其高度会更容易。这样，我们可以通过更改图像宽度来放大或缩小图像，并且不会破坏我们想要的纵横比。我们必须确保在求解图像高度时，得到的高度至少为 1。

除了为渲染图像设置像素尺寸外，我们还需要设置一个虚拟视口，通过该视口传递我们的场景光线。视区是 3D 世界中的虚拟矩形，其中包含图像像素位置的网格。如果像素的水平间距与垂直间距相同，则边界像素的视口将具有与渲染图像相同的纵横比。两个相邻像素之间的距离称为像素间距，方形像素是标准。

首先，我们将选择任意的视口高度 2.0，并缩放视口宽度以提供所需的纵横比。以下是此代码的代码片段：

auto aspect_ratio = 16.0 / 9.0;
int image_width = 400;

// Calculate the image height, and ensure that it's at least 1.
int image_height = int(image_width / aspect_ratio);
image_height = (image_height < 1) ? 1 : image_height;

// Viewport widths less than one are ok since they are real valued.
auto viewport_height = 2.0;
auto viewport_width = viewport_height * (double(image_width)/image_height);

如果你想知道为什么我们在计算 viewport_width 时不只使用 aspect_ratio，这是因为设置为 aspect_ratio 的值是理想的比率，它可能不是 image_width 与 image_height 之间的实际比率。如果允许 image_height 是实值 — 而不仅仅是一个整数 — 那么使用 aspect_ratio 就可以了。但是 image_width 和 image_height 之间的实际比率可能因代码的两个部分而异。首先，image_height 向下舍入到最接近的整数，这可以提高比率。其次，我们不允许image_height小于 1，这也会改变实际的纵横比。

请注意，aspect_ratio 是一个理想的比率，我们尽可能地使用基于整数的图像宽度与图像高度的比率来近似。为了使视口比例与图像比例完全匹配，我们使用计算出的图像纵横比来确定最终的视口宽度。

接下来，我们将定义摄像机中心：3D 空间中所有场景光线都源自的点（这通常也称为眼点）。从摄像机中心到视区中心的矢量将与视区正交。我们最初将视区和摄像机中心点之间的距离设置为一个单位。此距离通常称为焦距。

For simplicity we'll start with the camera center at (0,0,0)$(0,0,0)$. We'll also have the y-axis go up, the x-axis to the right, and the negative z-axis pointing in the viewing direction. (This is commonly referred to as right-handed coordinates.)

 
图 3：相机几何图形

现在是不可避免的棘手部分。虽然我们的 3D 空间具有上述约定，但这与我们的图像坐标相冲突，我们希望将第 0 个像素放在左上角，然后向下移动到右下角的最后一个像素。这意味着我们的图像坐标 Y 轴是倒置的：Y 轴沿着图像向下增加。

As we scan our image, we will start at the upper left pixel (pixel 0,0$0,0$), scan left-to-right across each row, and then scan row-by-row, top-to-bottom. To help navigate the pixel grid, we'll use a vector from the left edge to the right edge (Vu${\mathbf{V}}_{\mathbf{u}}$), and a vector from the upper edge to the lower edge (Vv${\mathbf{V}}_{\mathbf{v}}$).

Our pixel grid will be inset from the viewport edges by half the pixel-to-pixel distance. This way, our viewport area is evenly divided into width × height identical regions. Here's what our viewport and pixel grid look like:

 Figure 4: Viewport and pixel grid

In this figure, we have the viewport, the pixel grid for a 7×5 resolution image, the viewport upper left corner Q$\mathbf{Q}$, the pixel P0,0${\mathbf{P}}_{\mathbf{0}\mathbf{,}\mathbf{0}}$ location, the viewport vector Vu${\mathbf{V}}_{\mathbf{u}}$ (viewport_u), the viewport vector Vv${\mathbf{V}}_{\mathbf{v}}$ (viewport_v), and the pixel delta vectors Δu$\mathbf{\Delta }\mathbf{u}$ and Δv$\mathbf{\Delta }\mathbf{v}$.

#include "color.h"
#include "ray.h"
#include "vec3.h"

#include <iostream>

color ray_color(const ray& r) {
    return color(0,0,0);
}

int main() {

    // Image

    auto aspect_ratio = 16.0 / 9.0;
    int image_width = 400;

    // Calculate the image height, and ensure that it's at least 1.
    int image_height = int(image_width / aspect_ratio);
    image_height = (image_height < 1) ? 1 : image_height;

    // Camera

    auto focal_length = 1.0;
    auto viewport_height = 2.0;
    auto viewport_width = viewport_height * (double(image_width)/image_height);
    auto camera_center = point3(0, 0, 0);

    // Calculate the vectors across the horizontal and down the vertical viewport edges.
    auto viewport_u = vec3(viewport_width, 0, 0);
    auto viewport_v = vec3(0, -viewport_height, 0);

    // Calculate the horizontal and vertical delta vectors from pixel to pixel.
    auto pixel_delta_u = viewport_u / image_width;
    auto pixel_delta_v = viewport_v / image_height;

    // Calculate the location of the upper left pixel.
    auto viewport_upper_left = camera_center
                             - vec3(0, 0, focal_length) - viewport_u/2 - viewport_v/2;
    auto pixel00_loc = viewport_upper_left + 0.5 * (pixel_delta_u + pixel_delta_v);

    // Render

    std::cout << "P3\n" << image_width << " " << image_height << "\n255\n";

    for (int j = 0; j < image_height; j++) {
        std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
        for (int i = 0; i < image_width; i++) {
            auto pixel_center = pixel00_loc + (i * pixel_delta_u) + (j * pixel_delta_v);
            auto ray_direction = pixel_center - camera_center;
            ray r(camera_center, ray_direction);

            color pixel_color = ray_color(r);
            write_color(std::cout, pixel_color);
        }
    }

    std::clog << "\rDone.                 \n";
}

Notice that in the code above, I didn't make ray_direction a unit vector, because I think not doing that makes for simpler and slightly faster code.

Now we'll fill in the ray_color(ray) function to implement a simple gradient. This function will linearly blend white and blue depending on the height of the y$y$ coordinate after scaling the ray direction to unit length (so −1.0<y<1.0$-1.0<y<1.0$). Because we're looking at the y$y$ height after normalizing the vector, you'll notice a horizontal gradient to the color in addition to the vertical gradient.

I'll use a standard graphics trick to linearly scale 0.0≤a≤1.0$0.0\le a\le 1.0$. When a=1.0$a=1.0$, I want blue. When a=0.0$a=0.0$, I want white. In between, I want a blend. This forms a “linear blend”, or “linear interpolation”. This is commonly referred to as a lerp between two values. A lerp is always of the form

with a$a$ going from zero to one.

#include "color.h"
#include "ray.h"
#include "vec3.h"

#include <iostream>


color ray_color(const ray& r) {
    vec3 unit_direction = unit_vector(r.direction());
    auto a = 0.5*(unit_direction.y() + 1.0);
    return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
}

...

In our case this produces:

Image 2: A blue-to-white gradient depending on ray Y coordinate

Adding a Sphere

Let’s add a single object to our ray tracer. People often use spheres in ray tracers because calculating whether a ray hits a sphere is relatively simple.

Ray-Sphere Intersection

The equation for a sphere of radius r$r$ that is centered at the origin is an important mathematical equation:

You can also think of this as saying that if a given point (x,y,z)$(x,y,z)$ is on the surface of the sphere, then x2+y2+z2=r2$x^2+y^2+z^2=r^2$. If a given point (x,y,z)$(x,y,z)$ is inside the sphere, then x2+y2+z2<r2$x^2+y^2+z^2<r^2$, and if a given point (x,y,z)$(x,y,z)$ is outside the sphere, then x2+y2+z2>r2$x^2+y^2+z^2>r^2$.

If we want to allow the sphere center to be at an arbitrary point (Cx,Cy,Cz)$(C_x,C_y,C_z)$, then the equation becomes a lot less nice:

In graphics, you almost always want your formulas to be in terms of vectors so that all the x$x$/y$y$/z$z$ stuff can be simply represented using a vec3 class. You might note that the vector from point P=(x,y,z)$\mathbf{P}=(x,y,z)$ to center C=(Cx,Cy,Cz)$\mathbf{C}=(C_x,C_y,C_z)$ is (C−P)$(\mathbf{C}-\mathbf{P})$.

If we use the definition of the dot product:

Then we can rewrite the equation of the sphere in vector form as:

We can read this as “any point P$\mathbf{P}$ that satisfies this equation is on the sphere”. We want to know if our ray P(t)=Q+td$\mathbf{P}(t)=\mathbf{Q}+t\mathbf{d}$ ever hits the sphere anywhere. If it does hit the sphere, there is some t$t$ for which P(t)$\mathbf{P}(t)$ satisfies the sphere equation. So we are looking for any t$t$ where this is true:

which can be found by replacing P(t)$\mathbf{P}(t)$ with its expanded form:

We have three vectors on the left dotted by three vectors on the right. If we solved for the full dot product we would get nine vectors. You can definitely go through and write everything out, but we don't need to work that hard. If you remember, we want to solve for t$t$, so we'll separate the terms based on whether there is a t$t$ or not:

And now we follow the rules of vector algebra to distribute the dot product:

Move the square of the radius over to the left hand side:

It's hard to make out what exactly this equation is, but the vectors and r$r$ in that equation are all constant and known. Furthermore, the only vectors that we have are reduced to scalars by dot product. The only unknown is t$t$, and we have a t2$t^2$, which means that this equation is quadratic. You can solve for a quadratic equation ax2+bx+c=0$a{x}^2+bx+c=0$ by using the quadratic formula:

So solving for t$t$ in the ray-sphere intersection equation gives us these values for a$a$, b$b$, and c$c$:

Using all of the above you can solve for t$t$, but there is a square root part that can be either positive (meaning two real solutions), negative (meaning no real solutions), or zero (meaning one real solution). In graphics, the algebra almost always relates very directly to the geometry. What we have is:

 Figure 5: Ray-sphere intersection results

Creating Our First Raytraced Image

If we take that math and hard-code it into our program, we can test our code by placing a small sphere at −1 on the z-axis and then coloring red any pixel that intersects it.

bool hit_sphere(const point3& center, double radius, const ray& r) {
    vec3 oc = center - r.origin();
    auto a = dot(r.direction(), r.direction());
    auto b = -2.0 * dot(r.direction(), oc);
    auto c = dot(oc, oc) - radius*radius;
    auto discriminant = b*b - 4*a*c;
    return (discriminant >= 0);
}

color ray_color(const ray& r) {
    if (hit_sphere(point3(0,0,-1), 0.5, r))
        return color(1, 0, 0);

    vec3 unit_direction = unit_vector(r.direction());
    auto a = 0.5*(unit_direction.y() + 1.0);
    return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
}

What we get is this:

Image 3: A simple red sphere

Now this lacks all sorts of things — like shading, reflection rays, and more than one object — but we are closer to halfway done than we are to our start! One thing to be aware of is that we are testing to see if a ray intersects with the sphere by solving the quadratic equation and seeing if a solution exists, but solutions with negative values of t$t$ work just fine. If you change your sphere center to z=+1$z=+1$ you will get exactly the same picture because this solution doesn't distinguish between objects in front of the camera and objects behind the camera. This is not a feature! We’ll fix those issues next.

Surface Normals and Multiple Objects

Shading with Surface Normals

First, let’s get ourselves a surface normal so we can shade. This is a vector that is perpendicular to the surface at the point of intersection.

We have a key design decision to make for normal vectors in our code: whether normal vectors will have an arbitrary length, or will be normalized to unit length.

It is tempting to skip the expensive square root operation involved in normalizing the vector, in case it's not needed. In practice, however, there are three important observations. First, if a unit-length normal vector is ever required, then you might as well do it up front once, instead of over and over again “just in case” for every location where unit-length is required. Second, we do require unit-length normal vectors in several places. Third, if you require normal vectors to be unit length, then you can often efficiently generate that vector with an understanding of the specific geometry class, in its constructor, or in the hit() function. For example, sphere normals can be made unit length simply by dividing by the sphere radius, avoiding the square root entirely.

Given all of this, we will adopt the policy that all normal vectors will be of unit length.

For a sphere, the outward normal is in the direction of the hit point minus the center:

 Figure 6: Sphere surface-normal geometry

On the earth, this means that the vector from the earth’s center to you points straight up. Let’s throw that into the code now, and shade it. We don’t have any lights or anything yet, so let’s just visualize the normals with a color map. A common trick used for visualizing normals (because it’s easy and somewhat intuitive to assume n$\mathbf{n}$ is a unit length vector — so each component is between −1 and 1) is to map each component to the interval from 0 to 1, and then map (x,y,z)$(x,y,z)$ to (red,green,blue)$(\mathit{r}\mathit{e}\mathit{d},\mathit{g}\mathit{r}\mathit{e}\mathit{e}\mathit{n},\mathit{b}\mathit{l}\mathit{u}\mathit{e})$. For the normal, we need the hit point, not just whether we hit or not (which is all we're calculating at the moment). We only have one sphere in the scene, and it's directly in front of the camera, so we won't worry about negative values of t$t$ yet. We'll just assume the closest hit point (smallest t$t$) is the one that we want. These changes in the code let us compute and visualize n$\mathbf{n}$:

double hit_sphere(const point3& center, double radius, const ray& r) {
    vec3 oc = center - r.origin();
    auto a = dot(r.direction(), r.direction());
    auto b = -2.0 * dot(r.direction(), oc);
    auto c = dot(oc, oc) - radius*radius;
    auto discriminant = b*b - 4*a*c;

    if (discriminant < 0) {
        return -1.0;
    } else {
        return (-b - std::sqrt(discriminant) ) / (2.0*a);
    }
}

color ray_color(const ray& r) {
    auto t = hit_sphere(point3(0,0,-1), 0.5, r);
    if (t > 0.0) {
        vec3 N = unit_vector(r.at(t) - vec3(0,0,-1));
        return 0.5*color(N.x()+1, N.y()+1, N.z()+1);
    }

    vec3 unit_direction = unit_vector(r.direction());
    auto a = 0.5*(unit_direction.y() + 1.0);
    return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
}

And that yields this picture:

Image 4: A sphere colored according to its normal vectors

Simplifying the Ray-Sphere Intersection Code

Let’s revisit the ray-sphere function:

double hit_sphere(const point3& center, double radius, const ray& r) {
    vec3 oc = center - r.origin();
    auto a = dot(r.direction(), r.direction());
    auto b = -2.0 * dot(r.direction(), oc);
    auto c = dot(oc, oc) - radius*radius;
    auto discriminant = b*b - 4*a*c;

    if (discriminant < 0) {
        return -1.0;
    } else {
        return (-b - std::sqrt(discriminant) ) / (2.0*a);
    }
}

First, recall that a vector dotted with itself is equal to the squared length of that vector.

Second, notice how the equation for b has a factor of negative two in it. Consider what happens to the quadratic equation if b=−2h$b=-2h$:

This simplifies nicely, so we'll use it. So solving for h$h$:

double hit_sphere(const point3& center, double radius, const ray& r) {
    vec3 oc = center - r.origin();
    auto a = r.direction().length_squared();
    auto h = dot(r.direction(), oc);
    auto c = oc.length_squared() - radius*radius;
    auto discriminant = h*h - a*c;

    if (discriminant < 0) {
        return -1.0;
    } else {
        return (h - std::sqrt(discriminant)) / a;
    }
}

An Abstraction for Hittable Objects

Now, how about more than one sphere? While it is tempting to have an array of spheres, a very clean solution is to make an “abstract class” for anything a ray might hit, and make both a sphere and a list of spheres just something that can be hit. What that class should be called is something of a quandary — calling it an “object” would be good if not for “object oriented” programming. “Surface” is often used, with the weakness being maybe we will want volumes (fog, clouds, stuff like that). “hittable” emphasizes the member function that unites them. I don’t love any of these, but we'll go with “hittable”.

This hittable abstract class will have a hit function that takes in a ray. Most ray tracers have found it convenient to add a valid interval for hits tmin$t_{\mathit{m}\mathit{i}\mathit{n}}$ to tmax$t_{\mathit{m}\mathit{a}\mathit{x}}$, so the hit only “counts” if tmin<t<tmax$t_{\mathit{m}\mathit{i}\mathit{n}}<t<t_{\mathit{m}\mathit{a}\mathit{x}}$. For the initial rays this is positive t$t$, but as we will see, it can simplify our code to have an interval tmin$t_{\mathit{m}\mathit{i}\mathit{n}}$ to tmax$t_{\mathit{m}\mathit{a}\mathit{x}}$. One design question is whether to do things like compute the normal if we hit something. We might end up hitting something closer as we do our search, and we will only need the normal of the closest thing. I will go with the simple solution and compute a bundle of stuff I will store in some structure. Here’s the abstract class:

#ifndef HITTABLE_H
#define HITTABLE_H

#include "ray.h"

class hit_record {
  public:
    point3 p;
    vec3 normal;
    double t;
};

class hittable {
  public:
    virtual ~hittable() = default;

    virtual bool hit(const ray& r, double ray_tmin, double ray_tmax, hit_record& rec) const = 0;
};

#endif

#ifndef SPHERE_H
#define SPHERE_H

#include "hittable.h"
#include "vec3.h"

class sphere : public hittable {
  public:
    sphere(const point3& center, double radius) : center(center), radius(std::fmax(0,radius)) {}

    bool hit(const ray& r, double ray_tmin, double ray_tmax, hit_record& rec) const override {
        vec3 oc = center - r.origin();
        auto a = r.direction().length_squared();
        auto h = dot(r.direction(), oc);
        auto c = oc.length_squared() - radius*radius;

        auto discriminant = h*h - a*c;
        if (discriminant < 0)
            return false;

        auto sqrtd = std::sqrt(discriminant);

        // Find the nearest root that lies in the acceptable range.
        auto root = (h - sqrtd) / a;
        if (root <= ray_tmin || ray_tmax <= root) {
            root = (h + sqrtd) / a;
            if (root <= ray_tmin || ray_tmax <= root)
                return false;
        }

        rec.t = root;
        rec.p = r.at(rec.t);
        rec.normal = (rec.p - center) / radius;

        return true;
    }

  private:
    point3 center;
    double radius;
};

#endif

正面与背面

法线的第二个设计决策是它们是否应该始终指出。目前，找到的法线将始终在中心到交点的方向上 （法线指向外）。如果光线从外部与球体相交，则法线指向光线。如果光线从内部与球体相交，则法线（始终指向外）与光线相交。或者，我们可以让法线始终指向射线。如果光线位于球体外部，则法线将指向外部，但如果光线位于球体内部，则法线将指向内部。

 
图 7：球体表面法线几何体的可能方向

我们需要选择其中一种可能性，因为我们最终需要确定光线来自表面的哪一侧。这对于每侧渲染方式不同的对象（如双面纸上的文本）或具有内部和外部的对象（如玻璃球）非常重要。

如果我们决定让法线始终指向，那么在给光线着色时，我们需要确定光线在哪一侧。我们可以通过将光线与法线进行比较来解决这个问题。如果射线和法线面朝同一方向，则射线位于对象内部，如果射线和法线面朝相反方向，则射线位于对象外部。这可以通过取两个向量的点积来确定，如果它们的点为正，则射线位于球体内。

if (dot(ray_direction, outward_normal) > 0.0) {
    // ray is inside the sphere
    ...
} else {
    // ray is outside the sphere
    ...
}

bool front_face;
if (dot(ray_direction, outward_normal) > 0.0) {
    // ray is inside the sphere
    normal = -outward_normal;
    front_face = false;
} else {
    // ray is outside the sphere
    normal = outward_normal;
    front_face = true;
}

我们可以进行设置，使法线始终从表面“向外”指向，或始终指向入射光线。此决定取决于您是要在几何相交时还是在着色时确定曲面的一侧。在这本书中，我们的材质类型比几何体类型多，因此我们将减少工作量，并在几何体时确定。这只是一个偏好问题，您将在文献中看到这两种实现。

我们将 front_face bool 添加到 hit_record 类中。我们还将添加一个函数来为我们解决这个计算：set_face_normal（）。为方便起见，我们假设传递给新 set_face_normal（） 函数的向量是单位长度。我们总是可以显式地规范化参数，但如果几何代码这样做会更有效，因为当你对特定几何有更多了解时，通常会更容易。

class hit_record {
  public:
    point3 p;
    vec3 normal;
    double t;
    bool front_face;

    void set_face_normal(const ray& r, const vec3& outward_normal) {
        // Sets the hit record normal vector.
        // NOTE: the parameter `outward_normal` is assumed to have unit length.

        front_face = dot(r.direction(), outward_normal) < 0;
        normal = front_face ? outward_normal : -outward_normal;
    }
};

class sphere : public hittable {
  public:
    ...
    bool hit(const ray& r, double ray_tmin, double ray_tmax, hit_record& rec) const {
        ...

        rec.t = root;
        rec.p = r.at(rec.t);
        vec3 outward_normal = (rec.p - center) / radius;
        rec.set_face_normal(r, outward_normal);

        return true;
    }
    ...
};

可点击对象列表

我们有一个称为 hittable 的通用对象，光线可以与之相交。现在，我们添加一个存储可击中列表的类：

#ifndef HITTABLE_LIST_H
#define HITTABLE_LIST_H

#include "hittable.h"

#include <memory>
#include <vector>

using std::make_shared;
using std::shared_ptr;

class hittable_list : public hittable {
  public:
    std::vector<shared_ptr<hittable>> objects;

    hittable_list() {}
    hittable_list(shared_ptr<hittable> object) { add(object); }

    void clear() { objects.clear(); }

    void add(shared_ptr<hittable> object) {
        objects.push_back(object);
    }

    bool hit(const ray& r, double ray_tmin, double ray_tmax, hit_record& rec) const override {
        hit_record temp_rec;
        bool hit_anything = false;
        auto closest_so_far = ray_tmax;

        for (const auto& object : objects) {
            if (object->hit(r, ray_tmin, closest_so_far, temp_rec)) {
                hit_anything = true;
                closest_so_far = temp_rec.t;
                rec = temp_rec;
            }
        }

        return hit_anything;
    }
};

#endif

Some New C++ Features

The hittable_list class code uses some C++ features that may trip you up if you're not normally a C++ programmer: vector, shared_ptr, and make_shared.

shared_ptr<type> is a pointer to some allocated type, with reference-counting semantics. Every time you assign its value to another shared pointer (usually with a simple assignment), the reference count is incremented. As shared pointers go out of scope (like at the end of a block or function), the reference count is decremented. Once the count goes to zero, the object is safely deleted.

shared_ptr<double> double_ptr = make_shared<double>(0.37);
shared_ptr<vec3>   vec3_ptr   = make_shared<vec3>(1.414214, 2.718281, 1.618034);
shared_ptr<sphere> sphere_ptr = make_shared<sphere>(point3(0,0,0), 1.0);

make_shared<thing>(thing_constructor_params ...) allocates a new instance of type thing, using the constructor parameters. It returns a shared_ptr<thing>.

auto double_ptr = make_shared<double>(0.37);
auto vec3_ptr   = make_shared<vec3>(1.414214, 2.718281, 1.618034);
auto sphere_ptr = make_shared<sphere>(point3(0,0,0), 1.0);

We'll use shared pointers in our code, because it allows multiple geometries to share a common instance (for example, a bunch of spheres that all use the same color material), and because it makes memory management automatic and easier to reason about.

std::shared_ptr is included with the <memory> header.

The second C++ feature you may be unfamiliar with is std::vector. This is a generic array-like collection of an arbitrary type. Above, we use a collection of pointers to hittable. std::vector automatically grows as more values are added: objects.push_back(object) adds a value to the end of the std::vector member variable objects.

std::vector is included with the <vector> header.

最后，清单 21 中的 using 语句告诉编译器，我们将从 std 库中获取 shared_ptr 和 make_shared，因此我们不需要在每次引用它们时都用 std：：作为前缀。

常用常量和效用函数

我们需要一些数学常量，我们可以方便地在它们自己的头文件中定义这些常量。现在我们只需要 infinity，但我们也会把我们自己的 pi 定义放进去，我们稍后会用到。我们还将在此处提供常见的有用常量和未来的实用函数。这个新的头文件 rtweekend.h 将成为我们的通用主头文件。

#ifndef RTWEEKEND_H
#define RTWEEKEND_H

#include <cmath>
#include <iostream>
#include <limits>
#include <memory>


// C++ Std Usings

using std::make_shared;
using std::shared_ptr;

// Constants

const double infinity = std::numeric_limits<double>::infinity();
const double pi = 3.1415926535897932385;

// Utility Functions

inline double degrees_to_radians(double degrees) {
    return degrees * pi / 180.0;
}

// Common Headers

#include "color.h"
#include "ray.h"
#include "vec3.h"

#endif

程序文件将首先包含 rtweekend.h，因此所有其他头文件（我们的大部分代码将驻留在这里）可以隐式地假设已经包含 rtweekend.h。头文件仍需要显式包含任何其他必要的头文件。我们将根据这些假设进行一些更新。

#include <iostream>

#include "ray.h"

#include <memory>
#include <vector>

using std::make_shared;
using std::shared_ptr;

#include "vec3.h"

#include <cmath>
#include <iostream>

#include "rtweekend.h"

#include "color.h"
#include "ray.h"
#include "vec3.h"
#include "hittable.h"
#include "hittable_list.h"
#include "sphere.h"

#include <iostream>

double hit_sphere(const point3& center, double radius, const ray& r) {
    ...
}

color ray_color(const ray& r, const hittable& world) {
    hit_record rec;
    if (world.hit(r, 0, infinity, rec)) {
        return 0.5 * (rec.normal + color(1,1,1));
    }

    vec3 unit_direction = unit_vector(r.direction());
    auto a = 0.5*(unit_direction.y() + 1.0);
    return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
}

int main() {

    // Image

    auto aspect_ratio = 16.0 / 9.0;
    int image_width = 400;

    // Calculate the image height, and ensure that it's at least 1.
    int image_height = int(image_width / aspect_ratio);
    image_height = (image_height < 1) ? 1 : image_height;

    // World

    hittable_list world;

    world.add(make_shared<sphere>(point3(0,0,-1), 0.5));
    world.add(make_shared<sphere>(point3(0,-100.5,-1), 100));

    // Camera

    auto focal_length = 1.0;
    auto viewport_height = 2.0;
    auto viewport_width = viewport_height * (double(image_width)/image_height);
    auto camera_center = point3(0, 0, 0);

    // Calculate the vectors across the horizontal and down the vertical viewport edges.
    auto viewport_u = vec3(viewport_width, 0, 0);
    auto viewport_v = vec3(0, -viewport_height, 0);

    // Calculate the horizontal and vertical delta vectors from pixel to pixel.
    auto pixel_delta_u = viewport_u / image_width;
    auto pixel_delta_v = viewport_v / image_height;

    // Calculate the location of the upper left pixel.
    auto viewport_upper_left = camera_center
                             - vec3(0, 0, focal_length) - viewport_u/2 - viewport_v/2;
    auto pixel00_loc = viewport_upper_left + 0.5 * (pixel_delta_u + pixel_delta_v);

    // Render

    std::cout << "P3\n" << image_width << ' ' << image_height << "\n255\n";

    for (int j = 0; j < image_height; j++) {
        std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
        for (int i = 0; i < image_width; i++) {
            auto pixel_center = pixel00_loc + (i * pixel_delta_u) + (j * pixel_delta_v);
            auto ray_direction = pixel_center - camera_center;
            ray r(camera_center, ray_direction);

            color pixel_color = ray_color(r, world);
            write_color(std::cout, pixel_color);
        }
    }

    std::clog << "\rDone.                 \n";
}

这将生成一张图片，该图片实际上只是球体所在位置及其表面法线的可视化。这通常是查看几何模型的任何缺陷或特定特征的好方法。

Image 5: Resulting render of normals-colored sphere with ground

An Interval Class

Before we continue, we'll implement an interval class to manage real-valued intervals with a minimum and a maximum. We'll end up using this class quite often as we proceed.

#ifndef INTERVAL_H
#define INTERVAL_H

class interval {
  public:
    double min, max;

    interval() : min(+infinity), max(-infinity) {} // Default interval is empty

    interval(double min, double max) : min(min), max(max) {}

    double size() const {
        return max - min;
    }

    bool contains(double x) const {
        return min <= x && x <= max;
    }

    bool surrounds(double x) const {
        return min < x && x < max;
    }

    static const interval empty, universe;
};

const interval interval::empty    = interval(+infinity, -infinity);
const interval interval::universe = interval(-infinity, +infinity);

#endif

// Common Headers

#include "color.h"
#include "interval.h"
#include "ray.h"
#include "vec3.h"

class hittable {
  public:
    ...
    virtual bool hit(const ray& r, interval ray_t, hit_record& rec) const = 0;
};

class hittable_list : public hittable {
  public:
    ...
    bool hit(const ray& r, interval ray_t, hit_record& rec) const override {
        hit_record temp_rec;
        bool hit_anything = false;
        auto closest_so_far = ray_t.max;

        for (const auto& object : objects) {
            if (object->hit(r, interval(ray_t.min, closest_so_far), temp_rec)) {
                hit_anything = true;
                closest_so_far = temp_rec.t;
                rec = temp_rec;
            }
        }

        return hit_anything;
    }
    ...
};

class sphere : public hittable {
  public:
    ...
    bool hit(const ray& r, interval ray_t, hit_record& rec) const override {
        ...

        // Find the nearest root that lies in the acceptable range.
        auto root = (h - sqrtd) / a;
        if (!ray_t.surrounds(root)) {
            root = (h + sqrtd) / a;
            if (!ray_t.surrounds(root))
                return false;
        }
        ...
    }
    ...
};

color ray_color(const ray& r, const hittable& world) {
    hit_record rec;
    if (world.hit(r, interval(0, infinity), rec)) {
        return 0.5 * (rec.normal + color(1,1,1));
    }

    vec3 unit_direction = unit_vector(r.direction());
    auto a = 0.5*(unit_direction.y() + 1.0);
    return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
}

Moving Camera Code Into Its Own Class

Before continuing, now is a good time to consolidate our camera and scene-render code into a single new class: the camera class. The camera class will be responsible for two important jobs:

1. Construct and dispatch rays into the world.
2. Use the results of these rays to construct the rendered image.

In this refactoring, we'll collect the ray_color() function, along with the image, camera, and render sections of our main program. The new camera class will contain two public methods initialize() and render(), plus two private helper methods get_ray() and ray_color().

Ultimately, the camera will follow the simplest usage pattern that we could think of: it will be default constructed no arguments, then the owning code will modify the camera's public variables through simple assignment, and finally everything is initialized by a call to the initialize() function. This pattern is chosen instead of the owner calling a constructor with a ton of parameters or by defining and calling a bunch of setter methods. Instead, the owning code only needs to set what it explicitly cares about. Finally, we could either have the owning code call initialize(), or just have the camera call this function automatically at the start of render(). We'll use the second approach.

After main creates a camera and sets default values, it will call the render() method. The render() method will prepare the camera for rendering and then execute the render loop.

#ifndef CAMERA_H
#define CAMERA_H

#include "hittable.h"

class camera {
  public:
    /* Public Camera Parameters Here */

    void render(const hittable& world) {
        ...
    }

  private:
    /* Private Camera Variables Here */

    void initialize() {
        ...
    }

    color ray_color(const ray& r, const hittable& world) const {
        ...
    }
};

#endif

class camera {
  ...

  private:
    ...


    color ray_color(const ray& r, const hittable& world) const {
        hit_record rec;

        if (world.hit(r, interval(0, infinity), rec)) {
            return 0.5 * (rec.normal + color(1,1,1));
        }

        vec3 unit_direction = unit_vector(r.direction());
        auto a = 0.5*(unit_direction.y() + 1.0);
        return (1.0-a)*color(1.0, 1.0, 1.0) + a*color(0.5, 0.7, 1.0);
    }
};

#endif

class camera {
  public:
    double aspect_ratio = 1.0;  // Ratio of image width over height
    int    image_width  = 100;  // Rendered image width in pixel count

    void render(const hittable& world) {
        initialize();

        std::cout << "P3\n" << image_width << ' ' << image_height << "\n255\n";

        for (int j = 0; j < image_height; j++) {
            std::clog << "\rScanlines remaining: " << (image_height - j) << ' ' << std::flush;
            for (int i = 0; i < image_width; i++) {
                auto pixel_center = pixel00_loc + (i * pixel_delta_u) + (j * pixel_delta_v);
                auto ray_direction = pixel_center - center;
                ray r(center, ray_direction);

                color pixel_color = ray_color(r, world);
                write_color(std::cout, pixel_color);
            }
        }

        std::clog << "\rDone.                 \n";
    }

  private:
    int    image_height;   // Rendered image height
    point3 center;         // Camera center
    point3 pixel00_loc;    // Location of pixel 0, 0
    vec3   pixel_delta_u;  // Offset to pixel to the right
    vec3   pixel_delta_v;  // Offset to pixel below

    void initialize() {
        image_height = int(image_width / aspect_ratio);
        image_height = (image_height < 1) ? 1 : image_height;

        center = point3(0, 0, 0);

        // Determine viewport dimensions.
        auto focal_length = 1.0;
        auto viewport_height = 2.0;
        auto viewport_width = viewport_height * (double(image_width)/image_height);

        // Calculate the vectors across the horizontal and down the vertical viewport edges.
        auto viewport_u = vec3(viewport_width, 0, 0);
        auto viewport_v = vec3(0, -viewport_height, 0);

        // Calculate the horizontal and vertical delta vectors from pixel to pixel.
        pixel_delta_u = viewport_u / image_width;
        pixel_delta_v = viewport_v / image_height;

        // Calculate the location of the upper left pixel.
        auto viewport_upper_left =
            center - vec3(0, 0, focal_length) - viewport_u/2 - viewport_v/2;
        pixel00_loc = viewport_upper_left + 0.5 * (pixel_delta_u + pixel_delta_v);
    }

    color ray_color(const ray& r, const hittable& world) const {
        ...
    }
};

#endif

#include "rtweekend.h"

#include "camera.h"
#include "hittable.h"
#include "hittable_list.h"
#include "sphere.h"

color ray_color(const ray& r, const hittable& world) {
    ...
}

int main() {
    hittable_list world;

    world.add(make_shared<sphere>(point3(0,0,-1), 0.5));
    world.add(make_shared<sphere>(point3(0,-100.5,-1), 100));

    camera cam;

    cam.aspect_ratio = 16.0 / 9.0;
    cam.image_width  = 400;

    cam.render(world);
}

Running this newly refactored program should give us the same rendered image as before.

Antialiasing

If you zoom into the rendered images so far, you might notice the harsh “stair step” nature of edges in our rendered images. This stair-stepping is commonly referred to as “aliasing”, or “jaggies”. When a real camera takes a picture, there are usually no jaggies along edges, because the edge pixels are a blend of some foreground and some background. Consider that unlike our rendered images, a true image of the world is continuous. Put another way, the world (and any true image of it) has effectively infinite resolution. We can get the same effect by averaging a bunch of samples for each pixel.

通过单个光线穿过每个像素的中心，我们正在执行通常所说的点采样。点采样的问题可以通过在很远的地方渲染一个小棋盘来说明。如果这个棋盘格由一个 8×8 的黑白图块网格组成，但只有四条光线击中它，那么所有四条光线可能只与白色图块相交，或者只与黑色图块相交，或者一些奇怪的组合。在现实世界中，当我们用眼睛感知远处的棋盘格时，我们会将其感知为灰色，而不是尖锐的黑白点。这是因为我们的眼睛自然而然地在做我们希望光线追踪器做的事情：整合落在渲染图像的特定（离散）区域的光（连续功能）。

显然，仅仅通过多次通过像素中心对同一条光线进行重采样并不会获得任何好处 — 每次我们只会得到相同的结果。相反，我们希望对落在像素周围的光线进行采样，然后对这些样本进行积分以近似于真正的连续结果。那么，我们如何整合落在像素周围的光线呢？

我们将采用最简单的模型：对以像素为中心的方形区域进行采样，该像素延伸到四个相邻像素中每个像素的一半。这不是最佳方法，但却是最直接的方法。（有关此主题的更深入探讨，请参阅 像素不是小方块。

 
图 8：像素样本

一些随机数实用程序

我们需要一个返回实数的随机数生成器。此函数应 返回一个规范随机数，按照惯例，该随机数位于 . 0≤n<1$0\le n<1$ “更少 than“很重要，因为我们有时会利用这一点。

A simple approach to this is to use the std::rand() function that can be found in <cstdlib>, which returns a random integer in the range 0 and RAND_MAX. Hence we can get a real random number as desired with the following code snippet, added to rtweekend.h:

#include <cmath>
#include <cstdlib>
#include <iostream>
#include <limits>
#include <memory>
...

// Utility Functions

inline double degrees_to_radians(double degrees) {
    return degrees * pi / 180.0;
}

inline double random_double() {
    // Returns a random real in [0,1).
    return std::rand() / (RAND_MAX + 1.0);
}

inline double random_double(double min, double max) {
    // Returns a random real in [min,max).
    return min + (max-min)*random_double();
}