光照贴图和全局照明

Lightmaps and Global Illumination

光照贴图和全局照明

Introduction

介绍

Baked lightmaps allow pre-generating the direct lighting from lights such as DirectionalLight, PointLight, and SpotLight, including the shadows cast by the lights. At run time, instead of performing the appropriate calculations in the fragment shader, and, in case of shadows, generating the potentially costly shadow maps in real time, the pre-generated image map is sampled instead.

​烘焙光照贴图允许从诸如DirectionalLight、PointLight和SpotLight等灯光预生成直接照明，包括灯光投射的阴影。在运行时，不是在片段着色器中执行适当的计算，也不是在阴影的情况下实时生成可能代价高昂的阴影贴图，而是对预先生成的图像贴图进行采样。

Note: As of Qt 6.4, lightmap baking is in an early technical preview state. Changes to features, quality, and API are likely to happen in future releases.

注意：从Qt 6.4开始，光照贴图烘焙处于早期技术预览状态。功能、质量和API的变化可能会在未来的版本中发生。

A lightmap is generated per Model. Even if a Model has multiple submeshes, and is therefore associated with multiple materials, there will be one single lightmap image generated for the entire model.

每个模型都会生成光照贴图。即使一个模型有多个子表，因此与多个材质相关联，也会为整个模型生成一个光照贴图图像。

Lightmaps are generated using raytracing, which by nature provides proper occlusion ("light does not travel through walls"), and possibly more realistic shadows than the real-time techniques for lighting and shadow mapping.

光照贴图是使用光线追踪生成的，光线追踪本质上提供了适当的遮挡（“光不会穿过墙壁”），并且可能比实时照明和阴影贴图技术更逼真的阴影。

More importantly, lightmaps also allow baking indirect lighting, providing a solution for global illumination. This takes light rays reflected from other surfaces in the scene into account.

更重要的是，光照贴图还允许烘焙间接照明，为全局照明提供了解决方案。这考虑了从场景中其他表面反射的光线。

Below is a simple example. The scene contains four Rectangle and a Sphere model, with a DirectionLight pointing downwards and a PointLight. The rectangle models are rotated 0 and 90 degrees, which exaggerates the limitations of the real-time lighting calculations because they are all either parallel or perpendicular to the DirectionalLight's direction.

​下面是一个简单的例子。该场景包含四个矩形和一个球体模型，其中DirectionLight指向下方，PointLight指向下方。矩形模型旋转了0度和90度，这夸大了实时照明计算的局限性，因为它们都平行于或垂直于DirectionalLight的方向。

On the right, the scene is rendered with lightmapping enabled, after having lightmaps baked for all five models. Both lights are set to fully baked, meaning both direct and indirect illumination is baked. Indirect lighting uses 256 samples and a maximum of 3 bounces. The resulting lightmaps were then denoised. This gives a significantly more realistic image.

​在右侧，在为所有五个模型烘焙光照贴图后，场景在启用光照贴图的情况下渲染。两个灯光都设置为完全烘焙，这意味着直接和间接照明都已烘焙。间接照明使用256个样本和最多3次反弹。然后对生成的光照贴图进行去噪处理。这提供了一个更真实的图像。

Real-time lighting

实时光源

Fully baked lighting

全烘焙照明

Below is a snippet that shows how the lightmapped results were achieved. The difference lies in the usedInBakedLighting, bakeMode, and bakedLightmap properties. For this example, the lightmap size has been reduced using the lightmapBaseResolution property, to save disk space and reduce application load times.

​下面是一个片段，显示了如何实现光照贴图结果。区别在于所使用的InBakedLighting、bakeMode和bakedLightmap属性。对于这个例子，使用lightmapBaseResolution属性减小了光照贴图大小，以节省磁盘空间并减少应用程序加载时间。

