新年伊始，随着大家紧锣密鼓地开始了工作，UWA每周推送的知识型栏目《厚积薄发 | 技术分享》已经伴随大家走过了150个工作周。在此我们优选了12个开放性的精彩回答，分享给大家。
UWA QQ群2：（原群已满员）
1、如何设计渲染等级？
现思考如何设计项目中的渲染等级，求有经验的大佬指个方向，例如ShaderLOD，还有其他什么思路吗？谢谢！
精彩回答：正好我也整理过项目的LOD规则，可能不限于题主描述的渲染等级。一套好的LOD系统需要美术在资源上做大量的资源分级工作，需要程序搭建完善的LOD框架和辅助工具，每增加一个功能模块都需要把LOD考虑进来。
一、如何确定项目的LOD分档和性能标准
LOD（Level of Detail），这里的D代表Detail而不是Distance，也就是说，所有游戏画面和游戏功能的细节都可以进行分级，不必受限于距离。
1、如何制定性能标准？
在分级之前，需要确定目标（省电、正常的游戏体验、噱头），我们要在哪一种机型上面运行哪些表现效果和功能，达到怎样的性能目标（帧数FPS、内存占用、Drawcall、同屏三角面数等）。
1）画质的表现力与性能开销是相互矛盾的
2）需要持续维护，相关功能系统的设计都需要考虑到不同画质
3）极简画质牺牲了可玩性，同时会增加LOD框架的复杂性，使用最简单暴力的方式去处理
1）低配画质需要考虑的适配问题
可能不支持Shader定义8张以上的贴图纹理
可能不支持ETC2格式的贴图纹理
2、PBR在手游开发中的适用性
我们是MMO游戏，现在想给主角（包括其它玩家）使用PBR材质（Untiy自带的Standard），其它角色和场景不使用。不知这种情况下性能是否能抗住，同时我也想了解下目前手游中对于PBR材质的使用情况。
精彩回答：目前手游中使用PBR材质的项目明显增多，特别是MMO、RPG等项目中，主要角色、NPC和大Boss等都开始往PBR方面走了。
如果PBR仅是在以上情况下使用时，Unity引擎自带的PBR是没有太大性能问题的，因为一般角色占据的屏幕面积都会比较小，而过剧情时，虽然屏幕面积占据较大，但时间一般都很短，所以给总体性能造成的压力不大。
但PBR暂时还不建议在中低端设备上用在地形等常常在屏幕中占据较大面积区域的物体上，因为它确实会造成较高的GPU压力，我们在UWA Day 2018上也对此进行了定量分析（类似下图），这点需要研发团队在使用时注意。但是，一切应该以自身项目测试为主，具体查看项目在自己设定的低配机器上到底性能如何。
最后，在使用Standard Shader时，除了关注性能外，还要关注下它对于内存的影响，可以参考这篇文章：【求知探新】Unity中ShaderLab内存优化。
该回答由UWA提供，欢迎大家转至社区交流：
我们新项目中想使用下FairyGUI，主要还是为了减轻程序工作量，请问大家有在项目中使用过的吗？主要是关于图集、DrawCall优化、一些滚动条的优化和Richtext解析等等，想问下在这些方面FairyGUI有没有很好的支持呢。另外可以支持自定义UI控件么？有经验的朋友都可以分享下吗？
精彩回答1：两个上线产品，一个自家的一个朋友的：
1）对美术十分友好，各种习惯跟Adobe系列的一致，编辑器本身就是AS3开发的；
2）包装了一些概念，十分方便拼界面工作；如关联=>屏幕适配 、控制器=>状态控制等等；
3）之前的版本解析使用xml，GC较多，最新版本已经更新为二进制，界面创建的CPU和内存消耗都降低了很多，但是还在内部使用，并未应用到线上；这个功能FairyGUI也刚刚发布不到两个月；
4）自带图集支持Alpha通道分离，在贴图压缩和机型兼容上可以直接应用到；PS：建议稍微修改源码，让Alpha的贴图格式为Alpha8，实测这样的在保证视觉效果的前提下可以把贴图压很比较小；
5）各种基本的东西：DrawCall、图集、各种类型组件等等这些都属于还不错的状态，一般不会遇到什么支持不了的；
6）讲一个调试缺点，FairyGUI的组件并不是MonoBehaviour类型的，所以在Unity里面看到的GameObject并不能和组件一一> 对应，遇到一些奇怪问题的时候需要一定想象力，不能像UGUI或者NGUI简单直接看到UI的参数；
7）FairyGUI是跨平台的，会遇到FairyGUI编辑器中预览的和UnityEditor里面看到的不一样的情况，如果对Flash的渲染有一定了解，应该不算什么障碍，如果没有相关经验还是需要踩一点坑的。
感谢袁首京@UWA问答社区提供了回答
精彩回答2：作者也来凑凑热闹。最大的优势当然是开发效率，用了FairyGUI的基本都中毒，这种开发模式的效率是其他UI远远不能比的，越大的项目优势越明显。UI开发有一个很大的特点是重构次数比较多，一旦发生这种情况，通常都会有让一线程序员辞职的念头，但用FairyGUI的就可以做到云淡风轻。
大家很关注的性能，我觉得NGUI/UGUI为了降低DrawCall采用的合并Mesh技术对UI制作要求太高，一旦动静分离不合理会引发灾难。FairyGUI提供的优化技术是动态后期优化，在制作时对UI人员基本没有要求。简单的说，就是你随便拼，FairyGUI负责自动优化。两者的运行性能，你很难感受到差别。但如果UGUI你不优化，就会和FairyGUI有很大差别。所以有一个说法，FairyGUI可以轻松应付低端机，但UGUI却要花大力气。
GC问题是C#库不可回避的话题，FairyGUI也在不停迭代中改进。最近推出的二进制格式，更是解决了大家一直有意见的加载问题。FairyGUI运行时，如果不发生文字和图片的更换，是没有GC的，即使各种动效（位移、透明、旋转等等）在不停运行。这一点是很难得的，因为一般情况下，你如果要用其他UI实现这些效果，那么势必要引入其他插件或者自己写大量代码，那么这些代码的优化是要你自己完成的。
最后也来说说缺点，首先FairyGUI需要你学习多一个编辑器，了解一种不同的开发模式，在FairyGUI目前知名度远远不及UGUI的情况下，选择FairyGUI需要决策者有前瞻性；其次FairyGUI结合UI实际运用的痛点，自带了很多缓存机制，例如游戏中List总是避免不了不停刷新，所以FairyGUI的List是自带Cache的等等，你需要了解一下这些特点，否则会造成FairyGUI有内存泄漏的错觉。
感谢谷主@UWA问答社区提供了回答，欢迎大家转至社区交流：
4、Lightmap平台色差问题解决方案
PC上烘培，转到安卓平台即可复现，但非所有项目都会遇到这个问题。我使用的Unity版本是/forum//p/
5、如何深入掌握研发项目的物理性能
如何提高Unity物理引擎Physx的性能？我在场景中加入100个具有物理刚体的小人，并充分碰撞，发现低端机的帧率只能跑到10帧以下。
精彩回答1：如果需要充分进行物理计算，这些拥挤在一起的小人很可能会造成大量的物理碰撞，进而造成很高的物理耗时。
在优化之前，题主需要先了解一些基础物理数值推荐，并不是所有设备都能流畅跑起100个自由制作的蒙皮模型的。所以，建议先看这篇文章：
6、大世界场景优化和加载策略
1）市面上是否有手游（比如吃鸡）使用了 SECTR 和 Terrain 来解决大世界的问题，并且实现效果还不错的呢？另外是否有其他现成插件也适用大世界的？？
2）Terrain 的 Draw Call 有没有什么优化的 Guideline？我注意到 Terrain 自带的树和草似乎都比较费。另外，水平视角的时候能看到较多场景中的内容，有什么一般性的策略来减轻渲染负担？
3）在 SECTR 的框架下，可以很容易的给一个地图分块，但应该如何解决地表分层的问题（比如地面、建筑、装饰等）？这里的层似乎已经不符合 SECTR 中 Sector 的概念，而是另一个维度。
4）大地图中用何种手段解决 LOD 的问题比较好？SECTR 提供了一个简单的 LOD 方案，只是对组件（尤其是 Renderer）根据其 Bound 来进行显隐。SECTR 是否在 GC 方面有坑？
5）性能上，通过 AssetBundle 频繁加载和卸载子场景（这需要修改 SECTR_Chunk），如何能减少卡顿？
精彩回答：就目前我们优化过的超大地形（8kx8k）的移动游戏来看，基本上都没有使用SECTR+Terrain这一解决方案的，而是全部转换成Mesh来进行无缝拼接。我们没有使用过SECTR这一插件，所以对其分拆机理和组织方式并不了解。但是对于Terrain来说，一般研发团队更倾向于使用Mesh来进行替换。
Terrain的优势在于编辑十分方便，通过一些插件（比如Terrain Composer）可以快速生成基础地形等等，但是它的Draw Call并不容易控制，至少很不直观，内存同样较之同等复杂程度的Mesh要大，且TerrainData的加载效率也并不高。所以，对于前期通过Terrain来进行地形编辑的团队，后续往往会将其导出成Mesh来进行动态分块加载。这是目前我们较为推荐的方案。
对于场景的加载，只要AssetBundle中的内容不多，Size不大，现在通过LoadFromFile+LZ4的方式来进行加载已经相当快了，现在的顿卡一般不出现在AB加载上，而是出现在/question/5bc518d8d5356
7、如何把握卡通渲染制作流程？
我最近在Unity中制作角色的卡通渲染效果，目前的工作流程是这样的：1）程序在Unity中写Shader调效果；2）美术在3dmax修改模型顶点色和法线等资源，修改完导出给程序；3）程序将资源导入Unity中验证效果。目前需要频繁地修改资源、导出导入资源，效率比较低下。
所以我有以下两个问题：
1、如何在3ds max中写着色器，美术修改模型后能及时看到效果？
2、成熟的制作流程是什么样的？
精彩回答1：1、这个不难的，让渲染程序员简单看一下Maya或者Max的文档，几个小时基本都是可以搞定的，Max或者Maya都有例子和文档，比如Max的话就是用DirectX Shader Material，不用把这个想得很难，好好看文档。
2、我觉得本质上主要是想要所见即所得，所有的工作也都是为了这个目的。卡通渲染对美术资源的修改大多需要定制化，例如靠刷顶点色控制描边，靠改顶点法线去改善光照，所以如果把shader做到max里可以大大提高美术的制作流程，而不是总是导入导出。通常的流水线是，维护一个和引擎预览效果一直的max（或maya）shader材质，再加一个自定义的法线编辑工具（如果美术觉得内置的不够用的话，比如max的法线编辑比较困难），这样在修改美术资源保证效果一致性就好了。
感谢乐乐@UWA问答社区提供了回答
精彩回答2：对于第一个问题，读书哥提供了一个方法：
8、吃鸡游戏的物理碰撞
由于吃鸡类游戏的强同步，很多时候可能使用帧同步，客户端无法使用直接使用物理引擎，或者状态同步情况下服务器需要计算碰撞等。此时怎么处理这一块碰撞呢？数据结构又是怎样呢？
精彩回答1：如果让我选择技术方案的话，绝地求生这种3D自由视角的吃鸡游戏绝对不会选择帧同步，原因有：
1）射击游戏在玩家移动、开枪等操作上会有较强的手感体验上的诉求，帧同步很难支持即时的操作反馈；
2）自由视角的吃鸡虽然没有战争迷雾，但是会有视距的问题，使用帧同步把所有信息广播给玩家，外挂做起来简单太容易，而吃鸡手游中标定其他玩家位置这样的外挂又有很大的优势，所以本质上不适合。
不知道题主说的帧同步和我理解的帧同步是否一致。然后，基于状态同步，服务器可以跑物理，但是真实的物理完全在服务器跑，对于服务器的压力太大，需要付出的成本过高，一台物理机也可能承载不了多少同时在线的玩家消耗，运维的成本你要评估下是否可以接受。
答案较长，欢迎大家转至【厚积薄发】吃鸡游戏的物理碰撞查看。
感谢贾伟昊@UWA问答社区提供了回答
精彩回答2：吃鸡玩家数量一般在100个以上，这种情况下用帧同步需要同步的数据量会很大，延迟也会比较严重。因为帧同步一般需要收集所有同场景玩家的输入，然后分发给各个客户端，让各个客户端用相同的逻辑自己去计算每个玩家的位置、状态，游戏逻辑是跑在客户端的。MOBA适合使用帧同步是因为一场比赛只有10个玩家。
我觉得吃鸡还是适合状态同步。状态同步怕的是角色太多，导致需要同步状态的角色过多，造成网络同步数据量大。吃鸡没有什么野怪，全部是玩家，所以场景里角色就是玩家。可拾取的装备需要同步的数据比较少，基本上需要一个位置坐标就行了，玩家身上的状态数据量要多很多。客户端看不见的玩家、装备，完全可以不用同步，因为逻辑完全跑在服务器端，客户端只需按照服务器的逻辑做绘制就行了。
关于游戏手感的问题，FPS游戏对延迟的要求是所有游戏类型中最高的。如果玩家网络不是很好，也很难优化到比较好的情况。客户端先行可以先做显示的预判例如：击中后的血迹。但是数值结果还是依靠服务器端的计算，否则很容易被外挂利用。即使服务器结果判定没有打中，问题也不是很大，最多就是玩家看到有几枪打中有血迹特效，但是对方没扣血。这种情况大概率出现在网络环境不好的情况。
感谢ZFK@UWA问答社区提供了回答，欢迎大家转至社区交流：
9、帧同步的浮点数精度的不一致问题
我们游戏采用帧同步框架，计算逻辑的时候不可避免地产生浮点数运算，如移动和跳跃等。为了保证在不同的平台和不同的机器上得到一致的结果，有什么好的方案能解决或避免浮点数结果不一致的问题呢？
精彩回答1：一般情况下，浮点计算涉及到的位置同步无需保留过高的精度，小数点后保留2位到4位足矣。因此计算前将浮点数乘以1000，然后取整再进行计算，可以有效地解决多端的精度不同步问题。但是需要注意一个问题，就是别超出了你数值类型的最大值范围。
感谢odiecc@UWA问答社区提供了回答
精彩回答2：根据我们自己正在摸索的帧同步经验，如果不是王者荣耀这种级别的游戏，帧同步的浮点数精度影响不是系统的瓶颈。如果战斗时长不长，露馅的概率很低，全改整数的工作量是非常巨大。如果是小公司，要好好评估是否能挺住。
逻辑与表现的分离才是最大的问题，意味着Unity的大量组件不能使用。大量的重新实现的东西需要从头去写，当然全用整数也一样得重头去写。游戏小公司需慎重评估生存问题和完美方案的性价比。
感谢李先生@UWA问答社区提供了回答
精彩回答3：帧同步还是定点数比较靠谱，浮点数带来的误差有可能累计到一个无法接受的地步。另外回答其他朋友的一些问题。
1）网络传输，使用可靠的UDP（TCP）传输；
2）另外看到其他朋友提到的逻辑与表现的分离，这个是帧同步方案必须的，至于说到的Unity中大量组件组件无法使用，主要是> > 帧同步方案逻辑的处理不应该按照本地时钟时序，而是严格按照服务器逻辑帧处理，说不可用其实主要针对逻辑层而言，表现层其实不见得Unity组件都不可以用，表现层上Unity的组件其实必不可少的。
感谢Chale@UWA问答社区提供了回答，欢迎大家转至社区交流：
10、Unity中纹理格式的探究
关于Unity中使用的纹理格式问题，自己查了一些资源，有了一些大概的认知，但是希望能有比较完整、有理有据的依据。如果已有整理好的文章求科普！目前从各方面渠道得到的大致结论有：
-
以上结论是否正确，有没有什么补充或者坑？目前使用来说感觉PVRTC的尺寸限制比较大（正方形+长宽2的幂）
-
大家在场景、角色、UI不同的用途来说一般都是如何选择的？目前我们项目里感觉UI用PVRTC美术接受不了（ASTC暂时还没决定用），lightmap用ETC2在某些地方放大疵边比较明显，有什么好的办法吗？
-
尺寸大家一般是如何定的？比如的全屏Loading图，一般定多少？（我看王者荣耀的loading图画质很差）
-
Mipmap一般要不要开咧？如果开的话，其中的一些设置怎么设比较合理？
-
其他可能大佬们愿意教教我的这方面的内容？
精彩回答1：关于ASTC的支持率，参考贾伟昊的回答。
可以考虑在iOS上用起来，但是要放弃一些机型。安卓上建议使用ETC2，搭配Unity的Crunched算法，效果更佳。RGB24/RGBA32确实不建议使用，主要是会占用显存带宽，但是效果确实好。Dither是可以用，但是对Scale9和渐变不友好。
UI的Mipmap不要开，UI不会发生Mipmapping的情况，除非你设计的纹理尺寸比实际用到的要大很多。
11、项目中策划数据如何储存和读取
12、半透明物体实现阴影效果的方法
当"RenderType" = "Transparent"的时候貌似是没有办法接受阴影的。我们需要在场景中做一层半透的地表, 来掩盖模型和地表之间的接缝，所以需要显示阴影, 请教各位大佬有什么好的方法吗？另外我想了解下为什么半透明物件默认不能接受阴影呢?
精彩回答1：抛开Unity引擎，从本质上说，半透物体肯定是可以接受阴影的。之前就实现过地表有一块玻璃材质，会在玻璃上以及下面的物体上都有投射的阴影效果。所以如果自己编写的Shader，想要接受阴影，只需要采样Shadowmap，走一下阴影计算的过程就可以了。
对于Unity引擎，我试了一下的确选择Transparent的RenderType也就没有了阴影，这个我不是非常清楚是否可以自己在Shader中去强制走一下Shadowmap的处理过程来解决，题主可以试下。
但是题主要注意，半透物体接受阴影的情况下，尤其是题主要解决的这种覆盖接缝的情况，会导致这部分最后产生的阴影变得比较重的效果，因为半透下面的物体肯定还会有阴影产生，半透的阴影虽然可以受Alpha的影响变淡，但是叠加在一起就会出现变得更暗的问题。当然Transparent的部分不接受阴影，意味着阴影效果经过Alpha Blend之后会变得淡。
精彩回答2：这个问题恰好之前做了些尝试，正如@贾伟昊所说，内置的Transparent是不接受阴影的，但可以尝试在自定义shader中强制走Shadowmap的。参考代码如下：
回顾三年多来，我们分享了近500个和游戏开发、优化相关的精彩问答。这些问答不仅有具象明确的提问，也有详细周全的解答；既能供研发团队自身项目中即学即用，还能通过参与者的回答分析，帮助我们在解决问题的过程中触类旁通、鉴往知来。如果你知道答案，欢迎你来分享；如果你有疑惑，欢迎你来提问。生有涯而学无涯，期待你的加入！
【博物纳新】Unreal中的烟雾火焰流体模拟！
【博物纳新】XR合集推荐&新功能上线！
【厚积薄发】Bake工作流下，如何实现卡通化渲染！
【厚积薄发】Android的刘海适配！
