在上一周,我终于成功,至少看起来成功的解决了之前提到的UE4的r.MobileHDR变量修改的问题。成功解决之后更是倍感蛋疼,因为我之前确实数次和正确的答案擦肩而过,只是因为不相信,而和他失之交臂。

补充: UE4 preInit几个神坑

       在上篇blog中已经记录了preInit的几个神坑,纠正一下,isCached没有问题,有问题的是shouldCache,它判断shader应该被缓存之后,就会顺手把shader cache住。

       UE4还有一个坑,不光在perInit中有,在全部地方都有使用。而且这个特性绝大多数编程语言都有,实际上使用很广,就是短路求值。短路求值这个特性一说大家都明白,对于&&如果左值为false,或者||的左值为true,就会跳过右边的判断。一般情况下,这也没啥。但如果右侧的判断,是我上面提到的shouldCache,这个代码的逻辑就会变得非常微妙。并且,事实上,很多情况下UE4直接执行短路执行右侧的条件是直接崩溃的,不过,相比调试这个坑爹的shouldCache逻辑,我倒是更希望他直接崩溃。

(看起来是)移动平台超越mobileHDR限制烘焙LDR和HDR材质的方法

       注意:我写了看起来是,因为这种方法也许有很多想想就知和不可预知的问题。

       这个问题的一个答案,简单的超乎寻常,简单的我自己都不信,简单的让我认为我的C++水平就是一坨屎(事实上也是)。

       /Engine/Source/Runtime/Renderer/Private/MobileBasePassRendering.h,引擎源码的这个文件的ShouldCacheShaderByPlatformAndOutputFormat,将它的返回值改为true写死。这样烘焙出来的material.uasset就同时含有LDR和HDR的shader了。

       不过,再次提醒一下,这么做有很多一直和未知的错误,希望大家谨慎使用。考虑到EPIC官方绝对不会修复这个问题,也希望诸位大佬能协助小弟排查一下这样的后果和代价。