Archives de catégorie : DirectX

Le Compute Shader avec DirectX 11 (DirectCompute)

GPU

Intro :

Pour faire simple, le compute shader de DirectX 11 permet d’effectuer des calculs directement par le processeur de la carte graphique (nommé GPU) alors qu’ils auraient pu être fait par le CPU (le processeur de la carte-mère du PC). Il est dénommé par un autre nom : le DirectCompute.

A noter que bien que leur sortie s’est faite avec DirectX 11, on peut utiliser les compute shader avec du matériel DirectX 10.

Explications :

Le compute shader permet le partage de la mémoire entre processus légers synchronisés à l’intérieure de la CG et de la mémoire de l’ordinateur. Il utilise le langage HLSL (High Level Shader Language) classique de DirectX.

En théorie on peut calculer n’importe quoi. Le compute shader fait office d’accès mémoire en entrée / sortie par les programmes exécutés par le processeur.

Maintenant et depuis l’ajout de cette fonctionnalité, avec DirectX on peut faire du calcul non graphique en utilisant la CG.


Voici un petit exemple d’initialisation d’un compute shader :

– Avec srcFile comme le nom du fichier .fx d’un compute shader.
– Avec defines comme structure de déclaration des constantes defines à l’intérieur de l’effet.

Quand le compute shader sera exécuté dans la mémoire de la carte graphique, il pourra tirer avantage d’un grand nombre d’unités d’exécution parallèles à l’intérieur du GPU.

Qu’est-ce qu’un « thread group » ?

Un thread group est un groupe d’unités d’exécution en parallèle qui est interprété et conçu par la CG comme un tableau en 3 dimensions dont chaque membre est un « thread ».

On utilise la méthode ID3D11DeviceContext::Dispatch pour envoyer un « thread group » au GPU. C’est-à-dire qu’on utilise cette méthode pour faire exécuter des commandes un compute shader.

En effet un compute shader peut être exécuté sur plusieurs unité d’exécution en parallèle, le tout formant un « thread group ». On identifie un thread (unité d’exécution parallèle) en particulier avec un numéro d’index assimilé par un vecteur en 3 dimensions (x, y, z).

Dans cette image illustrant un exemple, la taille des « threads groups » est de 5x5x2, soit 50 groupes d’unités d’exécution en parallèle (« thread »). Ici un thread en particulier est adressé par le triplet (4,1,1). A noter que chaque groupe de threads est fait de 16×16 = 256 unité ou threads d’exécution.

Single Thread

Chaque processus léger (« thread ») peut exécuter plusieurs élément de données à travers le compute shader. Et l’application C++ qui gère tous ces calculs peut définir le nombre de threads en exécution.


La principale capacité des compute shaders est le partage et l’accès de la mémoire par plusieurs threads en parallèle.

Le principe de base du calcul par le biais de ces shaders est l’envoi régulier d’une grille de threads. Les threads d’un même groupe s’exécute en parallèle, mais des threads de groupes différents le peuvent dans certaines conditions.

Les données accessibles par le compute shader peuvent être les Buffers et Textures de DirectX 11.


Les applications au compute shader peuvent être :

– Le traitement d’images
– La construction procédurale de modèles
– La physique et l’animation
– Le rendu
– L’intelligence artificielle
– Les effets de particules
– Les algorithmes de tri
– L’encodage vidéo
– Le calcul scientifique
– Des effets graphiques tels que : le depth of field, HDR bloom, le motion blur, etc…

Une classe TextureScreenQuad pour afficher vos effets shaders de Post-Traitement

fig-1-war-and-peace

Intro :

Dans un jeu, nous avons besoin d’afficher une texture / image qui prend la place de tout l’écran. Cette image peut être modifiée pour appliquer un rendu de post-effet avec un fichier shader .fx.

Explications :

Nous nous servons d’un tampon de vertices formant un carré ou d’un quad.

Voici le fichier TextureScreenQuad.h :

 

Voici le fichier TextureScreenQuad.cpp :


Résumé :

Nous avons présenté une façon d’utiliser un Quad de de post-traitement afin de modifier les couleurs de rendu du front buffer.

Références :

– Stackoverflow.com

Une classe RenderTarget pour afficher un tampon d’image de rendu

