ShaderLab: SubShader Tags

        subshader通过tags告诉渲染引擎什么时间什么方式来渲染他们。

        指定TagName1有一个Value1值，TagName2有一个Value2值，如果你愿意的话可以有多个tags。

        tags是基础的键值对，在subshader内的tags决定一个subshader的渲染顺序和其他参数。请注意以下的tags只能被Unity在subshader中识别而不是pass中识别。

        除了被Unity识别的内置tags外，你也可以使用你自己的tags并且通过使用MaterialGetTag方法来查询它们。

        你可以使用Queue tag来决定你的对象被绘制的顺序。shader决定了其对象属于什么渲染队列，这样所有透明的shader确保它们在不透明的物体之后绘制等等。

        有四个预先定义好的渲染队列，但是在预先定义好的队列中间还可以有很多其他队列。预先定义好的队列是：

        ·Background-此渲染队列在其他所有渲染队列之前渲染。你通常可以给真的需要在背景中的对象使用它。

        ·Geometry(默认)-它用于大多数的对象，不透明的几何体使用这个队列。

        ·AlphaTest-经受过alpha测试的几何体使用这个队列。它是从Geometry队列中分离出来的队列。因为在所有实体被绘制之后再来渲染经过alpha测试的对象会更有效率。

        ·Transparent-这个渲染队列在Geometry和AlphaTest队列之后渲染，以从后到前的顺序。任何alpha混合（即不写入深度buffer的着色器）都应该放在这里（玻璃，粒子效果）。

        ·Overlay-这个渲染队列表示叠加效果，任何最后渲染的对象都应该放到这里（比如镜头光晕）。

        一个例子来说明怎样在transparent队列中来渲染一个东西。

        为了特殊的用途也可以使用在中间的队列。在内部每个队列通过整数索引来表示， Background是1000,Geometry是2000,AlphaTest是2450,Transparent是3000,Overlay是4000。如果一个shader使用了一个像这样的队列：

        这将使对象在所有不透明物体之后，透明物体之前渲染，因为渲染队列索引将是2001 (geometry加1)。这在当你想使某些对象总是在一些物体之间渲染时非常有用。比如在大多数情况下透明的水应该在不透明物体之后但是在透明物体之前绘制。

        渲染队列上升到2500（Geometry+500）被认为是不透明的，并且优化对象的渲染顺序来获取最佳性能。更高的渲染队列被认为是“透明物体”并通过距离开排序，从远到近来渲染。天空盒在所有不透明物体和所有透明物体之间绘制。

        RenderType tag将shader分类为一些预定义的组，例如是一个不透明的shader，或是一个经过了alpha测试的shader等等。这用于shader的替换使用（链接见原网页），并且在一些情况下产生相机的深度纹理（链接见原网页）。

        一些shader（大多数是做本地空间顶点变形的），当Draw Call Batching（链接见原网页）被使用时不起作用，这是因为batching将所有几何体变换到了世界空间，所以本地空间丢失了。

        DisableBatching tag可以用于防止上面情况。这里可以有三个值：“True”(总是为此shader禁用batching)，“False”（不禁用batching;这是默认设置），以及“LODFading”（当LOD淡入激活时禁用batching;主要用于树）。

        如果ForceNoShadowCasting tag被设定并且值是true，那么使用这个subshader渲染的对象将永远不会投下影子。这大多数用于当你在透明物体上使用shader替换，并且你将不会从其他subshader上继承一个影子pass。

        如果IgnoreProjector tag被设定并且值是true，那么使用这个shader的对象将不会被被投影效果影响。这大多数用于半透明的物体，因为没有一个比较好的给他们投影的方法。

        如果这个shader是应用于sprite的，那么设置CanUseSpriteAtlas tag的值为false，那么这些sprite被打入图集中的时候此shader将不会工作（请参阅Sprite打包，链接见原网页）。

        PreviewType表示材质的监视面板预览画面来怎样显示材质。默认材质被显示成球形，但是PreviewType也可以被设置为“平板”（将显示为2D）或者“天空盒”（将显示为天空盒）。

        pass也可以具有tags,请看pass tags（链接见原网页）。

