仓库:https://gitee.com/mrxiao_com/2d_game_2

回顾bug

接下来回顾一下这个bug的具体情况。当前是一个调试视图，我们并不是直接在调试视图下工作，而是在进行相关的调试。展示了地图，这里是环境贴图，上面是正在使用的环境贴图，下面的环境贴图暂时未使用。我们在实现时遇到了一个问题，其中一个贴图反射效果正常，而另一个却没有。

在调试过程中，发现反射的区域并不像预期的那样模糊，反而显示成了一条非常细的狭窄区域，这看起来很不对。经过仔细检查后，似乎没有发现明显的错误，所有的设置看起来都合理。但实际的bug是一个非常简单的问题，原因在于代码中对环境贴图的处理方式出了些问题。

黑板：精灵卡片和投射方向

问题的核心在于计算反射贴图时，原本以为可以简单地从屏幕空间的UV坐标出发进行反射光线投射，但实际上，光线投射的计算方式存在问题。在做反射计算时，假设从一个顶视图来看，反射贴图与屏幕对齐，并且使用了一个棋盘图案进行测试。目标是模拟从地面（或者视角中的“天空”）向上投射反射光线，以便确定需要反射的区域。

问题出现的根本原因是，使用了屏幕空间UV坐标来决定投射的起始位置，但这种方法只适用于二维的平面投射。因为在实际场景中，物体（如球体、树木等）并不是完全平坦的，而是呈现出一定的透视效果，所以将这些对象作为平面卡片来处理，会导致反射计算的错误。

具体来说，反射计算是基于屏幕空间的二维坐标进行投射，但卡片类型的物体（例如树木）实际上在三维空间中是有高度的，反射的坐标应当依赖于该物体在Z轴上的位置，而不是简单地在Y轴上移动。因此，投射方向错误，导致了反射效果看起来不合理。

反射效果的异常表现为：反射区域在底部正确显示，而顶部则出现了错误。这是由于反射光线的投射方向与物体的法线方向不一致，导致了反射效果的扭曲。当反射光线朝着法线的相反方向投射时，反射区域会被压缩，而朝着正确的方向投射时，反射区域则显得正常。

最终的解决办法是，需要重新计算反射光线的起始点。必须明确物体（卡片）的基准点，并在该基准点上进行反射光线的投射。需要根据物体在三维空间中的实际位置来决定投射方向，确保反射效果与物体的空间位置一致。这需要对物体的坐标进行调整，以便能够正确地计算反射光线的投射起点和方向。通过这种方式，反射效果将得到修复。

总之，需要通过调整基准点和投射方式来修正反射问题，使得反射效果符合预期。

查看game_render_group.cpp中的有问题的概念

首先，问题出在了屏幕空间UV坐标的使用上，特别是如何正确地处理Y坐标。在目前的实现中，直接使用了X和Y坐标来计算反射光线，但这并不适用于所有类型的物体（如卡片类型的精灵）。为了修正这一问题，必须重新考虑如何计算Y坐标。

具体来说，对于卡片类型的精灵，屏幕空间UV中的Y坐标实际上并不应该直接使用，而是应该用一个固定的投射Y坐标。此投射Y坐标将成为投射光线的起始点。此外，真正需要关注的应该是V坐标，V坐标决定了我们在卡片上的位置。V坐标实际上代表了我们在卡片的高度上的位置，因此，它才是计算反射光线的关键。

目前的坐标系统尚未最终确认，但为了确保当前的计算正确，可以暂时假设坐标系统是从底部向上进行计算的，尽管实际情况可能还没有完全统一。接下来的工作将会集中在完善坐标系统的最终确定，确保计算无误并且能够正确处理反射光线。

最终目标是在调整完成坐标系统后，优化计算并确保所有相关功能可以正常工作，确保每个投射光线都能准确地反映物体的位置和方向。

基于HeightOfCard调整DistanceFromMapInZ

目标是修正屏幕空间UV坐标的计算，特别是对卡片类型物体的Z轴偏移进行调整。首先，对于卡片的Y轴投射坐标是固定的，因此不需要做偏移。但需要根据V坐标来调整物体在Z轴的高度，这个V坐标代表物体在卡片上的垂直位置。

