Sur cette page

Qt Quick Architecture 3D

Qt Quick La 3D étend Qt Quick pour prendre en charge le rendu de contenu 3D. Elle ajoute de nombreuses fonctionnalités, notamment plusieurs nouvelles importations QML publiques, ainsi qu’un nouveau graphe de scène et un nouveau moteur de rendu internes. Ce document décrit l’architecture de Qt Quick 3D, depuis l’API publique jusqu’aux détails du fonctionnement du pipeline de rendu.

Présentation du module

Qt Quick La 3D se compose de plusieurs modules et plugins qui exposent les API 3D supplémentaires ainsi que des utilitaires permettant de préparer et d’importer des ressources 3D existantes.

Importations QML

  • QtQuick3D - L’import principal, qui contient tous les composants essentiels d’ Qt Quick 3D
  • QtQuick3D.AssetUtils - Une bibliothèque permettant d’importer des ressources 3D lors de l’exécution
  • QtQuick3D.Helpers - Une bibliothèque de composants supplémentaires pouvant être utilisés pour faciliter la conception et le débogage de scènes 3D.

Bibliothèques C++

  • QtQuick3D - Le seul module C++ public. Il contient les définitions de tous les types exposés à l'importation QML d'QtQuick3D, ainsi que quelques API C++
  • QtQuick3DAssetImport - Une bibliothèque interne et privée facilitant l'importation et la conversion des ressources au format QML.
  • QtQuick3DRuntimeRender - Bibliothèque interne et privée contenant les nœuds du graphe de scène spatiale et le moteur de rendu.
  • QtQuick3DUtils - Une bibliothèque interne et privée utilisée comme bibliothèque d’utilitaires commune par tous les autres modules C++.

Plug-ins AssetImporters

Les outils d’importation de ressources sont implémentés à l’aide d’une architecture basée sur des plugins. Les plugins fournis avec Qt Quick 3D étendent les fonctionnalités de la bibliothèque et de l’outil d’importation de ressources, Balsam.

  • Assimp - Ce plugin utilise la bibliothèque tierce libAssimp pour convertir des ressources 3D dans des formats d'échange 3D en composants QML d'Qt Quick 3D.

Comment Qt Quick 3D s'intègre-t-il dans la pile graphique Qt ?

Schéma de l'architecture de la pile graphique <span translate=Qt Quick 3D" src="images/quick3d-graphics-stack.drawio.svg" title="Schéma de l'architecture de la pile graphique Qt Quick 3D"/>

Le diagramme ci-dessus illustre la manière dont Qt Quick 3D s’intègre dans la pile graphique Qt au sens large. Qt Quick 3D fonctionne comme une extension de l’API 2D Qt Quick, et lorsque des éléments de scène 3D sont utilisés conjointement avec View3D, la scène est rendue via l’interface matérielle de rendu Qt (RHI). La RHI traduira les appels d’API en appels d’API matériels de rendu natifs adaptés à une plateforme donnée. Le schéma ci-dessus présente les options disponibles pour chaque plateforme. Si aucun backend natif n’est explicitement défini, Qt Quick choisira par défaut un backend natif adapté au rendu pour chaque plateforme.

L’intégration entre les composants 3D de la pile Qt Quick et la pile Qt Quick est décrite ci-dessous dans les sections suivantes.

Intégration 3D en 2D

L’affichage de contenu 3D en 2D est l’objectif principal de l’API 3D d’ Qt Quick. L’interface principale permettant d’intégrer du contenu 3D en 2D est le composant View3D.

Le composant ` View3D ` fonctionne comme n’importe quelle autre classe dérivée de ` QQuickItem ` contenant du contenu et implémente la fonction virtuelle ` QQuickItem::updatePaintNode`. ` Qt Quick ` appelle `updatePaintNode` pour tous les éléments « modifiés » du graphe de scène ` Qt Quick ` pendant la phase de synchronisation. Cela inclut les éléments 3D gérés par un ` View3D`, qui subissent également leur phase de synchronisation à la suite de l’appel à `updatePaintNode`.