像素着色器是什么？
1 像素着色器也是一组指令，这组指令在顶点中像素被渲染时执行。在每个执行时间，都会有很多像素被渲染。（像素的数目依靠屏幕的分辨率决定）2像素着色器的指令和顶点着色器的指令非常接近。像素着色器不能像顶点着色器那样，单独存在。他们在运行的时候，必须有一个顶点着色器被激活。1 像素着色器过去是一种高级图形技术，专门用来提高渲染速度。2 和顶点着色器一样，使用像素着色器，程序员能自定义渲染每个像素。一个像素着色器 *** 作顶点上单独的像素。和顶点着色器一样，像素着色器源代码也是通过一些API加载到硬件的。也和顶点着色器一样，你只需要一个文本编辑器和支持着色器编程的显卡即可。
unity3d 着色器有什么用
这个就涉及到图形渲染管线了，管线就像是一个流水线，从框架上是固定的，但是到了某个阶段怎么 *** 作处理数据是可以编程的，片段着色器就是可编程的一个阶段。

在渲染一个物体时，模型的顶点信息被送给gpu，然后vertex顶点着色器负责将模型顶点从模型空间转换到屏幕空间，之后再将处理过的数据发给fragment片段着色器，它负责计算每个像素的颜色信息。

以上讲的非常简略，也可能不完全准确，仅供大概的理解。建议你去看下unity的官方文档中关于shader的描述。
vertex 顶点

fragment 片段，表示的是可能出现在屏幕上的像素点，也可能由于深度测试等原因没有显示
opengl 着色器 有什么用
这是可编程管线里的术语 着色器分为 顶点和像素 两种 也叫 vertex shader 和 fragment shader(或pixel shader),就是可编程管线里两种代码的称呼用shader可以完成你的各种3d模型,显示需要
什么是硬件顶点着色器
具体说Vertex是计算机图形学中的最基本元素，三个顶点可以连接成一个三角形，而且在三维空间中，而且呵每个顶点都拥差不多和颜色值等数据，
ue显示编译著色器是什么意思
这是因为UE不太支持中文输出。在UE里配置的Java编译命令，编译后再UE输出窗口输出的内容，直接用CMD窗口编译能够输出中文的编译信息。
请问着色器和GPU有什么区别？？
着色器是GPU诸多集成功能中一种
shader的子着色器pass 是什么意思
A Pass can define its Name and arbitrary number of Tags - name/value strings that municate Pass' intent to the rendering engine

一个通道能定义它的Name 和任意数量的Tags （用于向渲染引擎传递通道的意图的名称/值的字符串）。
显卡的着色器频率指的是什么呢？难道是每秒画面颜色变换的速度？？？
着色器频率就是指GPU内部流处理器的频率，没错同步与异步就是指这两者频率之间的关系。

至于和GPU频率的关系，A卡同步、N卡是2:1（现在，GT200的时候更大）。流处理器是渲染单元，频率越高速度渲染越快。A卡流处理器要多很多，N卡则是频率要高很多。因此同等级的A卡与N卡虽然流处理器数量差很多，但是性能差不多。
psp模拟器后处理着色器有什么用
你看到的那些,比如GBA的psp模拟器,是让你放到PSP上用PSP玩GBA游戏用的,在电脑上玩PSP游戏用的PSP模拟器现在没有\r\nPS2游戏难道没有PS游戏好玩但PS2照样兼容PS游戏,那为什么还要兼容\r\n在电脑上玩GBA游戏难道没有在电脑上玩电脑游戏好玩那为什么还要模拟GBA\r\nPSP的一些游戏玩厌了,又想玩一些喜欢的GBA游戏了,又没有GBA,电脑上又不能带着走,那就需要用到了\r\nGBA也有优秀的游戏,虽然画面没有PSP的好,系统没有PSP的很多游戏丰富,但也有很多人会去玩
像素着色器的原理
纹理寻址指令提供了多种读取和应用纹理数据的 *** 作。着色器具有这样的功能，可以给颜色分量设置掩码以及交换颜色分量。着色器的正文看起来有点像汇编语言，它用Direct3D扩展（D3DX）进行汇编，输入可以是文本字符串或是文件。汇编器的输出是一系列 *** 作码，应用程序可以通过IDirect3DDevice9::CreatePixelShader方法把这些 *** 作码提供给Direct3D。本示例用像素着色器对一个四边形的漫反射色进行高洛德插值。示例显示了着色器文件的内容以及应用程序中所需的代码。