DirectionalLight {
    bakeMode: Light.BakeModeAll

    eulerRotation.x: -90
    brightness: 0.5
    castsShadow: true
    shadowFactor: 75
}
PointLight {
    bakeMode: Light.BakeModeAll

    y: 200
    z: 100
    color: "#d9c62b"
    castsShadow: true
    shadowFactor: 75
}
Model {
    usedInBakedLighting: true
    lightmapBaseResolution: 256
    bakedLightmap: BakedLightmap {
        enabled: true
        key: "sphere1"
    }

    source: "#Sphere"
    materials: PrincipledMaterial { }
    y: 100
}
Model {
    usedInBakedLighting: true
    lightmapBaseResolution: 256
    bakedLightmap: BakedLightmap {
        enabled: true
        key: "rect1"
    }

    source: "#Rectangle"
    materials: PrincipledMaterial { }
    eulerRotation.x: -90
    scale: Qt.vector3d(10, 10, 10)
}

// ... three additional Rectangle models, with rotations 0, 90, and -90

The above example used fully baked lights. A light can also be configured to only use baked lighting for indirect illumination, while performing direct lighting and shadow mapping in real time. In the below scene there are 5 point lights, all of which are set to BakeModeIndirect for the right screenshot. While the direct lighting and shadows look identical, the right image looks significantly better due to a degree of global illumination added.

​上面的例子使用了完全烘培的灯。灯光也可以配置为仅使用烘焙照明进行间接照明，同时实时执行直接照明和阴影映射。在下面的场景中，有5个点光源，对于右侧的屏幕截图，所有这些点光源都设置为“烘焙模式间接”。虽然直接照明和阴影看起来相同，但由于添加了一定程度的全局照明，右侧图像看起来明显更好。

Real-time lighting

实时光源

With baked indirect lighting added

添加了烘焙间接照明

Important considerations when working with lightmaps

使用光照贴图时的重要注意事项

Lights contributing to baked lighting have their bakeMode property set to either BakeModeIndirect or BakeModeAll. The latter indicates that both the direct and indirect contribution for that particular light is coming from the lightmap. The direct contribution always includes shadows as well. On the other hand, if the intention with the lightmap is only to add indirect illumination to the scene for a particular light, while still having direct lighting calculated (and perform shadow mapping) in real time, then the light should use BakeModeIndirect instead.

​有助于烘焙照明的灯光将其bakeMode属性设置为BakeModeIndirect或BakeModeAll。后者表明，对该特定光的直接和间接贡献都来自光照贴图。直接贡献也总是包括阴影。另一方面，如果光照贴图的目的只是为特定灯光的场景添加间接照明，同时仍然实时计算直接照明（并执行阴影映射），那么灯光应该使用BakeModeIndirect。

Note: Lightmaps are, generally speaking, suitable for models that are static when it comes to transform, geometry, and materials. The same applies to the lights participating in the baked lighting.

注意：一般来说，光照贴图适用于在变换、几何和材质方面是静态的模型。这同样适用于参与烘焙照明的灯光。

For example, a scene that rotates a Model by animating the eulerRotation property will give visually incorrect results when applying a lightmap to that Model. The rendering results for that particular Model will be incorrect, as the pre-generated lightmap only captures one single rotation state for the object. The same would be true, taking another example, if the material for one of the model's submeshes dynamically changes its baseColor property based on time (animation) or some user interaction. The lightmap can only capture one given material baseColor. The same is true for lights. For example, a DirectionalLight that rotates, changes its brightness, color, etc. over time is not suitable for baked lighting.

​例如，通过设置eulerRotation属性的动画来旋转模型的场景在将光照贴图应用于该模型时会给出视觉上不正确的结果。该特定模型的渲染结果将不正确，因为预生成的光照贴图只捕获对象的一个旋转状态。再举一个例子，如果模型的一个子网格的材质根据时间（动画）或某些用户交互动态更改其baseColor属性，情况也是如此。光照贴图只能捕获一个给定的材质基础颜色。灯光也是如此。例如，随着时间的推移而旋转、改变亮度、颜色等的DirectionalLight不适合烘焙照明。

Note: On the other hand, it is always a designer choice when to use lightmapping. Especially with BakeModeIndirect lights, it is likely that there will be scenes where the results are still visually satisfying, even though some of the objects in the lightmapped scene employ dynamic behavior.

​
注意：另一方面，何时使用光照贴图始终是设计师的选择。特别是使用BakeMode间接灯光时，即使光照贴图场景中的一些对象采用了动态行为，也可能会有一些场景的结果在视觉上仍然令人满意。

