Unity Graphics (Unity 图形渲染 )
- Everything for Lighting and Rendering in Unity
- 主要涉及到光照与渲染方面的知识

本文档主要是对Unity官方教程的个人理解与总结（其实以翻译记录为主：>）
仅作为个人学习使用，不得作为商业用途，欢迎转载，并请注明出处。
文章中涉及到的操作都是基于 Unity2017.3版本
参考链接：https://unity3d.com/cn/learn/tutorials/s/graphics

下面是将要介绍的章节，黑体是本次内容：

• Introduction to Lighting and Rendering(2)
  介绍光照和渲染（2）
• Precomputed Realtime GI (Realtime Global Illumination)
  预处理实时全局光照
• Rendering and Shading
  渲染与着色
• Cameras and Effects
  相机与效果
• Geometry in Unity
  几何体

3. The Precompute Process

3.预计算过程

In Unity, precomputed lighting is calculated in the background - either as an automatic process, or it is initiated manually. In either case, it is possible to continue working in the editor while these processes run behind-the-scenes.
When the precompute process is running, a blue progress bar will appear in the bottom right of the Editor. There are different stages which need to be completed depending on whether Baked GI or Precomputed Realtime GI is enabled. Information on the current process is shown on-top of the progress bar.

Unity的预计算光照是在后台处理的，可以是自动处理或手动操作。无论何种方式，它只是在后台运行，不影响编辑器的继续工作。当预计算正在处理，一个蓝色进度条会在编辑器右下角显示。烘焙GI和预计算实时GI有着不同的处理阶段。当前处理信息会在进度条的上面显示。

Progress bar showing the current state of Unity’s precompute.
进度条显示出Unity的预计算的当前运行的状态。

In the example above, we can see that we are at task 5 of 11 which is, ‘Clustering’ and there are 108 jobs remaining before that task is complete and the precompute moves on to task 6. The various stages are listed below:

上面的示例，我们可以看到处理进行到11个任务的第5个：“Clustering”，并且有108个工作在这个任务完成前，然后预计算进行第6个任务。下面列出各个阶段：

Starting a Precompute

开始预计算

Only static geometry is considered by Unity’s precomputed lighting solutions. To begin the lighting precompute process we need at least one GameObject marked as ‘static’ in our scene. This can either be done individually, or by shift-selecting multiple GameObjects from the hierarchy panel.
From the Inspector panel, the Static checkbox can be selected (Inspector>Static). This will set all of the GameObject’s ‘static options’, or ‘flags’, including navigation and batching, to be static, which may not be desirable. For Precomputed Realtime GI, only ‘Lightmap Static’ needs to be checked.
For more fine-grained control, individual static options can be set from the drop-down list accessible to the right of the Static checkbox in the Inspector panel. Additionally, objects can also be set to Static in the Object area of the lighting window.
If your scene is set to Auto (Lighting>Scene>Auto), Unity’s lighting precompute will now begin automatically. Otherwise it will need to be started manually as described below.

只有静态几何体才会被Unity的预计算光照处理。为了开始光照预计算，在场景中我们至少需要有一个游戏对象被标记为“静态的”。这可以单个操作，也可以多选游戏对象从hierarchy（层次）面板。
在Inspector（属性）面板，静态复选框可被勾选。这会设置游戏对象的所有静态选项/标记，包括导航、批处理等，有些可能是不希望勾选的。对于预计算实时GI，只需要 “Lightmap Static”被勾选即可。
为了更为精细的控制，可单独从属性面板【Static】右边的下拉列表中选择。另外，对象也可以从lighting窗口的Object Maps页签中设置为静态的。(Unity2017.3不可设置，只可观察)。
如果你的场景设置成Auto(【Lighting>Scene>Auto】)，Unity的光照预计算将会自动开始。否则，要像下面描述的方式手动操作开始。

Auto/Manual Precompute

自动/手动预计算

If ‘Auto’ is checked from the bottom of Unity’s Lighting panel (Lighting>Scene>Auto), then this precompute will begin automatically as a background process whenever changes are made to static geometry within your scene.
However, if Auto is not selected, you will need to manually start a precompute by clicking the ‘Build’ button next to it. This will begin the precompute in much the same way, while giving you control over when this process starts.
Manually initiating a precompute will cause all aspects of your scene lighting to be evaluated and (re)computed. If you wish to selectively recalculate Reflection probes by themselves, this can be done via the drop-down menu next to the Build button (Lighting>Scene>Build).

如果设置成“Auto”,预计算将在静态几何体修改的时候自动后台开始计算。
如果未设置成“Auto”,需要自动点击“Build”按钮手动开启预计算。这和自动的预计算处理一致，不过你可以自己控制开始的时机。
手动开启预计算将会评估和计算场景的各个方面。如果你想选择只重计算反应探头，可以从按钮右边的下拉列表中选取（【Lighting>Scene>Build】）。

