这个是因为自己被自己蠢哭了动笔的，里面大概记录自己所犯的错，和一些小知识。
1.有一个错误我经常犯：内部定义的字段没对应开放到编辑器的字段。这个是由于我有点依赖ide写代码的习惯导致，而shader的ide只提供了基本的关键字高亮。
纠正方法：对一个字段，一直使用拷贝粘贴的方式进行书写。
cg教程给了一个写cg代码的tip:
2.法线没归一化正确，导致效果奇奇怪怪，这个我是在写matcap那里犯的错：漏了这句：
o.twoUv.zw = o.twoUv.zw * 0.5 + 0.5;//(-1,1)->(0,1)
3.Tiling和Offset:
Tiling:缩放模型UV纹理采样坐标，比如Tiling = 2,表示把模型UV坐标的U扩大2倍，U范围变成了0-2
[此时模型U=[0,1]就采用了整个纹理，即模型的左半使用整个纹理;模型U = (1,2]的采样值使用纹理溢出填充值，看下面]
Offset：偏移模型UV纹理采用坐标；比如Offset x=0.1表示把UV纹理坐标往左偏移，然后再采样，
至于超出UV纹理的UV坐标采样的颜色值(纹理溢出填充值)，则依赖UV纹理的WrapMode
具体实现：
float4 _MainTex_ST;//纹理缩放偏移向量（Unity默认此变量赋值，变量命名规则：纹理名_ST）
vert()
{
...
//第一种方式：
o.uv = v.vertex.xy * _MainTex_ST.xy + _MainTex_ST.zw;
//第二种方式：使用内建宏,这只是对第一种的封装
o.uv = TRANSFORM_TEX(v.vertex,_MainTex);
}
4.shader的几个优化tips：
1.gpu是并行运算，即运算一个float和运算float4是一样代价的，所以：
float4 color;
color.rgb = color.rgb*a;
color.a = color.a*b;
可以改成：float4 color; color = color*float4(a,a,a,b)
2.少用if else，用step+乘法代替：
step的定义图
如：
if (a >= b) { c = 1; } else { c = 2; } //可以用下面的代替 tmp = step(b,a) c = tmp + 2 *(1-tmp);
这里讲一下步骤：
第一步，参照step的定义图，我们需要先想方设法把if内的内容搞成 a >= b或者a <= b,然后分析一下if else里面所求内容,写成可以根据step得到的0或1进行计算的表达式，因为shader的判断逻辑一般比较简单，所以这一步不会特别难，然后就ok了，下面让我们来做一下：
改写:
if(a && b)
{ c = 1; }
else{c = 2;}
a&&b可以用乘法来代替，即if (a*b <=0)[这里也不严谨，如果a，b是负数就不对了，但很少会是负数]，所以我们对比step的定义图可以得到：
tmp = step(a*b,0);
c = tmp + 2 * (1-tmp);
3.如果能用fixed(-2,2)就用fixed，不然用half，最后才考虑用float，是几倍的性能之差。
4.使用纹理来编码函数，即控制贴图，可以用很小的贴图然后通过插值获得大范围的数据，这些都是GPU硬件支持的，节省了GPU处理周期。
5.只渲染必须着色的片段。比如可以预先打开深度测试，然后再对经过测试的片段进行fragment shader指令。
5.
- float4 _Time : Time (t/20, t, t*2, t*3), use to animate things inside the shaders
6.记一次svn从主干merge .unity场景文件到分支的坑：
1.必须文件级别merge，不能文件夹级别merge，也就是说merget from的目录要详细到该文件
2.merge后必须在分支打开该.unity文件，看是否和主干一致，我发现修改一些obj的static属性没有同步过去
总结：.unity文件不知具有何特殊性，svn merge时需要谨慎对待，这次问题出乎我意料，严重影响了出包时间。
7.GrabPass捕捉屏幕纹理
Shader "Custom/GrabVF" { Properties { //_MainTex ("Base (RGB)", 2D) = "white" {} } SubShader { // 在所有不透明对象之后绘制自己，更加靠近屏幕 Tags{"Queue"="Transparent"} // 通道1：捕捉对象之后的屏幕内容放到_GrabTexture纹理中 GrabPass{} // 通道2：设置材质 Pass{ Name "pass2" CGPROGRAM #pragma vertex vert #pragma fragment frag #include "UnityCG.cginc" sampler2D _GrabTexture; float4 _GrabTexture_ST; struct v2f { float4 pos : POSITION; // 输入的模型空间中，顶点坐标信息 float4 uv : TEXCOORD0; // 材质信息也包含了xyzw，通常只用xy，但是这里由顶点生成 }; v2f vert (appdata_base v) { v2f o; // 从模型坐标-世界坐标-视坐标-（视觉平截体乘以投影矩阵并进行透视除法）-剪裁坐标 o.pos = mul(UNITY_MATRIX_MVP,v.vertex); //o.uv = TRANSFORM_TEX(v.texcoord, _GrabTexture);// UV纹理坐标集信息来自屏幕样本对象，如果用这个uv采样，就把全屏的纹理显示到当前物体上了。 float4 screenUV = ComputeGrabScreenPos(o.pos);//计算该模型顶点在屏幕坐标的纹理信息，,_GrabTexture得到的是全屏纹理，要根据当前模型所在位置进行采样，显示的是物体背后的屏幕纹理而不是全屏，这个函数输入的是在[-w,w]立方体中的坐标，输出的是[0,w]立方体中的坐标，所以下面还要/w o.uv = screenUV.xy/screenUV.w; return o; } float4 frag (v2f i) : COLOR { // 对_GrabTexture纹理进行取样，进行2D纹理映射查找 half4 texCol = tex2D(_GrabTexture, i.uv); // 颜色反相，便于观察效果 return 1 - texCol; } ENDCG } } FallBack "Diffuse" }
当然也可以把相机rtt到一个tex中，然后把tex设给物体的shader，这样也能获得屏幕纹理了。
8.语义可以在结构里修饰变量，也可以直接修饰变量
struct app_data { float4 pos: POSITION; } void vert(app_data v){} void vert(float4 pos:POSITION){}
语义是一种黏合剂，它把流水线各个阶段的数据连接起来，它指明了数据对应的硬件资源，只有入口函数（顶点函数/片段函数）才使用语义，内部函数(库or自定义的)不能使用。
但同一个语义在不同阶段（输入、输出、顶点、片段）不是一样的，它只是连接“不同阶段”，比如应用程序的输出和顶点函数的输入，顶点函数的输出和片段函数的输入，使得后者可以去相应硬件取得前者的值并生产自己的值，比如片段函数的输入的POSITION其实是顶点函数输出的POSITION插值后的数值，并不一致。
9.swizzle重组操作符是一个圆点.:
float4 a;
a.z;a.wz;等，这个操作符效率很高，被硬件支持。
矩阵重组：
float a; float3 b;
float4x4 matrix;
a = matrix._m32;b = matrix._m32_m00_m11;也可以数组提取b = matrix[0].xyz;
写入掩码:float4 a = (0,0,0,00;float2 b = (1,1); a.xz = b;这里不能写成a.zz，即写入掩码不能重复。
10.可以用使用“out”、“inout”、“in”等进行输入输出标识，无限制是默认是in， out可以用来输出更多变量，但感觉这个用处不大，毕竟使用结构体就能够输出多个。
11.
，即较老的机器可能出乎意料。
12.基本的片段profile（即早期）只能用一个给定的纹理坐标集存取它对应的纹理，即一个纹理一次只能读取采样一次，下面是不支持的：
float4 col1 = tex2D(_tex, uv1);
float4 col2 = tex2D(_tex, uv2);
需要搞成：tex2D(_tex, uv1);tex2D(_tex1, uv2);其中_tex和_tex1绑定同一纹理
13.diffuse = Kd * Max(dot(N, L), 0);
specular = Ks * (Max(dot(N, H), 0)^shininess;其中H 是规范化V和L的半角向量：H = normalize(V+L);
14.顶点shader 访问的光照向量，视线向量，是物体空间吗？应该是了，毕竟Unity的光照函数里，直接用之和模型的法线进行计算了，而那个法线是物体空间的。
15.有人在知乎问如何评测一个shader的性能，我摘取了叶劲峰老师的答案片段：
游戏过程有很多变数，例如渲染1个接近镜头的NPC和渲染10个远离镜头的NPC，其性能分别难以预测。瓶颈经常会改变。
有一些shader是较容易评测的，例如，全屏后期处理的瓶颈在于pixel shader、纹理采样和带宽，其运行复杂度与屏幕分辨率成正比。
对于其他shader，最简单的评测方式是，观察shader源代码编译成汇编之后的一般指令及纹理采样指令数目。这是一个非常粗糙的评测方式，但可以用于作一些简单的统计，找出那些可能有问题的shader。这适合像UE给美术随意创建shader的情况。
但在游戏开发中，我看到一般的做法是，以执行游戏来作整体评测及优化，而不是单独评测各个部分。一方面是因为游戏有很多变数，另一方面是因为人力成本。所以通常会做一些自动评测整体性能的测试，例如让Bot在场景中行走，记录整体的帧率、CPU/GPU时间、draw-call等。如自动测试程序发现超出预期的数值，就发电邮通知团队。这种测试每天自动执行，可画出按天数的性能图表，知道开发及优化的整体情况。
这种做法大概也可以推广到其他方面的自动化监控。
16.把对各个顶点数值不同的计算放shader里，把对各个顶点数值相同的变量放cpu里，然后传给shader
17.许多实现可以在顶程序点实现，也可以在片段程序实现，一般地，在后者实现能提高效果，但前者实现能提高性能，要斟酌。另外，如果该变量在顶点间是线性变化的，应该在顶点shader里计算，或者变化不快（如漫反射系数），可以在顶点shader里计算，如果变化很快（如高亮系数），应该在片段shader里计算，实践见真知。