具体做法是，通过将V坐标乘以卡片的高度，来计算物体在Z轴上的偏移。这样，物体的Z高度会根据其在卡片上的位置进行调整，确保反射投射时，物体的高度能够正确反映其实际大小。这个高度可以是树的高度，或者其他任何类型物体的高度。

在计算Z轴的投射距离时，需要根据V坐标来调整。可以假设物体的距离会随卡片的运动而变化，尤其是当物体远离或接近时，地图的Z轴距离会变得更大或更小。特别是，当物体位于卡片的下方时，Z轴的距离是负值，因此需要对这个负值进行处理，以确保反射计算的准确性。

总结来说，通过调整卡片高度的偏移，使用V坐标来控制Z轴的投射，可以解决反射计算中的错误，确保物体的反射效果符合预期。

黑板：确定投影的高度偏移量

在处理Z轴的计算时，最初的思路是将Y坐标作为固定值，但后续发现需要更加精确的方式来计算。问题出现在如何正确地确定物体在空间中的相对高度，尤其是当物体发生旋转时，原本的Y坐标不再准确。因此，需要重新考虑如何计算物体的Z坐标。

首先，要确保Z坐标的计算方式能够正确反映物体从基准点（例如坐标系的原点）上升或下降的高度。这个基准点应该是一个固定点，通常是坐标系的原点。

接着，游戏引擎需要根据渲染命令的要求，告知物体当前的Z高度，并且提供期望的Z轴高度变化。例如，给定一个“Y到米的转换常量”，表示每移动一个Y单位，在Z轴上所对应的米数。这意味着每个像素所代表的米数会影响物体在Z轴上的实际位置。

最终，调整计算公式时需要确保正确地使用Y的差值来决定Z轴的高度差，而不是直接将Y作为固定值。

计算ZDiff

为了确保正确的坐标计算，需要对Z轴的差异进行处理。首先，需要从坐标系的原点Y值中减去，得到Delta值，这实际上是Z轴上的差异。接下来，需要将其转换为实际的世界空间单位，通过一个“PixelToMeters”的转换因子，将Z轴差异从像素单位转换为世界空间的代理值。

一旦得到Z轴差异（ZDiff），就不再使用DistanceFromMapInZ，而是使用ZDiff来进行计算。这个值应当是相对于某个固定原点的，这样就能在世界空间中准确反映出位置变化。

此外，还需要注意坐标的符号问题，因为Y轴是相对坐标系统的基准，所以要确保使用Y轴基准的正确值，而不仅仅是依赖于V值，因为V值可能在旋转过程中不再给出可靠的参考值。因此，Y值基准应当作为计算的依据。

关于DistanceFromMapInZ，这个值应该相对于某个假设的原点进行参数化，即距离地图的Z轴值应该考虑到原点的Z轴高度，以便能够准确计算对象在不同高度之间的反射效果。

最后，考虑到高度的差异问题，必须确保能够处理不同地图之间的高度关系。举例来说，如果有两个地图，一个在上方，一个在下方，那么其反射的效果应当基于每个对象的实际高度进行调整。

将DistanceFromMapInZ转化为更合理的方程式

首先，目标是将方程式简化为一个更合理的形式。首先需要计算出当前位置在Z轴上的位置。该位置将从原点的Z值开始，通过Z差异（ZDiff）进行修改，从而得到最终的Z坐标。如果位置上升，ZDiff将是正值；如果下降，ZDiff将是负值。

接下来，不再使用“距离与地图的Z值”（DistanceFromMapInZ），而是直接使用“地图的Z值”（MapZ）。地图的Z值代表地图实际存在的高度，简化了之前的计算。

计算“距离与地图的Z值”时，只需简单地计算当前位置的Z值与地图的Z值之间的差异。这个差异可以通过从当前位置的Z值减去地图的Z值来获得，这样结果将自动是负值或正值，具体取决于地图位置相对当前的位置。通过这种方法，可以基于法线方向来确定哪个地图应该被选取，确保计算正确并简化了逻辑。

初始化数值

目前的目标是清理代码并调整一些参数。在此过程中，假设固定的角色位置FixedCastY（fixed cast position）将位于坐标系的原点。虽然这不是最终的实现方式，但为了简化，暂时将固定位置设为原点。最终，固定位置将需要更多的控制和参数化，因此需要根据实际情况进行调整。

