Jérôme Bousquié
63 lines
2.9 KiB
Markdown
63 lines
2.9 KiB
Markdown
# ARCHI_MESH_MATERIAL.md (Version corrigée)
|
|
|
|
## 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.
|
|
|
|
**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.
|
|
|
|
---
|
|
|
|
## 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`).
|
|
- **Rôle :** Fournir les données brutes au GPU.
|
|
|
|
---
|
|
|
|
## 2. Le Material & PipelineCache (Le Look & La Recette)
|
|
|
|
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.
|
|
|
|
---
|
|
|
|
## 3. Le Renderer (L'Orchestrateur)
|
|
|
|
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 :
|
|
|
|
```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é.
|