Cartes d'éclairage et éclairage global
Introduction
Remarque : à partir de Qt 6.4, la cuisson des lightmaps est en phase de prévisualisation technologique précoce. Des modifications concernant les fonctionnalités, la qualité et l’API sont susceptibles d’intervenir dans les prochaines versions.
Les lightmaps cuites permettent de pré-générer l’éclairage direct provenant de lumières telles que DirectionalLight, PointLight et SpotLight, y compris les ombres projetées par ces lumières. Au moment de l’exécution, au lieu d’effectuer les calculs appropriés dans le shader de fragment et, dans le cas des ombres, de générer en temps réel des cartes d’ombres potentiellement coûteuses, on échantillonne plutôt la carte d’image pré-générée.
Une carte d’éclairage est générée par Model. Même si une Model comporte plusieurs sous-maillages et est donc associée à plusieurs matériaux, une seule image de carte d’éclairage sera générée pour l’ensemble du modèle.
Les lightmaps sont générées à l’aide du ray tracing, qui, de par sa nature, assure une occlusion correcte (« la lumière ne traverse pas les murs ») et offre éventuellement des ombres plus réalistes que les techniques en temps réel d’éclairage et de mappage d’ombres.
Plus important encore, les lightmaps permettent également de « cuire » l’éclairage indirect, offrant ainsi une solution pour l’éclairage global. Ce processus prend en compte les rayons lumineux réfléchis par d’autres surfaces de la scène.
Voici un exemple simple. La scène contient quatre modèles « Rectangle » et un modèle « Sphere », avec une source lumineuse « DirectionalLight » orientée vers le bas et un « PointLight ». Les modèles « Rectangle » sont pivotés de 0 et 90 degrés, ce qui accentue les limites des calculs d’éclairage en temps réel, car ils sont tous soit parallèles, soit perpendiculaires à la direction de la source « DirectionalLight ».
Sur la deuxième image, la scène est rendue avec le lightmapping activé, après avoir cuit les lightmaps pour les cinq modèles. Les deux lumières sont réglées sur « entièrement cuites », ce qui signifie que l’éclairage direct et indirect est cuit. L'éclairage indirect utilise 256 samples et un maximum de 3 bounces. Les lightmaps obtenues ont ensuite été débruitées. Cela donne une image nettement plus réaliste.
Éclairage en temps réel

Éclairage entièrement cuit

