源自TextureUV
if
(_StaticUV1)
o.uv.xy = v.texcoord1.xy * unity_LightmapST.xy + unity_LightmapST.zw;
else
o.uv.xy = v.texcoord2.xy * unity_DynamicLightmapST.xy + unity_DynamicLightmapST.zw;
这个就顾名思义吧，如果bake了lightmap就使用第二套uv，如果没有bake，就使用第三套uv。
为啥这样做，如果bake了，大家都知道第二套uv是留给lightmap的，但是没有bake的时候，第二套uv可能是我们自己自定义用于别的目的，但是我们可能没有第三套uv啊，难道unity自己给我们copy了一份？
_Decode_HDR这个参数没有找到出处，估计是unity引擎里封装了之后，传值过来的吧。
接下来看一下
result =
LinearToGammaSpace
(result);
这个LineraToGammaSpace方法顾名思义了
inline
half3
LinearToGammaSpace
(
half3
linRGB)
{
linRGB =
max
(linRGB,
half3
(
0.
h,
0.
h,
0.
h));
// An almost-perfect approximation from http://chilliant.blogspot.com.au/2012/08/srgb-approximations-for-hlsl.html?m=1
return
max
(
1.
055h *
pow
(linRGB,
0.
416666667h) -
0.
055h,
0.
h);
// Exact version, useful for debugging.
//return half3(LinearToGammaSpaceExact(linRGB.r), LinearToGammaSpaceExact(linRGB.g), LinearToGammaSpaceExact(linRGB.b));
}
一个几乎完美的近似公式。
上面那根是pow(x,1/2.2)的曲线
下面那根是近似公式的曲线。
我截图的x范围是0-12，也就是说在0-1的范围能两个曲线基本上完美相似。
从这个公式中可以看出点什么呢？
反正我一头雾水，使用近似公式的普遍目的是什么？绝大多数是我了减少运算量。
但是这里我并没有看出来（1/2.2=0.45454545454545454545454545454545）。
1.055*pow(x,0.416666667)-0.055 与 pow(x,0.454545455)显然是后者的更少。
这么一来，我只能怀疑自己的认知了。
于是我有找了找GammaSpace与LinearSpace的资料重新翻读。
But But But。。。一圈下来可能是我google的方式不对，大家好像都是这么认为的。
冷不丁的。。。对，布丁挺冷的。。。哎，开了一个冷笑话。。
inline
float
LinearToGammaSpaceExact
(
float
value)
{
if
(value <=
0.
0F)
return
0.
0F;
else
if
(value <=
0.
0031308F)
return
12.
92F * value;
else
if
(value <
1.
0F)
return
1.
055F *
pow
(value,
0.
4166667F) -
0.
055F;
else
return
pow
(value,
0.
45454545F);
}
看到了源码中的这个精确的版本。
也就是说这个才是精确版本，所以近似版的优化还是挺多的
我先重新贴一下之前那两个方法的曲线图吧
接下来是Exact精确的计算方式的图
然后是三种方式的比较图
对于人眼这种极为感性的观察器官来说，几乎很难去察觉这一点的变化。，但是官方却用1.055*pow(x,0.416666667)-0.055，
x=0的时候，返回值是-0.055；
虽然两个很接近，差那点运算量也微乎其微。难道unity。。。。嗯。。。。
http://filmicworlds.com/blog/linear-space-lighting-i-e-gamma/