Pbr渲染

一、遇到了fps降低的BUG

国庆节前的老版本工程和最新的工程版本运行起来没任何区别，但新版本在真机上的的运行效率有问题，只有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渲染