Lightmapping is a complex engine and tooling feature. It replaces and reimplements several pieces of the engine's rendering pipeline. It works with a fundamentally different rendering model when baking lightmaps, while still consuming and interoperating with the same scene structure, asset data, and engine data structures. The raytracing-based results will often outclass the real-time alternatives, sometimes significantly, which comes at the expense of limitations, such as the mandatory static-ness of the models and lights involved, and, sometimes, quality and rendering artifact issues that are specific to lightmapping.

光映射是一个复杂的引擎和工具功能。它替换并重新实现了引擎渲染管道的几个部分。在烘焙光照贴图时，它使用一种根本不同的渲染模型，同时仍然使用相同的场景结构、资产数据和引擎数据结构并与之交互。基于光线追踪的结果通常会超越实时替代方案，有时甚至会显著，这是以限制为代价的，例如所涉及的模型和灯光的强制性静态性，有时是光照贴图特有的质量和渲染伪影问题。

In practice it will be an artistic choice by the designers what type of lighting to use, and when. All three bakeMode settings have their uses, and complex, larger scenes may very well utilize all three for different lights, depending on what is deemed suitable for a given section of the scene, and what sort of models, materials, and dynamic behavior are present. Lightmapping is not a simple on/off type of toggle switch that can be enabled for any scene and application, but a powerful feature that assumes careful evaluation of the lighting needs of a given scene, and often requires the scene contents and behavior to be designed accordingly, combined with a test-and-tune loop where different lightmap baking and quality settings are explored and tested before deciding on the final approach and the related settings.

​在实践中，设计师会选择使用哪种类型的照明以及何时使用。所有三种bakeMode设置都有其用途，复杂、较大的场景很可能会将这三种设置用于不同的灯光，具体取决于场景的给定部分被认为适合什么，以及存在什么样的模型、材质和动态行为。光照贴图不是一种简单的开/关类型的切换开关，可以为任何场景和应用程序启用，而是一种强大的功能，它假设对给定场景的照明需求进行仔细评估，并且通常需要相应地设计场景内容和行为，并结合一个测试和调整循环，在决定最终方法和相关设置之前，对不同的光照贴图烘焙和质量设置进行探索和测试。

Note: Lightmaps do not support two-sided surfaces. With real time lighting a material with a cull mode of Material.NoCulling automatically inverts the normal as appropriate based on the facing of the fragment. This is not an option for lightmaps since lightmap baking does not operate in view space. Therefore, avoid baked lighting for models that would rely on this.

​
注意：Lightmaps不支持双面曲面。使用“Material.NoCulling”的筛选模式实时照亮材质，会根据片段的朝向自动反转法线。这不是光照贴图的选项，因为光照贴图烘焙在视图空间中不起作用。因此，对于依赖于此的模型，应避免使用烘焙照明。

Baking Lightmaps

烘焙光照图

Properties and types relevant for baking lightmaps, meaning the offline process of generating the image maps that capture direct and indirect lighting and can be used by the renderer in subsequent runs of the application:

与烘焙光照贴图相关的属性和类型，这意味着生成捕获直接和间接光照的图像贴图的离线过程，渲染器可以在应用程序的后续运行中使用：

• Model::usedInBakedLighting
• Model::lightmapBaseResolution,
• Light::bakeMode,
• Lightmapper and SceneEnvironment::lightmapper
• BakedLightmap and Model::bakedLightmap

As of Qt 6.4, the lightmap baking process has to be triggered manually. Whenever the command line argument --bake-lightmaps is present, or the environment variable QT_QUICK3D_BAKE_LIGHTMAPS is set to 1 (or another non-zero value), the engine will work in baking mode and exit the application once baking has completed. The steps of the baking process can be followed by checking the messages printed on the debug output. The result is a set of .exr files written to the current directory, where the filenames each have a qlm_ prefix, followed by the unique key from BakedLightmap::key.

​从Qt 6.4开始，光照贴图烘焙过程必须手动触发。只要命令行参数--bake-lightmaps存在，或者环境变量QT_QUICK3D_BAKE_LIGHTMAPS设置为1（或其他非零值），引擎将在烘焙模式下工作，并在烘焙完成后退出应用程序。在烘焙过程的步骤之后，可以检查调试输出上打印的消息。结果是一组写入当前目录的.exr文件，其中每个文件名都有一个qlm_前缀，后面是BakedLightmap::key中的唯一键。

