> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Générateurs de BVH

> Générateurs de BVH

XDXR utilise actuellement l'algorithme LBVH suivi d'une reconstruction de 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 des BVH hors ligne, de les compresser au besoin et de les charger à partir du disque à l'exécution. Cela peut produire des BVH de meilleure qualité pour de meilleures performances de traversée, et nécessite beaucoup moins de temps GPU que le générateur à l'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 modifiables ainsi que les BLAS statiques. On s'attend à ce qu'un jeu typique génère la plupart de ses BLAS hors ligne, et n'effectue que les générations de TLAS et les mises à jour de BLAS pendant une image à l'exécution.

Le générateur hors ligne peut effectuer un fractionnement des triangles pour éviter les coûts liés aux triangles longs, minces et inclinés, dont les volumes englobants peuvent être beaucoup plus grands que leur surface. De plus, il peut effectuer une meilleure « quadification » des triangles dans les nœuds feuilles; consultez la section « Quads » ci-dessous.

Consultez l'exemple [OfflineRT](https://learn.microsoft.com/gaming/gdk/docs/gdk-dev/development-downloads/gdk-samples-list#graphics) pour obtenir des 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 aussi la page [Compression de BVH XDXR](/fr-CA/build/core-features/graphics/newfeatures/raytracing/rt-compression) 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 version du GDK.

## Générations par lots

XDXR prend en charge les générations de BVH « par lots ». La génération ou la mise à jour de plusieurs BVH en parallèle peut être de 10 à 25 fois plus rapide qu'en séquence.

Consultez [BuildRaytracingAccelerationStructureBatched2X](/fr-CA/reference/graphics/d3d12_xs/interfaces/ID3D12GraphicsCommandList6/methods/id3d12graphicscommandlist6_buildraytracingaccelerationstructurebatched2x).

De plus, envisagez d'utiliser le calcul asynchrone pour superposer les générations de BVH à des charges de travail comme les ombres. Il pourrait être possible de compenser entièrement le coût de génération, ou d'activer des options de qualité de génération supplémentaires pour une traversée plus rapide.

## FP16

Le test d'intersection BVH de RDNA2 prend en charge deux types de nœuds AABB :  des variantes à 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 traversée, car la précision réduite fait gonfler les AABB. Une heuristique de gonflement des boîtes est utilisée pour déterminer quand le 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` force tous les AABB à utiliser FP16 et réduit les allocations pessimistes de BVH. Une valeur inférieure à `1.0f` force tous les AABB à utiliser FP32. On peut aussi obtenir ce résultat 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 pratiques exemplaires et les mêmes pièges en matière de performances que la plupart des autres générateurs de BVH à deux niveaux (TLAS + BLAS). Un sujet de préoccupation courant concerne les grands volumes englobants de BLAS remplis d'espace vide, ou qui croisent fortement d'autres instances de BLAS. Si deux instances ont des volumes englobants qui se croisent, il peut être impossible pour la traversée de déterminer la position d'intersection la plus proche sans traverser 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 volumes englobants, auquel cas aucun tri ne peut être effectué. Parmi les objets particulièrement problématiques, on trouve par exemple les lignes électriques suspendues, qui ont probablement des volumes englobants très grands par rapport au volume du maillage d'origine et qui risquent de couvrir de grandes zones de la scène. Un autre exemple est la combinaison de plusieurs petits objets en une seule BLAS : les limites sont étendues 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 à fractionner ou à combiner des objets pendant les phases de création ou de modification du contenu. Cependant, cela peut être difficile, voire impossible, lorsqu'on ajoute des effets de lancer de rayons à des titres existants, ou plus tard dans le pipeline de création du jeu.

Pour offrir un certain degré de contrôle à cet égard, XDXR implémente l'option « TAPU » (TLAS-Pull-Up) dans son générateur de BVH. Celle-ci permet à l'utilisateur de marquer des instances individuelles comme nécessitant une « remontée » 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 « remonte » directement dans la TLAS le premier (TAPU4) ou le deuxième (TAPU16) niveau de la hiérarchie de la BLAS. Cela permet en pratique de fractionner 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 d'éliminer les zones d'espace vide.

Pour obtenir des informations sur le « fractionnement d'instances » (Instance Splitting) ou le « Rebraiding », qui est une version automatisée de TAPU, consultez [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS3](/fr-CA/reference/graphics/d3d12_xs/structs/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. Voici un exemple de code.