La méthode `updatePaintNode` de ` View3D ` effectue les actions suivantes :

  • Configurer un moteur de rendu et une cible de rendu s’ils n’existent pas déjà
  • Synchronise les éléments de la scène 3D via SceneManager
  • Mettre à jour toutes les textures « dynamiques » qui ont été rendues par Qt Quick (2D dans le chemin de texture 3D ci-dessous)

Le rendu de la scène 3D n’a toutefois pas lieu dans la méthode `updatePaintNode` d’ View3D. À la place, `updatePaintNode` renvoie une sous-classe de ` QSGNode ` contenant le moteur de rendu pour Qt Quick 3D, qui se chargera de rendre la scène 3D pendant la phase de prétraitement du processus de rendu d’ Qt Quick.

La mise en œuvre du rendu 3D d’ Qt Quick dépend de l’ View3D::renderMode utilisé :

Hors écran

Le mode par défaut d’ View3D est « Offscreen ». En mode hors écran, View3D devient un fournisseur de textures en créant une surface hors écran et en y effectuant le rendu. Cette surface peut être mappée en tant que texture dans Qt Quick et rendue à l’aide d’un QSGSimpleTextureNode.

Ce modèle est très proche du fonctionnement actuel des QSGLayerNodes dans Qt Quick.

Sous-couche

Lorsque l’on utilise le mode Underlay, la scène 3D est directement rendue sur l’ QQuickWindow contenant l’ View3D. Le rendu a lieu à la suite du signal QQuickWindow::beforeRenderPassRecording(), ce qui signifie que tout le reste de Qt Quick sera rendu par-dessus le contenu 3D.

Superposition

Lorsque vous utilisez le mode « Overlay », la scène 3D est directement affichée dans l’ QQuickWindow contenant l’ View3D. L’affichage se produit à la suite du signal QQuickWindow::afterRenderPassRecording(), ce qui signifie que le contenu 3D sera affiché par-dessus tout le reste du contenu de Qt Quick.

Inline

Le mode de rendu « Inline » utilise QSGRenderNode, ce qui permet un rendu direct vers la cible de rendu de Qt Quick sans passer par une surface hors écran. Pour ce faire, il injecte les commandes de rendu en ligne pendant le rendu 2D de la scène Qt Quick.

Ce mode peut poser problème car il utilise le même tampon de profondeur que le moteur de rendu Qt Quick, et les valeurs z ont une signification complètement différente entre Qt Quick et Qt Quick 3D.

Intégration de la 2D dans la 3D

Lors du rendu d’une scène 3D, il existe de nombreux cas de figure où il est nécessaire d’intégrer des éléments 2D dans la 3D. Il existe deux méthodes différentes pour intégrer du contenu 2D dans des scènes 3D, chacune ayant son propre chemin d’accès à l’écran.

Chemin direct

Le chemin direct est utilisé pour afficher le contenu 2D de type « Qt Quick » comme s’il s’agissait d’un élément plat au sein de la scène 3D. Prenons par exemple la définition de scène suivante :

Node {
    Text {
        text: "Hello world!"
    }
}

Voici ce qui se passe : lorsqu’un composant enfant est placé sur un nœud spatial de type ` QQuickItem`, il est d’abord encapsulé par un `QQuick3DItem2D`, qui n’est qu’un conteneur ajoutant des coordonnées 3D à un élément 2D. Cela définit la transformation 3D de base qui détermine la manière dont tous les éléments enfants 2D suivants seront rendus, afin qu’ils s’affichent correctement dans la scène 3D.

Au moment du rendu de la scène, les QSGNodes de ces éléments 2D sont transmis au moteur de rendu Qt Quick afin de générer les commandes de rendu appropriées. Comme les commandes sont générées en ligne et prennent en compte la transformation 3D actuelle, elles sont rendues exactement de la même manière que dans le moteur de rendu 2D, mais s’affichent comme si elles avaient été rendues en 3D.

L’inconvénient de cette approche est qu’aucune information d’éclairage de la scène 3D ne peut être utilisée pour ombrer le contenu 2D, car le moteur de rendu 2D d’ Qt Quick ne dispose d’aucun concept d’éclairage.

Chemin de texture

Le chemin de texture utilise une scène 2D d’ Qt Quick pour créer du contenu de texture dynamique. Prenons l’exemple de la définition de texture suivante :