Preparing a lightmapped scene takes the following main steps:

准备光照贴图场景需要以下主要步骤：

• Identify which models should use a lightmap, and which models should contribute to the lightmap. Models that are part of the lightmapped scene should set Model::usedInBakedLighting to true. Models that are lightmapped (i.e., a lightmap is to be baked for them) should in addition set Model::bakedLightmap to an enabled BakedLightmap object, that provides a unique key that will persistently identify the particular Model object instance. (this is because Qt needs a key to identify the model data in persistent disk storage) Only models with static geometry, transformation, and materials are guaranteed to have correct results when lightmapped at run-time. Most commonly, anything that leads to a non-static world transform over time, such as a dynamically changed or animated position, rotation, or scale, will disqualify the model from participating. Artistic needs can override this, however, especially for models that only contribute to baked indirect lighting but are not themselves lightmapped. For these it may often be visually acceptable to have dynamic transforms, but this always depends on the model and the scene in question.
• ​确定哪些模型应该使用光照贴图，哪些模型应该为光照贴图做出贡献。作为光照贴图场景一部分的模型应将Model::usedInBakedLighting设置为true。光照贴图的模型（即，要为它们烘焙光照贴图）还应将Model::bakedLightmap设置为启用的bakedLightmap对象，该对象提供一个唯一的键，用于持久标识特定的Model对象实例。（这是因为Qt需要一个密钥来识别持久磁盘存储中的模型数据）只有具有静态几何、变换和材质的模型才能保证在运行时进行光照映射时得到正确的结果。最常见的是，随着时间的推移，任何导致非静态世界变换的东西，如动态变化或动画位置、旋转或缩放，都会使模型失去参与资格。然而，艺术需求可以覆盖这一点，特别是对于只对烘焙间接照明有贡献但本身没有光照贴图的模型。对于这些，动态变换在视觉上通常是可以接受的，但这总是取决于所讨论的模型和场景。
• Identify which lights should contribute, and to which degree. Light::bakeMode offers three options:
• ​确定哪些灯应该做出贡献，以及贡献的程度。Light::bakeMode提供三种选项：
  • Light.BakeModeDisabled, the default, which effectively makes the light ignored for all lightmapping purposes.
  • Light.BakeModeDisabled 默认设置，这有效地使灯光在所有光照贴图中都被忽略。
  • Light.BakeModeIndirect is often the "safe" choice, if the only goal is to have a level of global illumination (indirect lighting) in the scene, while not affecting the rendering results for the light in other ways. In this mode the renderer will continue to perform all lighting, including diffuse, specular, sky/environment contributions, and shadow mapping for this light using the standard real-time techniques. However, the light will contribute to indirect lighting using the pre-baked data, possibly leading to illuminating surfaces that are otherwise left untouched by the standard real-time lighting calculations.
  • Light.BakeModeIndirect 如果唯一的目标是在场景中具有一定程度的全局照明（间接照明），同时不以其他方式影响灯光的渲染结果，那么Light.BakeModeIndirect通常是“安全”的选择。在此模式下，渲染器将继续使用标准实时技术执行所有照明，包括漫反射、镜面反射、天空/环境贡献以及此灯光的阴影映射。然而，使用预烘焙数据，光线将有助于间接照明，可能会导致照明表面不受标准实时照明计算的影响。
  • Light.BakeModeAll is an option which will likely be used for certain lights only, based on the designers' evaluation for what is deemed appropriate for a given scene. In this mode all contribution from the light is baked, including shadows. As of Qt 6.4 specular lighting are not supported as part of the baked lighting, so such lights will not have specular contributions. They will, on the other hand generate raytraced, baked shadows and have proper occlusion for the light (will not "pass through walls", for instance) since here all the direct lighting contributions resulting from the light are raytraced at lightmap baking time, instead of being calculated at run time. In addition, indirect lighting is baked, just as with BakeModeIndirect.
  • Light.BakeModeAll是一个选项，根据设计师对给定场景的评估，它可能仅用于某些灯光。在此模式下，将烘焙灯光的所有贡献，包括阴影。从Qt 6.4开始，镜面照明不支持作为烘焙照明的一部分，因此此类灯光将不会有镜面反射贡献。另一方面，它们将生成光线追踪的烘焙阴影，并对光线进行适当的遮挡（例如，不会“穿过墙壁”），因为在这里，光线产生的所有直接照明贡献都是在光照贴图烘焙时进行光线追踪的，而不是在运行时计算的。此外，间接照明是烘焙的，就像BakeModeIndirect一样。
