python零基础python零基础12-03 05:58

Unity Lighting - Choosing a Rendering Path 选择渲染路径(三)

 

Choosing a Rendering Path 选择渲染路径

 

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.

这种方法的优点是速度非常快 - 这意味着硬件要求比替代方案要低。此外,正向渲染为我们提供了广泛的自定义“着色模型”,并且可以快速处理透明度。它还允许使用诸如“多样本抗锯齿”(MSAA)之类的硬件技术,这些技术在其他替代品中不可用,例如可能对图像质量产生重大影响的延迟渲染。

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.

然而,前向路径的一个显着缺点是我们必须在每个灯光的基础上支付渲染成本。也就是说,影响每个对象的灯光越多,渲染性能就越慢。对于某些游戏类型,有很多灯光,这可能因此而不适用。但是,如果可以在游戏中管理灯光计数,则转发渲染实际上可以是一个非常快速的解决方案。

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.

另一方面,在“延迟”渲染中,我们延迟光线信息的阴影和混合,直到第一个Pass结束,屏幕每个表面的位置,法线和材质渲染为一系列屏幕空间纹理保存到“几何缓冲区”(G-Buffer)。然后,我们将这些结果与照明通行证混合在一起。这种方法的主要优点是,照明的渲染成本与光照像素数量成正比,而不是光源本身的数量。因此,您不再受到屏幕上呈现的灯光数量的限制,对于某些游戏来说,这是一个关键优势。

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.

有关延迟,转发和其他可用渲染路径的更多信息,请参阅此处的文档。


<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

程序之家二维码

小额赞赏

000
评论