同时，OriginZ暂时被设定为零或其他默认值（例如0.5），以便在没有明确数值的情况下进行计算。在此基础上，FixedCastY的值也可以根据Origin.y来设置。之后，计算PixelsToMeters转换时，通常需要与渲染信息相关联，可以通过设置与PixelsToMeters相关的值来完成。

需要特别注意的是，PixelsToMeters是一个常见的渲染转换，用于将像素与实际物理世界中的单位（例如米）之间的关系确定清楚。这个转换参数需要根据实际渲染情况来进行设置，确保从像素到物理单位的转换准确无误。

定位EnvMaps

目前还没有完全完成，但已经接近目标。在创建地图时，必须确定每个地图的位置和高度，以便在世界坐标中准确地显示它们。因此，在绘制这些地图时，需要指定每个地图的高度，明确它们在世界中的存在位置。

在设置地图时，可以通过指定位置参数来设置地图的高度。例如，底部地图（zero）可以暂时设置为一个默认的高度，而其他地图（如天空地图）可以设置在距离地面一定高度的位置，比如2米。这样可以为每个地图指定一个合理的高度，确保地图在世界中正确显示。这是一个示例，实际高度值可能根据需求进行调整。

球太大改小一点

在游戏中查看效果

目前有一些不确定的地方，特别是在代码的执行和投射（或是相关操作）部分，具体应该如何进行还不完全清楚。对这些内容的理解还不够明确，因此打算先不做进一步的工作，而是先回顾一下现有代码，确保对整体逻辑有清晰的了解。

目前的状态虽然有些混乱，但计划在深入研究代码之后再决定接下来的步骤。希望能够对当前的实现有一个更好的把握，然后再继续推进后续的开发工作。

暂时禁用采样调试可视化，检查反射效果

回到上面的部分，暂时可以关闭采样相关的内容，这样可以更清楚地查看结果。现在能看到新的反射球体，看起来已经比之前更合理了一些，但依然觉得顶部的反射可能还是有点问题，尽管很难准确判断。实际情况是，顶部反射实际上可能是底部反射的问题，或者可以从另一个角度理解。

当前的视觉效果确实有些奇怪，看起来不完全符合预期，但整体来说，已经有所改进。接下来需要进一步调整和确认，以确保反射效果更加准确。

设置EnvMaps值以供测试

目前的设置是，无论世界中的位置如何，所有的物体都会被设置到一个固定的Z坐标（0.5），即处于两个地图之间的中间位置。为了测试，可以暂时将其设置为两个地图的中点，这样可以看到它们是否相似。设置为中间后，结果显示出它们确实非常相似，比之前有所改善。

接下来，可以通过类似之前的设置来进行测试，比如一个地图位于下方（-2米），另一个位于上方（+2米），这时查看效果，发现它已经比之前合理得多，尽管还有一些不确定性，但整体比之前的状态更加理智和可接受。

将Origin设置为FixedCastY的中间位置

现在设置的固定投射位置（Fixed Cast Location）是根据原点（Origin）来确定的，假设原点位于物体的中心位置。为了更公平地进行比较，决定将固定投射Y位置设置为原点加上X轴和Y轴的半距，即将物体的中心作为投射位置。这样，投射位置就会位于物体的中心，从而使得不同位置之间的比较更加公正。

将ScreenSpaceUV设置为{0.5f，0.5f}，调查反射的变形

在当前的测试中，设定了固定的投射位置，并将屏幕空间UV设置为0.5，使其位于中心，目的是检查旋转时是否出现异常。由于使用了球形法线贴图，预期应该只在外部区域看到变化，而内部区域应保持稳定。然而，尽管设定了固定位置并停止了位移，仍然观察到了一些不应有的变化，尤其是在旋转时，法线变换似乎没有完全正确。

为了进一步调试，决定加速旋转并调整视图，使得旋转更明显，从而帮助排查问题。同时，开启采样器，观察形状的变化。这些操作帮助确认了在旋转过程中，采样的结果有一些波动。接下来，会进一步检查法线采样和反弹方向的变换，期望能找出问题所在并解决。

目前，虽然外部区域的变化正常，但内部区域似乎还存在不稳定，导致需要进一步处理和调试。这表明在旋转过程中可能需要更精细的法线调整或者其他变换参数需要优化。

对球体周围区域进行Alpha处理