Texture {
    sourceItem: Item {
        width: 256
        height: 256
        Text {
            anchors.centerIn: parent
            text: "Hello World!"
        }
    }
}

Cette approche fonctionne de la même manière que les éléments de calque dans Qt Quick: tout est rendu sur une surface hors écran de la taille de l’élément de niveau supérieur, et cette surface hors écran est ensuite utilisable comme une texture pouvant être réutilisée ailleurs.

Cette texture peut ensuite être utilisée par les matériaux de la scène pour rendre du contenu d’ Qt Quick sur les éléments.

Synchronisation de la scène

Gestionnaire de scène

Le gestionnaire de scène dans Qt Quick 3D est chargé de suivre les éléments spatiaux dans une scène 3D et de s’assurer que les éléments mettent à jour leurs nœuds correspondants dans le graphe de scène pendant la phase de synchronisation. Dans Qt Quick, ce rôle est assuré par QQuickWindow pour le cas 2D. Le gestionnaire de scène constitue l’interface principale entre les nœuds du front-end et les objets du graphe de scène du back-end.

Chaque élément d’ View3D dispose d’au moins un gestionnaire de scène, puisqu’un tel gestionnaire est créé et associé à la racine de scène intégrée lors de la construction. Lorsque des nœuds spatiaux sont ajoutés en tant qu’enfants de l’ View3D, ils sont enregistrés auprès du gestionnaire de scène de l’ View3D. Lorsqu’on utilise une scène importée, un deuxième gestionnaire de scène (SceneManager) est créé (ou référencé s’il en existe déjà un) pour gérer les nœuds qui ne sont pas des enfants directs de l’objet « View3D ». Cela est nécessaire car, contrairement à l’objet « View3D », une scène importée n’existe pas sur un « QQuickWindow » tant qu’elle n’est pas référencée. Le SceneManager supplémentaire garantit que les ressources appartenant à la scène importée sont créées au moins une fois par QQuickWindow dans lequel elles sont référencées.

Bien que le gestionnaire de scène soit une API interne, il est important de savoir qu’il est chargé d’appeler la méthode `updateSpatialNode` sur tous les objets qui ont été marqués comme modifiés (dirty) par l’appel de la méthode `update()`.

Synchronisation front-end/back-end

L’objectif de la synchronisation est de s’assurer que les états définis sur le frontend (Qt Quick) correspondent à ceux définis sur le backend (Qt Quick Spatial Scene Graph Renderer). Par défaut, le frontend et le backend s’exécutent dans des threads distincts : le frontend dans le thread principal de Qt, et le backend dans le thread de rendu de Qt Quick. La phase de synchronisation permet au thread principal et au thread de rendu d’échanger des données en toute sécurité. Au cours de cette phase, le gestionnaire de scène appelle la fonction `updateSpatialNode` pour chaque nœud modifié de la scène. Cela permet soit de créer un nouveau nœud de backend, soit de mettre à jour un nœud existant, afin que le moteur de rendu puisse l’utiliser.

Qt Quick Graphique de scène spatiale

Qt Quick La 3D est conçue pour utiliser le même modèle de séparation front-end/back-end que Qt Quick: les objets front-end sont contrôlés par le moteur Qt Quick, tandis que les objets back-end contiennent les données d’état nécessaires au rendu de la scène. Les objets front-end héritent de QObject et sont exposés au moteur Qt Quick. Les éléments des fichiers source QML correspondent directement à des objets front-end.

À mesure que les propriétés de ces objets front-end sont mises à jour, un ou plusieurs nœuds back-end sont créés et placés dans un graphe de scène. Le rendu de scènes 3D impliquant beaucoup plus d’états que le rendu 2D, il existe un ensemble distinct de nœuds de graphe de scène spécialisés pour représenter l’état des objets de la scène 3D. Ce graphe de scène est connu sous le nom de « graphe de scène spatial d’ Qt Quick ».

Les objets du front-end et les nœuds du back-end peuvent tous être classés en deux catégories. Les premiers sont spatiaux, dans le sens où ils existent quelque part dans l’espace 3D. Concrètement, cela signifie que chacun de ces types contient une matrice de transformation. Pour les éléments spatiaux, la relation parent-enfant est importante, car chaque élément enfant hérite de la transformation de ses parents.

