Linear Rendering在移动设备上的支持率

作者：admin
/
时间：2018年11月08日
/
浏览：5064 次
/
分类：厚积薄发

本期我们聚集了这些话题：Linear Rendering的支持率、通过蓝图/C++在运行时修改MeshData粒子系统的Mesh、PSS增长定位、优化Lua逻辑代码产生的内存...

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

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

渲染

Q1：在此篇博客里，有提到Linear Space Color这个特性在安卓机上的支持率是61%，在苹果机上是71%。
不过这个数据是2016年的数据，已经不适用于现在了，我们希望能知道Linear Rendering这个特性在现在安卓机和苹果机上的支持率，当然，如果能区分地区（例如大中华区和东南亚各自的支持率）和更加细节（例如OpenGL ES 2和OpenGL ES3占有率、Vulkan支持率、iOS Metal的支持率等）就更好了。
另外，如果我们在Gamma颜色空间下，使用PBR流程制作手机游戏想要有更好的表现效果，有什么好的策略和方法吗？现在我们使用的是Metal-Roughness贴图，Shader是参考下面这篇博客，修改Standard的Shader代码写成的。

占有率这个东西，不同的统计渠道可以得出不同的统计结果，我这里没有具体的数据，只能提供个人的建议——2019年上市的3D游戏，除非特别小型，在国内市场，我个人认为是不用去考虑OpenGL ES 2.0的设备了。三四年前的千元机已经支持OpenGL ES 3.0了（比如红米Note2、小米2A），何必为了这点市场份额而额外增加那么多限制呢？（Alpha通道拆分、自己在Shader中做线性空间处理、Shader要注意贴图采样数量限制等等）
另外大致看了下题主贴的文章，其实是在Gamma的设置下自己在Shader中实现Linear Space的计算过程而已，这种方式有两个小问题：
1）增加GPU额外计算量，比基于硬件的方式消耗更大一点点；
2）最终的从线性空间转换到伽马空间的过程，注意最理想的是在最后一步来进行，如果有多个Pass，这里的计算过程在效果上可能有错误（单个Pass，没有后处理的情况下看上去是一致的）。当一个Pass输出的颜色会作为下一个Pass的输入时，也要将颜色转换回线性空间来计算才正确。
还有就是不仅仅albedo贴图，所有是颜色的贴图/通道都需要做这样的计算才是正确的。
使用链接中的方式可以实现线性空间的效果，比较老的游戏也通常是这样做的，但是我个人会倾向于直接使用Unity内置好的功能，性能上和便利性上都会更好一些。
另外，个人观点，基于PBR流程的话，在做好基准效果之后，程序能做的事情不多，毕竟都是物理计算的，后面的效果大都依赖于美术对于PBR的理解以及制作经验了。
感谢贾伟昊@UWA问答社区提供了回答

最近项目刚切到线性空间去，查了些资料，Linear Rendering需要支持OpenGL ES 3.0 ，Android版本参考4.3, 以下是一份Android版本参考数据，参考版本数据大致可以推出占比：
https://blog.csdn.net/qq_29428215/article/details/80847211
iOS参考iOS 7的iPhone 5s。
经过我查看的资料和调研，我跟楼上观点一致，直接切线性空间。
感谢赵林@UWA问答社区提供了回答

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

逻辑代码

Q2：控制Lua逻辑代码产生的内存，如何回收才能避免内存峰值过大？
C#和Lua都可以在回收的时候被标记为null，从UWA报告中的曲线可以看出，C#的回收机制是一段时间自行回收，Lua却没有，可以理解在堆内存管理上是有区别的？如果避免这样的内存泄露问题，控制内存暴涨，有什么更好的回收方法？
请输入图片描述

补充理解：
手动回收内存：Lua内存回收调用Collect，C#调用GC；
自动回收内存：C#申请的内存置空或Clear可以回收掉，而Lua描述中也是置空可以让其自动回收，但是下面的Lua变化曲线没有锯齿线的变化，这有点不明白了，是否我理解错了？

自动回收的说法可能有点问题，Clear或者置空只能认为是解除对对象的引用，并没有回收对象的内存。
回收的时间点总是发生在GC时的，只是有些是手动调用的，有的是自动触发的。上面C#和Lua的曲线不同，应该只是GC触发的规则和时间点不同（C#的频率高，而且每次是全量的GC，一次性回收；Lua的规则会复杂些，而且还可能是分代的）。
然后也可能是C#层的堆内存分配的比较快，量比较大，所以看上去GC就比较频繁了。
调用Collect是可以触发回收的，通过lua_gc的第二个参数还能控制是否分步进行。不过从曲线上看，Lua部分的内存有泄漏的风险，才会出现峰值越来越高的现象，所以建议还是先尝试定位下泄漏问题。
该回答由UWA提供

