鼠标控制两台台式机_台式机和控制台上的真棒实时GI

鼠标控制两台台式机

We’ve teamed up with Alex Lovett again and built The Courtyard, a demo that puts the Precomputed Realtime GI features in Unity 5 to good use. He previously built the Shrine Arch-viz demo. This time, however, the goal was to build a demo aimed at game developers requiring realtime frame rates. Check out this video:

我们再次与Alex Lovett合作，构建了The Courtyard ，该演示充分利用了Unity 5中的预计算实时GI功能。 他以前曾制作过Shrine Arch-viz演示程序 。 但是，这次的目的是要针对需要实时帧速率的游戏开发人员构建演示。 观看此视频：

演示地址

Alex built the demo in about 8 weeks using Unity 5.2 off the shelf without any additional packages from the Asset Store – everything was built from scratch.

Alex使用现成的Unity 5.2在大约8周的时间内构建了该演示，而没有从Asset Store获得任何额外的软件包-一切都是从头开始构建的。

该场景中没有烘烤的照明 (There is no baked lighting in this scene)

The demo relies on Precomputed Realtime GI and realtime lighting throughout. It has a full time-of-day cycle, emissive geometry, about 100 animated spotlights that come alive at night, as well as a number of floodlights on stands and an optional player flashlight. The time-of-day cycle uses an animated skybox that is synchronized with the sun in order to capture the subtle lighting changes. In the playable demo we are now making available to you (see below), a UI has been added that allows you to control all of these lighting features in-game. Here are a few shots from the scene at different times of day:

该演示始终依赖于预先计算的实时GI和实时照明。 它具有一天中的整个时间周期 ，自发光的几何形状，约100个动画聚光灯在夜间启用，以及展位上的多个泛光灯和一个可选的播放器手电筒 。 每天的时间周期使用与太阳同步的动画天窗，以捕捉微妙的灯光变化。 在我们现在向您提供的可播放演示中(请参见下文)，添加了一个UI，可让您在游戏中控制所有这些照明功能。 以下是一天中不同时间的场景快照：

The scene was created to be especially demanding in terms of lighting. A significant part of it is lit only by bounced light, and when the sun has set it is lit almost entirely by bounced light.

创建该场景对照明的要求特别高。 它的很大一部分仅由反射光照明，而当太阳落山后，几乎全部由反射光照明。

The realtime GI system works by precomputing all of the possible paths that light can take between static objects in the scene. This makes it possible to tweak the lighting in realtime, without interruption, because the system already has all the information it needs to quickly calculate the consequences of lighting changes. However, this means that static objects should not be modified, because doing so would require precomputing all the paths again. Given this, it makes sense to author levels in stages: geometry then lighting (and then repeat if necessary). Haphazardly moving static geometry around and adjusting lighting at the same time will require many lighting builds. We are working on more progressive and interactive lighting workflows for Unity 5.x. More details on this will follow in a separate blog post.

实时GI系统通过预先计算光线在场景中的静态对象之间可以采取的所有可能路径来工作。 由于系统已经拥有快速计算照明变化后果所需的所有信息，因此可以实时调整照明而不会中断。 但是，这意味着不应修改静态对象，因为这样做将需要再次预先计算所有路径。 鉴于此，分阶段创作各个层次是有意义的： 几何然后是光照 (然后在必要时重复)。 随意移动静态几何图形并同时调整照明将需要许多照明构造。 我们正在为Unity 5.x开发更多渐进式和交互式照明工作流。 对此的更多详细信息将在另一篇博客文章中提供。

编写实时GI (Authoring for Realtime GI)

The demo was built with desktop PCs and consoles in mind, see the blogpost on GI in Unity 5 covering the Transporter demo for Realtime GI use on mobile platforms.

该演示是在考虑台式机和控制台的情况下构建的，请参见Unity 5中有关GI的博客文章，其中涵盖了在移动平台上使用实时GI的Transporter演示 。

The Realtime GI system in Unity 5 is powered by Geomerics Enlighten and is designed for use in games. All the lighting computations are performed asynchronously on CPU worker threads; because games are usually GPU bound, the extra CPU work has very little impact on overall framerate. Also, only the areas where the lighting has changed are recomputed.

Unity 5中的Realtime GI系统由Geomerics Enlighten提供支持，并设计用于游戏中。 所有照明计算都是在CPU工作线程上异步执行的； 由于游戏通常是受GPU限制的，因此额外的CPU工作对整体帧速率的影响很小。 同样，仅重新计算照明已改变的区域。

