任务计划 图形界面
这是我们计划从Unity的未来版本中“删除”的与图形相关的事物的摘要，也就是 为了使渲染的光辉未来而丢失的事物 。 (This is a heads-up of graphics related things we plan to “drop” from future versions of Unity, a.k.a. Dropping of Things for Make Benefit Glorious Future of Rendering.)
Sometimes when we try to make things better (better looking, faster, more flexible, etc.), we find that some old corner case or old hardware limitations get in the way. In general, we try to keep as much as possible working between versions of Unity, but sometimes the potential benefit of removing legacy functionality is just too great and said functionality hopefully affects very few people (if any).
有时，当我们尝试使事情变得更好(外观更好，更快，更灵活等)时，我们发现某些旧的旧情况或旧的硬件限制会妨碍您的工作。 总的来说，我们尝试在两个版本的Unity之间保持尽可能多的工作，但是有时删除旧功能的潜在好处实在太大了，并且说该功能希望影响很少的人(如果有的话)。
So without further ado, here’s a tentative list of graphics related “it will stop working” items. Note that all these are “planned” and not actually done yet, so if you really, really need them to keep on working forever, let us know!
因此，事不宜迟，这里是与“将停止工作”项目相关的图形的暂定列表。 请注意，所有这些都是“计划中的”并且尚未实际完成，因此，如果您 确实 需要它们永远继续工作，请告诉我们！
着色器：放弃对“预编译”着色器资产的支持 (Shaders: Drop support for “precompiled” shader assets)
A “precompiled” shader is the one that effectively comes “without source code”. Instead of having readable HLSL code in there, these shaders contain already compiled shader assembly or microcode or translated shader code for several platforms.
“预编译”着色器是有效地“没有源代码”的着色器。 这些着色器不是在其中包含可读的HLSL代码，而是包含已编译的着色器程序集或微代码或已翻译的用于多个平台的着色器代码。
One problem with “precompiled” shaders (if you got them from somewhere) is that they will not work on platforms that might appear in the future. Say you’ve got a shader that was precompiled for DX9, OpenGL and OpenGL ES 2.0. This shader will not work on consoles, Metal, DX11 and so on! Hence using precompiled shaders is typically a bad practice for this reason alone.
“预编译”着色器 (如果您从某处获取它们)的 一个问题 是，它们将无法在将来可能出现的平台上运行。 假设您已经为DX9，OpenGL和OpenGL ES 2.0预编译了一个着色器。 此着色器不适用于控制台，Metal，DX11等！ 因此，仅由于这个原因，使用预编译的着色器通常是一个不好的做法。
Another reason why we want to remove support for them is because we want the shader serialization format to be much more efficient in disk storage, load times and runtime memory usage. The shader format we had so far was, shall we say, fairly inefficient text-based format that resulted in long shader load times and high memory usage. In our current experiments, we’re seeing big reductions in both of these (megabytes to dozens of megabytes saved depending on shader variant complexity, etc.) by changing to more efficient shader data format. However, that makes these “precompiled with old version of Unity” shaders not work anymore. We think that’s a fair tradeoff.
我们想要删除对它们的支持的另一个原因是，我们希望着色器序列化格式 在磁盘存储，加载时间和运行时内存使用 方面 更加高效。 到目前为止，我们所使用的着色器格式 相当低效 ，是基于文本的格式，导致着色器加载时间长且内存使用率高。 在当前的实验中，通过更改为更高效的着色器数据格式，我们看到这两种方法都可以大幅度减少(根据着色器变体的复杂性节省的兆字节至数十兆字节)。 但是，这使得这些“与Unity的旧版本进行预编译”的着色器不再起作用。 我们认为这是一个公平的权衡。
Advantages:
优点 ：
-
Shaders take up less space in your game data files (multiple times smaller).
着色器在您的游戏数据文件中占用的空间更少( 小 倍 )。
-
Shaders load much faster, and especially the “hiccups on the main thread” while loading them asynchronously are much smaller.
着色器的加载速度要快得多，尤其是异步加载它们时，“主线程打ic”要小得多。
-
Shaders take up a lot less memory at runtime.
着色器在运行时占用的内存少得多。
-
“Show compiled code” in shader inspector will display actual shader disassembly on DX11, instead of a not-very-usable sea of vowels.
着色器检查器中的“显示已编译代码”将在DX11上显示实际的着色器反汇编，而不是不太常用的元音海。
Disadvantages:
缺点 ：
-
Precompiling your shaders (“show compiled code” from shader inspector) and then later on using that code directly will stop working.
预编译着色器(来自着色器检查器的“显示已编译代码”)，然后在以后直接使用该代码将停止工作。
Affects: People who precompile shaders, and people who got precompiled shaders from someone else.
影响 ：预编译着色器的人，以及从其他人获得预编译的着色器的人。
When: Unity 5.3 (2015 December)
时间 ：Unity 5.3(2015年12月)
硬件：不再支持DirectX 9 Shader Model 2.0 GPU (Hardware: Drop support for DirectX 9 Shader Model 2.0 GPUs)
DX9 SM2.0 GPUs are fairly old and we’d like to drop support for them! This would mean that these GPUs would stop working in your Unity games: NVIDIA before 2004 (pre-GeForce 6000), AMD before 2005 (pre-Radeon X1000) and Intel before 2006 (pre-GMA X3000/965). In short, GPUs older than 10 years or so would stop working. Looking at the data, it seems that it’s only Intel GMA 950 aka 82945 GPU that is still sometimes found in the wild these days — so that one would stop working.
DX9 SM2.0 GPU相当旧，我们希望放弃对它们的支持！ 这意味着这些GPU将无法在您的Unity游戏中运行：2004年之前的NVIDIA (GeForce 6000之前的NVIDIA) ，2005年之前的 (Radeon X1000 之前的 ) AMD 和2006年之前的 (GMA X3000 / 965 之前 )的 英特尔 。 简而言之，超过10年左右的GPU将停止工作。 从数据来看，似乎只有Intel GMA 950或82945 GPU有时在野外有时仍能找到-这样一来，它就可以停止工作。
Note that we’re not dropping support for DirectX 9 as a whole! Often that is still the only practical option on Windows XP, which just isn’t going away… DirectX 9 rendering support (on Shader Model 3.0 or later GPUs) will continue to be in Unity for quite a while.
请注意，我们不会整体上放弃对DirectX 9的支持！ 通常，这仍然是Windows XP上唯一可行的选择，并且不会消失……DirectX 9渲染支持(在Shader Model 3.0或更高版本的GPU上)将继续在Unity中使用很长时间。
Advantages of doing this:
这样做的好处 ：
-
Less hassle for people writing shaders. Currently, all newly created shaders in Unity are compiled to “lowest common denominator” by default (shader model 2.0) and if you want any of more advanced features (vertex textures, dynamic branching, derivatives, explicit LOD sampling etc.), you need to add things like “#pragma target 3.0” etc. If we’d drop SM2.0 support, the minimum spec goes up and you don’t have to worry about it as much.
减少了编写着色器的麻烦。 当前，默认情况下，Unity中所有新创建的着色器均被编译为“最低公分母”(着色器模型2.0)，如果您需要任何更高级的功能(顶点纹理，动态分支，导数，显式LOD采样等)，则需要添加诸如“ #pragma target 3.0”之类的内容。如果我们放弃对SM2.0的支持，最低规格将提高，您不必为此担心。
-
Way, way less hassle for us internally at Unity. You don’t want to know, for example, how much time we’ve spent on trying to cram Unity 5 physically based shaders into DX9 SM2.0 fallbacks. We could be doing actually useful stuff in that time!
这样， 在内部团结 路 少些麻烦我们。 例如，您不想知道我们花了多少时间尝试将基于Unity 5的物理着色器塞入DX9 SM2.0后备。 那时 我们可能会做一些 有用的 事情！
Disadvantages:
缺点 ：
-
Unity games would no longer work on Intel GMA 950 / 82945 GPU.
Unity游戏将无法在Intel GMA 950/82945 GPU上运行。
Affects: Windows standalone player developers.
影响 ：Windows独立播放器开发人员。
When: Unity 5.4 (2016 March).
时间 ：Unity 5.4(2016年3月)。
硬件：不再支持Windows Store Apps DX11功能级别9.1 GPU (Hardware: Drop support for Windows Store Apps DX11 feature level 9.1 GPUs)
Almost all Windows Store Apps devices are at least DX11 feature level 9.3 capable (all Windows Phone devices are). But there were one or two devices in the past that only supported feature level 9.1, so that dragged down the minimum spec that we had to support.
几乎所有Windows Store Apps设备都至少具有DX11功能级别9.3的功能(所有Windows Phone设备都具有)。 但是过去有一两个设备仅支持9.1级功能，因此降低了我们必须支持的最低规格。
Advantages of doing this:
这样做的好处 ：
-
All WSA/WP8 shaders will be compiled to feature level 9.3, instead of 9.1, gaining some more functionality that wasn’t working previously (multiple render targets, derivative instructions in pixel shaders etc.).
所有WSA / WP8着色器将被编译为功能级别9.3，而不是9.1，从而获得了一些以前无法使用的功能(多个渲染目标，像素着色器中的派生指令等)。
-
We get to remove quite some code that had to deal with 9.1 limitations before.
我们之前删除了很多必须处理9.1限制的代码。
Disadvantages:
缺点 ：
-
Your Windows Store Apps would no longer support 9.1 devices (in practice this pretty much means “Surface RT tablet”). Note that Windows Phone is not affected, since all phones have at least 9.3 support.
您的Windows应用商店应用将不再支持9.1设备(实际上，这意味着“ Surface RT平板电脑”)。 请注意，由于所有电话均至少支持9.3，因此Windows Phone不会受到影响。
Affects: Windows Store Apps developers.
影响 ：Windows Store Apps开发人员。
When: Unity 5.4 (2016 March).
时间 ：Unity 5.4(2016年3月)。
着色器：在Android OpenGL ES 2.0上放弃对“本机阴影贴图”的支持 (Shaders: Drop support for “native shadow maps” on Android OpenGL ES 2.0)
Shadow mapping can be done using either “native GPU support for it” (sampling the shadowmap directly returns the “shadow value”, possibly also using hardware PCF filtering), or “manually” (sample depth from the shadowmap, compare with surface depth to determine whether in or out of shadow).
可以使用“原生GPU支持” (对 阴影贴图进行 采样直接返回“阴影值”，还可以使用硬件PCF过滤) 或“手动” (从 阴影贴图 采样的 深度，与表面深度进行比较 ) 来完成阴影贴图。 确定是否在阴影内或阴影外) 。
The first form is usually preferred, especially since many GPUs can provide 2×2 PCF filtering “for free”. On majority of platforms, we know ahead of time which of the shadow modes they support, however Android OpenGL ES 2.0 was the odd one, since some devices support “native shadow maps” (via EXT_shadow_samplers extension), but some other devices did not. This meant that for any shadow related shader, for Android ES 2.0 we’d have to compile and ship two variants of the shader to cover both cases.
通常首选第一种形式，尤其是因为许多GPU可以“免费”提供2×2 PCF过滤。 在大多数平台上，我们会提前知道它们支持哪种阴影模式，但是Android OpenGL ES 2.0是奇怪的一种，因为某些设备支持“本机阴影贴图”(通过 EXT_shadow_samplers 扩展)，而其他一些设备则不支持。 这意味着对于任何与阴影相关的着色器，对于Android ES 2.0，我们都必须编译并提供着色器的两个变体以涵盖两种情况。
However, we looked at the data and it seems that support for EXT_shadow_samplers on Android is extremely rare (1-2% of all devices). So we think it’s worth it to just remove support for that; we’d just always treat Android ES 2.0 as “manual depth comparison for shadows” platform.
但是，我们查看了数据，似乎在Android上很少支持EXT_shadow_samplers(占所有设备的1-2％)。 因此，我们认为删除对此的支持是值得的。 我们只会一直将Android ES 2.0视为“阴影的手动深度比较”平台。
Advantages of doing this:
这样做的好处 ：
-
Less shader variants to compile, ship and load at runtime on Android ES 2.0.
更少的着色器变体，可在运行时在Android ES 2.0上进行编译，发布和加载。
Disadvantages:
缺点 ：
-
About 1% of Android ES 2.0 devices would no longer do hardware shadow PCF sampling, but instead do a slightly slower depth comparison in the shader. Note, however, that all these devices can use OpenGL ES 3.0 which has built-in PCF, so it’s better to include support for that!
大约1％的Android ES 2.0设备将不再进行硬件阴影PCF采样，而是在着色器中进行稍慢的深度比较。 但是请注意，所有这些设备都可以使用内置PCF的OpenGL ES 3.0，因此最好包括对此的支持！
Affects: Android developers targeting OpenGL ES 2.0.
影响 ：面向OpenGL ES 2.0的Android开发人员。
When: Unity 5.4 (2016 March).
时间 ：Unity 5.4(2016年3月)。
翻译自: https://blogs.unity3d.com/2015/08/27/plans-for-graphics-features-deprecation/
任务计划 图形界面