关于rendering:从Gamma空间改为Linear空间会导致性能下降吗

1）从 Gamma 空间改为 Linear 空间会导致性能降落吗
2）如何解决没有应用 Unity Ads 却收到了 GooglePlay 平台的正告
3）C# 端如何解决 xLua 在执行 DoString 时候死循环
4）Texture2DArray 相干

这是第 350 篇 UWA 技术常识分享的推送，精选了 UWA 社区的热门话题，涵盖了 UWA 问答、社区帖子等技术知识点，助力大家更全面地把握和学习。

UWA 社区主页：community.uwa4d.com
UWA QQ 群：465082844

Rendering

Q：Linear 性能比 Gamma 差吗？咱们我的项目从之前应用的是 Unity 2020.2.7f1 版本，抉择的是 Gamma。目前降级到 2021.3.21f1，切换为 Linear 空间，Shader 和图片都进行过批改，性能也优化过。

然而总体测试下来性能不如之前的 Gamma，帧率没有以前高，帧率掉了很多，通过优化，还是不太令人满意，总感觉会卡顿，不晓得是不是从 Gamma 降级到 Linear 的起因？

A1：应该和换色彩空间没关系。如果没有非凡性能，Gamma 和 Linear 的次要区别就是最初输入到显示器时要不要做色彩的修改，依据你的形容应该和批改 Shader 无关。

感激李伟 @UWA 问答社区提供了答复

A2：在硬件反对的设施上，不该当有显著的性能差别。

在硬件不反对的状况下（比方 OpenGL ES 2.0），如果是基于 Shader 中的模仿转换来实现 Linear Space 的成果，会有肯定的 GPU 耗费。然而如果感触上是卡顿，而非继续的低帧率，那也不像是这种状况，倡议从具体的性能 Profile 数据动手来进行排查。

这里有一个相干的探讨，搜寻 performance 关键词能够看到一些人做的试验：
https://forum.unity.com/threads/gamma-vs-linear-space.613294/

局部论断援用如下：
“I have just done a stress test of Gamma vs Linear color spaces with transparencies and Gamma is indeed a liiiitle faster than Linear, but the difference is so minimal it doesn’t even matter. (2 to 3 frames per second more on a stress test that was overdrawing 8 transparent planes one over the other for the full screen space.)
On any GPU that handles GLES3 there is no performance reason to use Gamma space over Linear.

Gamma space is legacy now and is only useful for legacy GLES2 GPUs (because linear requires GLES3)”

不同的游戏测试后果可能略有差别，但原理上应该是没有可观测的性能差别的，题主能够参考一下。

感激贾伟昊 @UWA 问答社区提供了答复

Script

Q：我没有应用 Unity Ads，但依然收到了 GooglePlay 平台的正告：

您的“xxxxxxx”利用（版本代码：8）蕴含“com.unity3d.ads:unity-ads”SDK 或您的某个代码库所依赖的 SDK，该 SDK 会收集集体数据或敏感数据，这些数据包含但可能不仅限于 Advertising ID，Android ID 标识符。依据用户数据政策的相干规定，利用不得将永久性设施标识符与其余集体数据、敏感的用户数据或可重置的设施标识符相关联。

自世界协调工夫（UTC）2023 年 1 月 11 日午夜起，如果新利用版本蕴含 SDK 版本且不合乎用户数据政策，则可能无奈公布。您能够思考将该 SDK 降级至不含违规代码的合规版 SDK（若有），或者从您的利用内移除该 SDK。

依据您的 SDK 提供方的状况，您能够思考降级到 4.0.1，并 / 或分割您的 SDK 提供方，看看是否有适合的更高版本可用。Google 无奈举荐任何第三方软件，也无奈为这类软件提供任何背书。

A1：倡议查看下 SystemInfo 的援用。

感激 Knight-132872@UWA 问答社区提供了答复

A2：提供几个思路：
1、确认 Package 下有没有 com.unity.ads 包
2、如果应用的是 Unity 中国版，能够切换为以下版本或同版本国际版

