FairyGUI使用经验分享

本期我们聚集了这些话题：FairyGUI开发经验分享、线性工作流美术贴图制作方式选择、命令行编译包在播放VideoPlayer MP4视频出现蓝屏、Invalid AABB aabb报错...

---

这是第134篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。

UWA 问答社区：answer.uwa4d.com
UWA QQ群：793972859（原群已满员）

---

UI

Q1：我们新项目中想使用下FairyGUI，主要还是为了减轻程序工作量，请问大家有在项目中使用过的吗？主要是关于图集、DrawCall优化、一些滚动条的优化和Richtext解析等等，想问下在这些方面FairyGUI有没有很好的支持呢。另外可以支持自定义UI控件么？有经验的朋友都可以分享下吗？

两个上线产品，一个自家的一个朋友的：
http://www.9game.cn/xxyg
http://www.9game.cn/mengxiangqiyuan
主要几个点：
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问答社区提供了回答

作者也来凑凑热闹。最大的优势当然是开发效率，用了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问答社区提供了回答

该问答来自UWA问答社区，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5bd275efa4201c0aa434742a

---

渲染

Q2：我们项目采用了PBR材质，在伽马颜色空间下PBR中光照计算的结果是错误的。所以现在考虑转到线性空间中。Unity从5.5版本开始支持移动设备上的线性空间，OpenGL ES3.0的设备占比已经足够高，设备支持不是问题。

现在的问题是如果直接推行在线性空间制作贴图对美术的工作习惯挑战较大，所以想采用在线性空间导入时勾选sRGB来区分线性和伽马的方式来处理，想知道这种方式是否有特别需要注意的地方？期待有相关经验的大佬赐教。

我们之前的项目用了线性空间，新项目肯定也会使用线性空间。前段时间也推荐和协助了朋友的创业团队从Gamma空间转到了线性空间。所以，我对于线性空间是强烈推荐的，当然，如果美术团队中有人有线性空间相关的制作经验，这样程序推行起来会更好更快。
题主已经体会到线性空间的好处，这里就不细说，回归到问题本身。按照我对题主描述的理解，题主的想法是为了减少美术对于之前贴图修改的工作量，想把整个项目切换到线性空间，然后让之前按照Gamma空间的规范制作的贴图不勾选sRGB，让新制作的内容勾选sRGB来做，不知道这样理解题主的想法是否正确。
说先要明确的是线性空间的工作流程可不仅仅针对于贴图，贴图是否是线性的只是其中一小部分，线性空间核心改变的问题是光照叠加的计算。
做一个简单实验，在没有贴图的情况下，光照强度为1，Cube的颜色为(128, 128, 128)，在线性空间下和Gamma空间下的渲染效果：（Unity 5.6版本，Standard材质）

哪个是线性哪个是伽马空间？不重要，重要的是两者是不同的。也就是说单纯颜色在两种空间下，一盏灯的光照效果就有差别，那如何保证美术使用伽马空间制作的美术效果，在线性空间下是和之前的效果完全一致呢？
我个人觉得是很难。
截取带贴图的例子来看：

随意找的一张贴图，不用在意贴图内容，对比效果可以发现，他们之间会有差异。那什么情况下是相同的呢？选择Unlit材质看下：

说了这么多是想说明，线性空间的工作流程不仅仅和贴图格式相关，而且对光照渲染更加有影响。所以，我个人不建议混用两种色彩空间方式，起码在一个场景内不建议混用。
当然，对于客户端来说，没有说什么东西是一定“正确”的，混用之后美术觉得效果ok，那也不是说这种方案不能用。但可能会要提前考虑一些问题：
1）后续效果调整可能会有些麻烦，出现顾此失彼的情况；
2）美术制作可能会混乱，因为线性空间和伽马空间下总是会有各自的制作经验，比如线性空间下贴图的制作亮度会普遍偏亮一些等等经验，混用色彩空间的结果，可能会让美术也会迷惑，或者新来的美术对于之前资源的维护会存在困扰，不知道应该按照怎样的经验来制作。所以如果要这样做，最好界定好两种空间分别使用的界限。
3）经验告诉我们，无论是游戏开发还是恋爱，长痛不如短痛……
Anyway，虽然我个人不建议这样做，但毕竟实践出真知，建议题主在自己项目里先试试，看看我能够想到的问题是否都有一个满意的答案，也许你们可以在色彩空间混用这块走出一条康庄大道也说不定。
感谢贾伟昊@UWA问答社区提供了回答

Unity工程已经切了线性空间了，就必须是线性图（比如法线图、强度图、参数图）勾掉sRGB、Gamma图（比如颜色度）勾sRGB了。 如果你是想用这种方式还原Gamma的处理方式，是不合理的。
感谢李洋洋@UWA问答社区提供了回答