L’autre catégorie d’éléments est celle des ressources. Les éléments de type ressource n’ont pas de position dans l’espace 3D, mais correspondent simplement à un état utilisé par d’autres éléments. Il peut exister une relation parent-enfant entre ces éléments, mais celle-ci n’a d’autre signification que celle de la propriété.

Contrairement au graphe de scène 2D présenté sur Qt Quick, le graphe de scène spatial expose directement les nœuds de ressources à l’utilisateur. Ainsi, par exemple, dans Qt Quick, bien que QSGTexture fasse partie de l’API publique, il n’existe pas de QQuickItem qui expose directement cet objet. L’utilisateur doit donc soit utiliser un élément Image, qui décrit à la fois la provenance de la texture et la manière de la rendre, soit écrire du code C++ pour manipuler directement l’ QSGTexture. Dans Qt Quick 3D, ces ressources sont exposées directement dans l’API QML. Cela est nécessaire car les ressources constituent une partie importante de l’état de la scène. Ces ressources peuvent être référencées par de nombreux objets de la scène : par exemple, plusieurs « Materials » pourraient utiliser la même « Texture ». Il est également possible de définir des propriétés d’une « Texture » lors de l’exécution, ce qui modifierait directement la manière dont la texture est échantillonnée, par exemple.

Objets spatiaux

Tous les objets spatiaux sont des sous-classes du composant Node, qui contient les propriétés définissant la position, la rotation et l’échelle dans l’espace 3D.

Objets « Resource »

Les objets « Ressource » sont des sous-classes du composant « Object3D ». « Object3D » est simplement une sous-classe d’« QObject » dotée de quelques aides spéciales destinées à être utilisées avec le gestionnaire de scène. Les objets « Ressource » possèdent bien des associations parent/enfant, mais celles-ci sont principalement utiles pour la propriété des ressources.

View3D et couches de rendu

En ce qui concerne la séparation front-end/back-end, l’ View3D constitue le point de séparation du point de vue de l’utilisateur, car c’est l’ View3D qui définit le contenu de la scène à afficher. Dans le graphe de scène spatial d’ Qt Quick, le nœud racine d’une scène qui sera rendue est un nœud « Layer ». Les nœuds « Layer » sont créés par l’ View3D à l’aide d’une combinaison des propriétés de l’ View3D et de celles de l’ SceneEnvironment. Lors du rendu d’une scène pour un View3D, c’est ce nœud « Layer » qui est transmis au moteur de rendu pour effectuer le rendu de la scène.

Rendu de la scène

Schéma de fonctionnement du rendu 3D dans Qt Quick 3D

Configuration de la cible de rendu

La première étape du processus de rendu consiste à déterminer et à configurer la cible de rendu de la scène. La cible de rendu effective varie en fonction des propriétés définies dans l’ SceneEnvironment. Il faut d’abord décider si le contenu doit être rendu directement sur la surface d’une fenêtre ou sur une texture hors écran. Par défaut, View3D effectue le rendu sur une texture hors écran. L’utilisation d’effets de post-traitement rend obligatoire le rendu sur une texture hors écran.

Une fois la cible de rendu de la scène déterminée, certains états globaux sont définis.

  • taille de la fenêtre : si le rendu s’effectue dans une fenêtre
  • fenêtre de visualisation : la taille de la zone de la scène en cours de rendu
  • rectangle de découpe : sous-ensemble de la fenêtre auquel la fenêtre de visualisation doit être découpée
  • couleur d’effacement : couleur à utiliser pour effacer la cible de rendu, le cas échéant.

Préparation du rendu

L'étape suivante du rendu est la phase de préparation, au cours de laquelle le moteur de rendu effectue des tâches d'organisation pour déterminer ce qui doit être rendu pour une image donnée, et s'assurer que toutes les ressources nécessaires sont disponibles et à jour.

La phase de préparation comporte elle-même deux étapes : la préparation de haut niveau, qui consiste à déterminer ce qui doit être rendu et quelles ressources sont nécessaires ; et la préparation de bas niveau, qui utilise RHI pour configurer concrètement les pipelines et les tampons de rendu, ainsi que pour définir les dépendances de rendu du passage principal de la scène.