rtt

Intro :

Nous avons parfois besoin de stocker le rendu 3D dans une texture que l’on pourra utiliser n’importe tout dans le programme !

Explications :

Voici le fichier RenderToTexture.h :

 

Voici le fichier RenderToTexture.cpp :

 

Comment l’utiliser ?

 

Résumé :

Nous avons présenter la façon la plus optimale possible d’utiliser une RenderTarget !

Références :

Une simple classe D3D10Renderer

Intro :

1211804249

Pour utiliser DirectX, il nous faut une classe D3D10Renderer afin d’initialiser le rendu graphique 3D.

Prérequis :

– Aucun

Explications :

Voici le code du fichier D3D10Renderer.h :

 

Voici le code du fichier D3D10Renderer.cpp :

 

Résumé :

Nous avons présenté les deux fichiers nécessaire à l’initialiser du rendu graphique de DirectX !

Kit basique d’initialisation DirectX 10.1

 

Kit

KIT_2

Intro :

Voici un kit formé d’un ensemble de fichiers qui pourra servir de base pour vos programmes graphiques ou essais 3D. Le kit comprend à peu près 4000 lignes de code.

Prérequis :

– Savoir lire du C++

Explications :

[rajouter : ]

[fullscreen switch]

[shadermanager]

Il comprend :

– le support de la transparence

– une caméra classique

– une caméra de type FPS (First Person Shooter) avec laquelle on peut voler partout

– une énumération de couleurs

– un gestionnaire D3D10Renderer – quasi complet

– la possibilité de lancer l’application en plein-écran ou non

– la possibilité d’afficher du texte

– des gestionnaires en design-pattern Singleton (classe Singleton)

– un ensemble de macros toutes utiles

– un gestionnaire InputManager pour gérer les entrées clavier et souris de l’utilisateur

– une classe SceneNode pour représenter vos entités sur la scène

– avec fonctions de translation, rotation et agrandissement

– un gestionnaire de fichier effet Shader avec gestion automatique des variables shader

– quelques définitions de shaders (ex : simple, lumière)

– une classe SkyDomeSceneNode (pour afficher un ciel avec une TextureCube)

– une classe SphereMeshSceneNode pour générer une sphère de façon procédurale

– une classe System

– une classe TextureManager pour charger les fichiers textures rapidement

– une liste complète de déclaration de vertex (avec les Vertex Input Layout)

– une classe Utils avec fonctions toutes très utiles

Résumé :

Voici l’archive contenant le kit et tous ses fichiers associés.

Références :

– stackoverflow.com

Obtenir les informations de votre CG avec les interfaces DXGI*

gtx

Intro :

Il peut être utile d’obtenir le nom de la carte vidéo, sa mémoire vive maximum et tous ses modes d’affichage possibles pour un jeu vidéo.

Prérequis :

– Savoir initialiser DirectX 10

Explications :

Avant tout, voici deux petites macros affichant les erreurs tout en retournant false s’il y a en une !

 

Voici la fonction qui affiche les informations sur la carte graphique :

 

Voici la fonction qui affiche les capacités de la carte graphique en matière d’anti-aliasing (déjà présentée dans les articles précédents) :

 

Voici la sortie de la console une fois affichés les modes d’affichage :

CG_specs

 

Résumé :

Nous avons appris comment obtenir les informations à partir de la carte graphique.

Les principaux objets utilisés pour initialiser DirectX 11

objects

Intro :

Il est nécessaire de manipuler une bonne dizaine d’objets ou d’interfaces pour initialiser DirectX 11 avant de commencer tout affichage 3D.

Prérequis :

– Avoir déjà lu le code pour initialiser DirectX 10 ou 11

Explications :

Les-voici énumérés ci-dessous.

 


 

Afficher du rendu 3D :

IDXGISwapChain : interface qui stocke une ou plusieurs surfaces antérieures de rendu avant d’effectuer l’affichage à l’écran.

Voici ses méthodes principales :

 

ID3D11Device : interface qui représente un afficheur vidéo. Elle est utilisée soit pour afficher du rendu 3D soit pour créer des ressources.

Voici ses méthodes principales :

 

ID3D11DeviceContext : une interface qui représente un contexte d’affichage (device context) générant des commandes de rendu.