• Running the scene (application) in baking mode, ensuring lightmaps are successfully generated. As of Qt 6.4, applications are expected to be structured in a way that the lightmapped scene is the first view shown, or that the scene in question can be loaded up with a QML viewer such as the qml tool. Once baking completes, the progress of which can be followed on the console/debug output, the application exits.
• 在烘焙模式下运行场景（应用程序），确保成功生成光照贴图。从Qt 6.4开始，应用程序的结构应使光照贴图场景是显示的第一个视图，或者可以用QML查看器（如QML工具）加载所讨论的场景。一旦烘焙完成，可以在控制台/调试输出上跟踪烘焙的进度，应用程序就会退出。
• Running the scene (application) normally, to see how it looks with the lightmaps loaded. The tuning can then begin:
• 正常运行场景（应用程序），查看加载光照贴图后的外观。然后可以开始调谐：
  • For some models it will make sense to reduce lightmapBaseResolution from the default 1024 to something smaller. This applies especially to the built-in primitives and anything with simple enough geometry. This leads to smaller lightmaps and faster bake times. When baking the first time, the default should be sufficient, the value can be tuned afterwards.
  • ​对于某些型号，将lightmapBaseResolution从默认的1024降低到更小的值是有意义的。这尤其适用于内置图元和任何具有足够简单几何体的对象。这会导致更小的光照贴图和更快的烘焙时间。第一次烘焙时，默认值应该足够了，之后可以调整值。
  • The Lightmapper object exposes numerous settings that have reasonable defaults, but it is not unlikely that some of these will need to be tuned to match the designers' expectation. For example, samples and bounces can be changed to affect the quality of indirect lighting, while indirectLightFactor allows making the indirect contribution more prominent. If artifacts, in particular around shadows, occur, bias can be fine-tuned.
  • ​Lightmapper对象公开了许多具有合理默认值的设置，但其中一些设置需要调整以符合设计师的期望。例如，可以更改采样和反弹以影响间接照明的质量，而indirectLightFactor允许使间接贡献更加突出。如果出现伪影，特别是阴影周围的伪影，可以对偏差进行微调。
  • Denoising the generate lightmaps is essential. Indirect lighting is calculated using path tracing, which produces noisy images depending on the number of the samples used. Increasing the sample count reduces noise, but increases the time needed to generate the lightmap. Regardless of the sample count, it will almost always make sense to run a denoiser on the generated lightmaps, which are 32-bit RGBA floating point images stored in as .exr files.
  • ​对生成的光照贴图进行去噪至关重要。间接照明是使用路径跟踪计算的，路径跟踪会根据所使用的样本数量产生噪声图像。增加采样数可以减少噪声，但会增加生成光照贴图所需的时间。无论样本数量如何，对生成的光照贴图运行去噪器几乎总是有意义的，这些光照贴图是以.exr文件存储的32位RGBA浮点图像。

As of Qt 6.5, a runtime solution is provided interactively through the DebugView. Under Tools there is now a button that when pressed will trigger the baking process. A window will pop up showing the current process. Canceling can be done by either hitting the cancel button or closing this window. When complete, it will try to overwrite the existing .exr files if possible using the loadPrefix, else they will be written to the current directory. For now, Denoising is still a manual process even when using the runtime solution.

​从Qt 6.5开始，通过DebugView交互式地提供运行时解决方案。在“工具”下，现在有一个按钮，按下后将触发烘焙过程。将弹出一个窗口，显示当前进程。点击取消按钮或关闭此窗口即可取消。完成后，如果可能的话，它将尝试使用loadPrefix覆盖现有的.exr文件，否则它们将被写入当前目录。目前，即使使用运行时解决方案，去噪仍然是一个手动过程。

