warning

2025-08-22 20:25:28 +08:00 · 2018-02-19 22:38:57 -05:00
parent 8ed6129046
commit 2d8ea5e0be
26 changed files with 92 additions and 9 deletions
--- a/Lighting.md
+++ b/Lighting.md
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | gjy_1992

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 在光照教程中，我们简单的介绍了Phong光照模型，它给我们的场景带来的基本的现实感。Phong模型看起来还不错，但本章我们把重点放在一些细微差别上。

 ## Blinn-Phong
--- a/Correction.md
+++ b/Correction.md
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 当我们计算出场景中所有像素的最终颜色以后，我们就必须把它们显示在监视器上。过去，大多数监视器是阴极射线管显示器（CRT）。这些监视器有一个物理特性就是两倍的输入电压产生的不是两倍的亮度。输入电压产生约为输入电压的2.2次幂的亮度，这叫做监视器Gamma。

 !!! note "译注"
--- a/Lighting/03
+++ b/Lighting/03
@@ -6,7 +6,9 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | gjy_1992

+!!! note

+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。

 阴影是光线被阻挡的结果；当一个光源的光线由于其他物体的阻挡不能够达到一个物体的表面的时候，那么这个物体就在阴影中了。阴影能够使场景看起来真实得多，并且可以让观察者获得物体之间的空间位置关系。场景和物体的深度感因此能够得到极大提升，下图展示了有阴影和没有阴影的情况下的不同：

--- a/Lighting/03
+++ b/Lighting/03
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 上个教程我们学到了如何使用阴影映射技术创建动态阴影。效果不错，但它只适合定向光，因为阴影只是在单一定向光源下生成的。所以它也叫定向阴影映射，深度（阴影）贴图生成自定向光的视角。

 !!! Important