Voici ses méthodes principales :

 

ID3D11RenderTargetView : une interface qui représente une render-target (voir lexique) qui peut être accédée lors du rendu.

Elle possède la méthode principale :

 

ID3D11Texture2D : une interface qui représente une texture constituée de données texel qui
sont stockées dans la mémoire.

Elle possède la méthode principale :

 

ID3D11DepthStencilState : une interface qui représente l’état du depth-stencil pour que celui-ci
opère des tests à l’étape output-merger.

Elle possède la méthode principale :

 

ID3D11DepthStencilView : une interface qui peut accéder à une texture paramétrée durant le test du depth-stencil.

Elle possède la méthode principale :

 

Cette structure nommée D3D11_DEPTH_STENCIL_VIEW_DESC est décrite ci-dessous :

 

ID3D11RasterizerState : une interface qui permet de configurer l’état du Rasterzizer pour l’étape de rendu Rasterzizer.

Elle possède la méthode principale GetDesc(D3D11_RASTERIZER_DESC *pDesc).
Cette structure nommée D3D11_RASTERIZER_DESC est décrite ci-dessous :

 

Objets de description de données :

Une structure nommée DXGI_SWAP_CHAIN_DESC est décrite ci-dessous :

 

Une structure nommée D3D11_TEXTURE2D_DESC est décrite ci-dessous :

 

Une structure nommée D3D11_VIEWPORT est décrite ci-dessous :

 

Résumé :

L’initialisation de DirectX 11 est assez délicate à mettre en œuvre car elle nécessite la manipulation de nombreux d’objets et interfaces associés.

Références :

– Documentation – DirectX SDK – June 2010

La tessellation – Application (DirectX 11)

tessellation

Intro :

Nous allons voir comment mettre en pratique la « tessellation » de DirectX 11.

Prérequis :

– Avoir suivi la première partie de ce tutoriel concernant la tessellation.

Explications :

Le principe est simple : on ajoute de nouvelles vertices à un modèle puis on déplace ces vertices en suivant les données correspondantes d’une « height map». Il s’agit en l’occurrence du procédé de « Displacement Mapping ».

Résumé :

Références :

Les principales étapes de rendu de DirectX 11

Intro :

Les étapes de la chaîne de rendu de DirectX 11 sont les mêmes que celles de DirectX 10.1, sauf qu’il y a été ajouté le support des nouvelles fonctionnalités de tessellation.

Prérequis :

– Connaître les étapes de la chaîne de rendu de DirectX 10.1

Explications :

Voici un schéma qui les résume :

pipeline

Seuls les étapes Hull Shader et Domain Shader sont programmables ; l’étape Tessellator est rigidement fixée par le GPU.

Étape Hull Shader :

 

Étape Tessellator Shader :

Une étape de la chaîne du rendu graphique non-programmable qui s’occupe de subdiviser un « domain » (un une face, un triangle, une ligne) en morceaux plus petits.

Étape Domain Shader :

Un programme shader qui calcule la position du vertex d’un point subdivisé par « l’output patch ».

Résumé :

Nous avons présenté les nouvelles étapes de la « pipeline » du rendu graphique de DirectX 11 concernant la tessellation.

Références :

– DirectX SDK 2010

La tessellation – Théorie (DirectX 11)

tessellation

Intro :

Le principe de la tessellation est simple : on transforme un polygone et on le décompose en morceaux plus petits.

Prérequis :

– Savoir comment fonctionne un programme HLSL

– Savoir comment utiliser DirectX 11

Explications :

Si on prend un carré et qu’on le coupe en deux le long de sa diagonale, on opère une « tessellation » en deux triangles.

Dans DirectX 11, la tessellation est opérée directement par le GPU (c’est-à-dire par le processeur de la carte graphique).

Elle peut être utilisée dans le rendu en faisant du « Displacement Mapping ». Au lieu de précharger, dans la mémoire vidéo, un modèle très détaillé : on peut augmenter ses détails par le GPU ; en effet le Displacement Mapping va de paire avec la tessellation.

Par exemple au lieu d’implémenter une grille plate très détaillée, à la place, on peut augmenter les détails d’un polygone carré par le procédé de tessellation.