避免内存峰值过大，如果只是交给自动GC很难满足。
一般来说，是结合手动触发GC，甚至设置合理的步进。在一些特定的场景，比如说战斗场景，在内存准许的情况下还可能采用的策略是停掉自动GC以防止自动GC引起卡顿，然后出来场景做一次手动全回收并且开启GC。
防止内存泄露同样是要特别注意的问题，比如说Local不小心处理成了Global无法释放，被table表强引用等情况导致无法释放，导致内存占用越来越大。
感谢赵林@UWA问答社区提供了回答

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

虚幻&粒子系统

Q3：求助虚幻4大佬们的帮助：
1）有可能在蓝图中或者C++中对粒子系统的Mesh进行修改吗？

2）或者说有可能把蓝图创建的Procedural Mesh赋值给粒子系统的Mesh吗？
Procedural Mesh的创建方法参考的是：
http://orfeasel.com/creating-procedural-meshes

回答如下：
1）首先，题主要先确定需要Runtime修改的是单个ParticleSystemComponent实例的Mesh还是整个ParticleSystem（资源模板）的Mesh。两者都比较容易达成，引擎在渲染动态对象的时候，会每帧通过PrimitveSceneProxy的GetDynamicMeshElements收集实际的MeshBatch，ParticleSystem会根据Emitter的实际Instance类型，调用对应类型的GetDynamicData获取需要的数据。所以只需要给ParticleSystemComponent添加接口暴露给蓝图，用来设置新的StaticMesh，并且在接口实现中，传递给实际的FParticleEmitterInstance，FParticleEmitterInstance基类中新增SetMesh的接口，什么都不做，在继承类FParticleMeshEmitterInstance中，增加UStaticMesh*类型的成员变量，作为PerInstance的override用的Mesh数据，重载基类的SetMesh接口中把传入的Mesh复制给自己的Override用的Mesh，并在FParticleMeshEmitterInstance::GetDyanmicData接口最后NewEmitterData->Init的第三个参数改成 EmitterInstanceMeshOverride ? EmitterInstanceMeshOverride : MeshTypeData->Mesh。至于要改整个ParticleSystem模板的Mesh就更简单了，直接在SetMesh接口中换掉自己MeshTypeData->Mesh就行了。要做的完整需要对resourcesize，getmaterials以及计算bounds的相应接口做一些简单的调整。

2）用ProceduralMesh会比较麻烦，当然也不是不行，但这里有一些概念题主需要清楚：普通的StaticMesh是Assets，而实际的Component可以看成是使用某种Assets的实例。所以在Mesh Data中设置的其实是资源，在实际生成实例的时候，会利用资源的数据来生成对应的数据。而ProceduralMesh比较特殊，并不存在资源，只存在实例，如果想实现需求，需要把ProceduralMesh的各种stream（position，normal，tangent，vertexcolor等）转成Particle的FMeshParticleVertexFactory中的实际数据格式，参考FMeshParticleVertexFactory::FDataType和ProceduralMesh中对应的数据的结构关系。

感谢王祢@UWA问答社区提供回答，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5bcefd53ae74300ab0497bdb

内存

Q4：请教个问题，内存快速增长该如何确定是哪些导致的？我们的UWA测评报告中显示切场景的时候多了差不多两百兆。
请输入图片描述

UWA：这个是PSS内存增长，这块内存的进一步定位有两种方式：第一种是在UWA GOT Assets模式中，查看主流资源（纹理、网格、RenderTexture等）的增幅情况；第二种是传到UWA网站，进行线上深度测评，通过线上报告除主流资源外，可以进一步看到此处的提升是Unity自身增长，还是Gfx增长，如果是前者，则根据AssetBundle加载相关，如果是后者，则跟Texture、Mesh、ShaderLab相关，这样就可以比较清晰地定位了。
但是，需要注意的是，PSS的内存增幅要快于Unity引擎的实际内存增幅，即App中加载一个4MB的纹理，引擎增加的记录是4MB，而PSS可能增加6MB、8MB甚至更多，这个是由其OS和Driver来决定的。

该回答由UWA提供，欢迎大家转至社区交流：
https://answer.uwa4d.com/question/5be2b11773c493238df340d2