为了进一步测试，决定创建一个测试版本，其中使用了一个球形漫反射贴图。为了实现这一点，首先修改了现有的TestDiffuse函数，增加了一个MakeSphereDiffuseMap的选项。在新函数中，主要的区别在于漫反射贴图中加入了一个Alpha通道，用于确定球体的位置。这样可以更方便地检查球体的效果。

修改的过程中，将原来的法线计算部分去除，改为计算Alpha值，判断根值是否大于零，如果大于零则Alpha为1，否则为0。这样就可以通过Alpha值来裁剪不正确的法线，避免出现不合理的效果。此时，Alpha值使用预乘Alpha方式，并在计算时对Alpha值进行处理。最后，还要确保所有的颜色和Alpha值处理正确，避免覆盖掉原来的数据。

目前，测试已成功运行，但还需要确保在采样RGB值时不会被覆盖，同时需要确保预乘Alpha值的处理正确，以避免出现错误。

查看球体，验证BounceDirection是否没有变化

在调试过程中，遇到的球体问题比预期的要复杂，如果不是因为当时状态不佳，可能会更快地解决这个问题。然而，尽管如此，问题已经得到解决。通过观察，发现 BounceDirection 并没有明显变化，保持了相对恒定的状态。通过进一步验证，确认 BounceDirection 并不会发生足够大的变化，以至于导致预期之外的差异出现。因此，推测这一点是正确的。

考虑可能发生变化的其他因素

在进一步调试时，发现如果 BounceDirection 的计算没有变化，那么就需要检查其他可能发生变化的因素。一个可能的原因是 PZ 值，即OriginZ + ZDiff。另一个因素是屏幕空间的 UV 值，它应该在表面上保持相对常数。因此，决定检查 ZDiff 值的情况，看看当前的计算是否正确。

通过暂时将 ZDiff 从方程中移除后，发现其保持常数，这表明问题可能出在 if 语句的计算上。接下来需要进一步分析，找出为什么会出现如此错误的 ZDiff 计算结果。

黑板：坐标系考虑事项

在旋转坐标系时，原点位置的变化会导致计算结果发生变化。具体来说，如果从原点开始旋转，随着旋转的进行，球体的某些点会移到原点以下，这实际上符合预期。这意味着，若按照原点来指定位置，旋转后的点会低于原点，而不是像之前那样高于原点。即使调整位置以使球体重叠，球体上某些点的相对位置仍然会因为原点的变化而不同。这表明，今后可能不应继续采用这种指定方式。

设置OriginY以便传递给ZDiff

在调整旋转时，考虑到旋转的影响，原点位置需要进行合理设置。通过设定一个“OriginY”值，可以确保旋转时球体的中心始终保持一致，从而避免旋转过程中位置的误差。这种方法使得球体的中心在旋转过程中保持稳定，不再受到旋转的影响，从而保持一致性。这种调整让计算结果更为合理且可预测。

关键点

关闭采样过度绘制并加深球体颜色

为了更好地查看光照效果，需要确保球体的颜色足够暗，因为当前它的亮度过高，导致光照效果无法显示。因此，首先将漫反射贴图的基础颜色设为黑色，以便能够清晰看到入射光对球体的影响。通过调整这一点，可以更好地验证光照系统的表现。

查看稳定的球体并允许其再次移动

现在，球体看起来很稳定，效果比之前好多了，虽然还有一些调整的空间，但至少目前的表现已经很好。接下来，可以允许球体再次移动并观察反射的变化，这样反射在运动中的表现看起来就更符合预期了。唯一感觉有点问题的是反射的形状似乎有些奇怪，应该是更弯曲一些，但这需要再思考一下。

另外，目前在边缘出现的双线性采样导致了一些闪烁现象。虽然还不确定该如何处理这种情况，但这可能并不是个问题。如果将这些部分正确地设置为模糊的双线性采样效果，或许这种问题就能得到解决，这也可能是稍后在系列中讨论的一个话题。

大小改小看看效果

反射是“倒转”的——边缘应该是中心，反之亦然

反射的边缘应该是中心，而中心应该是边缘。出现了反射翻转的问题，需要修正这一不一致的表现。

问：反射我觉得是反向的，至少在垂直方向上

反射效果应该是向内弯曲的，看起来已经非常稳定了，但可能还存在一个数学错误。现在的效果已经比之前好很多，接近预期的结果。如果没有问题，可以继续检查数学部分，看看是否还有需要调整的地方。