简介

在渲染阶段，引擎所做的工作是把所有场景中的对象按照一定的策略（顺序）进行渲染。最早的是画家算法，顾名思义，就是像画家画画一样，先画后面的物体，如果前面还有物体，那么就用前面的物体把物体覆盖掉，不过这种方式由于排序是针对物体来排序的，而物体之间也可能有重叠，所以效果并不好。所以目前更加常用的方式是z-buffer算法，类似颜色缓冲区缓冲颜色，z-buffer中存储的是当前的深度信息，对于每个像素存储一个深度值，这样，我们屏幕上显示的每个像素点都会进行深度排序，就可以保证绘制的遮挡关系是正确的。而控制z-buffer就是通过ZTest，和ZWrite来进行。但是有时候需要更加精准的控制不同类型的对象的渲染顺序，所以就有了渲染队列。今天就来学习一下渲染队列，ZTest，ZWrite的基本使用以及分析一下Unity为了Early-Z所做的一些优化。

Unity中的几种渲染队列

首先看一下Unity中的几种内置的渲染队列，按照渲染顺序，从先到后进行排序，队列数越小的，越先渲染，队列数越大的，越后渲染。

Unity中设置渲染队列也很简单，我们不需要手动创建，也不需要写任何脚本，只需要在shader中增加一个Tag就可以了，当然，如果不加，那么就是默认的渲染队列Geometry。比如我们需要我们的物体在Transparent这个渲染队列中进行渲染的话，就可以这样写：

我们可以直接在shader的Inspector面板上看到shader的渲染队列：

另外，我们在写shader的时候还经常有个Tag叫RenderType，不过这个没有Render Queue那么常用，这里顺便记录一下：
Opaque : 用于大多数着色器（法线着色器、自发光着色器、反射着色器以及地形的着色器）。
Transparent :用于半透明着色器（透明着色器、粒子着色器、字体着色器、地形额外通道的着色器）。
TransparentCutout : 蒙皮透明着色器（Transparent Cutout，两个通道的植被着色器）。
Background : 天空盒着色器。
Overlay : GUITexture，镜头光晕，屏幕闪光等效果使用的着色器。
TreeOpaque : 地形引擎中的树皮。
TreeTransparentCutout : 地形引擎中的树叶。
TreeBillboard : 地形引擎中的广告牌树。
Grass : 地形引擎中的草。
GrassBillboard : 地形引擎何中的广告牌草。

相同渲染队列中不透明物体的渲染顺序

拿出Unity，创建三个立方体，都使用默认的bump diffuse shader（渲染队列相同），分别给三个不同的材质（相同材质的小顶点数的物体引擎会动态合批），用Unity5带的Frame Debug工具查看一下Draw Call。（Unity5真是好用得多了，如果用4的话，还得用NSight之类的抓帧）

可以看出，Unity中对于不透明的物体，是采用了从前到后的渲染顺序进行渲染的，这样，不透明物体在进行完vertex阶段，进行Z Test，然后就可以得到该物体最终是否在屏幕上可见了，如果前面渲染完的物体已经写好了深度，深度测试失败，那么后面渲染的物体就直接不会再去进行fragment阶段。（不过这里需要把三个物体之间的距离稍微拉开一些，本人在测试时发现，如果距离特别近，就会出现渲染次序比较乱的情况，因为我们不知道Unity内部具体排序时是按照什么标准来判定的哪个物体离摄像机更近，这里我也就不妄加猜测了）

相同渲染队列中半透明物体的渲染顺序

透明物体的渲染一直是图形学方面比较蛋疼的地方，对于透明物体的渲染，就不能像渲染不透明物体那样多快好省了，因为透明物体不会写深度，也就是说透明物体之间的穿插关系是没有办法判断的，所以半透明的物体在渲染的时候一般都是采用从后向前的方法进行渲染，由于透明物体多了，透明物体不写深度，那么透明物体之间就没有所谓的可以通过深度测试来剔除的优化，每个透明物体都会走像素阶段的渲染，会造成大量的Over Draw。这也就是粒子特效特别耗费性能的原因。