--- a/Lighting/04
+++ b/Lighting/04
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | [KenLee](https://hellokenlee.github.io/)

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 我们的场景中已经充满了多边形物体，其中每个都可能由成百上千平坦的三角形组成。我们以向三角形上附加纹理的方式来增加额外细节，提升真实感，隐藏多边形几何体是由无数三角形组成的事实。纹理确有助益，然而当你近看它们时，这个事实便隐藏不住了。现实中的物体表面并非是平坦的，而是表现出无数（凹凸不平的）细节。

 例如，砖块的表面。砖块的表面非常粗糙，显然不是完全平坦的：它包含着接缝处水泥凹痕，以及非常多的细小的空洞。如果我们在一个有光的场景中看这样一个砖块的表面，问题就出来了。下图中我们可以看到砖块纹理应用到了平坦的表面，并被一个点光源照亮。
--- a/Lighting/05
+++ b/Lighting/05
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 视差贴图(Parallax Mapping)技术和法线贴图差不多，但它有着不同的原则。和法线贴图一样视差贴图能够极大提升表面细节，使之具有深度感。它也是利用了视错觉，然而对深度有着更好的表达，与法线贴图一起用能够产生难以置信的效果。视差贴图和光照无关，我在这里是作为法线贴图的技术延续来讨论它的。需要注意的是在开始学习视差贴图之前强烈建议先对法线贴图，特别是切线空间有较好的理解。

 视差贴图属于位移贴图(Displacement Mapping)技术的一种，它对根据储存在纹理中的几何信息对顶点进行位移或偏移。一种实现的方式是比如有1000个顶点，更具纹理中的数据对平面特定区域的顶点的高度进行位移。这样的每个纹理像素包含了高度值纹理叫做高度贴图。一张简单的砖块表面的高度贴图如下所示：
--- a/Lighting/06
+++ b/Lighting/06
@@ -6,6 +6,10 @@
 翻译     | Meow J
 校对     | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 一般来说，当存储在帧缓冲(Framebuffer)中时，亮度和颜色的值是默认被限制在0.0到1.0之间的。这个看起来无辜的语句使我们一直将亮度与颜色的值设置在这个范围内，尝试着与场景契合。这样是能够运行的，也能给出还不错的效果。但是如果我们遇上了一个特定的区域，其中有多个亮光源使这些数值总和超过了1.0，又会发生什么呢？答案是这些片段中超过1.0的亮度或者颜色值会被约束在1.0，从而导致场景混成一片，难以分辨：

 ![](../img/05/06/hdr_clamped.png)
--- a/Lighting/07
+++ b/Lighting/07
@@ -6,6 +6,10 @@
 翻译     | [Django](http://bullteacher.com/)
 校对     | gjy_1992

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 明亮的光源和区域经常很难向观察者表达出来，因为监视器的亮度范围是有限的。一种区分明亮光源的方式是使它们在监视器上发出光芒，光源的的光芒向四周发散。这样观察者就会产生光源或亮区的确是强光区。（译注：这个问题的提出简单来说是为了解决这样的问题：例如有一张在阳光下的白纸，白纸在监视器上显示出是出白色，而前方的太阳也是纯白色的，所以基本上白纸和太阳就是一样的了，给太阳加一个光晕，这样太阳看起来似乎就比白纸更亮了）

 光晕效果可以使用一个后处理特效泛光来实现。泛光使所有明亮区域产生光晕效果。下面是一个使用了和没有使用光晕的对比（图片生成自虚幻引擎）：
--- a/Lighting/08
+++ b/Lighting/08
@@ -6,6 +6,10 @@
 翻译     | Meow J
 校对     | [KenLee](https://hellokenlee.github.io/)

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 我们现在一直使用的光照方式叫做**正向渲染(Forward Rendering)**或者**正向着色法(Forward Shading)**，它是我们渲染物体的一种非常直接的方式，在场景中我们根据所有光源照亮一个物体，之后再渲染下一个物体，以此类推。它非常容易理解，也很容易实现，但是同时它对程序性能的影响也很大，因为对于每一个需要渲染的物体，程序都要对每一个光源每一个需要渲染的片段进行迭代，这是**非常**多的！因为大部分片段着色器的输出都会被之后的输出覆盖，正向渲染还会在场景中因为高深的复杂度(多个物体重合在一个像素上)浪费大量的片段着色器运行时间。

 **延迟着色法(Deferred Shading)**，**或者说是延迟渲染(Deferred Rendering)**，为了解决上述问题而诞生了，它大幅度地改变了我们渲染物体的方式。这给我们优化拥有大量光源的场景提供了很多的选择，因为它能够在渲染上百甚至上千光源的同时还能够保持能让人接受的帧率。下面这张图片包含了一共1874个点光源，它是使用延迟着色法来完成的，而这对于正向渲染几乎是不可能的(图片来源：Hannes Nevalainen)。
--- a/Lighting/09
+++ b/Lighting/09
@@ -6,6 +6,10 @@
 翻译     | Meow J
 校对     | 未校对

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 我们已经在前面的基础教程中简单介绍到了这部分内容：环境光照(Ambient Lighting)。环境光照是我们加入场景总体光照中的一个固定光照常量，它被用来模拟光的**散射(Scattering)**。在现实中，光线会以任意方向散射，它的强度是会一直改变的，所以间接被照到的那部分场景也应该有变化的强度，而不是一成不变的环境光。其中一种间接光照的模拟叫做**环境光遮蔽(Ambient Occlusion)**，它的原理是通过将褶皱、孔洞和非常靠近的墙面变暗的方法近似模拟出间接光照。这些区域很大程度上是被周围的几何体遮蔽的，光线会很难流失，所以这些地方看起来会更暗一些。站起来看一看你房间的拐角或者是褶皱，是不是这些地方会看起来有一点暗？

 下面这幅图展示了在使用和不使用SSAO时场景的不同。特别注意对比褶皱部分，你会发现(环境)光被遮蔽了许多：
--- a/Practice/2D-Game/02
+++ b/Practice/2D-Game/02
@@ -6,6 +6,10 @@
 翻译     | [ZMANT](https://github.com/Itanq)
 校对     | Meow J

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 在开始真正写游戏机制之前，我们首先需要配置一个简单的框架，用来存放这个游戏，这个游戏将会用到几个第三方库，它们的大多数都已经在前面的教程中介绍过了。在需要用到新的库的时候，我会作出适当的介绍。

 首先，我们定义一个所谓的<def>超级</def>(Uber)游戏类，它会包含所有相关的渲染和游戏代码。这个游戏类的主要作用是（简单）管理你的游戏代码，并与此同时将所有的窗口代码从游戏中解耦。这样子的话，你就可以把相同的类迁移到完全不同的窗口库（比如SDL或SFML）而不需要做太多的工作。
--- a/Practice/2D-Game/03
+++ b/Practice/2D-Game/03
@@ -6,6 +6,10 @@
 翻译   | [ZMANT](https://github.com/Itanq)
 校对   |  Meow J

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 为了给我们当前这个黑漆漆的游戏世界带来一点生机，我们将会渲染一些精灵(Sprite)来填补这些空虚。<def>精灵</def>有很多种定义，但这里主要是指一个2D图片，它通常是和一些摆放相关的属性数据一起使用，比如位置、旋转角度以及二维的大小。简单来说，精灵就是那些可以在2D游戏中渲染的图像/纹理对象。

 我们可以像前面大多数教程里做的那样，用顶点数据创建2D形状，将所有数据传进GPU并手动变换图形。然而，在我们这样的大型应用中，我们最好是对2D形状渲染做一些抽象化。如果我们要对每一个对象手动定义形状和变换的话，很快就会变得非常凌乱了。
--- a/Practice/2D-Game/04
+++ b/Practice/2D-Game/04
@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 Breakout不会只是一个单一的绿色笑脸，而是一些由许多彩色砖块组成的完整关卡。我们希望这些关卡有以下特性：他们足够灵活以便于支持任意数量的行或列、可以拥有不可摧毁的坚固砖块、支持多种类型的砖块且这些信息被存储在外部文件中。

 在本教程中，我们将简要介绍用于管理大量砖块的游戏关卡对象的代码，首先我们需要先定义什么是一个砖块。
--- a/Practice/2D-Game/05
+++ b/Practice/2D-Game/05
@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 此时我们已经有了一个包含有很多砖块和玩家的一个挡板的关卡。与经典的Breakout内容相比还差一个球。游戏的目的是让球撞击所有的砖块，直到所有的可销毁砖块都被销毁，但同时也要满足条件：球不能碰触屏幕的下边缘。

 除了通用的游戏对象组件，球还需要有半径和一个布尔值，该布尔值用于指示球被固定(<def>stuck</def>)在玩家挡板上还是被允许自由运动的状态。当游戏开始时，球被初始固定在玩家挡板上，直到玩家按下任意键开始游戏。
--- a/Practice/2D-Game/05
+++ b/Practice/2D-Game/05
@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 当试图判断两个物体之间是否有碰撞发生时，我们通常不使用物体本身的数据，因为这些物体常常会很复杂，这将导致碰撞检测变得很复杂。正因这一点，使用**重叠**在物体上的更简单的外形（通常有较简单明确的数学定义）来进行碰撞检测成为常用的方法。我们基于这些简单的外形来检测碰撞，这样代码会变得更简单且节省了很多性能。这些<def>碰撞外形</def>例如圆、球体、长方形和立方体等，与拥有上百个三角形的网格相比简单了很多。

 虽然它们确实提供了更简单更高效的碰撞检测算法，但这些简单的碰撞外形拥有一个共同的缺点，这些外形通常无法完全包裹物体。产生的影响就是当检测到碰撞时，实际的物体并没有真正的碰撞。必须记住的是这些外形仅仅是真实外形的近似。
--- a/Practice/2D-Game/05
+++ b/Practice/2D-Game/05
@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 上个教程的最后，我们得到了一种有效的碰撞检测方案。但是球对检测到的碰撞不会有反作用；它仅仅是径直穿过所有的砖块。我们希望球会从撞击到的砖块**反弹**。此教程将讨论如何使用AABB-圆碰撞方案实现这项称为<def>碰撞处理</def>(Collision Resolution)的功能。

 当碰撞发生时，我们希望出现两个现象：重新定位球，以免它进入另一个物体，其次是改变球的速度方向，使它看起来像是物体的反弹。
--- a/Practice/2D-Game/06
+++ b/Practice/2D-Game/06
@@ -6,6 +6,10 @@
 翻译    | [ZMANT](https://github.com/Itanq)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 一个微粒,从OpenGL的角度看就是一个总是面向摄像机方向且(通常)包含一个大部分区域是透明的纹理的小四边形.一个微粒本身主要就是一个精灵(sprite),前面我们已经早就使用过了,但是当你把成千上万个这些微粒放在一起的时候,就可以创造出令人疯狂的效果.

 当处理这些微粒的时候,通常是由一个叫做粒子发射器或粒子生成器的东西完成的,从这个地方,持续不断的产生新的微粒并且旧的微粒随着时间逐渐消亡.如果这个粒子发射器产生一个带着类似烟雾纹理的微粒的时候,它的颜色亮度同时又随着与发射器距离的增加而变暗,那么就会产生出灼热的火焰的效果:
--- a/Practice/2D-Game/07
+++ b/Practice/2D-Game/07
@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 如果我们可以通过几个后期处理(Postprocess)特效丰富Breakout游戏的视觉效果的话，会不会是一件很有趣的事情？利用OpenGL的帧缓冲，我们可以相对容易地创造出模糊的抖动效果、反转场景里的所有颜色、做一些“疯狂”的顶点运动、或是使用一些其他有趣的特效。

 !!! important
--- a/Practice/2D-Game/08
+++ b/Practice/2D-Game/08
@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 Breakout已经接近完成了，但我们可以至少再增加一种游戏机制让它变得更酷。“充电”（译注：Powerups，很多游戏中都会用这个单词指代可以提升能力的道具，本文之后也会用道具一词作为其翻译）怎么样？

 这个想法的含义是，无论一个砖块何时被摧毁，它都有一定几率产生一个道具块。这样的道具快会缓慢降落，而且当它与玩家挡板发生接触时，会发生基于道具类型的有趣效果。例如，某一种道具可以让玩家挡板变长，另一种道具则可以让小球穿过物体。我们还可以添加一些可以给玩家造成负面影响的负面道具。
--- a/Practice/2D-Game/09
+++ b/Practice/2D-Game/09
@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 无论我们将游戏音量调到多大，我们都不会听到来自游戏的任何音效。我们已经展示了这么多内容，但没有任何音频，游戏仍显得有些空洞。在本节教程中，我们将解决这个问题。

 OpenGL不提供关于音频的任何支持。我们不得不手动将音频加载为字节格式，处理并将其转化为音频流，并适当地管理多个音频流以供我们的游戏使用。然而这有一些复杂，并且需要一些底层的音频工程知识。
--- a/Practice/2D-Game/10
+++ b/Practice/2D-Game/10
@@ -6,6 +6,10 @@
 | 翻译   | [aillieo](https://github.com/aillieo)    |
 | 校对   | 暂无                                       |

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 本教程中将通过增加生命值系统、获胜条件和渲染文本形式的反馈来对游戏做最后的完善。本教程很大程度上是建立在之前的教程[文本渲染](../02 Text Rendering.md)基础之上，因此如果没有看过的话，强烈建议您先一步一步学习之前的教程。

 在Breakout中，所有的文本渲染代码都封装在一个名为<fun>TextRenderer</fun>的类中，其中包含FreeType库的初始化、渲染配置和实际渲染代码等重要组成部分。以下是<fun>TextRenderer</fun>类的代码：
--- a/Practice/2D-Game/11
+++ b/Practice/2D-Game/11
@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无

+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 与仅仅是用OpenGL创建一个技术演示相比，这一整章的教程给我们了一次体验在此之上的更多内容的机会。我们从零开始制作了一个2D游戏，并学习了如何对特定的底层图形学概念进行抽象、使用基础的碰撞检测技术、创建粒子、展示基于正射投影矩阵的场景。所有的这些都使用了之前教程中讨论过的概念。我们并没有真正地学习和使用OpenGL中新的、令人兴奋的图形技术，更多的是在将所有知识整合至一个更大的整体中。

 Breakout这样的一个简单游戏的制作可以被数千种方法完成，而我们的做法也只是其中之一。随着游戏越来越庞大，你开始应用的抽象思想与设计模式就会越多。如果希望进行更深入的学习与阅读，你可以在[game programming patterns](http://gameprogrammingpatterns.com/)找到大部分的抽象思想与设计模式。（译注：《游戏编程模式》一书国内已有中文翻译版，GPP翻译组译，人民邮电出版社）
--- a/Theory.md
+++ b/Theory.md
@@ -6,9 +6,9 @@
 翻译     | [J.moons](https://github.com/JiangMuWen)
 校对     | Meow J（初校）

-!!! Important
+!!! note

-	注意： 作者正在对PBR章节进行大的调整，原文的内容时时可能有更新，建议仍是阅读原文。
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。

 PBR，或者用更通俗一些的称呼是指<def>基于物理的渲染</def>(Physically Based Rendering)，它指的是一些在不同程度上都基于与现实世界的物理原理更相符的基本理论所构成的渲染技术的集合。正因为基于物理的渲染目的便是为了使用一种更符合物理学规律的方式来模拟光线，因此这种渲染方式与我们原来的Phong或者Blinn-Phong光照算法相比总体上看起来要更真实一些。除了看起来更好些以外，由于它与物理性质非常接近，因此我们（尤其是美术师们）可以直接以物理参数为依据来编写表面材质，而不必依靠粗劣的修改与调整来让光照效果看上去正常。使用基于物理参数的方法来编写材质还有一个更大的好处，就是不论光照条件如何，这些材质看上去都会是正确的，而在非PBR的渲染管线当中有些东西就不会那么真实了。

--- a/Lighting.md
+++ b/Lighting.md
@@ -6,9 +6,10 @@
 翻译     | [KenLee](https://hellokenlee.github.io/)
 校对     | 暂无

-!!! Important

-	注意： 作者正在对PBR章节进行大的调整，原文的内容时时可能有更新，建议仍是阅读原文。
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。

 !!! Important

--- a/irradiance.md
+++ b/irradiance.md
@@ -4,6 +4,4 @@

 这篇教程暂时还没有进行翻译，您可以先阅读[原文](https://learnopengl.com/#!PBR/IBL/Diffuse-irradiance)，或经常来刷新看看是否有更新的进展。当然，我们更欢迎您在[GitHub上](https://github.com/LearnOpenGL-CN/LearnOpenGL-CN)认领翻译这篇文章，帮助我们完善这个教程系列。

-注意，作者正在对PBR章节进行大的调整，原文的内容时时可能有更新，所以建议目前不要进行认领。
-
 <img src="../../../img/development.png" class="clean">
--- a/docs/07
+++ b/docs/07
@@ -4,6 +4,4 @@

 这篇教程暂时还没有进行翻译，您可以先阅读[原文](https://learnopengl.com/#!PBR/IBL/Specular-IBL)，或经常来刷新看看是否有更新的进展。当然，我们更欢迎您在[GitHub上](https://github.com/LearnOpenGL-CN/LearnOpenGL-CN)认领翻译这篇文章，帮助我们完善这个教程系列。

-注意，作者正在对PBR章节进行大的调整，原文的内容时时可能有更新，所以建议目前不要进行认领。
-
 <img src="../../../img/development.png" class="clean">