调查球体反射似乎倒转的问题

反射效果之所以出现问题，是因为羽化（feathering）效果影响了反射的形状。羽化效果是通过计算反射方向的Y分量来决定边缘的羽化程度。通过去除羽化效果后，发现反射的形状是正确的，反射应该是向内弯曲的，而不是现在的样子。羽化导致了这个问题，因此可能需要改用不同的测试方法来调整羽化效果。总的来说，反射的计算是正确的，但羽化部分需要进行调整。此外，反射的渐变效果没有预期的那样逐渐变暗，可能需要进一步调整。

黑板：通过对tFarMap的衰减进行平方处理来加强

为了使反射的羽化效果更加平滑，可以考虑调整 tFarMap 值，使其变化更加渐进。通过平方该值，可以加剧其变化，特别是在0到1的范围内。例如，当该值小于1时，平方操作会将其值进一步减小，这种方式会产生更强烈的弯曲效果。类似于我们之前使用的伽马校正，平方操作会增强反射的弯曲，而开方操作则会平滑反射。这样的调整可能会改善反射图案，使其更加自然。

我的猜测是，边缘的法线现在是指向“正上方”，而中心的法线是指向“侧面”

在讨论中提到，当前的反射效果看起来正常。具体来说，边缘的法线现在指向上方，而中心的法线指向侧面。提到的反射曲线，看起来本身是正确的，且反射的部分已经按照预期进行曲线变化。

这个部分并不涉及反射，而是用于逐渐过渡到不同的反射贴图。对于这个过渡部分的曲线，有一些疑问，是否保留这个曲线效果并不确定。一些人认为这种曲线是无害的，甚至可能是有益的，因为这能使中间区域填充其他反射内容。

总的来说，讨论集中在反射的效果和如何平滑过渡到不同的反射贴图，特别是如何在中间区域逐步改变反射的方式。

问：移动它之后看起来不对

左到右的运动看起来是正确的，这种运动方式是合理的。至于上下的运动，问题部分在于，当前缺乏适当的坐标系统来处理上下方向，因此地图可能未能按照预期进行运动。尽管如此，上下运动的效果看起来也符合预期，即它应该表现出像是物体在表面上移动的效果，仿佛它正沿着表面滑动。这种运动方式也符合逻辑，并且是合理的。

球体相对于墙的位置在哪里？如果它在屏幕外面，比如在上面，那就不对了

球体表面反射的行为比较复杂，特别是涉及法线的旋转。例如，若想创建一个法线朝上的球体，反射效果将会不同，仅显示上方的反射。这种球体的法线旋转需要对球体进行特殊处理，调整法线方向。尽管目前还无法直接实现这一点，因为缺少必要的数学计算方法来处理这些变化，特别是对于 Z 轴的计算。

为了实现这一目标，需要通过两条路径来处理法线，一个用于处理躺下的物体，另一个则是处理正常方向的物体。具体来说，当处理坐标系时，如果物体躺下，像素的移动将与屏幕空间中的 UV 坐标相对应。当前的 Z 差异计算不准确，因此需要进行修正。理论上，这个过程可以通过重编译来实现，但要确保所有的坐标系计算都是准确的，仍需要进一步调试。

另外，反射计算中的路径也存在问题，尤其是在处理物体反射和偏移方向时。对于躺下的物体，如何计算反射偏移方向需要进行调整。因此，接下来会集中精力完善坐标系统的处理，并进行相应的调整和测试，确保一切都能按预期正确运行。

改一下法向的坐标(这个地方不是很明白只是验证)

感觉红色和蓝色应该交换位置

讨论中提到，蓝色的部分应该交换位置，这样才能解决“上向”与“下向”的问题。这个问题将在下次修复，届时将对这些方向进行调整。

你能把棋盘格弄得紧一些吗？我认为如果有更多颜色过渡，问题会更容易显现

你只打算支持竖着的卡片和躺着的卡片，还是也支持其他角度？

目前只需要支持站立的卡片和躺下的卡片，其他角度可能不需要处理。尽管如此，考虑到可能的需求，还是决定先实现这两种情况，以防万一。处理这部分内容时，调整坐标系统时应该不会花费太多时间，因此这个调整应该比较简单。