En conséquence et d’autre part, il devient possible de faire varier progressivement le niveau de détail géométrique des modèles.

Les avantages :

– Réduit la mémoire et la bande passante utilisées

– Permet de complexifier des modèles basse résolution en des modèles très détaillés et ceci à la volée

– Déplace le calcul classique de modification géométrique effectué par le CPU vers un calcul effectué par le GPU

– Facilite le LOD (Level of Detail) des objets distants. En effet la tessellation permet de faire varier dynamiquement le niveau de détail d’un modèle

– On peut effectuer le calcul physique de collision ou d’animation avec un modèle non détaillé en mémoire centrale tout en affichant un modèle très détaillé au rendu

– Possibilité d’affichage de meilleurs modèles détaillés

Trois nouvelles étapes de shader :

dx11_pipeline

DirectX 11 implémente la tessellation par 3 nouvelles étapes de chaîne de rendu : l’étape Hull Shader, l’étape Tessellator et l’étape Domain.

Ces trois étapes suive l’étape Vertex Shader et précède l’étape Geometry Shader.

Avant tout, définissons quelques concepts liés à la tessellation par DirectX 11 :

– Patch :
– Control Point :
– Tessellation factor :
– Input primitive :

Lorsque ces deux étapes (Hull Shader & Domain Shader) sont définis dans un fichier shader « .fx », l’étape Vertex Shader ne renvoie pas spécialement un vertex mais renvoie ce qu’on appel un « control point » qui représente le vertex d’un triangle ou d’une face. Ce sera la dernière étape de la « Pipeline » qui se chargera de renvoyer le vertex au Pixel Shader.

Hull Shader :

Est invoqué une fois par « control point » et renvoie des « tessellator factors ». Cette étape est programmable. Cette étape de shader permet de faire savoir à l’étape suivante Tesselator comment opérer la tesselation sur les données d’entrées.

TesselatorLevel

Tessellator Stage :

Génère de nouvelles vertices. Plus les « tessellator factors » reçues sont élevés plus il y a de triangles créés. Cette étape est non-programmable.

Domain Shader :

Cette étape est programmable. Est exécutée une fois par vertex. Convertis et fait correspondre les données (u, v) vers les données d’attributs (x, y, z, w).

Exemples :

1) Un carré subissant une « tessellation »

tesselator

 2) Puis utilisation d’une « displacement map »

tesselator_2

3) Enfin utilisation d’une texture et bump mapping

Tessellation3

Résumé :

Références :

– http://www.nvidia.fr/object/tessellation_fr.html

– https://msdn.microsoft.com/en-us/library/windows/desktop/ff476340%28v=vs.85%29.aspx

– http://www.rastertek.com/dx11tut38.html

– http://richardssoftware.net/Home/Post/28

– 3D Game Programming with DirectX 11 – Franck D. Luna

Une classe AlphaPass pour activer la transparence (façon RAII)

alpha

Intro :

Parfois on veut afficher certaines modèles tout en activant la transparence.

Ici je présente une façon simple de gérer cela avec le principe du RAII.

Prérequis :

– Comprendre le principe du RAII

– Savoir initialiser DirectX 10 à travers la classe D3D10Renderer

Explications :

Voici le code du fichier AlphaPass.h :

 

Voici le fichier AlphaPass.cpp :

 

warning

Vos entités transparentes doivent être affichées en dernier lors de le boucle de rendu et tout en désactivant le Z-Buffer.

Résumé :

Nous avons établi un objet AlphaPass qui permet d’activer, lors de sa création sur la pile, la transparence dans le rendu. La transparence est restauré lors de la destruction de l’objet en sortant du bloc de code.

Une classe Renderable pour afficher vos contenus 3D

test_remeshing

Intro :

Pour afficher rapidement du contenu 3D, il est laborieux de déclarer à chaque fois les vertex et index buffers, le shader associé, le Vertex Input Layout, la méthode d’affichage, etc…

Cette classe suivante vous permettra de restreindre ces difficultés.

Prérequis :

– Savoir utiliser la classe ShaderTechnique. Voir cet article.

– Savoir un peu utiliser DirectX 10.

Explications :

Voici le fichier Renderable.h :

 

Voici le fichier Renderale.cpp :

 

Résumé :

