English
Computer graphics constructs images and other visual representations by computation. A renderer takes a scene description—geometry, materials, lights, and a camera—and estimates the image that this scene would produce. Modeling and animation specify the scene and its changes over time. Visualization also asks how to encode data so that a viewer can understand it; a useful image need not be a physically realistic one.
A beginner can separate three questions: what is represented, what image is requested, and how much computation is available? A triangle mesh describes surfaces; a camera specifies a projection; a rendering algorithm estimates visibility and appearance. Changing one can alter the image without changing the others. This separation helps locate errors instead of treating a wrong-looking image as one undifferentiated graphics problem.
Visual computing connects graphics to image processing and computer vision. Rendering predicts an image from a scene; reconstruction tries to infer a scene from images. The latter is generally ambiguous: several combinations of shape, material, and lighting can explain similar observations. Learned representations (§5.3) add useful methods, while geometry, sampling, and camera models remain important.
Prerequisites: Linear algebra (§2.3) for coordinates and transformations; calculus (§2.4) and probability (§2.5) for light transport and sampling. Basic programming is enough to begin drawing and transforming simple shapes; GPU architecture (§4.1) becomes useful when studying performance.
From Oscilloscopes to Neural Radiance Fields
Interactive graphics developed from earlier work on electronic displays, plotting, and real-time systems. Sutherland’s 1963 Sketchpad was an influential demonstration of drawing and editing geometric objects with a light pen. It stored objects and relationships rather than only marks on a display. A constraint such as keeping two lines perpendicular could survive an edit. The distinction between a model and its displayed image made graphical interaction more useful.
As raster displays spread, visibility and shading became separate computational problems: which surface contributes to a sample, and what color should it contribute? Gouraud shading interpolated vertex colors; Phong shading interpolated normals before evaluating lighting. Phong also proposed a reflection model, which is a different idea from the interpolation method. Smoother interpolation improved appearance without adding geometric detail or solving all light transport.
Appel’s and Whitted’s ray-tracing work showed how intersections and secondary rays could calculate shadows, reflections, and refractions. These effects were not impossible with rasterization; alternative techniques could approximate or construct them. Ray tracing offered a way to query geometry along arbitrary directions. Whitted-style recursive tracing and Monte Carlo path tracing are related methods with different sampling and transport capabilities.
Kajiya’s 1986 rendering equation expressed outgoing surface light in terms of emission and reflected incoming light. It supported a common mathematical account of algorithms for global illumination. Veach’s later work developed Monte Carlo methods for difficult transport problems. The equation is a model: the usual surface form assumes geometric optics and needs extensions for participating media or other phenomena. A renderer can accurately solve its chosen model while that model omits a physical effect.
Film rendering and interactive graphics developed under different time budgets. RenderMan supported programmable production shading, while graphics accelerators moved repeated projection, rasterization, and texture operations into hardware. Programmable shaders gave developers more control over these operations. Hardware ray-tracing support later reduced some intersection and traversal costs; it did not remove the need to budget rays, memory, and reconstruction work.
Physically based material models made it easier to reason about reflectance, energy, and lighting consistently. Pharr and Humphreys’s first PBRT edition appeared in 2004; later editions with Jakob connected theory to increasingly capable implementations. Production material models also account for artistic control. Physical plausibility, speed, controllability, and a particular visual style remain different design goals.
NeRF in 2020 fitted a radiance-and-density representation from images and rendered new views by integrating along camera rays. The 2023 3D Gaussian Splatting work optimized explicit Gaussian primitives for view synthesis. Neither method is simply conventional path tracing with a new surface format. They made the dependence on capture coverage, camera estimation, and reconstruction assumptions especially visible. Generative models, denoisers, and upscalers add further tools, whose effects should be distinguished from recovering measured scene detail.
Rendering, Representation, and Real-Time Performance
The Rendering Pipeline: From Scene to Pixels
A geometric pipeline transforms object coordinates into world and camera coordinates, projects them, and determines contributions to image samples. In a simple pinhole camera looking along positive depth, with focal length 1 and image coordinates centered at the optical axis, (x,y,z) projects to (x/z,y/z). Thus (2,1,4) projects to (0.5,0.25). Depth changes apparent size even when the object itself is unchanged. Coordinate conventions and units must agree across the pipeline.
Rasterization determines which samples are covered by projected primitives. Attributes such as normals and texture coordinates are interpolated, and shaders calculate contributions. A depth buffer helps retain the nearest opaque surface at each sample. Fragments, samples, and displayed pixels are not identical: multiple fragments may compete, multisampling evaluates several coverage locations, and filtering combines information. Transparency and effects involving hidden surfaces need additional handling.
Ray tracing asks which geometry a ray intersects, usually using an acceleration structure such as a bounding-volume hierarchy. Shadow rays test light visibility; other rays can sample reflected or transmitted light. Tracing rays alone does not guarantee physical accuracy: material models, sampling, geometry, and which interactions are included determine the result. Hybrid renderers combine rasterization with selected ray queries.
For an opaque reflecting surface under the usual geometric-optics assumptions, outgoing radiance obeys L_o = L_e + ∫_Ω f_r L_i cosθ dω. Here L_e is emission, f_r is the BRDF, and the integral accumulates reflected incoming radiance over the outward hemisphere. The cosine accounts for projected area. For a Lambertian surface with reflectance ρ, f_r = ρ/π; reflectance and the value of the BRDF are not the same quantity.
Path tracing samples sequences of scattering events to estimate this transport. Monte Carlo integration weights each sampled contribution by its sampling density, which must cover the contributing region. An independent-sample estimator with finite variance has variance σ²/n and standard error σ/√n: reducing typical noise by half takes roughly four times as many samples. Unbiasedness describes the estimator under its assumptions, not every implementation. Clamping contributions, truncating paths, or denoising can introduce bias; correctly weighted Russian roulette can terminate paths without that truncation bias. PBRT develops this sampling view.
Sampling also affects geometry and textures. A fine repeating pattern can appear as false coarse stripes when undersampled. Antialiasing estimates pixel-area contributions instead of treating one point as the whole pixel; texture filtering and mipmaps use related ideas. More pixels, more light samples, and better filtering address different errors. Identify which error is visible before increasing every quality setting.
Geometric Representation
A representation makes some operations easy and others expensive. Triangle meshes describe surfaces through vertices and connectivity. They support rasterization, intersection tests, and local editing, but resolving fine curvature requires more elements. Texture and normal maps can change shading detail without changing the silhouette or collision surface.
Parametric and subdivision surfaces describe smooth shapes through parameters or control meshes. Evaluating or tessellating them produces samples or polygons for rendering. Continuity and behavior near special vertices depend on the chosen construction; a compact smooth model still needs finite computation to display and intersect.
A signed distance field assigns a point’s distance to a surface, with a sign distinguishing inside from outside. Under one common convention, outside is positive. From outside, sphere tracing can safely step by an exact distance or a conservative lower bound because no surface lies inside that radius. An arbitrary implicit function—or an imperfect learned distance estimate—does not automatically provide this guarantee. Numerical tolerances, thin features, and transformations require care.
NeRF uses a learned density-and-radiance field; a neural SDF instead represents a surface through distance. These are different quantities. Gaussian splatting represents appearance with positioned, oriented, colored primitives and opacity. Image-based optimization can produce useful new views without yielding the clean, watertight geometry needed for manufacturing or collision tests. Evaluate the representation for the intended operation: view synthesis, editing, relighting, simulation, or measurement.
GPU Architecture and Real-Time Performance
A GPU executes many work items using shared execution and memory resources. Shader invocations may process vertices, fragments, or general compute tasks. Nearby work that follows similar control flow and accesses nearby data often uses these resources efficiently. Divergence, irregular memory access, synchronization, and register pressure can reduce useful throughput; more parallel tasks do not guarantee proportional speedup.
Textures, geometry, and intermediate buffers compete for bandwidth and cache capacity. Texture units provide specialized sampling and filtering. Rendering performance can be limited by geometry processing, fragment shading, memory traffic, ray traversal, CPU submission, or synchronization. A frame capture shows which passes and resources are present; timing and profiling help determine which actually limit performance.
At 60 frames per second, the nominal frame budget is about 1000/60 ≈ 16.7 ms. If GPU work is the limiting stage and takes 20 ms, shortening already-overlapped CPU work from 8 ms to 4 ms may leave throughput unchanged. End-to-end input latency is a separate measurement from frame throughput. Measure representative scenes and frame-time distributions, including slow frames.
Level of detail chooses representations appropriate to projected size and error. Culling avoids work that cannot affect the requested image; occlusion and transparency complicate that decision. Virtualized geometry systems such as Nanite automate parts of streaming and detail selection within supported workloads. They still have geometry, memory, material, and bandwidth costs. Validate a change by comparing both performance and visible error.
What Studying This Changes
You should be able to trace one point from object coordinates to an image sample and explain where visibility, material evaluation, and filtering enter. Build a small rasterizer or ray tracer, change one operation at a time, and predict the result before rendering.
For a sampling experiment, render the same scene with 100 and 400 independent samples per pixel, using the same unbiased estimator. Compare error over repeated runs against a high-quality reference. The expected reduction concerns the sampling error scale, not a guarantee that every individual pixel improves in every run.
For a performance experiment, capture a frame and identify a costly pass. Change geometry detail, shader work, or output resolution separately, then check which change moves frame time. These exercises connect linear algebra, probability, data structures, and parallel architecture to an observable result.
Resources
Books and Texts
Use Physically Based Rendering to connect sampling and light transport with an implementation, and Real-Time Rendering to study techniques under a frame budget. Computer Graphics: Principles and Practice and Lengyel’s mathematics text provide broader foundations. Select chapters around a small renderer rather than trying to read every reference first. Munzner’s visualization text addresses a different question: whether visual encodings help people understand data.
| Book | Role | Type |
|---|---|---|
| Pharr, Jakob & Humphreys, Physically Based Rendering (4th ed., free) | Light transport, sampling, and implementation | Entry |
| Akenine-Möller et al., Real-Time Rendering (4th ed.) | Real-time rendering canonical reference | Reference |
| Hughes et al., Computer Graphics: Principles and Practice (3rd ed.) | Comprehensive foundational textbook | Reference |
| Lengyel, Mathematics for 3D Game Programming and Computer Graphics | Graphics mathematics | Entry |
| Gregory, Game Engine Architecture (3rd ed.) | Game engine systems | Depth |
| Botsch et al., Polygon Mesh Processing (free) | Geometry processing | Depth |
| Bridson, Fluid Simulation for Computer Graphics (2nd ed.) | Physics simulation | Depth |
| Munzner, Visualization Analysis and Design | Information visualization | Entry |
| Veach, PhD thesis (free) | Monte Carlo rendering foundations | Depth |
| The Graphics Codex (free samples; paid app/full access may apply) | Compact reference for graphics mathematics, rendering, and implementation details | Reference |
Courses and Lectures
The published Stanford CS148/CS348b and Berkeley CS184/284 materials combine concepts with implementation exercises. The Book of Shaders provides small visual experiments; LearnOpenGL and other API tutorials explain a particular programming interface. Pair an API exercise with a calculation of coordinates, coverage, or sampling so the operation is understandable independently of that interface.
| Course | Platform | Type |
|---|---|---|
| Stanford CS148/CS348b (free) | Stanford course site | Entry |
| UC Berkeley CS184/284 (free) | Berkeley course site | Entry |
| Cem Yuksel YouTube lectures (free) | YouTube | Practice |
| The Book of Shaders (free) | thebookofshaders.com | Practice |
| LearnOpenGL (free) | learnopengl.com | Practice |
| Scratchapixel (free) | scratchapixel.com | Entry |
| WebGPU Fundamentals (free) | webgpufundamentals.org | Practice |
| Vulkan Tutorial / Khronos Vulkan Learn (free) | vulkan-tutorial.com / vulkan.org | Practice |
Practice, Tools, and Current Sources
Inspect a PBRT integrator, modify a small shader, or build a controlled scene in Blender. Use a frame debugger such as RenderDoc when it supports the platform and API in use; combine captures with appropriate profiling. For NeRF and Gaussian Splatting, read the original paper and author implementation together, checking capture conditions, camera information, and which outputs were evaluated. Keep a reference image and a record of each experimental change.
| Resource | Platform | Type |
|---|---|---|
| PBRT source code (free) | github.com/mmp/pbrt-v4 | Practice |
| RenderDoc (free) | renderdoc.org | Practice |
| Shadertoy (free) | shadertoy.com | Practice |
| Blender (free) | blender.org | Practice |
| Mildenhall et al., NeRF code (free) | GitHub | Practice |
| Kerbl et al., Gaussian Splatting code (free) | GitHub | Practice |
| SIGGRAPH papers and author versions | dl.acm.org / author project pages | Reference |
| Inigo Quilez’s website (free) | iquilezles.org | Practice |
Traps
| Trap | Why it misleads | Better response |
|---|---|---|
| Equating an API with graphics | An API exposes operations but does not explain their geometric or sampling meaning. | Trace coordinates, coverage, shading, and filtering in one small implementation. |
| Deferring practice until every mathematical prerequisite is complete | The needed mathematics depends on the operation being studied. | Start with transformations and simple images, then derive the sampling and transport methods you use. |
| Treating real-time and offline rendering as unrelated | They share representations and light-transport ideas under different budgets. | Compare the same effect under different time, noise, and memory constraints. |
| Assuming view synthesis provides any desired scene operation | Good novel views do not establish editable geometry, correct relighting, or collision surfaces. | Test the representation against the operation your application requires. |
| Optimizing without locating the bottleneck | Reducing work outside the limiting stage may not improve frame throughput. | Combine frame inspection with timings and change one cost at a time. |
| Treating a plausible image as a validated model | Noise, aliasing, model bias, and artistic choices have different causes. | Use controlled reference scenes and separate numerical error from the chosen appearance. |
中文
计算机图形学通过计算构造图像和其他视觉表示。渲染器接收场景描述——几何、材质、光源和相机——估计这个场景会产生怎样的图像。建模和动画描述场景及其随时间的变化。可视化还研究怎样编码数据，帮助人理解；有用的图像不一定追求物理真实。
初学者可以先区分三个问题：表示什么、需要怎样的图像、能花多少计算成本？三角网格描述表面，相机规定投影，渲染算法估计可见性与外观。改变其中一项，即使其他项不变，图像也可能变化。这样分开思考，有助于定位错误，而不是把所有“不好看”都当成同一个问题。
视觉计算将图形学与图像处理、计算机视觉联系起来。渲染从场景预测图像，重建则试图从图像推断场景。后者通常有歧义：不同的形状、材质和光照组合，可能解释相似的观测。学习得到的表示（§5.3）提供了新方法，几何、采样和相机模型仍然重要。
前置知识：线性代数（§2.3）用于坐标和变换，微积分（§2.4）与概率（§2.5）用于光传输和采样。具备基本编程能力就可以开始绘制、变换简单形状；研究性能时再深入 GPU 架构（§4.1）。
从示波器到神经辐射场
交互图形学建立在电子显示、绘图和实时系统等早期工作之上。Sutherland 的 1963 年 Sketchpad 展示了如何用光笔绘制、编辑几何对象。它保存对象和关系，而不只是屏幕上的笔画。例如，让两条线保持垂直的约束，可以在编辑后继续成立。模型与显示图像的分离，使图形交互更有用。
随着光栅显示普及，可见性和着色成为可以分开处理的计算问题：哪个表面对一个采样位置有贡献，它应贡献什么颜色？Gouraud 着色插值顶点颜色，Phong 着色则先插值法向，再计算光照。Phong 还提出了反射模型，这与插值方法是两件不同的事。更平滑的插值可以改善外观，但并没有增加几何细节，也没有解决所有光传输问题。
Appel 和 Whitted 的光线追踪工作展示了如何用求交和次级光线计算阴影、反射与折射。光栅化并非完全不能表现这些效果，其他技术也能近似或构造它们。光线追踪提供了沿任意方向查询几何的方法。Whitted 式递归追踪与蒙特卡洛路径追踪相关，但采样方式和处理光传输的能力不同。
Kajiya 在 1986 年提出的渲染方程，用自发光与反射的入射光表达表面向外传播的光，为全局光照算法提供了共同的数学描述。Veach 后来的研究进一步发展了处理困难光传输问题的蒙特卡洛方法。方程本身也是模型：常见的表面形式采用几何光学假设，处理参与介质等现象还需要扩展。渲染器可能准确求解了选定模型，但模型仍遗漏某种物理效应。
电影渲染与交互图形在不同的时间预算下发展。RenderMan 支持可编程的制作流程着色，图形加速器则把重复的投影、光栅化和纹理操作移入硬件。可编程着色器让开发者进一步控制这些操作。后来的硬件光线追踪降低了部分求交和遍历成本，但仍需要分配光线、内存和图像重建的预算。
基于物理的材质模型，使反射率、能量和光照更容易得到一致解释。Pharr 与 Humphreys 的 PBRT 第一版发表于 2004 年，Jakob 参与的后续版本继续将理论与实现联系起来。制作使用的材质模型也考虑艺术控制。物理合理性、速度、可控性和特定视觉风格，仍然是不同的设计目标。
2020 年的 NeRF 从图像拟合辐射与密度表示，再沿相机光线积分以生成新视角。2023 年的 3D Gaussian Splatting 则优化显式的高斯基元以合成视图。这两种方法都不能简单理解成换了表面格式的传统路径追踪。它们也使拍摄覆盖、相机估计和重建假设的重要性更明显。生成模型、降噪器和超分辨率方法增加了工具选择，其效果应与恢复实际测得的场景细节区分开。
渲染、表示与实时性能
渲染流水线：从场景到像素
几何流水线把物体坐标变换到世界坐标、相机坐标，再进行投影，确定各部分对图像采样点的贡献。以沿正深度方向观察、焦距为 1、图像坐标原点位于光轴的简单针孔相机为例，(x,y,z) 投影为 (x/z,y/z)。因此 (2,1,4) 投影到 (0.5,0.25)。物体本身不变，深度也会改变它在图像中的大小。流水线各处的坐标约定和单位必须一致。
光栅化确定投影后的基元覆盖哪些采样位置，再插值法向、纹理坐标等属性，由着色器计算贡献。深度缓冲帮助保留各采样点处最近的不透明表面。片段、采样点和最终显示的像素并不相同：多个片段可能竞争，多重采样检查多个覆盖位置，过滤还会组合信息。透明和涉及隐藏表面的效果需要额外处理。
光线追踪查询一条光线与哪些几何对象相交，通常用包围体层次结构等加速结构。阴影光线检查光源是否可见，其他光线可以采样反射或透射的光。仅仅追踪光线并不保证物理准确；结果取决于材质模型、采样、几何，以及包含了哪些相互作用。混合渲染器把光栅化与选定的光线查询结合起来。
在通常的几何光学假设下，不透明反射表面的出射辐射亮度满足 L_o = L_e + ∫_Ω f_r L_i cosθ dω。其中 L_e 是自发光，f_r 是 BRDF，积分在向外的半球上累加入射光反射后的贡献。余弦项表示投影面积的影响。对于反射率为 ρ 的朗伯表面，f_r = ρ/π；反射率与 BRDF 的值并不是同一个量。
路径追踪通过采样一连串散射事件，估计这种光传输。蒙特卡洛积分用采样密度对各次贡献加权，采样范围必须覆盖有贡献的区域。对于方差有限的独立样本估计器，方差为 σ²/n，标准误为 σ/√n：典型噪声减半，大约需要四倍样本。“无偏”描述的是满足假设的估计器，不是每一种实现。截断贡献值、限制路径长度或降噪可能引入偏差；正确加权的俄罗斯轮盘赌可以终止路径，同时避免这种截断偏差。PBRT 系统展开了这种采样观点。
采样也影响几何与纹理。细密的重复图案在采样不足时，可能出现虚假的粗条纹。抗锯齿估计像素面积内的贡献，而不是用一个点代表整个像素；纹理过滤和 mipmap 使用相关思想。增加像素、增加光照样本与改进过滤处理的是不同错误。先识别可见问题，再调整对应的质量设置。
几何表示
一种表示会使某些操作容易，使另一些操作昂贵。三角网格通过顶点及其连接描述表面，支持光栅化、求交和局部编辑，但细致表达曲率需要更多单元。纹理和法线贴图可以改变着色细节，却不改变轮廓或碰撞表面。
参数曲面和细分曲面通过参数或控制网格描述平滑形状。求值或曲面细分产生用于渲染的采样点或多边形。连续性和特殊顶点附近的行为取决于具体构造；紧凑的平滑模型仍需有限计算才能显示和求交。
有符号距离场为每个点给出到表面的距离，并用符号区分内外。一种常见约定是外部为正。从外部出发，球面追踪可以安全地按精确距离或保守下界步进，因为这个半径内不存在表面。任意隐式函数，或有误差的学习距离估计，并不会自动提供这一保证。数值容差、薄小结构和坐标变换都需要注意。
NeRF 使用学习得到的密度与辐射场，神经 SDF 则通过距离表示表面，它们描述的量不同。高斯泼溅用具有位置、方向、颜色和不透明度的基元表示外观。通过图像优化可以生成有用的新视角，但未必得到制造或碰撞检测所需的干净、封闭几何。应按目标操作评价表示：视图合成、编辑、重新打光、模拟，还是测量。
GPU 架构与实时性能
GPU 使用共享的执行和内存资源处理大量工作项。着色器调用可以处理顶点、片段或通用计算任务。相邻工作采用相似控制流程、访问相近数据时，通常能更有效地利用资源。分支分歧、不规则访存、同步与寄存器压力都会降低有效吞吐量；任务更多不意味着按比例加速。
纹理、几何和中间缓冲竞争带宽与缓存容量。纹理单元提供专门的采样和过滤。渲染性能可能受几何处理、片段着色、内存流量、光线遍历、CPU 提交或同步限制。帧捕获展示有哪些处理阶段和资源，计时与性能分析则帮助确定真正的瓶颈。
每秒 60 帧对应的名义帧预算约为 1000/60 ≈ 16.7 ms。如果 GPU 是限制阶段，每帧需要 20 ms，那么把已经与其重叠的 CPU 工作从 8 ms 缩短到 4 ms，可能并不改变吞吐量。端到端输入延迟与帧吞吐量也应分开测量。使用有代表性的场景，观察包括慢帧在内的帧时间分布。
细节层次根据投影大小和误差选择表示。剔除可以省去不影响目标图像的工作，但遮挡和透明会使判断更复杂。Nanite 等虚拟化几何系统，在支持的工作负载中自动处理部分流送和细节选择，仍然有几何、内存、材质与带宽成本。验证一项改动时，应同时比较性能和可见误差。
学习这一部分会改变什么
学完后，应能跟踪一个点如何从物体坐标变成图像采样，并说明可见性、材质计算和过滤分别发生在哪里。编写一个小型光栅器或光线追踪器，每次只改变一个操作，先预测结果再渲染。
采样实验可以对同一场景分别使用每像素 100 和 400 个独立样本，保持无偏估计器相同。多次运行，并与高质量参考结果比较误差。预期下降的是采样误差的尺度，并不保证每次运行中每个像素都变得更准确。
性能实验可以先捕获一帧，找出成本高的处理阶段，再分别改变几何细节、着色器工作或输出分辨率，观察哪一项改变了帧时间。这些练习把线性代数、概率、数据结构和并行架构与可观察结果联系起来。
资源
书籍与文本
用 Physically Based Rendering 将采样、光传输与实现联系起来，用 Real-Time Rendering 学习帧预算下的技术。Computer Graphics: Principles and Practice 和 Lengyel 的数学教材补充更广的基础。围绕一个小渲染器选择章节，不必先读完所有参考书。Munzner 的可视化教材则处理另一个问题：视觉编码是否帮助人理解数据。
| 书籍 | 作用 | 类型 |
|---|---|---|
| Pharr, Jakob & Humphreys, Physically Based Rendering（第 4 版，免费） | 光传输、采样与实现 | 入门 |
| Akenine-Möller et al., Real-Time Rendering（第 4 版） | 实时渲染经典参考 | 参考 |
| Hughes et al., Computer Graphics: Principles and Practice（第 3 版） | 综合基础教材 | 参考 |
| Lengyel, Mathematics for 3D Game Programming and Computer Graphics | 图形学数学 | 入门 |
| Gregory, Game Engine Architecture（第 3 版） | 游戏引擎系统 | 深入 |
| Botsch et al., Polygon Mesh Processing（免费） | 几何处理 | 深入 |
| Bridson, Fluid Simulation for Computer Graphics（第 2 版） | 物理仿真 | 深入 |
| Munzner, Visualization Analysis and Design | 信息可视化 | 入门 |
| Veach, PhD thesis（免费） | 蒙特卡洛渲染基础 | 深入 |
| The Graphics Codex（免费样章；完整 app/访问可能付费） | 图形学数学、渲染和实现细节的紧凑参考 | 参考 |
课程与讲座
Stanford CS148/CS348b 与 Berkeley CS184/284 的公开材料，将概念与实现练习结合起来。The Book of Shaders 提供小型视觉实验，LearnOpenGL 等 API 教程解释具体编程接口。做接口练习时，配合坐标、覆盖或采样的计算，使操作能独立于该接口被理解。
| 课程 | 平台 | 类型 |
|---|---|---|
| Stanford CS148/CS348b（免费） | Stanford course site | 入门 |
| UC Berkeley CS184/284（免费） | Berkeley course site | 入门 |
| Cem Yuksel YouTube lectures（免费） | YouTube | 实践 |
| The Book of Shaders（免费） | thebookofshaders.com | 实践 |
| LearnOpenGL（免费） | learnopengl.com | 实践 |
| Scratchapixel（免费） | scratchapixel.com | 入门 |
| WebGPU Fundamentals（免费） | webgpufundamentals.org | 实践 |
| Vulkan Tutorial / Khronos Vulkan Learn（免费） | vulkan-tutorial.com / vulkan.org | 实践 |
实践、工具与当前资料
检查一个 PBRT 积分器、修改一个小着色器，或在 Blender 中构造受控场景。在平台与 API 受到支持时，使用 RenderDoc 等帧调试器，并配合适当的性能分析。学习 NeRF 和高斯泼溅时，结合原论文与作者实现，核对拍摄条件、相机信息和评估输出。保存参考图像及每次实验改动记录。
| 资源 | 平台 | 类型 |
|---|---|---|
| PBRT source code（免费） | github.com/mmp/pbrt-v4 | 实践 |
| RenderDoc（免费） | renderdoc.org | 实践 |
| Shadertoy（免费） | shadertoy.com | 实践 |
| Blender（免费） | blender.org | 实践 |
| Mildenhall et al., NeRF code（免费） | GitHub | 实践 |
| Kerbl et al., Gaussian Splatting code（免费） | GitHub | 实践 |
| SIGGRAPH 论文与作者版本 | dl.acm.org / 作者项目页 | 参考 |
| Inigo Quilez’s website（免费） | iquilezles.org | 实践 |
陷阱
| 误区 | 为什么会误导 | 更好的做法 |
|---|---|---|
| 把 API 等同于图形学 | API 提供操作入口，但不解释几何和采样含义。 | 在一个小实现中跟踪坐标、覆盖、着色和过滤。 |
| 等所有数学学完才开始实践 | 所需数学取决于正在研究的操作。 | 从变换和简单图像开始，再推导用到的采样与光传输方法。 |
| 把实时与离线渲染视为无关 | 它们在不同预算下共享表示与光传输思想。 | 比较同一效果在时间、噪声和内存约束下的实现。 |
| 认为视图合成支持一切场景操作 | 新视角好看不证明几何可编辑、重新打光正确或碰撞表面可用。 | 按应用需要的操作测试表示。 |
| 未定位瓶颈就优化 | 减少非限制阶段的工作未必改善帧吞吐量。 | 结合帧检查与计时，每次改变一项成本。 |
| 把看似合理的图像当成已验证的模型 | 噪声、混叠、模型偏差和艺术选择有不同原因。 | 使用受控参考场景，区分数值误差与选定外观。 |