The lighting latency in the game is dependent on the resolution chosen for the realtime indirect lightmaps. In this demo Alex set the resolution to be relatively low – in order to be responsive – but such that it still captures the desired lighting fidelity and subtleties in the indirectly lit areas.

游戏中的光照延迟取决于为实时间接光照图选择的分辨率。 在此演示中，Alex将分辨率设置为较低(以便响应)，但仍可以在间接照明的区域中捕获所需的照明保真度和细微度。

The indirect lightmap resolution was:

间接光照贴图分辨率为：

In order to balance the resolutions, an overall baseline of 0.25 texels per unit was set on the scene. Then, multipliers were added using custom lightmap parameters to give some really nice lighting and a precompute time of just 15 minutes.

为了平衡分辨率，在现场设置了每单位0.25纹素的总体基线。 然后，使用自定义光照贴图参数添加乘数，以提供一些非常好的光照，并且预计算时间仅为15分钟。

The following screenshots show a shaded overview of the scene, the Enlighten systems generated, the UV charting view (showing the resolution of the indirect lightmaps), the clusters (responsible for emitting bounce lighting), the bounced lighting, and the lighting directionality (used for lighting off axis geometry and specular):

以下屏幕快照显示了场景的阴影概述 ，生成的Enlighten系统 ， UV图表视图(显示了间接光照贴图的分辨率)， 聚类 (负责发射反射光)， 反射光和 照明方向性 (已使用用于照亮轴的几何形状和镜面反射)：

Care was taken to provide good lightmapping UVs. In some cases they were carefully authored to make sure that the models perform well for both lighting builds and the runtime. One specific instance of this is the staircase model.

注意提供良好的光照贴图UV。 在某些情况下，他们经过精心创作，以确保模型在照明构建和运行时均表现良好。 楼梯模型就是这种情况的一个具体实例。

Staircases can be difficult to get right, since at large texel sizes a texel can cover more that a single step. This can cause lighting levels to vary unexpectedly between the steps. On the other hand, using many texels for the steps becomes expensive in terms of performance. The staircase used in this scene also had bevels, which can really throw off the unwrapping and packing for realtime GI and generate many unnecessary charts taking up texel space. The initial staircase design looked like this in realtime GI UV layout:

楼梯可能很难正确放置，因为在大纹素尺寸的情况下，纹素可以覆盖一个步骤以上。 这可能会导致各步骤之间的照明水平发生意外变化。 另一方面，就步骤而言，使用许多纹理像素在性能方面变得昂贵。 此场景中使用的楼梯还带有斜面，可以真正地消除实时GI的展开和包装，并生成许多不必要的图表，占用了texel空间。 实时GI UV布局中的初始楼梯设计如下所示：

This takes up a 70×72 texel realtime lightmap. There are two problems with this layout. Firstly, it uses too many texels per step (4×4); secondly the bevels are split into separate charts that also take up a minimum of 4×4 texels. Why can each chart not just use 1 texel? Firstly, Enlighten is optimized to use 2×2 texel blocks when processing the textures in the runtime, so every chart must be at least 2×2 texels. Secondly, Enlighten includes a stitching feature where charts can be stitched together to allow smooth results on, for example, spheres and cylinders; this feature requires that a chart have separate directionality information at each edge. Directionality information is only stored on a per-block basis, so a stitchable chart will always need a minimum of 2×2 blocks – becoming a minimum of 4×4 texels. Since no stitching is needed for the staircase, 2×2 texel charts suffice.

这占用了70×72 texel实时光照贴图。 这种布局有两个问题。 首先，它每步使用太多纹理像素(4×4)； 其次，将斜角分成单独的图表，这些图表也至少占用4×4纹素。 为什么每个图表都不能只使用1个纹理像素？ 首先，对Enlighten进行了优化，以在运行时处理纹理时使用2×2 texel块，因此每个图表必须至少为2×2 texel。 其次，Enlighten具有缝合功能，可以将图表缝合在一起，以使例如球体和圆柱体上的结果平滑。 此功能要求图表在每个边都有独立的方向性信息。 方向性信息仅按块存储，因此，可缝制图表将始终需要最少2×2 块 -最少需要4×4像素。 由于楼梯不需要缝合，因此2×2纹素图表就足够了。

We have introduced an option for this in the Object properties of the lighting panel:

我们在照明面板的对象属性中为此引入了一个选项：

