VR导入美术场景问题，以及锯齿问题解决

我们的工作流程是程序这边做好关卡白盒，打包关卡给美术，美术再根据白盒搭建场景。

美术发来场景项目后，导入到Gameplay项目中出现了这样的问题：因为白盒关卡是在Gameplay项目中搭建，当美术场景关卡从场景项目迁移回Gameplay项目中时，尽管原关卡已被删除，但由于Gameplay项目中仍旧存在原关卡的缓存，导入的场景关卡打开后仍然是原来的白盒关卡，而不是美术关卡（尽管美术资源已被正确导入）。感觉是一些重定向资源的问题。

尝试解决：删除一些缓存文件夹后再次导入，还是出现了相同的问题，不敢删Binary，因为电脑没有重新编译的条件。

解决：为防止map文件出现在历史中同样的位置，我把美术的所有资源都移动到了一个文件夹里再迁移，不再出现上述问题。

另一个问题：导入VR项目的场景出现颗粒感，锯齿感严重的问题。下图是导入之前的场景画面：

下图是导入后的场景画面，颗粒感严重：

根据经验，这种问题的原因可能有两个，一个是lumen的采样率不够导致的flickering issue，另一个就是抗锯齿（反走样）出了问题。最后发现这两个问题其实都有，但flickering issue纯粹是lumen性能问题不能得到有效解决，故下面说明抗锯齿问题解决过程。

一开始我并不知道抗锯齿出了问题，但知道是引擎的渲染设置出了问题，故将项目分成两个拷贝，一个保持原先的DefaultEngine.ini文件（对照组），一个使用美术项目的DefaultEngine.ini文件（实验组）。通过VR测试，发现对照组的帧率更高，能达到60帧左右，而实验组只能达到35帧。故进一步查看GPU占用分布情况，使用Stat GPU，结果如下：

对照组：

实验组：

对比两者占用分布发现，实验组多了TSR的环节，可确定对照组的颗粒感情况是抗锯齿设置问题，设置成TSR即可解决问题。

值得一提的是，对照组由于是从UEVR模板开始开发的项目，其原始渲染器是前向渲染，使用MSAA进行抗锯齿。而后来我把项目改成了使用延迟渲染，但没有改变抗锯齿设置。

从图中可以看出，MSAA实际上对延迟渲染是不支持的，故对照组实际上并没有使用任何抗锯齿技术，故呈现出颗粒感严重情况，改为使用其他任何抗锯齿方法都能使情况有所好转，TSR效果最佳。

UE C++ Category的命名冲突

今天让AI给我写UEC++代码的时候，我让他给我创建一些可以在蓝图里调整的参数/函数，但我编译了几次都在蓝图里找不到我要的东西，于是发现了一个我以前没有注意到的东西。问题在于，如果属性/函数的Category和UE已有模块的Category命名相重叠，会产生反射上的问题，导致蓝图里找不到C++里写的属性/函数。

Debug过程：

我发现虽然在蓝图细节面板找不到属性，蓝图编辑器里也找不到函数，但当我取消勾选Context Sensitive的时候，却能够找到我定义的函数。

为了定位问题，我又创建了一个TestFunction，Category设为Test，结果我不用取消勾选Context Sensitive也能找到该函数，因此定位问题为Category的问题。

随后我将自己找不到的那些函数和变量的Category从Navigation设置为PlayerNav，再次编译，这些函数和变量就能够在蓝图当中找到了，问题解决。

总结：

UE 的 UNavigationSystemV1、ARecastNavMesh 等 AI 模块大量使用 "Navigation" 作为分类名。当在自己的 UPROPERTY 和 UFUNCTION 上也写 Category = "Navigation" 时，UHT 生成的反射元数据和引擎的 Navigation 类别产生了命名冲突。在蓝图中搜索时，引擎优先匹配了 AI 模块的 Navigation 分类，自己的属性和函数被"淹没"了，只有取消勾选 Context Sensitive 才能找到。

修复：把 "Navigation" 改成项目特有的分类名（比如 "PlayerNav"），问题立刻解决。

教训：在 UE 里避免使用引擎已有的系统名称作为你的 UPROPERTY/UFUNCTION 分类名，比如 Navigation、AI、Animation、Physics、Rendering、Input、Collision 等。加一个项目前缀区分（如 PlayerNav、JGFZ_Input）是最简单的策略。