Préparation du rendu de haut niveau

L’objectif de cette phase est d’extraire l’état du graphe de scène spatial pour le transformer en un format pouvant servir à créer des commandes de rendu. En résumé, le moteur de rendu crée des listes de combinaisons de géométries et de matériaux à rendre, du point de vue d’une caméra unique avec un ensemble d’états d’éclairage.

La première étape consiste à déterminer l’état global commun à l’ensemble du contenu. Si l’ SceneEnvironment e définit une sonde de lumière ( lightProbe), le moteur vérifie si la carte d’environnement associée à cette texture de sonde de lumière est chargée ; si ce n’est pas le cas, une nouvelle carte d’environnement est chargée ou générée. La génération d’une carte d’environnement consiste elle-même en une série de passes visant à convolver la texture source en une carte cubique. Cette carte cubique contiendra à la fois des informations de réflexion spéculaire et d’irradiance, qui sont utilisées pour l’ombrage des matériaux.

L’étape suivante consiste pour le moteur de rendu à déterminer quelle caméra de la scène utiliser. Si aucune caméra active n’est explicitement définie par une ` View3D`, la première caméra disponible dans la scène est utilisée. S’il n’y a aucune caméra dans la scène, aucun contenu n’est rendu et le moteur de rendu s’arrête.

Une fois la caméra déterminée, il est possible de calculer la matrice de projection pour cette image. Ce calcul est effectué à ce stade, car chaque élément rendable doit savoir comment être projeté. Cela signifie également qu’il est désormais possible de déterminer quels éléments rendables doivent être rendus. À partir de la liste de tous les éléments rendables, nous supprimons tous ceux qui ne sont pas visibles, soit parce qu’ils sont désactivés, soit parce qu’ils sont entièrement transparents. Ensuite, si le culling par frustum est activé sur la caméra active, chaque élément rendable est vérifié pour voir s’il se trouve entièrement en dehors du champ de vision du frustum de la caméra ; si c’est le cas, il est retiré de la liste des éléments rendables.

Outre la projection de la caméra, la direction de celle-ci est également calculée, car cela est nécessaire pour les calculs d’éclairage dans le code de shading.

S’il y a des nœuds d’éclairage dans la scène, ceux-ci sont alors regroupés dans une liste dont la longueur correspond au nombre maximal de lumières disponibles. S’il existe dans la scène plus de nœuds d’éclairage que le nombre de lumières prises en charge par le moteur de rendu, tous les nœuds d’éclairage supplémentaires au-delà de cette limite sont ignorés et ne contribuent pas à l’éclairage de la scène. Il est possible de spécifier la portée des nœuds d’éclairage, mais notez que même lorsqu’une portée est définie, l’état d’éclairage de chaque source lumineuse est toujours envoyé à chaque matériau comportant un éclairage ; toutefois, pour les sources lumineuses ne se trouvant pas dans la portée, la luminosité sera fixée à 0, de sorte qu’en pratique, ces sources lumineuses ne contribueront pas à l’éclairage de ces matériaux.

Maintenant que la liste des éléments rendables est, espérons-le, plus courte, chacun de ces éléments doit être mis à jour pour refléter l’état actuel de la scène. Pour chaque élément rendable, nous vérifions qu’un matériau adapté est chargé ; si ce n’est pas le cas, un nouveau est créé. Un matériau est une combinaison de shaders et d’un pipeline de rendu ; il est nécessaire à la création d’un appel de dessin. De plus, le moteur de rendu s’assure que toutes les ressources nécessaires au rendu d’un élément à rendre sont chargées, par exemple la géométrie et les textures associées au modèle. Les ressources qui ne sont pas encore chargées le sont à ce stade.

Voir Mise en cache sur disque des shaders pour une explication sur la mise en cache sur disque des shaders pour les matériaux et les effets.

La liste des éléments rendables est ensuite triée en trois listes.

  • Éléments opaques : ils sont triés de l’avant vers l’arrière, c’est-à-dire des éléments les plus proches de la caméra vers ceux qui en sont les plus éloignés. Cela permet de tirer parti du culling d’occlusion matériel ou de la détection précoce de la valeur z dans le shader de fragment.
  • Éléments 2D : il s’agit d’éléments « QtQuick » rendus par le moteur de rendu « Qt Quick ».
  • Éléments transparents : ils sont triés de l’arrière vers l’avant, c’est-à-dire des éléments les plus éloignés de la caméra vers ceux qui lui sont les plus proches. Cela s’explique par le fait que les éléments transparents doivent être mélangés avec tous les éléments situés derrière eux.

