Plan d'Implémentation : Consolidation et Finalisation du Moteur wsg_lib

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é.

Phase 1 : Finalisation et Nettoyage de l'Existant (Priorité Absolue)

Cette phase vise à supprimer la dette technique et à unifier les accès.

Uniformisation des Modules

Vérifier que tous les traits (AppHandler) et structures (App, Context) sont explicitement marqués pub dans leurs fichiers sources.
Ré-exporter l'API dans lib.rs pour permettre des imports simplifiés (ex : use wsg_lib::{App, AppHandler}).
Nettoyer les accès internes pour que l'utilisateur n'ait pas à importer les modules système (core, pipeline) sauf besoin spécifique.

Abstraction de la Boucle (`App::run`)

Déplacer la gestion de winit::event_loop et des Frame à l'intérieur de la méthode run() de App.
Garantir que le trait AppHandler reçoit une référence à App permettant d'appeler app.renderer ou app.scene.
Supprimer toute gestion de Frame ou EventLoop manuelle des exemples utilisateurs (simple.rs).

Correction du Builder et Initialisation

Standardiser la création de App via un AppBuilder robuste.
Gérer les dev-dependencies dans lib/Cargo.toml (notamment pollster avec la feature macro) pour permettre la compilation des exemples sans polluer les dépendances finales de la librairie.

Phase 2 : Structure de Rendu et Scène

Une fois la plomberie encapsulée, nous devons rendre l'assemblage des objets cohérent.

Intégration de la Scene

Formaliser la structure Scene : un conteneur qui liste les Entities.
Associer le PipelineCache à la Scene pour que le rendu des matériaux soit automatique.
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.

Gestion des Matériaux et Shaders

S'assurer que chaque Mesh possède une référence vers un Material.
Implémenter le comportement par défaut : si aucun matériau n'est assigné, le moteur injecte automatiquement le basic_shader.

Phase 3 : Documentation et Interface (API "User-Friendly")

Refonte des Exemples

simple.rs doit devenir le modèle : 15 lignes de code, pas de manipulation WGPU explicite.
manual.rs doit rester disponible en tant que tutoriel pour ceux qui veulent contourner l'abstraction App.

Nettoyage du Code Interne

Vérifier les durées de vie (lifetimes) et les Arc pour s'assurer qu'aucune fuite mémoire ou accès concurrentiel invalide ne survient lors des changements de frame.

Phase 4 : Nouvelles Fonctionnalités (Planification Future)

Une fois les phases 1 à 3 validées, nous pourrons introduire :

Système de Lumières : Ajout de buffers d'uniformes dans le PipelineCache.
Textures : Intégration d'un module de chargement d'images et de BindGroups.
Caméras : Gestion des matrices de projection/vue dans la Scene.

Check-list de Vérification pour le LLM d'Assistance

Est-ce que simple.rs compile sans importer winit ou wgpu ?
Est-ce que App::run gère bien le cycle update → render → present ?
Les modules sont-ils bien exposés via lib.rs ?
pollster est-il uniquement en dev-dependencies ?

Ce plan garantit que les fondations sont saines. Une fois la Scene rendue automatiquement par app.render(), l'ajout de toute nouvelle fonctionnalité (lumières, textures) deviendra une simple question d'ajout de données dans la structure de scène, sans modification de la boucle de rendu.

4.2 KiB Raw Blame History