Cette classe pourra servir à être dérivée pour afficher vos contenus 3D : image, quad de post-effect, rendu 3D, etc..

Différents types de déclarations de vertex pour DirectX 10

nvidia-quadro-graphics-card

Intro :

Dans nos programmes de rendu 3D nous avons besoin d’utiliser différents types de configurations de vertex.

Prérequis :

– Savoir utiliser les Vertex Input Layouts. Voir cet article.

Explications :

Les voici :

 

Résumé :

Nous avons présenté différents types de configurations de vertex dont vous pouvez vous inspirer.

Obtenir la taille d’une texture ressource shader

equerre

Intro :

Parfois nous avons besoin d’obtenir la taille d’une ressource shader de texture rapidement.

Explications :

Voici comment l’obtenir :

 

Résumé :

Nous avons vu comment obtenir les dimensions d’un ressource shader de texture.

Structures de DirectX 10

Intro :

1211804249

DirectX 10 utilise différentes structures pour se configurer.
Il peut être utile de les connaître afin de maitriser l’initialisation de DirectX 10.

[à faire]     D3D10_TEXTURE2D_DESC textureDesc;
D3D10_RENDER_TARGET_VIEW_DESC renderTargetViewDesc;
D3D10_SHADER_RESOURCE_VIEW_DESC shaderResourceViewDesc;

Les voici énumérées :

– DXGI_SWAP_CHAIN_DESC :

– utilisée pour configurer la Swap Chain au tout début de l’initialisation de DirectX

– D3D10_TEXTURE2D_DESC :

– utilisée pour décrire une surface 2D

– D3D10_BUFFER_DESC :

– utilisée pour décrire un buffer quelconque

– D3D10_RASTERIZER_DESC :

– utilisée pour configurer l’étape Rasterizer de la chaîne de rendu 3D

– D3D10_VIEWPORT :

– utilisée pour configurer un cadre de vue 3D

– D3D10_SAMPLER_DESC :

– utilisée pour décrire l’échantillonnage d’une texture utilisable dans un shader

– D3D10_COMPARISON_FUNC :

– utilisée pour spécifier la fonction de comparaison entre deux valeurs

– D3D10_USAGE :

– utilisée pour spécifier comment est gérée une ressource par le CPU ou le GPU

 –  DXGI_SWAP_CHAIN_DESC :

Explications :

Avant tout configuration de structure, pensez à l’initialiser à zéro avec la macro :

 

Pour DXGI_SWAP_CHAIN_DESC :

On la configure ainsi :

 

Pour D3D10_TEXTURE2D_DESC :

On la configure ainsi :

 

Pour D3D10_BUFFER_DESC :

On la configure ainsi :

 

Pour D3D10_RASTERIZER_DESC :

On la configure ainsi :

 

Pour D3D10_VIEWPORT :

On la configure ainsi :

 

Pour D3D10_SAMPLER_DESC :

On la configure ainsi :

 

Pour D3D10_USAGE :

Voici comment la configurer :

 

Résumé :

Nous avons appris le rôle que joue chaque structure de DirectX 10 afin de mieux comprendre son fonctionnement.

Références :

– DirectX June 2010 SDK Documentation

Un cube tout simple en 3D

cube

Intro :

Voici l’implémentation d’un cube tout simple par la définition de ses vertices et indices.

Il peut être utilisé pour faire des tests ou pour déboguer vos jeux.

Explications :

Dans le fichier Cube.h :

 

Dans le fichier Cube.cpp :

 

Résumé :

Nous avons implémenter le code pour afficher un petit cube.

Voici les fichiers sources : Simple Cube.zip.

Principe du Z-buffer

zbuffer

Intro :

L’utilisation du Z-buffer est une méthode consistant à afficher dans le bon ordre de profondeur les primitives géométriques envoyées au rendu 3D.

Prérequis :

– Comprendre les principales étapes de rendu de DirectX : voir cet article

Explications :

La technique du Z-buffer consiste à enregistrer pour chaque pixel une valeur de profondeur dans un tampon dédié (en l’occurrence le Z-buffer). Ce tampon a la même dimension que celui du frame buffer. Ces valeurs dans le tampon varient de 0.0f à 1.0f.