Préparation du rendu de bas niveau

Maintenant que tous les éléments à prendre en compte pour cette image ont été déterminés, on peut s’attaquer à l’infrastructure et aux dépendances du passage de rendu principal. La première étape de cette phase consiste à effectuer tous les pré-passages nécessaires au passage principal.

  • Rendu du « DepthPass » : certaines fonctionnalités, telles que l’occlusion ambiante dans l’espace écran (Screen Space Ambient Occlusion) et les ombres, nécessitent un pré-pass de profondeur. Ce pass consiste à rendre tous les éléments opaques dans une texture de profondeur.
  • Rendu du SSAO Pass – L’objectif du passage d’occlusion ambiante dans l’espace écran (Screen Space Ambient Occlusion) est de générer une texture d’occlusion ambiante. Cette texture est ensuite utilisée par les matériaux pour assombrir certaines zones lors de l’ombrage.
  • Rendu des passes d’ombres — Chaque lumière de la scène pour laquelle les ombres sont activées contribue à une passe d’ombres supplémentaire. Le moteur de rendu utilise deux techniques d’ombrage différentes ; il y aura donc des passes différentes selon les types de lumières. Lors du rendu des ombres provenant d’une lumière directionnelle, la scène est rendue dans une texture d’occlusion 2D à partir d’une combinaison de la direction de la lumière directionnelle et de la taille du frustum de la caméra. Lors du rendu des ombres provenant d’une lumière ponctuelle ou spot, la texture d’occlusion de la lumière est une carte cubique représentant la contribution d’occlusion par rapport à chaque direction de face de la lumière.
  • Rendu de la texture d'écran - Ce passage n'a lieu que lors de l'utilisation d'une « CustomMaterial » nécessitant une texture d'écran, qui peut être utilisée pour des techniques de rendu telles que la réfraction. Ce passage fonctionne comme un passage de profondeur, mais rend tous les éléments opaques sur une texture de couleur.

Une fois les rendus de dépendances terminés, les autres passes sont préparées mais ne sont pas rendues. Cette préparation consiste à prendre l’état recueilli lors de la phase de préparation de haut niveau et à le traduire en primitives graphiques, par exemple en créant ou en mettant à jour les valeurs des tampons uniformes, en associant des échantillonneurs aux textures de dépendance, en configurant les liaisons de ressources de shaders, ainsi que tout ce qui est nécessaire à la création d’un état de pipeline requis pour effectuer un appel de dessin.

Rendu de la scène

Maintenant que le gros du travail de préparation est terminé, la partie la plus simple consiste à exécuter les commandes qui contribuent au contenu de la scène principale. Ce rendu s’effectue dans l’ordre suivant :

  • Pass d’effacement – Il ne s’agit pas vraiment d’un pass, mais selon la valeur attribuée à `backgroundMode` dans ` SceneEnvironment`, différentes opérations peuvent avoir lieu ici. Si le mode d’arrière-plan est « transparent » ou « color », le tampon de couleur sera effacé soit par la transparence, soit par la couleur spécifiée. Si, en revanche, le mode d’arrière-plan est défini sur « SkyBox », une passe sera alors exécutée pour rendre la SkyBox depuis la perspective de la caméra, ce qui remplira également le tampon avec les données initiales.
  • Passage opaque – Ensuite, tous les éléments opaques seront dessinés. Cela consiste simplement à définir l’état du pipeline et à exécuter la commande de dessin pour chaque élément dans l’ordre de la liste, puisqu’ils sont déjà triés à ce stade.
  • Passage 2D – S’il y a des éléments 2D dans la scène, le moteur de rendu « Qt Quick » est alors invoqué pour générer les commandes de rendu nécessaires au rendu de ces éléments.
  • Passage transparent – Enfin, les éléments transparents de la scène sont rendus un par un, de la même manière que les éléments opaques.

Le rendu de la scène est alors terminé.

