问题描述
例如，在 Minecraft 中，您可以将手电筒放置在任何地方，每个手电筒都会影响世界中的光照水平，并且您可以在世界上放置的手电筒/光源的数量没有限制.我 99% 确定手电筒的照明在 CPU 上得到处理并为每个块存储，因此在渲染该特定块的光值时只需要将其传递到着色器中，但光源不能为此移动原因.如果你有一个游戏，你可以放置可以四处移动的光源(着火的箭头，上面有灯的矿车，发光的能量球)并且照明不是那么简单(包括颜色)什么是最有效的计算光照效果的方法.
In Minecraft for example, you can place torches anywhere and each one effects the light level in the world and there is no limit to the amount of torches / light sources you can put down in the world. I am 99% sure that the lighting for the torches is taken care of on the CPU and stored for each block and so when rendering the light value at that certain block just needs to be passed into the shader, but light sources cannot move for this reason. If you had a game where you could place light sources that could move around (arrow on fire, minecart with a light on it, glowing ball of energy) and the lighting wasn't as simple (color was included) what are the most efficient ways to calculate the lighting effects.
从我的研究中，我发现了不同的渲染、不同的光照、动态创建具有不同数量可用光照的着色器并使用 for 循环(由于展开而无法使用制服)和静态光照贴图(这些可能只是用于静止灯).有没有其他方法可以进行光照计算，例如除了允许移动灯光之外，做我的世界所做的事情，或者是否可以采用无限数量的灯光并将它们数学组合成仅涉及少数灯光的近似值(这是我的想法)想出了，但我不知道怎么做)?
From my research I have found differed rendering, differed lighting, dynamically creating shaders with different amounts of lights available and using a for loop (can't use uniforms due to unrolling), and static light maps (these would probably only be used for the still lights). Are there any other ways to do lighting calculations such as doing what minecraft does except allowing moving lights, or is it possible to take an infinite amount of lights and mathematically combine them into an approximation that only involves a few lights (this is an idea I came up with but I can't figure out how it could be done)?
如果有帮助，我是一名在 OpenGL(旧版和现代)方面拥有丰富经验的程序员，因此您可以给我代码片段，尽管我在照明方面没有做过太多工作，因此我们将不胜感激.如果你能指出我正确的方向，我也愿意做研究！
If it helps, I am a programmer with decent experience in OpenGL (legacy and modern) so you can give me code snippets although I have not done too much with lighting so brief explanations would be appreciated. I am also willing to do research if you can point me in the right direction!
推荐答案
你的标题有点误导 infinite light 暗示像太阳一样在无限距离内的定向光.我会改用无限数量的灯.这里有一些我知道的方法:
Your title is a bit misleading infinite light implies directional light in infinite distance like Sun. I would use unlimited number of lights instead. Here some approaches for this I know of:
(背面)光线追踪器
它们本身可以处理任意数量的光源.光只是引擎中的另一个对象.如果光线击中光源，它只需要光强度并停止递归.不幸的是，当前的 gfx 硬件不适合这种渲染.有用于此的GPU 增强引擎，但专用 gfx 硬件仍在开发中，尚未投放市场.内存要求与标准 BR 渲染没有太大不同，您仍然可以使用 BR 网格，但数学(分析)网格是本机支持的，并且更适合于此.
they can handle any number of light sources natively. Light is just another object in engine. If ray hits the light source it just take the light intensity and stop the recursion. Unfortunately current gfx hardware is not suited for this kind of rendering. There are GPU enhanced engines for this but the specialized gfx HW is still in development and did not hit the market yet. Memory requirements are not much different then standard BR rendering and You can still use BR meshes but mathematical (analytical) meshes are natively supported and are better for this.
标准 BR 渲染
BR 表示 boundary representation 这样的引擎(如 OpenGL 固定功能)只能处理有限数量的灯光.这是因为每个基本体/片段都需要完整的灯光列表，并且在每个基本体或每个片段的基础上对所有灯光进行计算.如果你有很多光，这会很慢.
BR means boundary representation such engines (Like OpenGL fixed function) can handle only limited number of lights. This is because each primitive/fragment needs the complete list of lights and the computations are done for all light on per primitive or per fragment basis. If you got many light this would be slow.
- 固定数量光源的 GLSL 示例参见片段着色器
- GLSL example of fixed number of light sources see the fragment shader
此外，当前的 GPU 对存储灯光和其他渲染参数的统一(寄存器)的内存有限，因此有可能的解决方法，例如将灯光参数存储在 纹理 中并迭代所有GLSL 着色器中的每个 基本体/片段，但灯光的数量会影响粗略的性能，因此您受到目标帧速率和计算能力的限制.额外的内存要求只是带有光参数的纹理，而不是那么多(每个光的向量很少).
Also the current GPU's have limited memory for uniforms (registers) in which the lights and other rendering parameters are stored so there are possible workarounds like have light parameters stored in a texture and iterate over all of them per primitive/fragment inside GLSL shader but the number of lights affect performance of coarse so you are limited by target frame-rate and computational power. Additional memory requirements for this is just the texture with light parameters which is not so much (few vectors per light).
光照贴图
它们甚至可以计算移动物体.复杂的光照贴图可以缓慢计算(不是每帧).这会导致小的照明伪影，但您需要知道要寻找什么来发现它.光照贴图和阴影贴图非常相似，并且经常同时计算.有简单的光照贴图和复杂的辐射贴图模型
they can be computed even for moving objects. Complex light maps can be computed slowly (not per frame). This leads to small lighting artifacts but you need to know what to look for to spot it. Light maps and shadow maps are very similar and often computed at once. There are simple light maps and complex radiation maps models out there
- look 用于辐射计算的着色遮罩算法
这些是:
- 投影的 2D 地图(难以实施/使用且通常不太精确)
- 3D 体素图(内存要求高但更容易计算/使用)
- projected 2D maps (hard to implement/use and often less precise)
- 3D Voxel maps (Memory demanding but easier to compute/use)
有些方法使用预渲染的 Z-Buffer 作为几何源，然后通过 Radiosity 或任何其他技术.这些可以处理任意数量的灯光，因为这些地图可能需要计算，它们通常在后台计算并不时更新.
Some approaches uses pre-rendered Z-Buffer as geometry source and then fill the lights via Radiosity or any other technique. These can handle any number of lights as these maps can be computation demanding they are often computed in the background and updated once in a while.
快速移动的光源通常会更频繁地更新或从地图中排除，并渲染为透明几何体以产生光的印象.为此所需的计算能力取决于基本的计算方法，例如:
fast moving light sources are usually updated more often or excluded from maps and rendered as transparent geometry to make impression of light. The computational power needed for this depends on the computation method the basic are done like:
- 将相机设置到较大的可见表面
- 渲染场景并将结果处理为光/阴影贴图
- 将其存储为 2D 或 3D 纹理或体素贴图
- 然后从相机视图继续正常渲染
因此，您需要在每次帧/贴图更新时多次渲染场景，并且还需要额外的缓冲区来存储渲染结果，这对于高分辨率或体素贴图来说可能是一大块内存.
So you need to render scene more then once per frame/map update and also need additional buffers to store the rendered result which for high resolution or Voxel maps can be a big chunk of memory.
多通道光层
有些情况是在渲染场景后添加光的，例如我将其用于
there are cases when light is added after rendering of the scene for example I used it for
这里是所有多通道渲染技术，您需要额外的缓冲区来存储子结果，并且通常多通道渲染是在同一个视图/场景上完成的，因此使用预渲染的几何图形可以显着加快速度VAO 或第一遍渲染的 Z 缓冲区 颜色和索引缓冲区.在此处理之后，接下来将作为单个或几个四边形(如大气散射链接)传递，因此与基本的BR渲染
Here comes all multi pass rendering techniques you need additional buffers to store the sub results and usually the multi pass rendering is done on the same view/scene so pre-rendered geometry is used which significantly speeds this up either as locked VAO or as already rendered Z-buffer Color and Index buffers from first pass. After this handle next passes as single or few Quads (like in the Atmospheric scattering link) so the computational power needed for this is not much bigger in comparison to basic BR rendering
前向渲染与延迟渲染
在谷歌这个 前向渲染 vs.延迟渲染 是我发现的第一个相关命中.这不是很好的一个(对我来说有点模糊)但对于初学者来说已经足够了
in a google this forward rendering vs. deferred-rendering is first relevant hit I found. It is not very good one (a bit to vague for my taste) but for starters it is enough
- 前向渲染技术通常是标准的单通道BR渲染
- 延迟渲染是标准的多通道渲染.在第一遍渲染场景的所有几何图形到 Z 缓冲区、颜色缓冲区和一些辅助缓冲区中只是为了知道结果的哪个片段属于哪个对象、材质、...然后在接下来的过程中添加效果、光，阴影，...但几何图形不会再次渲染，而是只渲染单个或少数覆盖 QUADs/per pass，因此下一个 pass 通常非常快 ...
- forward rendering techniques are usually standard single pass BR renders
- deffered rendering is standard multi pass renders. In first pass is rendered all the geometries of the scene into Z buffer, Color buffer and some auxiliary buffers just to know which fragment of the result belongs to which object,material,... And then in the next passes are added effects,light,shadows,... but the geometry is not rendered again instead just single or few overlay QUADs/per pass are rendered so the next passes are usually pretty fast ...
该链接表明，对于高光数，延迟渲染更适合，但这在很大程度上取决于使用的是哪种先前的技术.通常使用多通道光层(它是标准延迟渲染技术之一)，因此在这种情况下是正确的，并且内存和计算能力需求相同，请参见上一节.
The link suggest that for high lights number is the deffered rendering more suited but that strongly depends on which of the previous technique is used. Usually the multi pass light layer is used (with is one of the standard deffered rendering techniques) so in that case it is true, and the memory and computational power demands are the same see the previous section.
这篇关于无限数量的灯光构建游戏中的照明如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！