Denoising

去噪

Below is an example of a Cornell box scene, rendered first using the lightmap baked with 256 samples and a maximum of 3 bounces. In the second example, the generated image file has been run through a denoiser using the Open Image Denoise library. The results look significantly better, with the noise mostly gone.

​下面是一个康奈尔盒子场景的示例，首先使用256个样本和最多3次反弹的光照贴图进行渲染。在第二个示例中，生成的图像文件已经使用Open image Denoise库通过去噪器运行。结果看起来好多了，噪音基本消失了。

Original

原图

Denoised

去噪图

A simple, Qt-based command-line wrapper for OIDN that works with the Qt Quick 3D-generated qlm_*.exr images is available at Laszlo Agocs / qlmdenoiser · GitLab. It currently needs to be built from source and no pre-built binaries are available.

​Laszlo Agocs/qlmdenoiser·GitLab提供了一个简单的基于Qt的OIDN命令行包装器，可与Qt Quick 3D生成的qlm_*.exr图像配合使用。它目前需要从源代码构建，没有预构建的二进制文件可用。

Lightmap UVs

Lightmap UV coordinates do not use the same UV data as regular texturing. When rendering with lightmaps, neither the UV0 nor UV1 data is used by the renderer when sampling the lightmap. Instead, there is an additional, dedicated UV channel in the mesh, containing UV charts laid out in a manner that is suitable for the purposes of lightmapping. This involves avoiding overlaps and having padding where appropriate. For regular UV data there are no such requirements, and one may very well want to use the same U and V coordinates for more than one vertex.

光照贴图UV坐标不使用与常规纹理相同的UV数据。使用光照贴图渲染时，渲染器在采样光照贴图时既不使用UV0也不使用UV1数据。相反，网格中有一个额外的专用UV通道，其中包含以适合光照贴图的方式布局的UV图表。这涉及避免重叠，并在适当的情况下进行填充。对于常规UV数据，没有这样的要求，人们很可能希望对多个顶点使用相同的U和V坐标。

The process of generating a suitable UV set is called lightmap UV unwrapping. Qt is always able to perform this at run (load) time, both when baking lightmaps and also when rendering a scene normally.

生成合适的UV集的过程称为光照贴图UV展开。Qt始终能够在运行（加载）时执行此操作，无论是在烘焙光照贴图时，还是在正常渲染场景时。

In order to improve mesh load times by avoiding generating lightmap UV data for lightmapped models at run time, there are two options:

为了通过避免在运行时为光照贴图模型生成光照贴图UV数据来缩短网格加载时间，有两种选择：

• For models without lightmap UV data available the lightmap baking process also outputs a set of qlm_*.mesh files, the names generated based on the BakedLightmap::key, similarly to the with the .exr images. If the application wishes to, it can ship these extra .mesh files together with the .exr assets. When present, these mesh files will be used in place of the regular model data, with the lightmapping related data readily available. This is completely optional, however. When no qlm_key.mesh is found at run time, the UV unwrapping is done at run time, transparently to the application.
• ​对于没有可用光照贴图UV数据的模型，光照贴图烘焙过程还会输出一组qlm_*.mesh文件，这些文件的名称基于BakedLightmap::key生成，与.exr图像类似。如果应用程序愿意，它可以将这些额外的.mesh文件与.exr资产一起发送。当存在时，这些网格文件将用于代替常规模型数据，光照贴图相关数据随时可用。然而，这完全是可选的。当在运行时找不到qlm_key.mesh时，UV解包将在运行时完成，对应用程序透明。
• Alternatively, the balsam tool offers the option to pre-generate the lightmap UV data at asset import time. This means that the model's .mesh file will contain the necessary data right from the start, and no extra meshes will be generated during lightmap baking time, and so there are no extra assets to ship with the application (apart from the lightmap images, of course). To do this, pass --generateLightmapUV to balsam.
• ​或者，balsam工具提供在资源导入时预生成光照贴图UV数据的选项。这意味着模型的.mesh文件将从一开始就包含必要的数据，在光照贴图烘焙期间不会生成额外的网格，因此应用程序中没有额外的资源（当然，除了光照贴图图像）。为此，将--generateLightmapUV传递给balsam。