The value can either be 4, which works well for stitching in a setting that uses directionality, or 2 which is more compact. Setting the minimum chart size option to 2 reduces the texel density significantly – now the model fits in a 44×46 texel realtime lightmap:

该值可以是4(在使用方向性的设置中适合缝制)，也可以是2(更紧凑)。 将最小图表尺寸选项设置为2会大大降低纹理像素密度-现在该模型适合44×46纹理像素实时光照贴图：

The bevels are still taking up unnecessary chart space. This is somewhat unexpected as bevels and steps have been authored such that the bevel is part of the step in UV space. The image below shows the UV borders overlaid on the model. Notice how the bevels are integrated into the steps:

斜角仍在占用不必要的图表空间。 这是出乎意料的，因为已经编写了斜面和台阶，使得该斜面是UV空间中台阶的一部分。 下图显示了覆盖在模型上的UV边界。 请注意斜角如何集成到步骤中：

In the 2D view of the lightmapping UVs the bevels do not show up. This is because they have been collapsed into the step charts so they do not have any area in UV space. This is done to avoid that the lighting simulation takes the sloped bevels into account.

在光照贴图UV的2D视图中，不显示斜角。 这是因为它们已折叠到步骤图中，因此它们在UV空间中没有任何区域。 这样做是为了避免照明模拟将倾斜的斜角考虑在内。

The reason that the bevels are split into separate charts is that the UVs used for realtime GI have to be repacked at the actual resolution each instance will be used at. The packing algorithm guarantees that there is a half texel boundary around charts, such that bleeding artifacts between charts are avoided. This ensures very good use of the atlases and no need for packing margins at the expense of having per instance UVs.

将斜角拆分为单独的图表的原因是，用于实时GI的UV必须重新包装每个实例将使用的实际分辨率。 打包算法可确保图表周围有半个纹理像素边界，从而避免了图表之间出现渗色伪影。 这样可以确保很好地使用地图集，并且无需增加装箱边距，而却要浪费UV。

The problem arises when there is a hard edge, like in this example where there is a hard edge between the steps and the bevels. The model importer will already have duplicated the vertices at the hard edge since each side of the hard edge needs different normals. So the charts have already been split at the outset. Repacking this will cause the bevel to end up in a separate chart. This is because chart detection uses normals for detecting charts by default. When it finds an edge with identical vertex positions, identical UVs, but different normals, it will split the chart along that edge.

当存在坚硬的边缘时(例如在此示例中，台阶和斜面之间存在坚硬的边缘)，就会出现问题。 由于硬边的每一侧都需要不同的法线，因此模型导入器将已经在硬边处复制了顶点。 因此，图表一开始就已经被分割了。 重新包装将使斜角最终出现在单独的图表中。 这是因为默认情况下，图表检测使用法线来检测图表。 当找到具有相同顶点位置，相同UV，但法线不同的边时，它将沿该边拆分图表。

In this instance that behavior is not desirable. The bevel should be integrated in the chart for the step, since it will not have a significant impact on the lighting. In order to do so, we have exposed an option to ignore normals when doing chart detection during the packing step. This will keep the charts together as authored in the UVs regardless of the hard edge:

在这种情况下，这种行为是不希望的。 由于该斜角不会对照明产生重大影响，因此应将该斜角整合到该步骤的图表中。 为此，我们提供了在打包步骤中进行图表检测时忽略法线的选项。 不管硬边如何，这将使图表按照UV中的要求保持在一起：

Enabling the packer option reduces the texel density even further. Now the bevels are integrated with the steps. The final result fits in a 22×24 lightmap:

启用封隔器选项会进一步降低纹理像素密度。 现在，斜角已与台阶整合在一起。 最终结果适合22×24的光照贴图：

()

By using these new options where appropriate the realtime GI precompute time could be reduced from an hour and a half to just 15 minutes.

通过在适当的地方使用这些新选项，可以将实时GI预计算时间从一个半小时减少到仅15分钟。

性能如何？ (What about performance?)

The Realtime GI did not need much tweaking to fit within the desired runtime performance/memory budget. However, the post-effects stack is quite deep and includes Filmic Vignette, Bloom, Tonemapping, Lens Distort, Screen Space Ambient Occlusion, Color Correction Curves, Noise And Grain, Color Grading Properties and Antialiasing. Despite this the level runs at 60fps on a fast desktop with a decent GPU.

