Unity计划放弃支持部分图形特性

Unity放弃支持部分图形特性。这样做能够使渲染系统在未来变得更加简洁、高效。

有时候，当我们尝试做出一些优化（更好看、更快速、更灵活，等等）时，发现有一些古老的特例或过时的硬件支持阻碍前进。一般来说，我们试着尽可能的在多个版本间保持兼容，但是有的时候放弃一些旧功能所带来的潜在效益真是太大了，而这些功能可能只有很少人在用（如果确实有人在用的话）。

总而言之，这里有一个初步拟定的和图形相关的“即将停止工作”的列表。注意，这些只是在“计划中”，并没有实际执行，所以，如果你真的，真的需要它们来工作一直保留下去，请告诉我们！

着色器（Shader）:去掉对“precompiled(预编译)” shader assets的支持

---

“预编译“shader 是一个“没有源代码”的高效着色器。 这种着色器，不是具有可读性的高级着色器语言（HLSL）代码，而是包含了面向几个固定平台的已经编译好的shader文件或微程序（microcode）或经过翻译的shader代码。

一个“预编译”着色器的问题是（假如你从一些地方得到预编译着色器）可能无法在未来出现的某些平台上正常工作。假如说你现在有一个着色器，是针对DX9,OpenGL 和OpenEL ES2.0 进行的预编译。这个着色器将不能在 游戏机，苹果的Metal API,DX11等等下面环境下工作。因此，单就这一条来看使用预编译shader就不是什么好做法。

我们想这样做的另一个原因是为了改变shader的序列化格式，以大幅提高其在磁盘存储、加载期和运行期的内存使用等方面的效率。不得不说我们目前为止用到的着色基于文本的shader格式是相当低效的，这导致了低加载速度和高内存占用。在我们目前的实验中，我们通过着色使用更高效的shader数据格式，我们在这些两个方面都看有了很大改善（依据shader的variant复杂度不同节省了数兆到数十兆不等的空间）。然而，这使得旧版本中的预编译不能在工作了。我们认为这是个公平正确的权衡。

优势:

• 着色器在你的游戏数据文件中占用更少的空间；

• 着色器加载速度更快，尤其是在主线程中异步加载时“打嗝”少得多；

• 运行时着色器占用更少的内存；

检视面板中的“showcompiled code”功能会显示实际的由DX11编译生成的shader代码，而非一堆无用处的奇怪符号。

劣势：

• 预编译着色器（在检视面板中的“show compiled code”），且在随后直接使用这些代码将不再被支持。

影响：使用预编译着色器的用户和从别人那儿获得预编译着色器的人们。

时间：Unity5.3(2015年12月)

硬件：停止支持DirctX 9 Model 2.0的GPUs

---

DX9 SM2.0的GPU们已经相当陈旧，我们想放弃对它们的支持。这意味着你的游戏无法和这些GPU兼容：2004年之前的NVIDIAGeForce 6000之前),2005年之前的AMD （Radeon X1000之前）和2006年之前的Intel（GMA X3000/965之前）,简而言之，10年以上前生产的GPUs将不再被支持。查看数据，现在看来只有Intel GMA950 又名82945 GPU 被发现在某些时候还在使用，因此这个型号的GPU将不再被支持。

注意我们并未对DirectX 9完全停止支持。这在Windows XP（怎么还不消失……）上，仍然是唯一实际的选择。Unity将会继续支持DirectX 9渲染很长一段时间。

做这些的好处：

减少人们写着色器脚本的麻烦。现在，所有在Unity中新创建的着色器被默认编译成“最低通用标准(lowest common denominator)”：shader model 2.0。如果你需要更高级的特征（顶点纹理，动态分支(dynamicbranching ),派生(derivatives),清晰的纹理采样(explicitLOD sampling）等等，你需要添加想像“#pragma target 3.0”等这样的东西。如果我们放弃对SM2.0的支持，最小支持标准提高，而且你不需要担心太多。

减少了Unity开发人员很多麻烦。例如，你不会想知道，我们会花费多少时间实现在Unity5 上支持DX9 SM2.0。实际上，我们可以用这些时间做更有用的事情。！

坏处：Unity 游戏将不能在Intel GMA950/82945 GPU上运行。

影响：Windows Standalone平台的开发者。

时间：Unity 5.4(2016年3月)

硬件：停止支持Windows Store APP DX11 featurelevel 9.1 GPUs

---

几乎所有的WindowsStore Apps 设备至少都支持DX11 feature level 9.3(所有的Windows手机设备都是)。但是过去有一两个较早的设备只支持feature level 9.1。

这样做的好处：

所有的WSA/WP8着色器将会被编译成feature level 9.3而不是9.1,增加更多的以前不能用的功能（多重渲染目标(multiplerender targets)，像素着色器中的派生指令(derivative instructions)等等）

我们可以移除不少过去用来处理9.1限制的代码。

坏处：你的Windows StoreApps将不再支持9.1设备（大致上指的就是”SurfaceRT平板电脑”）。注意Windows Phone不会受到影响，因为所有的手机都是最少支持9.3。

影响： WindowsStore Apps 开发者。

时间：Unity5.4（2016年3月）

着色器：停止在Android OpenGL ES 2.0上支持“native shadow maps”

---

阴影映射可以通过以下两种方式实现：一种是使用”本地GPU支持“从阴影贴图(shadowmap)中采样后直接返回”阴影值“，也可能使用硬件的PCF过滤，）另一种是”手动“进行（从阴影贴图中获取深度信息，与像素深度做比较来决定是否在阴影范围内）。

第一种形式通常被喜欢更好一些，尤其因为很多GPUs提供“免费的”2*2 PCF filtering过滤. 在大多数平台式上，我们预先知道哪些阴影模式(shadow modes)受到支持，但是Android OpenGLES 2.0是奇怪的，因为一些设备支持“本地阴影贴图(native shadow maps)”,但是一些别的设备不支持。这就意味着所有shadow阴影相关的着色器，如在Android ES 2.0上,我们都要编译成两种着色器，以涵盖这两种情况。

然而，我们看见发现数据显示在Android上支持EXT_shadow_sampler的特别少（所有设备中有1-2%）。因此我们认为直接移除对它的支持是可以的。我们会一直认为把Android ES 2.0看成“在阴影上执行手动深度比较(manualdepth comparison for shadows)” 的平台。

这样做的好处：

减少在AndroidES平台上运行时编译、发送、加载的shader variants数量。

坏处：

大约1%的Android ES 2.0设备将不再有执行硬件阴影PCF采样.而是在shader里做一个稍微慢一点的深度比较。然而需要注意的是，所有这些设备都能够使用具备内置PCF的Open GL ES 3.0，所以最好加入对它的支持！

影响：面向OpenGL ES2.0的Android开发人员。

时间：Unity 5.4(2016年3月)

原文作者：ARAS PRANCKEVIČIUS

本文由蛮牛社区(manew.com)amazonove,王顺英翻译发布，除合作社区及合作媒体外，禁止转载。

蛮牛社区(manew.com)分享最新的游戏研发和虚拟现实相关技术内容。

蛮牛译馆现公开招募＂蛮牛译员＂，欢迎想要报名的网友在下方留言联系小编呦~