Skip to main content
XDXR utilise actuellement l’algorithme LBVH suivi d’une reconstruction par treelets pour les générations de BVH à l’exécution, et le générateur de BVH Embree pour les générations de BVH hors ligne.

Générateur hors ligne

XDXR permet de générer les BVH hors ligne, de les compresser éventuellement, puis de les charger depuis le disque à l’exécution. Cela peut produire des BVH de meilleure qualité, pour de meilleures performances de parcours, et nécessite beaucoup moins de temps GPU que le générateur d’exécution. Le générateur de BVH hors ligne ne prend actuellement en charge que la génération de BLAS, y compris les BLAS pouvant être mises à jour ainsi que les BLAS statiques. Un jeu typique est censé générer la plupart des BLAS hors ligne et n’effectuer que des générations de TLAS et des mises à jour de BLAS au cours d’une frame à l’exécution. Le générateur hors ligne peut effectuer un fractionnement des triangles afin d’éviter le coût des triangles longs, fins et inclinés, dont les boîtes englobantes peuvent être nettement plus grandes que leur surface. En outre, il peut réaliser une meilleure « quadification » des triangles dans les nœuds feuilles ; consultez la section « Quads » ci-dessous. Consultez l’exemple OfflineRT pour plus d’informations sur la génération de BVH hors ligne, ainsi que sur la sérialisation, la désérialisation et la compression des BVH hors ligne. Consultez également la page Compression de BVH XDXR pour plus de détails. Notez que les BVH générés hors ligne ne sont valides que pour la version du GDK avec laquelle ils ont été générés. Les BVH devront être régénérés après une mise à jour de la version du GDK.

Générations par lots

XDXR prend en charge les générations de BVH « par lots ». Générer ou mettre à jour plusieurs BVH en parallèle peut être de 10 à 25 fois plus rapide que de manière séquentielle. Consultez BuildRaytracingAccelerationStructureBatched2X. En outre, envisagez d’utiliser le calcul asynchrone pour superposer les générations de BVH à des charges de travail telles que les ombres. Il peut être possible de compenser la totalité du coût de génération, ou d’activer des options supplémentaires de qualité de génération pour un parcours plus rapide.

FP16

Le test d’intersection de BVH RDNA2 prend en charge deux types de nœuds AABB : en virgule flottante 32 bits et 16 bits. Les nœuds de boîte FP16 ne peuvent être utilisés que lorsque les étendues de l’AABB se situent dans la plage représentable en FP16. Pour offrir davantage d’occasions d’économiser de la mémoire, la géométrie peut être remise à l’échelle par des puissances de deux afin de tenir dans la plage FP16. Cette fonctionnalité peut être activée avec D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY. Bien que les boîtes FP16 soient plus petites, elles peuvent dégrader les performances de parcours, car la précision réduite provoque un gonflement des AABB. Une heuristique de gonflement des boîtes est utilisée pour déterminer quand ce gonflement est acceptable. Pour remplacer l’heuristique par défaut, spécifiez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1:: FP16BoxInflationThreshold. Une valeur supérieure à 10.0f forcera toutes les AABB à utiliser FP16 et réduira les allocations pessimistes de BVH. Une valeur inférieure à 1.0f forcera toutes les AABB à utiliser FP32. Le même effet peut être obtenu en spécifiant D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE sans D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY.

TAPU

XDXR partage les mêmes bonnes pratiques et les mêmes écueils en matière de performances que la plupart des autres générateurs de BVH à deux niveaux (TLAS + BLAS). Un problème courant concerne les grandes boîtes englobantes de BLAS remplies d’espace vide, ou fortement en intersection avec d’autres instances de BLAS. Si deux instances ont des boîtes englobantes qui se croisent, il peut être impossible pour le parcours de déterminer la position d’impact la plus proche sans parcourir les deux instances. La situation est encore pire lorsque davantage d’instances se chevauchent, ou lorsque l’origine du rayon se trouve à l’intérieur des boîtes englobantes, auquel cas aucun tri ne peut être effectué. Parmi les objets particulièrement problématiques figurent par exemple les lignes électriques suspendues, qui ont probablement des boîtes englobantes très grandes par rapport au volume du maillage d’origine et sont susceptibles de couvrir de vastes zones de la scène. Un autre exemple est la combinaison de plusieurs petits objets en une seule BLAS : les limites s’étendent pour contenir chaque maillage, mais il y aura probablement de grandes zones d’espace vide entre eux. Parfois, la solution la plus appropriée à ces problèmes consiste à scinder ou à combiner des objets pendant les phases de création ou de modification du contenu. Cependant, cela peut être difficile, voire impossible, lors de l’ajout d’effets de lancer de rayons à des titres existants, ou à un stade avancé du pipeline de création du jeu. Pour offrir un certain degré de contrôle, XDXR implémente l’option « TAPU » (TLAS-Pull-Up) dans son générateur de BVH. Elle permet à l’utilisateur de marquer des instances individuelles comme nécessitant une « remontée » (pull-up) dans la TLAS. En spécifiant l’indicateur D3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU4 ou D3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU16 dans la description d’une instance, le générateur « remontera » le premier (TAPU4) ou le deuxième (TAPU16) niveau de la hiérarchie de la BLAS directement dans la TLAS. Cela permet en pratique de scinder une grande instance de BLAS en 4 ou 16 nœuds, qui peuvent être partitionnés plus efficacement dans la hiérarchie de la TLAS, et de supprimer des zones d’espace vide. Pour plus d’informations sur le « fractionnement d’instances » (Instance Splitting) ou le « retressage » (Rebraiding), qui est une version automatisée de TAPU, consultez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3. En plus de spécifier l’indicateur TAPU, des nœuds supplémentaires doivent être alloués dans la TLAS. Un exemple de code suit.