实时GI不需要太多调整就可以满足所需的运行时性能/内存预算。 然而，后期效果叠加颇深，包括电影化暗角 ， 布卢姆 ， 色调映射 ， 镜头扭曲 ， 屏幕空间环境光遮蔽 ， 色彩校正曲线 ， 噪声和粮食 ， 调色配光性能和抗锯齿 。 尽管如此，在具有不错的GPU的快速桌面上，该级别仍可以60fps的速度运行。

There were however a few tweaks applied to realtime GI.

但是，对实时GI进行了一些调整。

快速环境照明 (Fast Environment Lighting)

The realtime GI system is capable of using a skybox directly to drive the environment lighting inputs. However, using this feature requires downloading the skybox textures from the GPU in order to update the CPU based realtime GI system. This is not ideal when the environment lighting changes every frame as it does in this demo when the time-of-day simulation is running. Instead, the environment lighting is derived from the current time and converted to a lighting gradient and ambient intensity that is used to drive the realtime GI system. These are the settings in the Lighting panel that are used to drive the gradient based ambient inputs:

实时GI系统能够直接使用天空盒来驱动环境照明输入。 但是，使用此功能需要从GPU下载skybox纹理，以便更新基于CPU的实时GI系统。 当一天中的时间模拟正在运行时，当环境照明每帧都发生变化时，如在本演示中所做的那样，这不是理想的。 取而代之的是，环境照明是从当前时间得出的，并转换为用于驱动实时GI系统的照明梯度和环境强度。 这些是“照明”面板中的设置，用于驱动基于渐变的环境输入：

The bare bones code used to update the environment lighting looks like this:

用于更新环境光照的基本代码如下所示：

[csharp] using System; using UnityEngine; using System.Collections; using System.Collections.Generic;

[csharp]使用系统； 使用UnityEngine; 使用System.Collections; 使用System.Collections.Generic;