我们实验一下Unity中渲染半透明物体的顺序，还是上面的三个立方体，我们把材质的shader统一换成粒子最常用的Particle/Additive类型的shader，再用Frame Debug工具查看一下渲染的顺序：

半透明的物体渲染的顺序是从后到前，不过由于半透相关的内容比较复杂，就先不在这篇文章中说了，打算另起一篇。

自定义渲染队列

Unity支持我们自定义渲染队列，比如我们需要保证某种类型的对象需要在其他类型的对象渲染之后再渲染，就可以通过自定义渲染队列进行渲染。而且超级方便，我们只需要在写shader的时候修改一下渲染队列中的Tag即可。比如我们希望我们的物体要在所有默认的不透明物体渲染完之后渲染，那么我们就可以使用Tag{“Queue” = “Geometry+1”}就可以让使用了这个shader的物体在这个队列中进行渲染。

还是上面的三个立方体，这次我们分别给三个不同的shader，并且渲染队列不同，通过上面的实验我们知道，默认情况下，不透明物体都是在Geometry这个队列中进行渲染的，那么不透明的三个物体就会按照cube1,cube2,cube3进行渲染。这次我们希望将渲染的顺序反过来，那么我们就可以让cube1的渲染队列最大，cube3的渲染队列最小。贴出其中一个的shader：

其他的两个shader类似，只是渲染队列和输出颜色不同。

通过渲染队列，我们就可以自由地控制使用该shader的物体在什么时机渲染。比如某个不透明物体的像素阶段 *** 作较费，我们就可以控制它的渲染队列，让其渲染更靠后，这样可以通过其他不透明物体写入的深度剔除该物体所占的一些像素。

PS：这里貌似发现了个问题，我们在修改shader的时候一般不需要什么其他 *** 作就可以直接看到修改后的变化，但是本人改完渲染队列后，有时候会出现从shader的文件上能看到渲染队列的变化，但是从渲染结果以及Frame Debug工具中并没有看到渲染结果的变化，重启Unity也没有起到作用，直到我把shader重新赋给材质之后，变化才起了效果（猜测是个bug，因为看到网上还有和我一样的倒霉蛋被这个坑了，本人的版本是532，害我差点怀疑昨天是不是喝了，刚实验完的结果就完全不对了）

ZTest（深度测试）和ZWrite（深度写入）

上一个例子中，虽然渲染的顺序反了过来，但是物体之间的遮挡关系仍然是正确的，这就是z-buffer的功劳，不论我们的渲染顺序怎样，遮挡关系仍然能够保持正确。而我们对z-buffer的调用就是通过ZTest和ZWrite来实现的。

首先看一下ZTest，ZTest即深度测试，所谓测试，就是针对当前对象在屏幕上（更准确的说是frame buffer）对应的像素点，将对象自身的深度值与当前该像素点缓存的深度值进行比较，如果通过了，本对象在该像素点才会将颜色写入颜色缓冲区，否则否则不会写入颜色缓冲。ZTest提供的状态较多。 ZTest Less（深度小于当前缓存则通过， ZTest Greater（深度大于当前缓存则通过），ZTest LEqual（深度小于等于当前缓存则通过），ZTest GEqual（深度大于等于当前缓存则通过），ZTest Equal（深度等于当前缓存则通过），ZTest NotEqual（深度不等于当前缓存则通过），ZTest Always（不论如何都通过）。注意，ZTest Off等同于ZTest Always，关闭深度测试等于完全通过。

下面再看一下ZWrite，ZWrite比较简单，只有两种状态， ZWrite On（开启深度写入）和ZWrite Off（关闭深度写入） 。当我们开启深度写入的时候，物体被渲染时针对物体在屏幕（更准确地说是frame buffer）上每个像素的深度都写入到深度缓冲区；反之，如果是ZWrite Off，那么物体的深度就不会写入深度缓冲区。但是，物体是否会写入深度，除了ZWrite这个状态之外，更重要的是需要深度测试通过，也就是ZTest通过，如果ZTest都没通过，那么也就不会写入深度了。就好比默认的渲染状态是ZWrite On和ZTest LEqual，如果当前深度测试失败，说明这个像素对应的位置，已经有一个更靠前的东西占坑了，即使写入了，也没有原来的更靠前，那么也就没有必要再去写入深度了。所以上面的ZTest分为通过和不通过两种情况，ZWrite分为开启和关闭两种情况的话，一共就是四种情况：