Lors de la transformation du repère 3D (celui des meshes / modèles) vers le repère 2D (celui de l’écran) nous avons bien les pixels sur les coordonnées (x, y) conservées mais nous avons perdu l’information sur la profondeur (z) ; il faut la recalculer par un algorithme adjacent.

 

1) Comment ça fonctionne ?

Avant qu’un pixel est affiché dans le tampon de rendu, sa valeur de profondeur est comparée
par sa valeur correspondante actuelle dans le Z-buffer. Si le pixel a sa valeur de profondeur inférieure ou égale alors le pixel est affiché et cette valeur est enregistrée dans le Z-buffer ; autrement le pixel est ignoré.

La carte graphique compare deux profondeurs (Z) une à une, et n’affiche que le pixel le plus proche de la caméra. Ensuite DirectX va automatiquement ignorer l’affichage des triangles cachés par d’autres triangles.

2) Comment le paramétrer ?

Le calcul effectué par le Z-buffer peut être ignoré et désactiver par un appel de l’API DirectX (voir cet article). Lorsqu’il est ignoré par DirectX, les derniers éléments dessinés seront affiché par dessus tous les autres.

Il faut noter aussi qu’à chaque tour de boucle le Z-buffer est réinitialisé et recalculé par cet appel :


Résumé :

Nous avons expliqué quel est le rôle du tampon de profondeur (le Z-buffer) dans le rendu 3D.
En effet cette étape permet de cacher les triangles placés à l’arrière d’autres triangles moins proches de la caméra.

Références :

– http://fr.wikipedia.org/wiki/Z-buffer

– http://www.toymaker.info/Games/html/z-buffer.html

Les principales fonctions de la bibliothèque D3DX (DirectX 10)

jigsawpuzzle

Intro :

La bibliothèque D3DX (D3DX utility library) implémente plusieurs fonctions courantes afin de faciliter certaines tâches d’utilisation de l’API 3D DirectX 10.

Nous verrons les objets de cette bibliothèque suivant :

– ID3DX10Sprite

– ID3DX10Font

– ID3DX10Mesh

Prérequis :

– Savoir comment initialiser correctement DirectX 10 (voir ces articles)

Explications :

 


 

ID3DX10Sprite :

Permet de simplifier l’affichage d’images 2D.

On créé cet objet avec la fonction : D3DX10CreateSprite()

J’ai déjà expliqué son utilisation dans cet article (dans la première méthode)

 


 

ID3DX10Font :

Permet d’afficher du texte à l’écran avec une police de font donnée.

On déclare les objets ID3DX10Font et ID3DX10Sprite :

On initialise plus loin ces objets comme suit :

 

Dans la boucle de rendu on ajoute :

Le paramètre D3DX10_SPRITE_SAVE_STATE permet de restaurer les états du rendu 3D après l’appel End() comme ils étaient configurés avant l’appel Begin().

On désactive l’écriture sur le Z-Buffer pour préserver la profondeur de ce qui est affiché avant l’appel à m_pFontText().

 


 

ID3DX10Mesh :

 

Les Vertex Input Layouts

 

nvidia-quadro-graphics-card

Intro  :

Dans le cas basique, et en général, un vertex a pour attribut seulement sa position. Il existe cependant un mécanisme où il est possible de rajouter d’autres attributs comme : une normale, une couleur, des coordonnées de textures, etc… Je vais tenter de vous expliquer ce mécanisme.

Explications :

Avant tout, lors de l’étape de rendu Input Assembler (voir cet article) les données géométriques présentes dans la mémoire vidéo (composées de ces attributs) sont reçues puis traitées par le Vertex Shader.

Dans DirectX 10, la configuration de ces attributs s’opère sur l’initialisation d’une structure appelée D3D10_INPUT_ELEMENT_DESC.

Ici en tant qu’exemple cette structure (appelée dans le jargon anglais « Vertex Input Layout ») s’implémente ainsi :

Elle permet de définir en mémoire vidéo la façon dont sont agencées les vertex.
Remarque : La taille d’un vertex en mémoire équivaut à la taille de cette structure implémentée.

Une structure correspondante est aussi utilisée dans notre programme :

 


 

Voici les variables de cette fameuse structure :

Paramètres :

SemanticName :

Nom de la « sémantique » de la variable.