Post-traitement

Si une fonctionnalité de post-traitement est activée, on peut supposer que le résultat du moteur de rendu de la scène était une texture servant d’entrée pour la phase de post-traitement. Toutes les méthodes de post-traitement sont des passes supplémentaires qui opèrent sur cette texture d’entrée de la scène.

Toutes les étapes de la phase de post-traitement sont facultatives, et si aucune fonctionnalité intégrée ni aucun effet défini par l’utilisateur n’est activé, le résultat du rendu de la scène est celui qui est utilisé par la cible de rendu finale. Notez toutefois que l’option « tonemapping » (Rendu de la scène en arrière-plan) est activée par défaut.

Graphique des passes de rendu de post-traitement

Le post-traitement intégré

ExtendedSceneEnvironment et son type parent, « SceneEnvironment », offrent les effets les plus courants utilisés dans les scènes 3D, ainsi que le tonemapping, qui sert à mapper les valeurs de couleur à plage dynamique élevée générées par le moteur de rendu vers la plage LDR (0-1). Parmi ces effets, on trouve la profondeur de champ, la lueur/le bloom, les reflets de lentille, le vignetage, le réglage et l’étalonnage des couleurs, le brouillard et l’occlusion ambiante.

Effets de post-traitement

Les applications peuvent spécifier leurs propres effets de post-traitement personnalisés sous la forme d’une liste ordonnée dans la propriété SceneEnvironment::effects. Lorsque cette liste n’est pas vide, les effets qu’elle contient sont appliqués avant les effets intégrés fournis par ExtendedSceneEnvironment. Chaque effet de post-traitement fait partie d’une chaîne telle que la sortie de l’effet précédent sert d’entrée à l’effet suivant. Le premier effet de cette chaîne reçoit son entrée directement à partir de la sortie de l’étape de rendu de la scène. Les effets peuvent également accéder à la texture de profondeur générée par le moteur de rendu de la scène.

Chaque effet de ce processus peut se composer de plusieurs sous-passes, ce qui signifie qu’il est possible de rendre du contenu dans des tampons intermédiaires. La passe finale d’un effet à passes multiples doit produire une texture unique contenant les données de couleur destinées à être utilisées par les étapes suivantes de la phase de post-traitement.

Anticrénelage temporel et progressif

Les étapes d’anticrénelage temporel et progressif sont activées de manière facultative en définissant des propriétés dans l’ SceneEnvironment. Bien qu’elles ne fassent pas strictement partie de la phase de post-traitement, les résultats effectifs de l’anticrénelage temporel et progressif sont obtenus au cours de cette phase.

L’anticrénelage temporel est effectué lorsque la scène est en cours de mise à jour. Lorsqu’il est activé, la caméra active procède à de très légers ajustements de sa direction à chaque image lors du rendu de la scène. L’image en cours est ensuite fusionnée avec l’image précédemment rendue afin de lisser le rendu.

L’anticrénelage progressif n’est appliqué que lorsque la scène n’est pas en cours de mise à jour. Lorsqu’il est activé, une mise à jour est forcée et l’état actuel de la scène est rendu avec de très légers ajustements de la direction de la caméra active. Jusqu’à 8 images sont accumulées et fusionnées selon des pondérations prédéfinies. Cela permet de lisser une scène non animée, mais entraîne une perte de performances car plusieurs images supplémentaires sont rendues à chaque mise à jour.

Anticrénelage par suréchantillonnage (SSAA)

L’anticrénelage par suréchantillonnage est une méthode «brute force» permettant de lisser une scène. Il consiste à effectuer le rendu sur une texture dont la taille est un multiple de la taille demandée pour la scène, puis à la sous-échantillonner à la taille cible. Ainsi, par exemple, si un SSAA 2X est demandé, la scène sera rendue sur une texture dont la taille est deux fois supérieure à la taille prévue, puis sous-échantillonnée au cours de cette phase. Cela peut avoir un impact considérable sur les performances et l’utilisation des ressources ; il convient donc de l’éviter si possible. Il est également possible que la taille de l’ View3D e soit trop importante pour utiliser cette méthode, car la texture nécessaire à celle-ci peut dépasser la capacité prise en charge par le matériel de rendu.

© 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.