. 所以我的问题实际上很简单，但显然我想在问这个问题时深入了解更多信息。因此，当我们尝试根据任务中每个刻度的增量时间来更改太阳的位置时，我们面临着巨大的 fps 下降，这很可能是由于光照贴图中发生的重新计算。有人问“理论上，有没有办法实现不依赖增量时间/帧率和预渲染闪电的太阳变化位置？” 我的回答是“是的，也不是。理论上，无论如何你总是在重绘框架。对于动画、非静态对象、阴影层等。但是，从我玩过的情况来看，目前的霸主 RGL 真的很擅长处理这个我很惊讶。让我也举一个例子，目前，在 RGL 中，只有重要的像素区域在闪电感上得到更新。这意味着，假设您的分辨率为 1024x1024，如果我们将其分成 4 个，您将有 16 个不同的区域，每个区域都有 256x256 像素区域。如果说，区域 1 中没有任何移动，那么区域 1 保持不变，只有多边形数据被绘制到屏幕上（这显然基于相机平截头体）这非常合乎逻辑，因为您不需要重新计算所有这些区域一遍又一遍，你可以重画它。但是当你改变太阳时，这会影响整个场景，这给 RGL 带来了沉重的计算问题。我认为为了克服这个问题，他们在场景中设置了一个标志，上面写着“IsInterior”，它基本上告诉引擎冷却而不计算阳光效果，因为这无关紧要。” 我有点想知道我的假设是否正确。我还想知道在游戏场景中创建动态天气和白天循环是否可行。
我可以很容易地猜出降低 FPS 的因素。太阳方向变化意味着重新计算：
* 静态阴影贴图。10 毫秒。
* 环境贴图（PBR 照明技术使用这些来计算漫反射环境、环境镜面反射和反射）。有计算量大的滤波操作，一般需要400ms。
* GI 重新照明。我们以独立于大气的方式存储 GI 数据，它预先计算了光的传输，“传入”映射到“传出”（从太阳，到物体，然后是眼睛）。一旦你改变了光照环境（天空盒、太阳方向、天空亮度），我们需要在 GI 探测器中将传入的光照重新映射到出射。（一般一个场景有 100K - 200K 个探针）。在高规格计算机中，这通常需要 300 - 400 毫秒。
但是，我们在世界地图中拥有动态的氛围。我们对此的处理如下：
* 我们现在不使用 GI，因此我们没有具体的解决方案。
* 我们有一个大气曲线，我们将大气值定义为曲线。然后假设每 1 小时，我们预渲染和预烘焙环境贴图并保存。然后加载它并在新旧之间进行插值。
该系统有可能用于处理这种情况。但是你肯定需要编辑器。
4. 坦率地说，我没想到 Profiler 会像毫秒一样给出答案，但这绝对证明我问对了人。静态阴影贴图完全可以花 10 毫秒，我应该说，我期待的东西比这更高。然而，就环境地图而言，究竟是什么占用了这么多计算能力？不能说我是这方面的专家，但据我所知，已经有真正主流的计算方法，这些方法已经被许多引擎证明了。另外，你能解释一下“大气曲线”是什么意思吗，因为根据我在《霸主》中看到的，我们可以认为大气是一个包含许多不同信息的对象。但这是你的意思还是你的意思是大气作为环境颜色和太阳方向？因为它们在修改和扩展游戏方面有点不同（即
您需要先在立方体贴图的位置在 6 个方向上渲染和点亮场景。通过少量工作，您可以在渲染时将其用作最光滑的反射。但是，当表面开始变得不那么光滑时，您需要使用像素值的组合。这不是一个简单的下采样操作，您需要投射随机光线并计算它们对不同光泽度级别的贡献。从某种意义上说，您需要进行蒙特卡洛积分。这部分需要一些。对于一个立方体贴图，这可能会很低，但对于多个立方体贴图，它可以很容易地占用这么多。（我们有本地立方体贴图，用于在贴图的不同区域获得正确的镜面反射）。对于插值大气，您可以将它们视为多条曲线，在一天中的每个时间都有不同的值。例如，太阳高度与一天中的时间图可以被认为是两条线，其中第一条线从 05:00 到 12:00 从 0 到 90。然后从对面往下走。对于您在 .xml 中看到的每个大气值，我们都有一条曲线。我们还可以改变这些曲线的陡峭程度。然后，我们预烘焙立方体贴图并在它们之间混合。
5.啊，好吧，这是有道理的。虽然，正如我所说，我绝对不是这方面的专家，但解释很清楚。我相信也无法通过手动覆盖一些 RGL 规则来更改这些类型，例如，假设创建一个标志以忽略/不计算已在主引擎中完成的某些操作。或者也许我们可以创建肮脏的着色器技巧，降低视觉质量但提高性能。但同样，我只是在疯狂地猜测。既然我们在现场，我想问一些事情。云。他们在哪里......我们至少会有一些带有花哨的云体积着色器的移动云吗？
好吧，我们有一些用于不同类型更改的脏标志。这些可能会暴露在大气值的 Setter 函数中，这将使重新烘焙的东西被禁用。对于体积效果，我们在几个月前在团队中进行了讨论。添加这种效果时有两个原因。首先，我们无法在大规模战斗中找到它的运行时间 ms 预算，以及所需的内存成本。其次，我们打算利用开发时间进一步打磨引擎的许多方面。所以，没有体积效果
现在引擎重构完成了， 这些还是不能改变么？ 我太难过了 我太伤心了
我可以很容易地猜出降低 FPS 的因素。太阳方向变化意味着重新计算：
* 静态阴影贴图。10 毫秒。
* 环境贴图（PBR 照明技术使用这些来计算漫反射环境、环境镜面反射和反射）。有计算量大的滤波操作，一般需要400ms。
* GI 重新照明。我们以独立于大气的方式存储 GI 数据，它预先计算了光的传输，“传入”映射到“传出”（从太阳，到物体，然后是眼睛）。一旦你改变了光照环境（天空盒、太阳方向、天空亮度），我们需要在 GI 探测器中将传入的光照重新映射到出射。（一般一个场景有 100K - 200K 个探针）。在高规格计算机中，这通常需要 300 - 400 毫秒。
但是，我们在世界地图中拥有动态的氛围。我们对此的处理如下：
* 我们现在不使用 GI，因此我们没有具体的解决方案。
* 我们有一个大气曲线，我们将大气值定义为曲线。然后假设每 1 小时，我们预渲染和预烘焙环境贴图并保存。然后加载它并在新旧之间进行插值。
该系统有可能用于处理这种情况。但是你肯定需要编辑器。
4. 坦率地说，我没想到 Profiler 会像毫秒一样给出答案，但这绝对证明我问对了人。静态阴影贴图完全可以花 10 毫秒，我应该说，我期待的东西比这更高。然而，就环境地图而言，究竟是什么占用了这么多计算能力？不能说我是这方面的专家，但据我所知，已经有真正主流的计算方法，这些方法已经被许多引擎证明了。另外，你能解释一下“大气曲线”是什么意思吗，因为根据我在《霸主》中看到的，我们可以认为大气是一个包含许多不同信息的对象。但这是你的意思还是你的意思是大气作为环境颜色和太阳方向？因为它们在修改和扩展游戏方面有点不同（即
您需要先在立方体贴图的位置在 6 个方向上渲染和点亮场景。通过少量工作，您可以在渲染时将其用作最光滑的反射。但是，当表面开始变得不那么光滑时，您需要使用像素值的组合。这不是一个简单的下采样操作，您需要投射随机光线并计算它们对不同光泽度级别的贡献。从某种意义上说，您需要进行蒙特卡洛积分。这部分需要一些。对于一个立方体贴图，这可能会很低，但对于多个立方体贴图，它可以很容易地占用这么多。（我们有本地立方体贴图，用于在贴图的不同区域获得正确的镜面反射）。对于插值大气，您可以将它们视为多条曲线，在一天中的每个时间都有不同的值。例如，太阳高度与一天中的时间图可以被认为是两条线，其中第一条线从 05:00 到 12:00 从 0 到 90。然后从对面往下走。对于您在 .xml 中看到的每个大气值，我们都有一条曲线。我们还可以改变这些曲线的陡峭程度。然后，我们预烘焙立方体贴图并在它们之间混合。
5.啊，好吧，这是有道理的。虽然，正如我所说，我绝对不是这方面的专家，但解释很清楚。我相信也无法通过手动覆盖一些 RGL 规则来更改这些类型，例如，假设创建一个标志以忽略/不计算已在主引擎中完成的某些操作。或者也许我们可以创建肮脏的着色器技巧，降低视觉质量但提高性能。但同样，我只是在疯狂地猜测。既然我们在现场，我想问一些事情。云。他们在哪里......我们至少会有一些带有花哨的云体积着色器的移动云吗？
好吧，我们有一些用于不同类型更改的脏标志。这些可能会暴露在大气值的 Setter 函数中，这将使重新烘焙的东西被禁用。对于体积效果，我们在几个月前在团队中进行了讨论。添加这种效果时有两个原因。首先，我们无法在大规模战斗中找到它的运行时间 ms 预算，以及所需的内存成本。其次，我们打算利用开发时间进一步打磨引擎的许多方面。所以，没有体积效果
现在引擎重构完成了， 这些还是不能改变么？ 我太难过了 我太伤心了