GI Cache

GI 缓存

In either Baked GI or Precomputed Realtime GI, Unity ‘caches’ (stores) data about your scene lighting in the ‘GI Cache’, and will try to reuse this data whenever possible to save time during precompute. The number and nature of the changes you have made to your scene will determine how much of this data can be reused, if at all.
This cache is stored outside of your Unity project and can be cleared using (Preference>GI Cache>Clear Cache). Clearing this means that all stages of the precompute will need to be recalculated from the beginning and this can therefore be time consuming. However in some cases, where perhaps you need to reduce disk usage, this may be helpful.

无论是烘焙GI或预计算实时GI, Unity都会缓存你的场景光照数据到“GI缓存”中，并在重计算时重复利用这个数据以节省时间。对场景修改的数据和性质将决定有多少数据可以被重复利用。
这个缓存是在你的Unity项目之外的，并可以清除（【Edit>Preference>GI Cache>Clear Cache】）。
清除 意味着预计算的所有阶段都需要从重新计算，因此需要花费大量时间。但是，在某些情况下，也许您需要减少磁盘使用，这可能是有帮助的。

4.Choosing a Rendering Path

4.选择一个渲染途径

Unity supports a number of rendering techniques, or ‘paths’. An important early decision which needs to be made when starting a project is which path to use. Unity’s default is ‘Forward Rendering”.

Unity支持很多渲染技术，或途径。当开始一个项目使用哪个渲染途径是一个前期重要的决策要做的。Unity默认是“正向渲染”。

Forward Rendering

正向渲染

In Forward Rendering, each object is rendered in a ‘pass’ for each light that affects it. Therefore each object might be rendered multiple times depending upon how many lights are within range.
The advantages of this approach is that it can be very fast - meaning hardware requirements are lower than alternatives. Additionally, Forward Rendering offers us a wide range of custom ‘shading models’ and can handle transparency quickly. It also allows for the use of hardware techniques like ‘multi-sample anti-aliasing’ (MSAA) which are not available in other alternatives, such as Deferred Rendering which can have a great impact on image quality.
However, a significant disadvantage of the forward path is that we have to pay a render cost on a per-light basis. That is to say, the more lights affecting each object, the slower rendering performance will become. For some game types, with lots of lights, this may therefore be prohibitive. However if it is possible to manage light counts in your game, Forward Rendering can actually be a very fast solution.

正向渲染，每个对象被渲染到受某个光源影响的一个通道。因此每个对象可能被渲染的次数取决于受多少范围内的光源影响。
这个方式的优势是运行快，并且硬件要求比其他渲染途径更低。另外，正向渲染提供了一系列定制的着色模型，并且能快速处理透明度。它也允许硬件技术的使用，像“多采样抗锯齿(MSAA)“，这在其他渲染途径无效的，比如图形质量有巨大影响的延迟渲染。
然而，正向渲染最大的缺点是要基本每个光源花费渲染成本。也就是说，影响到对象的光源越多渲染性能越差。对一些拥有大量的光源游戏类型来说，是不适用的。然而，如果光源数量是可控的话，正向渲染其实是一个效率很快的解决方案。

Deferred Rendering

延迟渲染

In ‘Deferred’ rendering, on the other hand, we defer the shading and blending of light information until after a first pass over the screen where positions, normals, and materials for each surface are rendered to a ‘geometry buffer’ (G-buffer) as a series of screen-space textures. We then composite these results together with the lighting pass. This approach has the principle advantage that the render cost of lighting is proportional to the number of pixels that the light illuminates, instead of the number of lights themselves. As a result you are no longer bound by the number of lights you wish to render on screen, and for some games this is a critical advantage.
Deferred Rendering gives highly predictable performance characteristics, but generally requires more powerful hardware. It is also not supported by certain mobile hardware.
For more information on the Deferred, Forward and the other available rendering paths, please see the documentation here.

另一方面，延迟渲染会延迟光照信息的着色和融合，直到每个表面的位置、法线、材质被渲染到一个“几何体缓冲“（G-buffer）成为一系列屏幕空间贴图后，在屏幕空间第一个通道执行。然后，我们用光照通道把结果合在一起。这个方式有个重大优势：光照的渲染成本和光照像素数成正比，和光源数量成本没有关系。这样就不需要担心光源的数量，对于一些游戏这是关键的优势技术。
延迟具有高度可预测的性能特性，但通常需要更强大的硬件。它也不受某些移动硬件的支持。
有关延迟、转发和其他可用呈现路径的更多信息，请参阅这里的文档。