```cpp theme={null}
D3D12_RAYTRACING_INSTANCE_DESC desc[3] = {};
// This example enables TAPU4 on every instance, this probably will not help performance, and will have a memory cost.
// You'll want a more targeted solution, such as marking up problematic instances manually by name,
// or enabling based on world-space-size or volume.
for (unsigned i=0; i < _countof(desc); ++i)
{
    desc[i].AccelerationStructure = blas->GetGPUVirtualAddress();
    // Use TAPU16 to break up the object by a further level.
    desc[i].Flags = D3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU4;
    desc[i].InstanceMask = 0xff;
    desc[i].InstanceContributionToHitGroupIndex = 0;
    desc[i].Transform[0][0] = desc[i].Transform[1][1] = desc[i].Transform[2][2] = 1.0f;
}

ComPtr<ID3D12Resource> pInstanceDescs;
UploadBuffer(desc, sizeof(desc), &pInstanceDescs);

// Set special options
struct
{
D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1 params1;
D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2 params2;
} options;
D3D12XboxMakeDefault_D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1(&options.params1);
D3D12XboxMakeDefault_D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2(&options.params2);

// Access via a batched build
D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_BATCHED_DESC2 tlasBatchedBuild {};
tlasBatchedBuild.NumPostbuildInfoDescs = 0;
tlasBatchedBuild.pPostbuildInfoDescs = nullptr;
tlasBatchedBuild.ExtraOptions.SizeInBytes = sizeof(options);
tlasBatchedBuild.ExtraOptions.pXdxrStreamDesc = &options;

// Tell the builder that this is how many outputs slots it can rely on!
// This should be the total number of instance nodes in your build.
// E.G. instances without a TAPU flag take up 1 element, instances with TAPU4 take up 4 elements, and instances with TAPU16 take up 16 elements.
options.params2.NumberOfElementsAllocated = _countof(desc) * 4;

D3D12_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_DESC buildDesc {};
D3D12_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_INPUTS &topLevelInputs = buildDesc.Inputs;
topLevelInputs.DescsLayout = D3D12_ELEMENTS_LAYOUT_ARRAY;
topLevelInputs.Flags = D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE;
// This is the number of instance descs, NOT multiplied by the TAPU factor.
topLevelInputs.NumDescs = _countof(desc); 
topLevelInputs.Type = D3D12_RAYTRACING_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL;
topLevelInputs.InstanceDescs = pInstanceDescs->GetGPUVirtualAddress();

// Get total size required including additional nodes for TAPU.
D3D12_RAYTRACING_ACCELERATION_STRUCTURE_PREBUILD_INFO topLevelPrebuildInfo;
m_pDxrDevice->GetRaytracingAccelerationStructurePrebuildInfoX(&topLevelInputs,
&tlasBatchedBuild.ExtraOptions,
&topLevelPrebuildInfo);

ComPtr<ID3D12Resource> pScratchResource;
ComPtr<ID3D12Resource> tlas;

AllocateRawUAVBuffer(topLevelPrebuildInfo.ScratchDataSizeInBytes, &pScratchResource);
auto tlasPointer = AllocateAccelerationStructureBuffer(topLevelPrebuildInfo.ResultDataMaxSizeInBytes, &tlas);

buildDesc.DestAccelerationStructureData = tlasPointer;
buildDesc.ScratchAccelerationStructureData = pScratchResource->GetGPUVirtualAddress();

// Make sure the number of incoming instances is clearly communicated!
tlasBatchedBuild.Desc = buildDesc;

// Build acceleration structure.
((ID3D12GraphicsCommandList6*)m_CommandList.Get())->BuildRaytracingAccelerationStructureBatched2X(1, &tlasBatchedBuild);
```

## Options et indicateurs de génération

En plus de prendre en charge les indicateurs habituels des générateurs DXR comme `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](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params1), [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS2](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params2), [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS3](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params3).

Il peut être avantageux de sacrifier du temps de génération de la TLAS au profit des performances de traversée, surtout 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](/fr-CA/reference/graphics/d3d12_xs/interfaces/ID3D12GraphicsCommandList6/methods/id3d12graphicscommandlist6_buildraytracingaccelerationstructurebatched2x) pour un exemple de code qui augmente le nombre d'itérations de treelets pendant la génération de la TLAS. Cela peut améliorer considérablement les performances de traversée, 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 un seul AABB englobant et considérés comme un « quad ». Les générateurs à l'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 le volume englobant combiné reste dans une marge de gonflement acceptable par rapport au volume englobant 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 large. Le générateur à l'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 de PIX](/fr-CA/tools/tools-console/pix/gpu/pix-bvh-viewer) 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 traversée. 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 conservateurs dans l'espace monde. Consultez la [documentation sur les k-DOP](/fr-CA/build/core-features/graphics/newfeatures/raytracing/rt-kdop) 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 fabricants PC. Actuellement, de 120 à 140 octets sont nécessaires par triangle, en tenant compte de l'en-tête, des AABB, des données de triangles 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 importante 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 à l'exécution, il est recommandé d'utiliser une mémoire tampon d'index optimisée pour la « réutilisation du cache de sommets ». Les triangles seront ainsi ordonnés de sorte que des triangles consécutifs soient plus susceptibles 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 le disque, consultez [Compression de BVH XDXR](/fr-CA/build/core-features/graphics/newfeatures/raytracing/rt-compression). Cela peut réduire la taille sur le disque **de 3,5 à 6,6 fois**, et peut être combiné avec ZLIB pour réduire davantage la taille. Cela ne réduit pas la taille en mémoire.

## Voir aussi

[Compression de BVH XDXR](/fr-CA/build/core-features/graphics/newfeatures/raytracing/rt-compression) [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS1](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params1)  [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS2](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params2) [D3D12XBOX\_BUILD\_RAYTRACING\_ACCELERATION\_STRUCTURE\_PARAMS3](/fr-CA/reference/graphics/d3d12_xs/structs/d3d12xbox_build_raytracing_acceleration_structure_params3) [BuildRaytracingAccelerationStructureBatched2X](/fr-CA/reference/graphics/d3d12_xs/interfaces/ID3D12GraphicsCommandList6/methods/id3d12graphicscommandlist6_buildraytracingaccelerationstructurebatched2x) [Vue d'ensemble du lancer de rayons (et de DXR)](/fr-CA/build/core-features/graphics/newfeatures/raytracing/rt-overview)


## Related topics

- [Répertoire des rubriques NDA : liens actifs vers Microsoft Learn](/fr/nda/nda-topic-directory.md)
- [Compiler et exécuter votre premier titre console GDKX](/fr/home/build-first-title/first-console-title-walkthrough.md)
- [Raytracing en XBOX Series X|S con XDXR](/es/build/core-features/graphics/newfeatures/raytracing/index.md)
- [XBOX Accessibility Guidelines (XAG)](/fr/build/game-principles/accessibility/xbox-accessibility-guidelines.md)
- [Raytracing on XBOX Series X|S with XDXR](/build/core-features/graphics/newfeatures/raytracing/index.md)