1深度测试通过，深度写入开启：写入深度缓冲区，写入颜色缓冲区；
2深度测试通过，深度写入关闭：不写深度缓冲区，写入颜色缓冲区；
3深度测试失败，深度写入开启：不写深度缓冲区，不写颜色缓冲区；
4深度测试失败，深度写入关闭：不写深度缓冲区，不写颜色缓冲区；

Unity中默认的状态（写shader时什么都不写的状态）是ZTest LEqual和ZWrite On，也就是说默认是开启深度写入，并且深度小于等于当前缓存中的深度就通过深度测试，深度缓存中原始为无限大，也就是说离摄像机越近的物体会更新深度缓存并且遮挡住后面的物体。如下图所示，前面的正方体会遮挡住后面的物体：

写几个简单的小例子来看一下ZTest，ZWrite以及Render Queue这几个状态对渲染结果的控制。

让绿色的对象不被前面的立方体遮挡，一种方式是关闭前面的蓝色立方体深度写入：

通过上面的实验结果，我们知道，按照从前到后的渲染顺序，首先渲染蓝色物体，蓝色物体深度测试通过，颜色写入缓存，但是关闭了深度写入，蓝色部分的深度缓存值仍然是默认的Max，后面渲染的绿色立方体，进行深度测试仍然会成功，写入颜色缓存，并且写入了深度，因此蓝色立方体没有起到遮挡的作用。
另一种方式是让绿色强制通过深度测试：

这个例子中其他立方体的shader使用默认的渲染方式，绿色的将ZTest设置为Always，也就是说不管怎样，深度测试都通过，将绿色立方体的颜色写入缓存，如果没有其他覆盖了，那么最终的输出就是绿色的了。

那么如果红色的也开了ZTest Always会怎么样？

在红色立方体也用了ZTest Always后，红色遮挡了绿色的部分显示为了红色。如果我们换一下渲染队列，让绿色在红色之前渲染，结果就又不一样了：

更换了渲染队列，让绿色的渲染队列+1，在默认队列Geometry之后渲染，最终重叠部分又变回了绿色。可见，当ZTest都通过时，上一个写入颜色缓存的会覆盖上一个，也就是说最终输出的是最后一个渲染的对象颜色。

再看一下Greater相关的部分有什么作用，这次我们其他的都使用默认的渲染状态，绿色的立方体shader中ZTest设置为Greater：

这个效果就比较好玩了，虽然我们发现在比较深度时，前面被蓝色立方体遮挡的部分，绿色的最终覆盖了蓝色，是想要的结果，不过其他部分哪里去了呢？简单分析一下，渲染顺序是从前到后，也就是说蓝色最先渲染，默认深度为Max，蓝色立方体的深度满足LEqual条件，就写入了深度缓存，然后绿色开始渲染，重叠的部分的深度缓存是蓝色立方体写入的，而绿色的深度值满足大于蓝色深度的条件，所以深度测试通过，重叠部分颜色更新为绿色；而与红色立方体重合的部分，红色立方体最后渲染，与前面的部分进行深度测试，小于前面的部分，深度测试失败，重叠部分不会更新为红色，所以重叠部分最终为绿色。而绿色立方体没有与其他部分重合的地方为什么消失了呢？其实是因为绿色立方体渲染时，除了蓝色立方体渲染的地方是有深度信息的，其他部分的深度信息都为Max，蓝色部分用Greater进行判断，肯定会失败，也就不会有颜色更新。
有一个好玩的效果其实就可以考ZTest Greater来实现，就是游戏里面经常出现的，当玩家被其他场景对象遮挡时，遮挡的部分会呈现出X-光的效果；其实是在渲染玩家时，增加了一个Pass，默认的Pass正常渲染，而增加的一个Pass就使用Greater进行深度测试，这样，当玩家被其他部分遮挡时，遮挡的部分才会显示出来，用一个描边的效果渲染，其他部分仍然使用原来的Pass即可。

Early-Z技术