另外，提到蓝色和红色部分需要交换位置，这是“Y轴上和下”问题，计划在下周处理坐标系统时解决这个问题。目前，对整体效果的判断是正确的，看起来一切都在朝着正确的方向进行。

我认为问题的一部分可能是它没有正确地“坐”在地面上

在讨论中提到，当前的并没有完全坐落在地面上，因为它距离地面有8个单位的高度，但并没有达到8个单位的高度，所以它实际上是悬浮的。地面和天空之间的距离不算太远，但也不直接接触。为了能够更好地看到棋盘图案，可以将地面拉得更近，但这会导致棋盘显示得较少。这个问题还可以通过调整其他因素来优化，但目前我们并不清楚这些地图在世界空间中的实际大小，因此需要进一步计算这些值。

此外，当前的坐标系统问题也需要解决，尤其是如何确定单位与实际场景的映射关系。为了准确设置反射的大小和位置，必须明确像素与实际物理空间的关系。这可能需要通过计算每个单位在世界空间中的大小和环境贴图的密度来进行调整。

最后，尽管目前对这些值的设定还不完全明确，但计划通过接下来的坐标系统工作来优化这些参数，以便更精确地控制光照反射等效果。

很高兴，考虑到软件渲染器

目前的代码执行速度非常快，尽管代码本身还比较粗糙，主要是为了搞清楚数学运算的方式。虽然代码比较简陋，但运行速度却很惊人，这为软件渲染的前景带来了积极的信号。即使是在这台机器上，配备了12个核心，如果将屏幕分成12个区域，每个区域由不同的线程渲染，速度将提升大约12倍。因此，通过并行渲染每个屏幕区域，理论上可以显著提高渲染速度。

虽然这个软件渲染器在教育上具有一定的意义，可能还会变成一个能够实际玩的游戏，这种可能性是存在的。不过，考虑到分辨率问题，虽然软件渲染器可以运行，但它的分辨率较低，因此更希望将游戏运行在GPU上，以获得更高的分辨率和更好的视觉效果。

这是开启优化后的吗？

坦率地说，当前的优化几乎完全依赖于编译器的优化。预计当代码进行优化时，性能应该至少能提升四倍，因为这台机器支持八宽度指令，最多可能提升四倍。此外，通过多线程处理，渲染速度还能再提高大约十二倍。总体来说，当前的性能在经过这些优化后，有可能达到目前速度的五十倍，这确实是一个令人惊讶的结果。考虑到这一点，软件渲染器可能会变得可玩，虽然最初并未预期能够实现这个目标。

还没有线程化吗？

目前的代码完全没有进行线程化，也没有做任何优化。虽然启用了编译器优化，但编译器的优化并没有做太多的改进，这与我们通常会做的优化不同。

展望未来

目前进展顺利，感觉离最终目标越来越近。接下来有两个主要任务需要完成才能继续进行渲染器的开发。首先，需要整理和清理坐标系统，确保这一部分没有问题。其次，需要解决如何处理近场光照的问题，这对于屏幕的表现至关重要。

绿色

当前遇到的一个挑战是如何处理“绿色”部分，特别是如何填充靠近物体的光照区域。虽然可以通过模糊处理来实现天空反射或光照的效果，使其变得更加光滑或有光泽，但对于接近物体的近场光照，尤其是反射这一部分，无法轻松实现。原因之一是缺少足够的数据来正确处理反射，尤其是当物体背后没有详细的艺术数据时。例如，如果房子的后面没有绘制，放置在房子左侧和后方的物体就无法反射。这意味着近场反射可能在技术上不可行。不过，可以尝试使用模糊光源来模拟一般的光照，使整体照明效果看起来合理，虽然这不能做到完美的反射。

那Fresnel呢！！！

可以考虑将一些真实的光照术语纳入到光照计算中，但由于当前采用的是解释性的2D光照方法，这些术语可能不会产生太多实际意义。为了决定反射如何根据角度衰减，需要确定合适的术语和模型，虽然这方面的调整和优化是可以尝试的，但不一定会深入探讨物理基础光照，因为没有足够的正确光源数据支持，这样做可能浪费时间。目标是创造艺术上令人愉悦的光照效果，而非严格遵循物理规律。因此，尽管会进行一些光照模型的计算，但它们更多的是为实现视觉效果，而不是严格的物理模拟。