灯光数量不受限制的建筑游戏中的灯光是如何工作的？
How lighting in building games with unlimited number of lights works?
例如，在 Minecraft 中，您可以在任何地方放置火把，每个火把都会影响世界中的光照水平，并且您可以在世界中放置的火把/光源的数量没有限制。我 99% 确定手电筒的照明在 CPU 上得到处理并为每个块存储，因此在渲染特定块的光值时只需要将其传递到着色器中，但是光源由于这个原因不能移动。如果你有一个游戏，你可以放置可以四处移动的光源（着火的箭头，上面有灯的矿车，发光的能量球）并且照明不是那么简单（包括颜色）什么是最有效的计算灯光效果的方法。
根据我的研究，我发现了不同的渲染、不同的光照、动态创建具有不同可用光量的着色器并使用 for 循环（由于展开不能使用制服）和静态光照贴图（这些可能会仅用于静止灯）。是否有任何其他方法可以进行照明计算，例如除了允许移动灯光之外，做我的世界所做的事情，或者是否可以采用无限量的灯光并在数学上将它们组合成仅涉及少数灯光的近似值（这是我的想法想到了，但我不知道怎么做）？
如果有帮助，我是一名在 OpenGL（传统和现代）方面有丰富经验的程序员，所以你可以给我代码片段，尽管我没有做过太多关于照明的事情，所以简短的解释将不胜感激。如果你能给我指明正确的方向，我也愿意做研究！
你的标题有点误导infinite light暗示像太阳一样无限远的定向光。我会改用 unlimited number of lights 。这里有一些我知道的方法：
(返回)ray-tracers
他们可以原生处理任意数量的光源。 Light 只是引擎中的另一个 object。如果光线击中光源，它只会获取光强度并停止递归。不幸的是，当前的 gfx 硬件不适合这种渲染。为此有 GPU 增强引擎，但专门的 gfx 硬件仍在开发中，尚未投放市场。内存要求与标准 BR 渲染没有太大区别，您仍然可以使用 BR 网格，但数学（分析）网格是原生支持的并且更适合这个.
标准BR渲染
BR 表示 boundary representation 此类引擎（如 OpenGL 固定功能）只能处理有限数量的灯光。这是因为每个 primitive/fragment 都需要完整的灯光列表，并且每个 primitive 或每个 片段 基础。如果光线充足，这会很慢。
此外，当前 GPU 的制服（寄存器）内存有限，其中存储了灯光和其他渲染参数，因此有可能的解决方法，例如将灯光参数存储在 纹理 中并在 primitive/fragment 内迭代所有 GLSL 着色器，但灯光的数量会影响粗糙的性能，因此您受到目标的限制frame-rate 和计算能力。额外的内存需求只是带有光参数的纹理，它不是那么多（每个光的向量很少）。
光照贴图
即使移动 object 也可以计算它们。可以缓慢地计算复杂的光照图（不是每帧）。这会导致小的照明伪影，但您需要知道要寻找什么才能发现它。光照贴图和阴影贴图非常相似，通常是同时计算的。那里有简单的光照贴图和复杂的辐射贴图模型
这些是：
- 投影二维地图（很难implement/use并且通常不太精确）
- 3D Voxel maps（需要内存但更容易compute/use）
有些方法使用 pre-rendered Z-Buffer 作为几何源，然后通过 Radiosity 或任何其他技术填充灯光。这些可以处理任意数量的灯光，因为这些地图可以计算要求它们通常在后台计算并偶尔更新一次。
快速移动的光源 通常会更频繁地更新或从地图中排除并渲染为透明几何体以产生光的印象。所需的计算能力取决于基本的计算方法，如：
- 将相机设置为较大的可见表面
- 渲染场景并将结果处理为light/shadow贴图
- 将其存储为 2D 或 3D 纹理或体素贴图
- 然后继续从相机视图进行正常渲染
因此，您需要在每次 frame/map 更新时多次渲染场景，并且还需要额外的缓冲区来存储渲染结果，这对于高分辨率或体素贴图可以是一大块内存。
多通道光层
有些情况下会在渲染场景后添加灯光，例如我将其用于
这是所有多通道渲染技术，您需要额外的缓冲区来存储子结果，通常多通道渲染是在同一个 view/scene 上完成的，因此使用 pre-rendered 几何体可以显着加快速度向上锁定 VAO 或已呈现 Z-buffer 颜色和索引缓冲区从第一遍。在这个句柄接下来作为单个或几个四边形传递后（就像在大气散射 link 中一样），因此与基本 BR 渲染相比，它所需的计算能力并不大很多
前向渲染对比deferred-rendering
在 google 中，这个 forward rendering vs. deferred-rendering 是我发现的第一个相关命中。它不是很好（对我来说有点模糊）但对于初学者来说已经足够了
- 前向渲染技术通常是标准的单通道BR渲染
- 延迟渲染 是标准的多通道渲染。在第一遍中，将场景的所有几何图形渲染到 Z 缓冲区、颜色缓冲区和一些辅助缓冲区中，只是为了知道结果的哪个片段属于哪个 object、material、... 然后在下一个通道是添加效果、光、阴影...但几何体不会再次渲染，而只是渲染单个或几个叠加层 QUADs/per 通道被渲染，因此下一个通道通常非常快...
link 建议对于高光数，延迟渲染更适合，但这在很大程度上取决于使用的是先前的哪种技术。通常使用多通道光层（with 是一种标准的延迟渲染技术）所以在这种情况下是正确的，并且内存和计算能力需求与上一节相同。
例如，在 Minecraft 中，您可以在任何地方放置火把，每个火把都会影响世界中的光照水平，并且您可以在世界中放置的火把/光源的数量没有限制。我 99% 确定手电筒的照明在 CPU 上得到处理并为每个块存储，因此在渲染特定块的光值时只需要将其传递到着色器中，但是光源由于这个原因不能移动。如果你有一个游戏，你可以放置可以四处移动的光源（着火的箭头，上面有灯的矿车，发光的能量球）并且照明不是那么简单（包括颜色）什么是最有效的计算灯光效果的方法。
根据我的研究，我发现了不同的渲染、不同的光照、动态创建具有不同可用光量的着色器并使用 for 循环（由于展开不能使用制服）和静态光照贴图（这些可能会仅用于静止灯）。是否有任何其他方法可以进行照明计算，例如除了允许移动灯光之外，做我的世界所做的事情，或者是否可以采用无限量的灯光并在数学上将它们组合成仅涉及少数灯光的近似值（这是我的想法想到了，但我不知道怎么做）？
如果有帮助，我是一名在 OpenGL（传统和现代）方面有丰富经验的程序员，所以你可以给我代码片段，尽管我没有做过太多关于照明的事情，所以简短的解释将不胜感激。如果你能给我指明正确的方向，我也愿意做研究！
你的标题有点误导infinite light暗示像太阳一样无限远的定向光。我会改用 unlimited number of lights 。这里有一些我知道的方法：
(返回)ray-tracers
他们可以原生处理任意数量的光源。 Light 只是引擎中的另一个 object。如果光线击中光源，它只会获取光强度并停止递归。不幸的是，当前的 gfx 硬件不适合这种渲染。为此有 GPU 增强引擎，但专门的 gfx 硬件仍在开发中，尚未投放市场。内存要求与标准 BR 渲染没有太大区别，您仍然可以使用 BR 网格，但数学（分析）网格是原生支持的并且更适合这个.
标准BR渲染
BR 表示
boundary representation此类引擎（如 OpenGL 固定功能）只能处理有限数量的灯光。这是因为每个 primitive/fragment 都需要完整的灯光列表，并且每个 primitive 或每个 片段 基础。如果光线充足，这会很慢。此外，当前 GPU 的制服（寄存器）内存有限，其中存储了灯光和其他渲染参数，因此有可能的解决方法，例如将灯光参数存储在 纹理 中并在 primitive/fragment 内迭代所有 GLSL 着色器，但灯光的数量会影响粗糙的性能，因此您受到目标的限制frame-rate 和计算能力。额外的内存需求只是带有光参数的纹理，它不是那么多（每个光的向量很少）。
光照贴图
即使移动 object 也可以计算它们。可以缓慢地计算复杂的光照图（不是每帧）。这会导致小的照明伪影，但您需要知道要寻找什么才能发现它。光照贴图和阴影贴图非常相似，通常是同时计算的。那里有简单的光照贴图和复杂的辐射贴图模型
这些是：
- 投影二维地图（很难implement/use并且通常不太精确）
- 3D Voxel maps（需要内存但更容易compute/use）
有些方法使用 pre-rendered Z-Buffer 作为几何源，然后通过 Radiosity 或任何其他技术填充灯光。这些可以处理任意数量的灯光，因为这些地图可以计算要求它们通常在后台计算并偶尔更新一次。
快速移动的光源 通常会更频繁地更新或从地图中排除并渲染为透明几何体以产生光的印象。所需的计算能力取决于基本的计算方法，如：
- 将相机设置为较大的可见表面
- 渲染场景并将结果处理为light/shadow贴图
- 将其存储为 2D 或 3D 纹理或体素贴图
- 然后继续从相机视图进行正常渲染
因此，您需要在每次 frame/map 更新时多次渲染场景，并且还需要额外的缓冲区来存储渲染结果，这对于高分辨率或体素贴图可以是一大块内存。
多通道光层
有些情况下会在渲染场景后添加灯光，例如我将其用于
这是所有多通道渲染技术，您需要额外的缓冲区来存储子结果，通常多通道渲染是在同一个 view/scene 上完成的，因此使用 pre-rendered 几何体可以显着加快速度向上锁定 VAO 或已呈现 Z-buffer 颜色和索引缓冲区从第一遍。在这个句柄接下来作为单个或几个四边形传递后（就像在大气散射 link 中一样），因此与基本 BR 渲染相比，它所需的计算能力并不大很多
前向渲染对比deferred-rendering
在 google 中，这个 forward rendering vs. deferred-rendering 是我发现的第一个相关命中。它不是很好（对我来说有点模糊）但对于初学者来说已经足够了
- 前向渲染技术通常是标准的单通道BR渲染
- 延迟渲染 是标准的多通道渲染。在第一遍中，将场景的所有几何图形渲染到 Z 缓冲区、颜色缓冲区和一些辅助缓冲区中，只是为了知道结果的哪个片段属于哪个 object、material、... 然后在下一个通道是添加效果、光、阴影...但几何体不会再次渲染，而只是渲染单个或几个叠加层 QUADs/per 通道被渲染，因此下一个通道通常非常快...
link 建议对于高光数，延迟渲染更适合，但这在很大程度上取决于使用的是先前的哪种技术。通常使用多通道光层（with 是一种标准的延迟渲染技术）所以在这种情况下是正确的，并且内存和计算能力需求与上一节相同。