docs: reconcile README/ROADMAP/PLAN state and settle slotmap vs String IDs
- README stays the source of truth for current state; drive/item-5 now reflects the settled decision: String IDs for the MVP, slotmap deferred. - ROADMAP gains a 'point de depart' (present-state) block, marks glam done, removes the slotmap Phase-1 mandates, and documents the String-ID decision plus the deferred 'typed handles' step. - PLAN corrects stale [X] checkmarks (App render() cannot draw, Scene rendering not automated, simple example does not compile) and notes its verification checklist against current reality. - Remove the unused slotmap direct dependency from wsg-lib (package remains in Cargo.lock only as a transitive dep of glow).
This commit is contained in:
Jérôme Bousquié
+13
-7
@@ -11,6 +11,12 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
|
||||
|
||||
Ce plan définit les étapes prioritaires pour finaliser l'architecture actuelle. L'objectif est de rendre l'API intuitive pour l'utilisateur standard tout en conservant la puissance de contrôle pour l'utilisateur avancé.
|
||||
|
||||
> **Statut réel (à jour au 2026-09-14).** Ce plan couvre la phase de *consolidation* passée ; la source
|
||||
> de vérité sur l'état actuel est **README.md** et le code. Plusieurs cases `[X]` ci-dessous ont été
|
||||
> re-corrigées car elles ne reflétaient plus la réalité : notamment l'exemple `simple` **ne compile pas**
|
||||
> actuellement (`App::new()` obsolète, à remplacer par `AppBuilder`) et le rendu de la `Scene` n'est
|
||||
> **pas automatisé** (items Phase 2 et Check-list concernés).
|
||||
|
||||
## Phase 1 : Finalisation et Nettoyage de l'Existant (Priorité Absolue)
|
||||
|
||||
Cette phase vise à supprimer la dette technique et à unifier les accès.
|
||||
@@ -39,19 +45,19 @@ Une fois la plomberie encapsulée, nous devons rendre l'assemblage des objets co
|
||||
### Intégration de la Scene
|
||||
|
||||
- [X] Formaliser la structure `Scene` : un conteneur qui liste les Entities.
|
||||
- [X] Associer le `PipelineCache` à la Scene pour que le rendu des matériaux soit automatique.
|
||||
- [X] Implémenter la logique `app.render(scene)` : cette méthode doit parcourir la scène, récupérer les matériaux, gérer les pipelines via le cache, et soumettre les draw calls.
|
||||
- [ ] Associer le `PipelineCache` à la Scene pour que le rendu des matériaux soit automatique (actuellement le cache est porté par `App`, indépendant de la Scene ; le rendu n'est pas automatisé).
|
||||
- [ ] Implémenter la logique `app.render(scene)` : cette méthode doit parcourir la scène, récupérer les matériaux, gérer les pipelines via le cache, et soumettre les draw calls (non implémenté — cf. README, étape 1 du Roadmap : scene auto-rendering).
|
||||
|
||||
### Gestion des Matériaux et Shaders
|
||||
|
||||
- [X] S'assurer que chaque Mesh possède une référence vers un Material.
|
||||
- [X] Implémenter le comportement par défaut : si aucun matériau n'est assigné, le moteur injecte automatiquement le `basic_shader`.
|
||||
- [ ] S'assurer que chaque Mesh possède une référence vers un Material (à l'heure actuelle le lien est porté par l'entité `(mesh_id, material_id)` de la Scene, pas par le Mesh lui-même).
|
||||
- [ ] Implémenter le comportement par défaut : si aucun matériau n'est assigné, le moteur injecte automatiquement le `basic_shader` (non implémenté).
|
||||
|
||||
## Phase 3 : Documentation et Interface (API "User-Friendly")
|
||||
|
||||
### Refonte des Exemples
|
||||
|
||||
- [X] `simple.rs` doit devenir le modèle : **15 lignes** de code, pas de manipulation WGPU explicite.
|
||||
- [ ] `simple.rs` doit devenir le modèle : **15 lignes** de code, pas de manipulation WGPU explicite (actuellement ne compile pas — API obsolète `App::new()` → `AppBuilder`).
|
||||
- [X] `manual.rs` doit rester disponible en tant que tutoriel pour ceux qui veulent contourner l'abstraction App.
|
||||
|
||||
### Nettoyage du Code Interne
|
||||
@@ -68,8 +74,8 @@ Une fois les phases 1 à 3 validées, nous pourrons introduire :
|
||||
|
||||
## Check-list de Vérification pour le LLM d'Assistance
|
||||
|
||||
- [X] Est-ce que `simple.rs` compile sans importer `winit` ou `wgpu` ?
|
||||
- [X] Est-ce que `App::run` gère bien le cycle update → render → present ?
|
||||
- [ ] Est-ce que `simple.rs` compile sans importer `winit` ou `wgpu` ? (ne compile pas actuellement ; `App::new()` → `AppBuilder`)
|
||||
- [ ] Est-ce que `App::run` gère bien le cycle update → render → present ? (boucle + présentation OK, mais `render()` ne peut pas encore dessiner — vue de frame non exposée)
|
||||
- [X] Les modules sont-ils bien exposés via `lib.rs` ?
|
||||
- [X] `pollster` est-il uniquement en dev-dependencies ?
|
||||
|
||||
|
||||
+15
-9
@@ -11,6 +11,14 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
|
||||
|
||||
> Basé sur l'architecture existante (ARCHI_APP, ARCHI_ARENES, ARCHI_CPU_GPU, ARCHI_RENDU).
|
||||
> Objectif : prototype fonctionnel d'abord, enrichissement progressif ensuite.
|
||||
>
|
||||
> **Point de départ (état réel au 2026-09-14 — la source de vérité est README.md).**
|
||||
> Les fondations suivantes existent et fonctionnent déjà ; cette roadmap décrit la **trajectoire à
|
||||
> venir** à partir de cet état (elle reprend les étapes 1-4 du README avant la montée GPU-driven) :
|
||||
> - Workflow manuel (`Context` + `Renderer` + `PipelineCache`) : ✅ fonctionnel (exemple `manual`).
|
||||
> - Façade `App` / `AppBuilder` / `AppHandler` : 🚧 scaffold — boucle et présentation OK, mais `render()` ne peut pas encore dessiner (vue de frame non exposée) et le rendu de la scène n'est pas automatisé.
|
||||
> - `Scene` avec identifiants **String** (décision prise — voir tableau Notes de Décision) : 🚧 enregistrement seul.
|
||||
> - `Camera` / `Transform` et `glam` : types et mathématiques présents (`math/`, `resources/camera.rs`), non branchés au pipeline.
|
||||
|
||||
---
|
||||
|
||||
@@ -19,8 +27,8 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
|
||||
**Objectif** : Afficher un cube (ou autre mesh) 3D avec un éclairage Phong basique.
|
||||
|
||||
### 1.1 Dépendances & Mathématiques
|
||||
- [ ] Ajouter `glam = "0.33"` en dépendance (`lib/Cargo.toml`)
|
||||
- [ ] Ajouter `slotmap = "1.0"` en dépendance
|
||||
- [x] `glam = "0.33"` ajouté (`lib/Cargo.toml`) — déjà présent, utilisé par `math/transform.rs` et `resources/camera.rs`
|
||||
- [x] `slotmap` **retiré** — décision prise : **String IDs pour le MVP** ; slotmap reporté à l'étape "handles typés" (voir Notes de Décision)
|
||||
- [ ] Créer module `math/` (ou `transform.rs`) :
|
||||
- [ ] Struct `Transform { translation: Vec3, rotation: Quat, scale: Vec3 }`
|
||||
- [ ] Méthode `to_matrix() -> Mat4` pour calculer la matrice locale
|
||||
@@ -46,12 +54,10 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
|
||||
- [ ] Uniforms : `view_matrix`, `proj_matrix`, `world_matrix`, `light_dir`, `light_color`
|
||||
- [ ] Mettre à jour `Material` pour supporter les uniforms du shader Phong
|
||||
|
||||
### 1.4 Scene avec Arènes (slotmap)
|
||||
- [ ] Implémenter `Scene` avec arènes générationalles :
|
||||
- [ ] `SlotMap<MeshId, Mesh>`
|
||||
- [ ] `SlotMap<MaterialId, Material>` (préparation future)
|
||||
- [ ] Méthodes : `add_mesh()`, `get_mesh()`, `iter_meshes()`
|
||||
- [ ] Les entités stockent des `MeshId` (handles typés), pas des références
|
||||
### 1.4 Scene avec identifiants (MVP : String IDs)
|
||||
- [x] `Scene` implémentée avec **String IDs** (`HashMap<String, Arc<Mesh>>`, `...Material`, entités) — état actuel validé ; décision : rester en String IDs pour le MVP
|
||||
- [x] Méthodes : `add_mesh()`, `get_mesh()`, `add_material()`, `add_entity()`, `iter_entities()`, `remove_entity()`
|
||||
- [ ] **Reporté (étape "Handles typés")** : migrer vers `slotmap` générationnel (`MeshId`/`MaterialId`) quand l'éviction/les performances le justifieront
|
||||
|
||||
### 1.5 Rendu du Prototype
|
||||
- [ ] Uniform buffer pour la frame : `view_matrix`, `proj_matrix`, `light_dir`
|
||||
@@ -143,4 +149,4 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
|
||||
| **UVs en Phase 4** | Inutiles avant les textures ; on garde `Geometry` simple au départ |
|
||||
| **BBox en Phase 3** | Utile uniquement pour le frustum culling GPU |
|
||||
| **World Matrix CPU → MVP, GPU → Phase 3** | Le MVP est plus simple avec un uniform par mesh ; la migration GPU-driven est progressive |
|
||||
| **slotmap dès Phase 1** | Architecture décidée (`ARCHI_ARENES.md`) ; mieux de l'adopter tôt que de refactorer |
|
||||
| **String IDs pour le MVP, slotmap reporté** | Le code et le README utilisent des String IDs (simples, sûrs, figés avant la boucle de rendu) ; `ARCHI_ARENES.md` reste la cible "handles typés" pour plus tard. La dépendance `slotmap` a été retirée tant qu'elle est inutilisée |
|
||||
|
||||
Reference in New Issue
Block a user