refactor renderer responsable + docs + schema
This commit is contained in:
Jérôme Bousquié
+18
-39
@@ -1,62 +1,41 @@
|
||||
# ARCHI_MESH_MATERIAL.md (Version corrigée)
|
||||
# ARCHI_MESH_MATERIAL.md
|
||||
|
||||
## La nouvelle vision architecturale : L'Atelier de Rendu
|
||||
|
||||
Pour comprendre notre structure, imagine que tu veux peindre 10 tableaux différents.
|
||||
|
||||
**Avant :** Chaque tableau possédait sa propre cuisine, son propre chef (le pipeline), et son propre matériel. C'était inefficace et lourd.
|
||||
**Avant :** Chaque tableau possédait sa propre cuisine et ses propres outils. C'était inefficace.
|
||||
|
||||
**Après :** Tu as un Atelier (Renderer) qui orchestre le dessin. Il utilise des Recettes (Material + PipelineCache) pour définir l'apparence et traite des Toiles (Mesh) pour la géométrie. Tu peux utiliser la même recette pour 50 toiles différentes sans effort.
|
||||
**Après :** Tu as un Atelier (`Renderer`) qui orchestre le dessin et possède les outils de base (`Device`, `Queue`, `Format`). Il utilise des Recettes (`Material` + `PipelineCache`) pour définir l'apparence et traite des Toiles (`Mesh`) pour la géométrie.
|
||||
|
||||
---
|
||||
|
||||
## 1. Le Mesh (La Géométrie)
|
||||
|
||||
Il est purement passif. Il ne sait pas comment il est affiché, il sait seulement ce qu'il est.
|
||||
|
||||
- **Contenu :** `vertexBuffer`, optionnellement `indexBuffer`, et les compteurs associés (`num_vertices`, `num_indices`).
|
||||
- **Contenu :** `vertex_buffer`, optionnellement `index_buffer`, et les compteurs (`num_vertices`, `num_indices`).
|
||||
- **Rôle :** Fournir les données brutes au GPU.
|
||||
|
||||
---
|
||||
|
||||
## 2. Le Material & PipelineCache (Le Look & La Recette)
|
||||
Le look est découplé de la géométrie via une gestion centralisée.
|
||||
|
||||
Le look est désormais découplé de la géométrie via une gestion centralisée.
|
||||
|
||||
**PipelineCache :** C'est la bibliothèque de recettes. Il charge les shaders (WGSL), compile les RenderPipeline, et les met en cache (via `HashMap` + `Arc`) pour éviter de dupliquer les ressources GPU.
|
||||
|
||||
**Material :** C'est une instance légère qui pointe vers une recette compilée. Il contient un `shader_id` et une référence partagée (`Arc`) vers le RenderPipeline.
|
||||
|
||||
- **Rôle :** Garantir la réutilisation. Si 100 objets partagent le même shader, ils pointent tous vers la même instance compilée en mémoire.
|
||||
- **PipelineCache :** Bibliothèque de recettes. Il charge les shaders (WGSL), compile les `RenderPipeline`, et les met en cache (via `HashMap` + `Arc`) pour éviter de dupliquer les ressources GPU.
|
||||
- **Material :** Instance légère qui pointe vers une recette compilée. Il contient un `shader_id` et une référence partagée (`Arc`) vers le `RenderPipeline`.
|
||||
- **Rôle :** Garantir la réutilisation. Si 100 objets partagent le même shader, ils pointent tous vers la même instance compilée.
|
||||
|
||||
---
|
||||
|
||||
## 3. Le Renderer (L'Orchestrateur)
|
||||
## 3. Le Renderer (L'Orchestrateur propriétaire)
|
||||
Le `Renderer` a été promu au rang de propriétaire des ressources matérielles.
|
||||
|
||||
Il est devenu ultra-léger et généraliste. Il ne possède plus aucun buffer ni pipeline en dur.
|
||||
|
||||
- **Contenu :** Aucun état lourd.
|
||||
- **Rôle :** Il fait la liaison au moment de l'appel :
|
||||
- **Contenu :** `device`, `queue`, `format`.
|
||||
- **Rôle :**
|
||||
1. **Initialisation :** Reçoit le `Context` au démarrage et s'approprie ses ressources.
|
||||
2. **Exécution :** Orchestre les appels GPU en utilisant ses ressources internes. Il expose une API simplifiée qui ne demande plus à l'utilisateur de manipuler le `device` ou la `queue`.
|
||||
3. **Présentation :** Possède la méthode `present(frame)` qui utilise sa `queue` interne pour afficher l'image.
|
||||
|
||||
```rust
|
||||
// Schématiquement
|
||||
render_pass.set_pipeline(&material.pipeline); // On change de recette
|
||||
render_pass.set_vertex_buffer(0, mesh.vertex_buffer.slice(..)); // On pose la toile
|
||||
// Puis dessin indexé ou simple...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pourquoi cette structure est-elle meilleure ?
|
||||
|
||||
1. **Performance :** Les shaders sont compilés une seule fois. La mémoire GPU est optimisée grâce au partage des RenderPipeline via `Arc`.
|
||||
2. **Modularité :** Tu peux combiner n'importe quel Mesh avec n'importe quel Material.
|
||||
3. **Propreté :** Ton Renderer est désormais un orchestrateur pur. Il ne connaît plus le détail des shaders ou des layouts de sommets : il se contente d'exécuter la commande de dessin.
|
||||
|
||||
---
|
||||
|
||||
## Quelques notes techniques pour ta doc
|
||||
|
||||
- **Découplage :** Le Material demande au PipelineCache de lui fournir un pipeline au moment de sa création.
|
||||
- **Sécurité :** Le PipelineCache utilise un `HashMap` pour retrouver instantanément un pipeline existant par son `shader_id`, évitant les compilations inutiles.
|
||||
- **Flexibilité :** Le Mesh gère lui-même ses indices, permettant de passer facilement du rendu simple au rendu indexé optimisé.
|
||||
// Exemple d'orchestration simplifiée dans main.rs
|
||||
renderer.render(frame.view(), &mesh, &material);
|
||||
renderer.present(frame); // Plus besoin de passer la queue !
|
||||
|
||||
Reference in New Issue
Block a user