题主：非常感谢贾伟昊和李洋洋的解答。
可能我的表述不清，所以引起了理解偏差。我描述不是原来Gamma空间制作的贴图不勾选sRGB选项。我的意图有两个，一个是之前在Gamma空间做的资源可以尽可能少地进行改动，另一个是后面的美术资源制作如果可以，就是尽可能少改变美术出资源的习惯，当然，没有好的方法的话美术也得去适应新的工作流。
先解释下我们转线性空间的背景，我们在Gamma空间倒腾了一段时间，现在来看，我们一直走在错误的道路上，我们确定修改为线性空间就是因为在Gamma颜色空间的效果跟SP里的出入比较大，美术反馈说很绝望，然后查了些资料发现SP是在线性空间工作，在Gamma空间基本上没有调出比较一致的可能性，也有人通过修改Shader等进行一些Gamma矫正使美术制作工具和Unity环境中的效果一致，考虑到现在大部分机器已经支持线性空间了，我们就直接切到了线性空间。
之前看了些资料，但主要的关注点都在贴图上，但是看到伟昊的那句“那个是伽马空间，那个线性空间，不重要，重要的是两者是不同的”，这句给我的启发非常大。确实，至于是Gamma空间还是线性空间确实不重要，而更重要的是尽可能地在美术制作工具里和引擎环境中保持一致，保证在引擎中的效果尽可能少地打折，以及减少美术同学从美术制作工作导入引擎的调整时间。
不一致的原因也不复杂，在伽马颜色空间下，Unity采用放任的方式，就是你给我什么输入我就拿什么计算，到最后设备显示的时候做一次伽马矫正，线性空间的差别是会根据贴图是否勾选sRGB做一次线性转换，在最后的输出阶段还是做一次反伽马矫正，大约就是pow4.5的计算，就是说不管你有没有贴图采样参与计算，在线性空间下最后一步的反伽马矫正都是要做的，这就是差别的原因。
理解了为什么不同，剩下的就是考虑美术制作要注意的问题。
在切换到Unity线性空间的情况下，PBR制作需要关注的地方我注意到的有以下方面：
1）就是李洋洋提到的， 线性图不能勾选sRGB选项，而伽马图需要勾选sRGB；
2）切换到线性空间后，想在SP里的表现和Unity引擎里完全一致，也基本上不可能，它们有很多的不同之处，比如光照信息不同，SP里面是从环境贴图拿光照，很强，没有主光源。一些效果在SP内找不到相近的效果，一些算法实现不同，比如说DRDF，如果希望引擎内和SP内表现一致，还是需要做一些工作，把材质从引擎内移到SP中。
3）和我们美术沟通，发现他们会拿数据图，比如说粗照度，高光图等去PS里处理，如果不注意设置，那么在SP里输出的线性图，在PS里逛一圈出来成了伽马图了。目前我还没有清晰的流程来处理这种情况，包括SP里导出的贴图数据通道合并，之前也是拿到PS里来处理的。这也有问题，可能不知觉间一张线性图就成伽马图了。
4）线性空间的半透图在PS里混合的时候，是在伽马空间混合的，在Unity线性空间的话会在线性空间混合，结果会一致。可以通过设置线性混合，但是就得出线性图了，目前我们还没做出规范是否要出线性图，后面可能采用就是直接出伽马图，跟之前出图习惯一致，然后混合的时候直接在Unity调整到想要的效果。
再次感谢贾伟昊和李洋洋的解答。因为我们刚转到线性空间，正处于摸索阶段，我的理解可能存在偏差，如有理解不对的地方，希望可以帮忙指出来，感激不尽。
感谢赵林@UWA问答社区提供以上分享

该回答来自UWA问答社区，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5bd1724fae74300ab0497bed

---

视频

Q3：我们测试发现，在使用Unity打包的时候可以正常播放，但是在使用Unity命令行进行打包的时候，打包IL2CPP的包在VideoPlayer播放MP4视频时会出现蓝屏，但是有声音，没有发现异常，有人遇到过这个问题吗？

adb命令连接手机获取Android系统Log才发现ReportException: UnityLogError Could not find material Hidden/VideoDecodeAndroid 异常，查看本地手动的GraphiceSetting发现没有这个Shader的设置。
但是前台Unity直接打包IL2CPP就正常，命令行就会有这种异常，手动加上该Shader保存GrahpicsSettings.asset后进行命令行打包正常。

感谢郁建秋@UWA问答社区分享了该回答，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5bcd9818a4201c0aa43473dd

---

编辑器

Q4：美术同事上传了许多Prefab之后，我们程序同事开启Unity工程，Console就立即报出了许多如上图的错误讯息，但是没有指出是哪些Prefab或Asset造成的，请问各位有遇到这种状况吗？该如何定位问题原因呢？我们的unity版本是5.5.4。

由于除数为0造成的问题，可以检查美术生成的资源，有些资源数值变成的无穷小或者无穷大，这时碰撞盒计算出现错误，就会报错。
感谢郑骁@UWA问答社区提供了回答

推荐一下Misaka同学的MonoHooker
Hook到CreatePreviewForAsset方法上，把参数打印出来。
感谢凯奥斯@UWA问答社区提供了回答

该回答来自UWA问答社区，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5bc9e25e8af62a50acb8e12e

今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，我们早已在UWA问答网站上准备了更多的技术话题等你一起来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。

官网：www.uwa4d.com
官方技术博客：blog.uwa4d.com
官方问答社区：answer.uwa4d.com
官方技术QQ群：793972859（原群已满员）