Une « sémantique » est une chaîne de caractère qui indique dans quel but la variable doit être utilisée.

Ici son rôle est la position donc on met : « POSITION ».
On peut mettre aussi « NORMAL », « COLOR », « TEXCOORD », etc…

SemanticIndex :

C’est un index (un nombre entier) qui désigne le numéro d’un sémantique qui a déjà été déclaré.

Par exemple, si on déclare deux textures avec sémantique « TEXTURE », on mettra comme SemanticIndex pour le premier champ « 0 » et pour le deuxième champ « 1 ».

Format :

Le format définit le type de données qui sera utilisé pour cet élément.

Par exemple, pour DXGI_FORMAT_R32G32B32_FLOAT : il s’agit d’un attribut avec comme type un flottant et 8 octets alloués par couleur.

InputSlot :

Dans l’étape Input Assembler on peut définir jusqu’à 16 Vertex buffer qui peuvent être utilisés par la carte graphique avant d’être envoyés au Vertex Shader.

Ici on spécifie quel Vertex buffer doit être utilisé par cet attribut.

AlignedByteOffset :

Ce champ dit à la carte graphique quel l’emplacement mémoire pour commencer à aller chercher les données pour cet attribut.
Indiquez D3D10_APPEND_ALIGNED_ELEMENT pour que cet emplacement soit défini de manière automatique.

InputSlotClass :

Cet attribut est utilisé pour gérer l’Instancing. Voir cet article.

InstanceDataStepRate :

Cet attribut est utilisé pour gérer l’Instancing. Voir cet article.

Au final on peut créer cette composition de vertex par le biais de cette méthode : ID3D10Device::CreateInputLayout.

 


 

 

Résumé :

La déclaration d’une structure / composition de vertex permet à la carte graphique de regrouper les informations utiles concernant les vertex en mémoire vidéo avant d’être traités et envoyés au Vertex Shader.

Références :

– http://msdn.developpez.com/direct3d/10/tutoriels/base/

– https://msdn.microsoft.com/en-us/library/windows/desktop/bb205316%28v=vs.85%29.aspx

– https://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx

Index buffer et Vertex buffer

AMD_6990

Intro :

Les notions d’Index buffer et de Vertex buffer sont fondamentales dans la compréhension des étapes de rendu 3D de modèles / meshes. Ils sont appelés sommets et d’indices en français.

Prérequis :

– Aucun

Vertex :

D’abord, qu’est-ce qu’un vertex ?

On peut imaginer un vertex comme un simple point dans un espace 3D. Ce sont ces vertex qui nous permettront de construire les primitives de base (points, lignes, triangles). Et c’est ces primitives nous permettrons de construire des modèles / objets dans le rendu 3D.

Index / Indice :

Qu’est-ce qu’un index (indice) ? Il faut noter que ce sont juste des nombres que l’on va utiliser par groupe de 3 pour représenter l’ordre d’utilisation d’un triangle.

Autrement dit, c’est un triplet d’index qui sert à indiquer à la carte graphique dans quel ordre sont utilisés les vertex affichés par celle-ci. Ces index peuvent servir à réutiliser les vertices précédemment déclarés.

Vertex buffer :

Un Vertex buffer est simplement une interface stockant les informations sur les vertices d’un modèle du jeu. C’est un tableau situé dans la mémoire de la carte graphique.

On peut stocker dans un vertex buffer des informations : comme la position, les vecteurs normales, les coordonnées d’une texture ou encore même la couleur, voir même n’importe quoi…

Index buffer :

De même que le Vertex buffer,  c’est une interface qui stocke les indices présents dans un tableau contigu.


Déclaration de vertex :

Pour que la carte graphique comprenne comment sont agencées les données d’un vertex buffer, il faut déclarer une structure correspondante. On appel cela une « déclaration de vertex ».

 


 

Avant tout il faut définir une structure correspondante et représentative du type de Vertex :


Code C++ d’implémentation d’un Vertex Buffer statique :


Code C++ d’implémentation d’un Index Buffer :


Résumé :

Pour afficher un modèle dans un rendu 3D on a besoin de définir comment il est représenté : c’est-à-dire par deux tableaux d’informations de Vertex et d’Indices et une déclaration de vertex.