Pbr渲染
国庆节前的老版本工程和最新的工程版本运行起来没任何区别，但新版本在真机上的的运行效率有问题，只有7.5fps
开发和运行环境，
XCode6.1 IOS8.1
IPad Air 分辨率 2048x1536
Graphic level GLES 3.0
图1 老版本的运行截图，为了能做参考，我这里把新版本的场景文件拷贝到老工程里
新版本相同的场景就只有不到8FPS
然后对两个版本用Xcode做了分析，旧版本fps analyze
新版本fps analyze,同样的shader消费的ms是老版的5倍
发现bug后，尝试定位问题
1 一开始认为是marmoset版本问题，但用老版本完全覆盖，fps并没有提升
2 删除和场景资源相关外的所有资源，重新build后，fps就恢复了，不过这种解决方法应该是无非接受的
目前临时的解决方法，把老工程的ProjectSettings里的文件替换过好了，具体的原因还要继续排查。
另外有一些版本的SkyShop的Mobile shader没有gles3.0的支持，需要在给所有场景里使用的Marmoset的shader里添加关键字
#pragma surface MarmosetSurf MarmosetDirect vertex:MarmosetVert exclude_path:prepass noforwardadd approxview
#pragma only_renderers d3d9 opengl gles d3d11 d3d11_9x gles3
好早marmoset的是UberShader的设计，所以只要改几个就好了。
要unity支持es3.0的话，需要在设置Player Settings.. 的图形等级里选择 Automatic或强制gles3.0。
如果只用es2.0的话，因为unity会使用texCube或texCubeBias来替换texCubeLod，没有lod的支持，使用cubemap的mipmap来实现粗糙度的功能就会受到影响
最终渲染画面里可能会看不到材质的粗糙度表现。
如果把这个bug解决的话，那么性能评估应该和10.1前的报告一样，IPad Air 可以承受的是全屏，100Draw Call的支持IBL材质物体的绘制，另外有IBL的shader的瓶颈
应该是在pixel shader上，如果1，2个IBL材质占满整个2048x1536屏幕的话，一样会有潜在的瓶颈问题产生。
二、关于另外一个场景的问题解决
Draw Call可以先在Editor或联机Porfile里查看，一些设备不支持Unity Editor的GPU Profile，所以还是要用到Xcode
没做任何优化的前提下 draw call是592, GPU里两个占用最高的shader，9.8ms和7.94ms都是Terrain占用的（地形和他和阴影贴图），
另外关闭阴影后为289 drawcall，关闭地形后289->219（地形 70dc），关闭水面289dc->246dc（水面反射）
首先是Terrain，不论是shader还是dc都有些多，在Xcode的Frame view里，Terrain的绘制有不合理的地方，从截图场景来看，这种大小的地形需要70的draw call次数有些夸张了，另外就是shader上，如果是静态烘培阴影，应该是可以合并到一个shader里绘制的。建议还是从优化地形开始，降低dc，合并shader，如果u3d 的terrain没有优化的可能，不如就直接max里制作网格的地面来代替。
水面可以优化反射部分的实现，静态场景的反射可以预烘培到一张贴图里，而可以反射的部分，建议单独添加到一个layer里。降低dc数量。
摄像机的可视范围，角度，以及shader Lod的设置，在Xcode的分析中，一些极远位置的山体还是被绘制了，而且和近处的角色一样高质量的shader，这点用unity的内部设置应该就可以解决。另外这个demo摄像机的角度过低，导致远处的物体也都被渲染到，如果适当修改摄像机角度，例如传统的45视角，应该可以裁剪一部分场景物体。起到降低dc和ps填充率的作用。
三、关于Marmoset shader的改进意见
1。如果不使用skyshop的天空盒的动态功能的话，skymanager的update可以关闭
public void LateUpdate() {
if(firstFrame) {
if(_GlobalSky) {
firstFrame = false;
_GlobalSky.Apply(0);
_GlobalSky.Apply(1);
if(_SkyboxMaterial) {
_GlobalSky.Apply(_SkyboxMaterial, 0);
_GlobalSky.Apply(_SkyboxMaterial, 1);
}
}
}
#if UNITY_EDITOR
if(!Application.isPlaying) return;
#endif
直接在 #if UNITY_EDITOR前面返回return就可以了，这样可以节省skymanager的Update的cpu消耗和GC。
2 GlossyMap的使用，之前为了解决7FPS的问题时，尝试的一种解决方案，在Anylaze里直接修改textureLod的参数
tmpvar_40 = textureLod (_SpecCubeIBL, lookup_38.xyz, lookup_38.w);
例如
tmpvar_40 = textureLod (_SpecCubeIBL, lookup_38.xyz, 1);，
这样效率可以提高1倍以上
分析可以看下图
highp float glossLod_36;
glossLod_36 = tmpvar_27;
mediump vec4 spec_37;
mediump vec4 lookup_38;
highp vec4 tmpvar_39;
tmpvar_39.xyz = ((v_33.xyz * tmpvar_32.x) + ((v_34.xyz * tmpvar_32.y) + (v_35.xyz * tmpvar_32.z)));
tmpvar_39.w = glossLod_36;
lookup_38 = tmpvar_39;
lowp vec4 tmpvar_40;
tmpvar_40 = textureLod (_SpecCubeIBL, lookup_38.xyz, lookup_38.w);
上面是还没有做任何修改的shader，lod，也就是lookup_38.w还是根据glossy map的值，在shader里计算得出
tmpvar_39.w = glossLod_36;
lookup_38 = tmpvar_39;
lowp vec4 tmpvar_40;
tmpvar_40 = textureLod (_SpecCubeIBL, lookup_38.xyz, 1.0);
在shader里直接传一个const值的方法，热更新后可以看到shader消费的ms和之前有一定的减少。
不过重新启动游戏的话，ms有了40%左右的减少，这是因为IOS做的优化，如果lod在shader运行前已经确定的话，会直接pre fetch制定的texture，就不需要在每个pix shader里重新执行一次采样了。
所以，glossy map建议适量使用，一些不需要细节的材质可以直接用一个恒定的roughness参数替代。
还有就是关于pbr shader算法的优化，marmoset自己内部有MARMO_HQ的关键字，通过切换可以实现一定程度的优化，先是两种质量的对比
MARMO_LQ
MARMO_HQ 差别在shader的精确度上，以及出射光的亮度上
MARMO_HQ的用处，对向量的规格化，起到类似能量守恒的作用，Fresenl函数的算法选择，使得渲染的出射光总量更符合物理效果
//self-shadowing blinn
#ifdef MARMO_DIFFUSE_DIRECT
spec *= saturate(10.0*dp);
#else
spec *= saturate(10.0*dot(N,L));
#endif
#ifdef MARMO_DIFFUSE_DIRECT
spec *= saturate(10.0*dp);
#else
spec *= saturate(10.0*dot(N,L));
#endif
#ifdef MARMO_HQ
localN = normalize(localN);
#endif
以上是shader代码里一些规格化设置的样本。
shader里还有其他一些可优化点
例如Specular Intensity，Sharpenss，fresnel Strength，并不是pbr Material的标准参数，一般只需要roughness或glossy map里选择其一做粗糙度参数就可以
而其他参数去掉可以减少一部分shader的计算量
前面提到的glossymap和roughness的切换，需要shader支持，编辑器也要做一定的修改。
fresenl 反射方程，marmoset提供了的 splineFresnel和fastFresnel的两种方法，但实际的计算量还是比较多，根据GDC2014上的unity5的方案，可以换成简单的pow 4次方的形式。
确定TextureCubeLod的方向和lod值的算法上也优化的空间。
UberShader的设计是一个优点，在开发的时候可以减少很大的工作量，实际运行时，创建和编译shader数量也很少，方便分析和定位shader的问题，和在Xcode里进行优化调试。
另外就是marmoset的skymanager部分，还是需要修改的，他本来的设计目的是基于天空盒来生成IBL使用的Cubemap，而真正的IBL光照是基于周围环境来生成，所以，skyshop这种整个场景统一一张cubemap的方法，在真实性和效果上还是很值得斟酌的，它的IBL的生成和管理接口对做游戏来说也不是很方便，优点就是它提供了编辑器和cumbemap生成部分的全部代码，不论是扩展还是修改bug，都是可行的。
unity4.x的版本里，在移动端是无法支持延迟渲染方法的，所以对场景里的光源限制会比较严格，一盏方向光就是极限了，其他烘托场景的用的点光源，就只能使用lightmap了
而lightmap的具体算法，也是要用户自己实现的，Marmoset在MarmosetDirect.cginc里实现了directional lightmap lighting的实现，LightingMarmosetDirect_DirLightmap
这个的命名是要按照unity custom shader的规范来命名，就可以在unity渲染管线里自动被识别，如果想优化，或者要支持Dual lightmap等其他类型的liaghtmap，最好还是自己提供优化的方法。希望我们自己的项目里，将来能提供TBDR的支持来达到大量光源的支持。
最后考虑还是要和UE4的移动产品做一下竞品测试的：
UE4的Sum Temple项目是个很好的参考，gles2.0的图形规格下，也能获得很好的效果
UE4 mobile的图形规格，简单来说就是一个Directional light+distance shadow来生成光照和阴影，其他的场景明暗和各种颜色灯光的亮度由lightmap来实现，
IBL方面，可以为通过设置RefelctCapture，给制定区域内的对象生成IBL，同一场景内可以使用多个cubemap的实现（ppt里说他在移动端是使用了一个统一的cubemap，这点需要后面直接对它的工程做真机剖析了）。另外也有bloom+AA+light shaft+dof等的后处理效果，但因为图形规格的限制，ES2.0版本是没有真实HDR的支持的。
接下来我会用业余时间准备一篇针对UE4渲染和优化方法的分析。
四，总结
通过这次U3D的PBR的实验，在IPAD Air和K1这种硬件级别的机器上，制作PBR的游戏还是没有问题的，一开始担心视网膜屏的填充率问题，在实际测试中，还是可行的，但需要整个开发团队有一定的优化意识，才能在整个上保证一个良好的运行效率，比如支持IBL的分配，而且游戏制作方面，也要考虑什么样的游戏类型，才能发挥PBR渲染的优势，特别是间接照明对游戏场景品质的提升（消费最高的IBLshader支持的是间接照明的高光部分）。还有就是多使用unity的batch功能，尽量降低dc和关于shader状态切换等等，另外可惜的是，因为之前7fps bug的问题，这次没有时间把unity的post effect部分实现，个人考虑是可以把ue4的这部分实现移植过来， UE4对U3D可以起到很好的竞品作用，在今后的PBR效果和效率的测试和优化中，一定的对比分析和借鉴，也是很有帮助的。
转自：http://nuil.cn/topic/96841/pbr渲染