感激 bo@UWA 问答社区提供了答复

A3：亲测，用对应的国内版本就行了，解包发现，中国版不管是否导入 Ads，打的包外面都会有 Ads 内容，国内版本不会有这个问题，明天提交谷歌商店验证过了。

解包后在 smali\com\unity3d 目录下，splash 文件夹，首先要在工程里移除 Ads，再打包测试，我用 2020.3.38f1 和 2018.4.36f1 测试都没问题。

感激 TimWang@UWA 问答社区提供了答复

Script

Q：我应用 xLua 作为游戏的内嵌脚本语言，容许玩家自定义脚本。

当初有个玩家在脚本外面写了一个死循环，当我用 DoString 去加载这个脚本时候会间接卡死，于是我在里面退出了一个 Task：

var isSucceed = false;
var task = Task.Run(() => {isSucceed = sandbox.DoString(xxxx)// 这里简化一下. 外围就是加载这个脚本执行 DoString
});

bool isCompletedSuccessfully = task.Wait(TimeSpan.FromMilliseconds(1500)); //1.5s timeout

if (!isCompletedSuccessfully)
{CELog.LogError("加载脚本超时");
    isSucceed = false;

    luaEnv.Dispose(); //Kill 掉以后的 Evn


    return; // 不再加载后续脚本
}

当初是只有调用‘luaEnv.Dispose()’编辑器就间接闪退，无论是这里 Timeout 了调用，还是等几秒当前。

我感觉是因为 Task 的 Timeout 只是在超时后回调，然而此时 Lua 还在死锁中，所以我无奈 Dispose。

官网的 FAQ 提了一句：

调用 LuaEnv.Dispose 解体，很可能是这个 Dispose 操作是由 lua 那驱动执行，相当于在 lua 执行的过程中把 lua 虚拟机给开释了，改为只由 C# 执行即可。

我感觉和我这个状况是一样的，应该如何解决？

A：Update 一下目前钻研的停顿：

这是找 xLua 求教的后果，目前满足我本人的需要：
https://github.com/Tencent/xLua/issues/1077

如果以上办法不满足，还搞不定底层，能够尝试以下几个方向：

MoonSharp
https://www.moonsharp.org/

MoonSharp 是纯用 C# 写的 Lua，不过曾经不更新了。Discord 还有沉闷，问的问题都会解答。

https://gist.github.com/xanathar/2c777a79937398834ad4

用 Hook 的形式能够实现以上的需要。

长处就是纯 C# 的，相对来说好操作。不过就是性能弱，然而如果和我一样 Lua 只是用于玩家的 Mod。其实还好，因为 Lua 端的逻辑会很弱。

nLua
https://github.com/NLua/NLua/issues/56

nLua 的 DebugHook 是间接被集成好的，xLua 的 Hook 大佬没给裸露进去，要本人搞。

uLua
https://assetstore.unity.com/packages/tools/utilities/lua-mod…

Assetstore 下面的资源，近期还在更新。

感激题主 Eran@UWA 问答社区提供了答复

Texture

Q：从 Texture arrays 文档（https://docs.unity3d.com/Manual/SL-TextureArrays.html）上来看，GLES3 Metal 曾经能够反对了。

最容易想到的就是地形的 Splat 层，如果是四层 Splat，那么就能够用一个 Texture2DArray 来代替，益处是缩小了 Bind 耗费。其中依据龚大（https://www.zhihu.com/question/56015505）的意思来看，仿佛还能够缩小 Splat 采样次数，但依据本人的测试和了解来看并不行，因为 Texture2DArray 的 Slice 之间并不会 Blending，不知是不是我了解问题。

我应用一个 Texture2DArray 来代替 4 层的 Splat 地形，从 xCode 上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。AssetStore 上有一个插件叫 MegaSplat 就是应用 Texture2DArray 来达到很多层混合。

目前想到的 Texture2DArray 还有一个能够利用的中央是场景贴图。比方场景用到了多张 1024 的贴图，或者多张 Lightmap，原来因为贴图不同导致 StaticBatching 无奈合并，当初就能够应用 Texture2DArray 来做了。