[ExecuteInEditMode] public class EnvironmentUpdater : MonoBehaviour {

[ExecuteInEditMode]公共类EnvironmentUpdater：MonoBehaviour {

public Gradient groundGradient, equatorGradient, skyGradient; private TimeOfDayManager m_TimeOfDayManager;

public GradientgroundGradient，赤道Gradient，skyGradient； 私人TimeOfDayManager m_TimeOfDayManager;

void OnEnable () { m_TimeOfDayManager = FindObjectOfType<timeofdaymanager> (); }

void OnEnable(){m_TimeOfDayManager = FindObjectOfType <timeofdaymanager>(); }

void Update () { float currentTime = m_TimeOfDayManager.time; RenderSettings.ambientGroundColor = groundGradient.Evaluate(currentTime); RenderSettings.ambientEquatorColor = equatorGradient.Evaluate(currentTime); RenderSettings.ambientSkyColor = skyGradient.Evaluate(currentTime); } } [/csharp]

void Update(){float currentTime = m_TimeOfDayManager.time; RenderSettings.ambientGroundColor = groundGradient.Evaluate(currentTime); RenderSettings.ambientEquatorColor = equatorGradient.Evaluate(currentTime); RenderSettings.ambientSkyColor = skyGradient.Evaluate(currentTime); } [/ csharp]

The code assumes a manager that handles time-of-day. This demo has such a manager that is hooked up to the UI so you can adjust time-of-day interactively.

该代码假定管理者处理一天中的时间。 该演示具有连接到UI的管理器，因此您可以交互地调整时间。

快速发光照明 (Fast Emissive Lighting)

In a vein similar to the environment lighting the realtime GI system is capable of driving emissive objects directly from the emissive shader properties. It will by default render out an emissive map in realtime lightmap space using the emission material property or, alternatively, a customized shader meta pass can be added. This will require a texture download from the GPU before the data can be consumed by the realtime GI system. In order to avoid this, there are script bindings available to set the emissive property directly on the object as a fixed color (DynamicGI.SetEmissive) and allow the realtime GI system to apply the emission directly on the GI simulation. This bypasses the GPU completely and provides a way to light the scene nearly for free. Here is a few mood shots using this feature:

与环境照明类似，实时GI系统能够直接从发射着色器属性驱动发射对象。 默认情况下，它将使用发射材质属性在实时光照贴图空间中渲染发射贴图，或者可以添加自定义的着色器元通道。 这将需要从GPU下载纹理，然后实时GI系统才能使用数据。 为了避免这种情况，可以使用脚本绑定将对象的发射属性直接设置为固定颜色( DynamicGI.SetEmissive )，并允许实时GI系统将发射直接应用于GI模拟。 这完全绕过了GPU，并提供了一种几乎免费照明场景的方法。 这是使用此功能的一些心情镜头：

()

在更大的世界中如何缩放？ (How does it scale with larger worlds?)

Clearly this is not a massive world – so how does it scale? In order to keep the memory footprint low and the lighting responsiveness high it makes sense to dice up larger worlds so that parts of them can be streamed in and out while the player navigates the world. The Realtime GI system works with LoadLevelAdditive and UnloadLevel. Of course some care needs to be taken when unloading levels since levels that are not directly visible may still affect the bounced lighting significantly. We are looking into adding some scripting hooks for enabling bounce fade between levels before unloading, so that lighting pops can be avoided, thereby allowing for more aggressive streaming. Another thing that we are looking into is providing scripting control for prioritizing update frequency for instances within the level for more fine-grained control beyond level streaming.

显然，这不是一个庞大的世界-那么它如何扩展？ 为了保持较低的内存占用量和较高的光照响应性，将较大的世界切成小方块是有意义的，以便在玩家导航世界时可以将其中的一部分流进和流出。 实时GI系统可与LoadLevelAdditive和UnloadLevel一起使用 。 当然，在卸载水平仪时需要特别小心，因为不直接可见的水平仪仍可​​能严重影响反射的照明。 我们正在考虑添加一些脚本挂钩，以在卸载之前使各个级别之间的反弹淡入淡出，从而可以避免出现爆裂声，从而允许更积极的流式传输。 另一件事，我们正在研究为超越级别流更细粒度的控制水平之内优先更新频率情况下被提供的脚本控制。

Using additive loading, or the Multi-Scene Editing feature currently scheduled for release in Unity 5.3 on December 8, will allow you to easily build scalable worlds lit by beautiful Realtime GI.

使用加性加载或当前计划于12月8日在Unity 5.3中发布的多场景编辑功能，将使您能够轻松构建由精美的实时GI照明的可伸缩世界。

我如何获得这个演示？ (How do I get this demo?)

You can download a prebuilt player here for OSX and Win64 and finally for Linux. In addition you can download the Project from the Asset Store. The project works with Unity 5.2.2p2 and later. The controls are described in a text file in the player zip file.

您可以在此处下载适用于OSX和Win64 ，最后适用于Linux的预构建播放器。 另外，您可以从Asset Store下载项目 。 该项目适用于Unity 5.2.2p2及更高版本。 播放器zip文件中的文本文件中描述了控件。

The demo runs best on a desktop machine. The timings listed here were achieved with an Intel i7-4790 3.6GHz machine with 16GB RAM, NVIDIA GeForce GTX 780 GPU, running on Windows 10.

该演示在台式机上运行最佳。 此处列出的计时是通过在Windows 10上运行的具有16GB RAM的Intel i7-4790 3.6GHz计算机，NVIDIA GeForce GTX 780 GPU实现的。

学分 (Credits)

Alex Lovett (aka @heliosdoublesix) creative-directed, art-directed, built, lit, animated, audio-directed and delivered this demo while tirelessly stress testing GI features in Unity. Thomas Pasieka and Plamen ‘Paco’ Tamnev modelled the props. Music Marks composed the music for the video preview. Dave Dexter composed the audio for the playable. Silvia Rasheva supported the demo as a producer. Morgan McGuire fixed some reflection issues.

Alex Lovett (aka @heliosdoublesix)指导创意，艺术指导，构建，照明，动画，音频指导，并交付了此演示，同时不懈地在Unity中测试GI功能。 Thomas Pasieka和Plamen'Paco'Tamnev为道具建模。 音乐标记构成了用于视频预览的音乐。 戴夫·德克斯特(Dave Dexter)创作了可播放的音频。 Silvia Rasheva支持制作人演示。 Morgan McGuire解决了一些反思问题。

Jesper Mortensen, Kuba Cupisz and Kasper Storm Engelstoft supported Alex during development, and used the collaboration to further improve the lighting system in Unity for all artists out there.

Jesper Mortensen ， Kuba Cupisz和Kasper Storm Engelstoft在开发过程中为Alex 提供了支持，并通过合作进一步改善了Unity中所有艺术家的照明系统。

Special shout-out to Plamen ‘Paco’ Tamnev for fixing some last minute issues for us.

特别感谢Plamen'Paco'Tamnev为我们解决了一些最后的问题。

翻译自: https://blogs.unity3d.com/2015/11/05/awesome-realtime-gi-on-desktops-and-consoles/

鼠标控制两台台式机