Options et indicateurs de génération

En plus de prendre en charge les indicateurs habituels des générateurs DXR, tels que D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE, XDXR prend en charge une API permettant de spécifier des options supplémentaires pour les générateurs de BVH. Consultez D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3. Il peut être intéressant de sacrifier du temps de génération de la TLAS au profit des performances de parcours, en particulier si la génération de la TLAS peut être effectuée en calcul asynchrone. Consultez l’exemple 1 de la section Remarques de BuildRaytracingAccelerationStructureBatched2X pour un exemple de code augmentant le nombre d’itérations de treelets lors de la génération de la TLAS. Cela peut améliorer considérablement les performances de parcours, au prix de temps de génération de la TLAS beaucoup plus longs.

Quads

Les nœuds feuilles des BVH XDXR contiennent jusqu’à deux triangles. Ces triangles peuvent avoir deux nœuds AABB englobants distincts, ou être combinés en une seule AABB englobante et considérés comme un « quad ». Les générateurs d’exécution et hors ligne peuvent tous deux générer des quads en recherchant des triangles voisins qui partagent une arête et dont la boîte englobante combinée reste dans une marge de gonflement acceptable par rapport à la boîte englobante propre à chaque triangle. Une bonne « quadification » est souhaitable et améliore l’utilisation de la mémoire et les performances. Le générateur hors ligne peut produire davantage de quads grâce à un espace de recherche de voisins plus grand. Le générateur d’exécution ne peut associer que le 1er et le 2e triangle adjacents d’une liste de triangles, et non le 2e et le 3e. La visionneuse de BVH de PIX décrite dans Visionneuse de BVH PIX peut afficher des statistiques sur les quads.

k-DOP

Lors de la génération d’une BLAS, la construction d’un k-DOP peut améliorer les performances de parcours. Il s’agit d’un compromis entre mémoire et performances. Le k-DOP sert de table de recherche permettant de construire rapidement des AABB d’instance conservatrices dans l’espace monde. Consultez la documentation sur les k-DOP pour plus d’informations.

Exigences de mémoire des BVH

Les exigences de mémoire des BVH XDXR sont plus élevées que celles de certains fournisseurs PC. Actuellement, 120 à 140 octets sont nécessaires par triangle en tenant compte de l’en-tête, des AABB, des données de triangle et des métadonnées. Cela vaut pour les BVH générés hors ligne et pour les BVH générés à l’exécution après compactage, et il est peu probable que cela change de manière significative en raison des formats de nœuds matériels. Pour réduire la taille en mémoire compactée des BLAS générées avec le générateur d’exécution, il est recommandé d’utiliser un tampon d’index optimisé pour la « réutilisation du cache de sommets ». Les triangles seront ainsi ordonnés de sorte que des triangles consécutifs aient plus de chances de partager une arête. Cela facilite la formation de quads, ce qui réduit à la fois le nombre de feuilles et le nombre de nœuds internes. Pour réduire la taille sur disque, consultez Compression de BVH XDXR. Cela peut permettre une réduction de 3,5x à 6,6x de la taille sur disque, et peut être combiné avec ZLIB pour réduire encore davantage la taille. Cela ne réduit pas la taille en mémoire.

Voir aussi

Compression de BVH XDXR D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1 D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2 D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3 BuildRaytracingAccelerationStructureBatched2X Vue d’ensemble du lancer de rayons (et de DXR)
Last modified on October 6, 2026