Vous trouverez ci-dessous un extrait de code illustrant comment les résultats avec lightmaps ont été obtenus. La différence réside dans les propriétés usedInBakedLighting, bakeMode et bakedLightmap. Dans cet exemple, la taille de la lightmap a été réduite à l’aide de la propriété texelsPerUnit, afin d’économiser de l’espace disque et de réduire les temps de chargement de l’application.
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
bakedLightmap: BakedLightmap {
enabled: true
key: "sphere1"
}
source: "#Sphere"
materials: PrincipledMaterial { }
y: 100
}
Model {
usedInBakedLighting: true
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 -90L’exemple ci-dessus utilise des lumières entièrement précalculées. Une lumière peut également être configurée pour n’utiliser l’éclairage précalculé que pour l’éclairage indirect, tout en effectuant l’éclairage direct et le mappage des ombres en temps réel. Dans la scène ci-dessous, il y a 5 lumières ponctuelles, toutes configurées sur « BakeModeIndirect » pour la deuxième capture d’écran. Bien que l’éclairage direct et les ombres semblent identiques, la deuxième image est nettement plus réussie grâce à l’ajout d’un certain degré d’éclairage global.
Éclairage en temps réel

Avec ajout d’un éclairage indirect précalculé

Considérations importantes lors de l’utilisation des lightmaps
Les lumières contribuant à l’éclairage précalculé ont leur propriété « bakeMode » définie soit sur « Light.BakeModeIndirect », soit sur « Light.BakeModeAll ». Cette dernière option indique que les contributions directes et indirectes de cette lumière particulière proviennent toutes deux de la carte d’ombres. La contribution directe inclut toujours les ombres également. En revanche, si l’objectif de la carte d’éclairage est uniquement d’ajouter un éclairage indirect à la scène pour une lumière particulière, tout en conservant le calcul de l’éclairage direct (et le mappage des ombres) en temps réel, alors la lumière doit plutôt utiliser la valeur « Light.BakeModeIndirect ».
Remarque : les lightmaps conviennent généralement aux modèles statiques en termes de transformation, de géométrie et de matériaux. Il en va de même pour les lumières participant à l’éclairage cuit.
Par exemple, une scène qui fait pivoter un « Model » en animant la propriété « eulerRotation » donnera des résultats visuellement incorrects lors de l’application d’une carte d’éclairage à ce « Model ». Les résultats de rendu pour ce « Model » particulier seront incorrects, car la carte d’éclairage pré-générée ne capture qu’un seul état de rotation pour l’objet. Il en irait de même, pour prendre un autre exemple, si le matériau d'un des sous-maillages du modèle modifiait dynamiquement sa propriété « baseColor » en fonction du temps (animation) ou d’une interaction de l’utilisateur. La lightmap ne peut capturer qu’une seule é baseColor du matériau. Il en va de même pour les lumières. Par exemple, une DirectionalLight qui tourne, change de luminosité, de couleur, etc. au fil du temps, ne se prête pas à l’éclairage « baked ».
Remarque : d’un autre côté, le choix d’utiliser ou non le lightmapping relève toujours du concepteur. En particulier avec les lumières BakeModeIndirect, il est probable qu’il existe des scènes où les résultats restent visuellement satisfaisants, même si certains objets de la scène soumise au lightmapping présentent un comportement dynamique.
Le lightmapping est une fonctionnalité complexe du moteur et de l’environnement de développement. Il remplace et réimplémente plusieurs éléments du pipeline de rendu du moteur. Il fonctionne avec un modèle de rendu fondamentalement différent lors de la cuisson des lightmaps, tout en continuant à utiliser et à interagir avec la même structure de scène, les mêmes données d’actifs et les mêmes structures de données du moteur. Les résultats basés sur le ray tracing surpasseront souvent les alternatives en temps réel, parfois de manière significative, ce qui s’accompagne toutefois de certaines contraintes, telles que le caractère statique obligatoire des modèles et des lumières concernés, ainsi que, parfois, des problèmes de qualité et d’artefacts de rendu spécifiques au lightmapping.
Dans la pratique, le choix du type d’éclairage à utiliser, et à quel moment, relèvera d’une décision artistique des concepteurs. Les trois paramètres d’ bakeMode s ont chacun leur utilité, et les scènes complexes et de grande envergure peuvent très bien les utiliser tous les trois pour différents éclairages, en fonction de ce qui est jugé approprié pour une section donnée de la scène, ainsi que du type de modèles, de matériaux et de comportements dynamiques présents. Le lightmapping n’est pas un simple interrupteur de type « marche/arrêt » pouvant être activé pour n’importe quelle scène ou application, mais une fonctionnalité puissante qui suppose une évaluation minutieuse des besoins en éclairage d’une scène donnée, et qui nécessite souvent que le contenu et le comportement de la scène soient conçus en conséquence, en combinaison avec un cycle d’essais et d’ajustements au cours duquel différents paramètres de cuisson et de qualité des lightmaps sont explorés et testés avant de choisir l’approche finale et les réglages associés.
Remarque : les lightmaps ne prennent pas en charge les surfaces à double face. Avec l'éclairage en temps réel, un matériau dont l'cull mode e est définie sur « Material.NoCulling » inverse automatiquement la normale en fonction de l'orientation du fragment. Cette fonctionnalité n'est pas disponible pour les lightmaps, car la cuisson des lightmaps ne s'effectue pas dans l'espace de vue. Par conséquent, évitez d'utiliser l'éclairage cuit pour les modèles qui en dépendraient.
Cuisson des lightmaps
Propriétés et types pertinents pour le « baking » des lightmaps, c’est-à-dire le processus hors ligne de génération des cartes d’images qui capturent l’éclairage direct et indirect et peuvent être utilisées par le moteur de rendu lors des exécutions ultérieures de l’application :
- Model::usedInBakedLighting
- Model::lightmapBaseResolution,
- Light::bakeMode,
- Lightmapper et SceneEnvironment::lightmapper
- BakedLightmap et Model::bakedLightmap
À partir de Qt 6.4, le processus de « baking » des lightmaps doit être déclenché manuellement. Dès que l'argument de ligne de commande ` --bake-lightmaps ` est présent, ou que la variable d'environnement ` QT_QUICK3D_BAKE_LIGHTMAPS ` est définie sur ` 1 ` (ou une autre valeur non nulle), le moteur fonctionne en mode « baking » et quitte l'application une fois le « baking » terminé. Il est possible de suivre les étapes du processus de cuisson en consultant les messages affichés dans la sortie de débogage. Le résultat est un fichier binaire (lightmaps.bin par défaut) enregistré dans le répertoire de travail actuel et contenant toutes les cartes de lumière cuites de la scène. Un fichier « .raw » sera également créé ; il contient la lightmap complète ainsi que des données supplémentaires nécessaires au débruitage. Chaque lightmap est identifiée de manière unique dans le fichier par la clé unique issue de BakedLightmap::key.
La préparation d’une scène avec lightmaps s’effectue selon les étapes principales suivantes :
- Identifier les modèles qui doivent utiliser une carte de lumière et ceux qui doivent y contribuer. Les modèles faisant partie de la scène avec carte de lumière doivent définir Model::usedInBakedLighting sur true. Les modèles pour lesquels une carte de lumière est générée (c’est-à-dire pour lesquels une carte de lumière doit être cuite) doivent en outre définir ` Model::bakedLightmap ` sur un objet ` BakedLightmap ` activé, qui fournit une clé unique permettant d’identifier de manière persistante l’instance particulière de l’objet `Model` (en effet, Qt a besoin d’une clé pour identifier les données du modèle dans le stockage persistant sur disque). Seuls les modèles dont la géométrie, la transformation et les matériaux sont statiques sont garantis de produire des résultats corrects lors de la création d’une carte d’éclairage à l’exécution. En général, tout ce qui entraîne une transformation du monde non statique au fil du temps, comme une position, une rotation ou une échelle modifiée dynamiquement ou animée, rendra le modèle inéligible. Les impératifs artistiques peuvent toutefois prévaloir, en particulier pour les modèles qui ne contribuent qu’à l’éclairage indirect précalculé mais ne font pas eux-mêmes l’objet d’un lightmapping. Pour ceux-ci, il peut souvent être visuellement acceptable d’avoir des transformations dynamiques, mais cela dépend toujours du modèle et de la scène en question.
- Déterminez quelles lumières doivent contribuer, et dans quelle mesure. L’option « Light::bakeMode » propose trois possibilités :
- Light.BakeModeDisabled, la valeur par défaut, qui fait en sorte que la lumière soit ignorée pour tout ce qui concerne le lightmapping.
- Light.BakeModeIndirect est souvent le choix « sans risque », si le seul objectif est d’obtenir un niveau d’éclairage global (éclairage indirect) dans la scène, sans affecter les résultats de rendu de la lumière d’une autre manière. Dans ce mode, le moteur de rendu continuera à effectuer tous les calculs d’éclairage, y compris les contributions diffuses, spéculaires, du ciel et de l’environnement, ainsi que le mappage des ombres pour cette lumière, en utilisant les techniques standard en temps réel. Cependant, la lumière contribuera à l’éclairage indirect à l’aide des données précalculées, ce qui peut entraîner l’éclairage de surfaces qui, autrement, ne seraient pas affectées par les calculs d’éclairage standard en temps réel.
- Light.BakeModeAll est une option qui ne sera probablement utilisée que pour certaines lumières, en fonction de l’évaluation des concepteurs quant à ce qui est jugé approprié pour une scène donnée. Dans ce mode, toutes les contributions de la lumière sont précalculées, y compris les ombres. À partir de Qt 6.4, l’éclairage spéculaire n’est pas pris en charge dans le cadre de l’éclairage précalculé ; ces lumières n’auront donc pas de contribution spéculaire. En revanche, elles généreront des ombres cuites par lancer de rayons et présenteront une occlusion correcte pour la lumière (elles ne « traverseront pas les murs », par exemple), car ici toutes les contributions d’éclairage direct résultant de la lumière sont calculées par lancer de rayons au moment de la cuisson de la carte d’éclairage, au lieu d’être calculées au moment de l’exécution. De plus, l’éclairage indirect est cuit, tout comme avec le mode BakeModeIndirect.
- Exécutez la scène (l’application) en mode de cuisson pour vous assurer que les lightmaps sont correctement générées. À partir de Qt 6.4, les applications doivent être structurées de manière à ce que la scène avec lightmaps soit la première vue affichée, ou que la scène en question puisse être chargée à l’aide d’un visualiseur QML tel que l’outil
qml. Une fois la cuisson terminée (dont la progression peut être suivie sur la console ou dans les sorties de débogage), l’application se ferme. - Exécutez la scène (l'application) normalement pour voir à quoi elle ressemble une fois les lightmaps chargées. Le réglage peut alors commencer :
- Pour certains modèles, il sera judicieux de réduire la valeur par défaut de ` texelsPerUnit ` à une valeur inférieure. Cela s'applique en particulier aux primitives intégrées et à tout élément présentant une géométrie suffisamment simple. Cela permet d'obtenir des lightmaps plus petites et des temps de cuisson plus courts. Lors de la première cuisson, la valeur par défaut devrait être suffisante ; elle pourra être ajustée par la suite.
- L’objet Lightmapper propose de nombreux paramètres dont les valeurs par défaut sont raisonnables, mais il n’est pas rare que certains d’entre eux doivent être ajustés pour répondre aux attentes des concepteurs. Par exemple, les paramètres « samples » et « bounces » peuvent être modifiés pour influencer la qualité de l’éclairage indirect, tandis que « indirectLightFactor » permet de rendre la contribution indirecte plus marquée. Si des artefacts apparaissent, en particulier autour des ombres, le paramètre « bias » peut être ajusté avec précision.
- Le débruitage des lightmaps générées est essentiel. L’éclairage indirect est calculé à l’aide du traçage de chemin, ce qui produit des images bruitées en fonction du nombre d’ samples s utilisées. Augmenter le nombre d’échantillons réduit le bruit, mais augmente le temps nécessaire à la génération de la lightmap. Quel que soit le nombre d’échantillons, il est presque toujours judicieux d’appliquer un débruiteur aux lightmaps générées, qui sont des images RGBA 32 bits en virgule flottante stockées dans un fichier binaire.
À partir de Qt 6.5, une solution d’exécution est fournie de manière interactive via l’ DebugView. Sous « Outils », un bouton permet désormais de lancer le processus de « baking ». Une fenêtre s’affiche alors pour indiquer l’avancement du processus. Pour annuler l’opération, il suffit d’appuyer sur le bouton « Annuler » ou de fermer cette fenêtre. Une fois le processus terminé, le fichier binaire de la carte de lumière sera enregistré dans le répertoire courant.
Débruitage
Vous trouverez ci-dessous un exemple de scène représentant une boîte de Cornell, d’abord rendue à l’aide de la carte de lumière cuite avec 256 samples et un maximum de 3 bounces. Dans le deuxième exemple, le fichier image généré a été débruité, et les résultats sont nettement meilleurs, le bruit ayant en grande partie disparu.
Original

Dénoyé

Le débruitage s’effectue automatiquement sur chaque lightmap cuite. Il est possible de ne procéder qu’au débruitage, si un fichier de lightmap cuite existant ( .raw ) se trouve dans le répertoire de travail, en cliquant sur le bouton « Denoise » dans l’ DebugView. Il est également possible de débruiter en appelant l’application avec l’argument « --denoise-lightmaps ». Pour ajuster l’intensité du débruitage, la propriété « denoiseSigma » peut être utilisée.
Coordonnées UV des lightmaps
Les coordonnées UV des lightmaps n’utilisent pas les mêmes données UV que la texturation classique. Lors du rendu avec des lightmaps, ni les données UV0 ni les données UV1 ne sont utilisées par le moteur de rendu lors de l’échantillonnage de la lightmap. À la place, il existe un canal UV supplémentaire dédié dans le maillage, contenant des cartes UV disposées de manière adaptée aux besoins du lightmapping. Cela implique d’éviter les chevauchements et de prévoir un remplissage lorsque cela est nécessaire. Pour les données UV classiques, de telles exigences n’existent pas, et l’on peut très bien souhaiter utiliser les mêmes coordonnées U et V pour plusieurs sommets.
Le processus de génération d'un ensemble UV adapté est appelé « dépliage UV pour les lightmaps ». Qt effectuera cette opération lors de la cuisson des lightmaps et stockera le maillage résultant dans le fichier de lightmaps, de sorte qu’un maillage compatible soit toujours chargé et utilisé pour la lightmap générée. Cela signifie que, si un modèle utilise systématiquement un éclairage cuit, le fichier de maillage source n’a pas besoin d’être fourni avec l’application.
Taille de la texture de la carte de lumière
Pour chaque modèle, y compris tous ses sous-maillages, le processus de cuisson des lightmaps déterminera une taille de texture de lightmap adaptée lors de la phase de génération des UV de la lightmap. Cela a un impact sur la qualité, les performances et l’utilisation des ressources (tant sur le disque qu’en mémoire).
La valeur par défaut est souvent adaptée et ne nécessite aucun ajustement, en particulier pour les modèles de complexité moyenne à élevée.
Pour les modèles très simples, il peut toutefois être souhaitable de réduire manuellement cette taille, car une lightmap plus petite peut tout de même offrir de bons résultats visuels, tandis que la réduction de la taille des ressources (image de lightmap) permet d’économiser à la fois de l’espace disque et de la mémoire. Pour ce faire, définissez la valeur « texelsPerUnit » sur un nombre suffisamment petit. La largeur et la hauteur réelles de la lightmap tenteront alors, en fonction de la taille et de la géométrie du modèle, de se rapprocher de la densité de texels afin qu’elle corresponde à texelsPerUnit.
Lorsque vous modifiez cette valeur, il est recommandé de toujours recalculer les lightmaps et d’inspecter visuellement les résultats afin d’évaluer les effets de la nouvelle taille de lightmap.
Utilisation des lightmaps lors de l’exécution
Propriétés et types pertinents lors de l’utilisation des lightmaps pré-calculées en exécution :
Une fois le calcul terminé, l'exécution normale de l'application (sans argument de ligne de commande ni variable d'environnement définie) utilisera désormais les images de lightmap générées et les affichera correctement, ce qui n'est pas possible tant que les lightmaps n'ont pas été calculées au préalable. Si vous le souhaitez, l'application peut les placer à un autre emplacement, ou les intégrer à l'exécutable via le système de ressources Qt. Cette fonctionnalité est activée par la propriété source.
Si l’on reprend l’exemple de code ci-dessus avec la sphère et les quatre rectangles, le processus de « baking » génère un fichier « lightmaps.bin » contenant tous les maillages et lightmaps cuits. L’application doit inclure ce fichier, afin qu’il puisse être trouvé par le moteur, à l’emplacement spécifié par « source ».
Voir également Qt Quick 3D - Exemple de lightmap cuite et Qt Quick 3D - Exemple de lightmap SSGI.
© 2026 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.