Lightmap texture size

光照贴图纹理大小

For each model, including all its submeshes, the lightmap baking process will determine a suitable lightmap texture size during the lightmap UV generation phase. This has an impact on quality, performance, and resource usage (both on disk and in memory).

对于每个模型，包括其所有子表，光照贴图烘焙过程将在光照贴图UV生成阶段确定合适的光照贴图纹理大小。这会影响质量、性能和资源使用（包括磁盘和内存）。

The default is often suitable and needs no adjustment, especially for models with medium to high complexity.

默认值通常是合适的，不需要调整，特别是对于中高复杂度的模型。

For very simple models it may be desirable to manually reduce the size, however, because a smaller lightmap size could still provide visually good looking results, while reducing the asset (lightmap image) sizes saves both disk space and memory. To do this, set the lightmapBaseResolution to a suitably small number. Common choices are 256, 512, or 1024, but it could be another number as well, with 128 as the minimum. The actual lightmap width and height will likely be different, but in approximately the same ballpark as the specified size.

​然而，对于非常简单的模型，可能需要手动减小大小，因为较小的光照贴图大小仍然可以提供视觉上好看的结果，而减小资产（光照贴图图像）大小可以节省磁盘空间和内存。为此，请将lightmapBaseResolution设置为适当小的数字。常见的选择是256、512或1024，但也可以是另一个数字，最小值为128。实际的光照贴图宽度和高度可能不同，但与指定尺寸大致相同。

When changing the value, one should always rebake the lightmaps and visually inspect the results in order to evaluate the effects of the changed lightmap size.

更改值时，应始终重新绘制光照贴图并目视检查结果，以评估更改后的光照贴图大小的效果。

Using Lightmaps at Run-Time

在运行时使用Lightmaps

Properties and types relevant when using the pre-baked lightmaps at run time:

在运行时使用预烘焙光照贴图时相关的属性和类型：

• Light::bakeMode,
• BakedLightmap and Model::bakedLightmap

Once the baking has successfully completed, running the application normally (without the command-line argument or environment variable set) will now pick up the generated lightmap images and render correctly, which is not possible until the lightmaps have been baked first. If desired, the application can place those in a different location, or ship them as part of the executable via the Qt Resource System. This is enabled by the BakedLightmap::loadPrefix property.

​烘焙成功完成后，正常运行应用程序（不设置命令行参数或环境变量）现在将拾取生成的光照贴图图像并正确渲染，这在光照贴图首先烘焙之前是不可能的。如果需要，应用程序可以将它们放置在不同的位置，或者通过Qt资源系统将它们作为可执行文件的一部分运送。这是通过BakedLightmap::loadPrefix属性启用的。

Taking the example code with the sphere and four rectangles from above, the baking process generates five .exr files (qlm_sphere1.exr, qlm_rect1.exr, qml_rect2.exr, etc.), and a list file qlm_list.txt which is useful as input for denoising utilities that support processing multiple files in one go but is not used at runtime otherwise. The application needs to ship the .exr files, so that they can be found by the engine, either in the same directory as the containing component, or in the location specified by the loadPrefix.

​以上面带有球体和四个矩形的示例代码为例，烘焙过程生成五个.exr文件（qlm_sphere1.exr、qlm_rect1.exr和qml_rect2.exr等），以及一个列表文件qlm_list.txt，该文件可用作去噪实用程序的输入，该实用程序支持一次处理多个文件，但在运行时不使用。应用程序需要提供.exr文件，以便引擎可以在与包含组件相同的目录中或loadPrefix指定的位置找到它们。

The loading rules also apply to the optional .mesh files, such as qlm_sphere1.mesh or qlm_rect1.mesh. If the application wishes to accelerate the scene load times, it should ship these extra .mesh files next to the .exr lightmap images.

加载规则也适用于可选的.mesh文件，如qlm_sphere1.mesh或qlm_rect1.mesh。如果应用程序希望加快场景加载时间，则应将这些额外的.mesh文件放在.exr光照贴图图像旁边。

See also Qt Quick 3D - Baked Lightmap Example.

​另请参阅Qt Quick 3D-烘焙光图示例。

Custom Material EditorShadow Mapping

© 2024 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.