传统的渲染管线中，ZTest其实是在Blending阶段，这时候进行深度测试，所有对象的像素着色器都会计算一遍，没有什么性能提升，仅仅是为了得出正确的遮挡结果，会造成大量的无用计算，因为每个像素点上肯定重叠了很多计算。因此现代GPU中运用了Early-Z的技术，在Vertex阶段和Fragment阶段之间（光栅化之后，fragment之前）进行一次深度测试，如果深度测试失败，就不必进行fragment阶段的计算了，因此在性能上会有很大的提升。但是最终的ZTest仍然需要进行，以保证最终的遮挡关系结果正确。前面的一次主要是Z-Cull为了裁剪以达到优化的目的，后一次主要是Z-Check，为了检查，如下图：

Early-Z的实现，主要是通过一个Z-pre-pass实现，简单来说，对于所有不透明的物体（透明的没有用，本身不会写深度），首先用一个超级简单的shader进行渲染，这个shader不写颜色缓冲区，只写深度缓冲区，第二个pass关闭深度写入，开启深度测试，用正常的shader进行渲染。其实这种技术，我们也可以借鉴，在渲染透明物体时，因为关闭了深度写入，有时候会有其他不透明的部分遮挡住透明的部分，而我们其实不希望他们被遮挡，仅仅希望被遮挡的物体半透，这时我们就可以用两个pass来渲染，第一个pass使用Color Mask屏蔽颜色写入，仅写入深度，第二个pass正常渲染半透，关闭深度写入。

关于Early-Z技术可以参考ATI的论文Applications of Explicit Early-Z Culling以及PPT，还有一篇Intel的文章。

Unity渲染顺序总结

如果我们先绘制后面的物体，再绘制前面的物体，就会造成over draw；而通过Early-Z技术，我们就可以先绘制较近的物体，再绘制较远的物体（仅限不透明物体），这样，通过先渲染前面的物体，让前面的物体先占坑，就可以让后面的物体深度测试失败，进而减少重复的fragment计算，达到优化的目的。Unity中默认应该就是按照最近距离的面进行绘制的，我们可以看一下Unity官方的文档中显示的：

从文档给出的流程来看，这个Depth-Test发生在Vertex阶段和Fragment阶段之间，也就是上面所说的Early-Z优化。
简单总结一下Unity中的渲染顺序： 先渲染不透明物体，顺序是从前到后；再渲染透明物体，顺序是从后到前 。

Alpha Test（Discard）在移动平台消耗较大的原因

从本人刚刚开始接触渲染，就开始听说移动平台Alpha Test比较费，当时比较纳闷，直接discard了为什么会费呢，应该更省才对啊？这个问题困扰了我好久，今天来刨根问底一下。还是跟我们上面讲到的Early-Z优化。正常情况下，比如我们渲染一个面片，不管是否是开启深度写入或者深度测试，这个面片的光栅化之后对应的像素的深度值都可以在Early-Z（Z-Cull）的阶段判断出来了；而如果开启了Alpha Test（Discard）的时候，discard这个 *** 作是在fragment阶段进行的，也就是说这个面片光栅化之后对应的像素是否可见，是在fragment阶段之后才知道的，最终需要靠Z-Check进行判断这个像素点最终的颜色。其实想象一下也能够知道，如果我们开了Alpha Test并且还用Early-Z的话，一块本来应该被剃掉的地方，就仍然写进了深度缓存，这样就会造成其他部分被一个完全没东西的地方遮挡，最终的渲染效果肯定就不对了。所以，如果我们开启了Alpha Test，就不会进行Early-Z，Z Test推迟到fragment之后进行，那么这个物体对应的shader就会完全执行vertex shader和fragment shader，造成over draw。有一种方式是使用Alpha Blend代替Alpha Test，虽然也很费，但是至少Alpha Blend虽然不写深度，但是深度测试是可以提前进行的，因为不会在fragment阶段再决定是否可见，因为都是可见的，只是透明度比较低罢了。不过这样只是权宜之计，Alpha Blend并不能完全代替Alpha Test。

关于Alpha Test对于Power VR架构的GPU性能的影响，简单引用一下官方的链接以及一篇讨论帖：

最后再附上两篇参考文章

>