还有比方 UI 上的 Icon 之类的，能够合并到一个 Texture2DArray 来达到 DrawCall 的合并。

目前 Texture2DArray 最不好的中央是，只能通过代码来创立，没有编辑器的反对。如果要离线制作 Texture2DArray，就须要为不同的平台筹备多份资源了。

请问大家有没有 Texture2DArray 的教训能够分享呢，曾经应用或者有打算应用的?

A1：钻研了一下 Texture2DArray，看起来它是将多个 2D 的 Texture 组合起来变成一个对象，所以在应用的时候只须要绑定一次，就能够采样多个 2D Texture。确实如题主所说，采样的时候还是一次只能采样一个指定的 Slice，Blend 也须要另外的 Shader 代码来实现。

题主说了：

其中依据龚大的意思来看，仿佛还能够缩小 splat 采样次数，但依据本人的测试和了解来看并不行。

我感觉他的意思可能是：并不是每次采样必须把所有的 Slice 都采了，而是能够只采其中一部分。预计本来想表白的是一次采样只采一个 Slice。

我应用一个 Texture2DArray 来代替 4 层的 Splat 地形，从 xcode 上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。

如果单从性能上看，Texture2DArray 比 Texture2D 确实只是缩小纹理绑定的开销，而后在游戏引擎中可能会对合批产生影响。其余的做法跟一般 Texture2D 是一样的。Texture2DArray 比 Texture3D 在 LOD 解决上不同，Texture3D 会缩小 Slice，这并不是渲染 Terrain 时想要的。而后 Texture2DArray 在 Filter 的时候只会在 u，v 上做，而 Texture3D 还会在 d 上做，所以这部分 Texture2DArray 也比 Texture3D 性能更好。综合这些因素可能就是举荐渲染 Terrain 应用 Texture2DArray 的起因。题主通过试验阐明 Texture2DArray 渲染地形没有缩小开销，也有可能是因为个别一个场景就一个地形，从绑 4 张纹理变成绑 1 张就少了几毫秒，而且也不是每帧都绑，所以从整体成果上看体现的不显著。

— 更新 2018.2.22

做了个简略试验验证了一下，下图别离是用 Texture2D 和 Texture2DArray 渲染地形后果和 GLES API 调用。试验设施为三星 s6。

Texture2D：

Texture2DArray：

其中，GLES API 调用图中红色框示意纹理绑定的 API 调用，绿色框示意渲染 API 调用。WT 示意了该 API 调用的耗时，单位为纳秒。从 Texture2D 图中可知一共有 5 次纹理绑定，别离对应于材质中的 5 张纹理绑定，而 Texture2DArray 图中只有两次调用，别离是 Splat 纹理和四层混合纹理的绑定。从图中可知一次 glBindTexture 的耗时大概为 1000~10000ns，即最多 0.01ms。因而，三次 glBindTexture 加上三次 glActiveTexture 也最多 0.06ms。所以看不出来。

感激 ZFK@UWA 问答社区提供了答复

A2：如果地形须要 16 张图片，制作上确保同一地位最多受 4 张图影响，是否可行？若可行是否能够了解为应用 Texture2DArray 比不应用节俭了 16-(4+1)=11 次 Sample，与相应的 Bind？（这个 4 也可能 2 或者 10 看需要，+ 1 是因为要别离存索引跟权重，具体要不要 + 1 视理论状况决定。）不应用 Array 时缩小 Sample 次数也能用 if 断定但对 GPU 并行影响更大。

感激 makebalance@foxmail.com@UWA 问答社区提供了答复

明天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，咱们遇到的问题只是冰山一角，UWA 社区愿伴你同行，一起摸索分享。欢送更多的开发者退出 UWA 社区。

UWA 官网：www.uwa4d.com
UWA 社区：community.uwa4d.com
UWA 学堂：edu.uwa4d.com
官网技术 QQ 群：465082844