SEQUA-Engine/docs/SEQUA_Engine_resume_complet_v2.md

SEQUA Engine

SEQUA signifie Simulate Environments, Quantify Uncertainty, Adapt.

Cette phrase exprime la philosophie du projet : simuler des environnements, quantifier l'incertitude liée à leur représentation et aux traitements nécessaires, puis adapter les méthodes de calcul et de rendu au contexte.

Version 2 : refonte autour de SEQUA Studio, de la création guidée par l'intention et de l'indépendance vis-à-vis des moteurs d'exécution.

---

1. Synthèse

SEQUA Engine est un environnement de création et d'exécution de mondes virtuels dont le premier domaine d'application est le jeu vidéo. Il repose sur un changement de paradigme :

Ce que l'utilisateur recherche n'est plus la maîtrise technique, mais l'expression d'une volonté artistique, la finesse du gameplay et l'innovation des modes de jeu.

SEQUA est composé de quatre couches :

1. SEQUA Studio : l'outil de création, cœur et visage du produit. Il est puissant, novateur, et pensé pour des personnes, pas pour des paramètres.
2. SEQUA Core : la source de vérité. Il possède le format de projet, la simulation déterministe, l'enregistrement et le rejeu, la couche d'intention, l'orchestrateur de rendu et la mesure de l'incertitude. Il ne connaît aucun moteur 3D.
3. SEQUA 3D : la couche d'interface 3D, propriété de SEQUA. Elle définit le contrat de données, la synchronisation de la scène, la négociation des capacités et les adaptateurs vers les moteurs. C'est par elle, et par elle seule, que SEQUA parle à un moteur 3D.
4. Moteurs 3D : les vrais moteurs d'exécution qui affichent et font tourner le monde (Godot en premier, Unreal ensuite, puis un moteur maison). Ils sont interchangeables et ne contiennent aucune logique du produit.

SEQUA n'est pas un plugin d'un autre moteur. Les moteurs existants sont des composants que SEQUA pilote, pas des hôtes dont il dépend. Le projet, la scène de référence, les règles et les intentions appartiennent à SEQUA.

Principe directeur : la simulation détermine ce qui existe et ce qui se passe ; l'intention de l'auteur détermine ce que le monde doit faire ressentir ; les systèmes neuronaux et génératifs déterminent comment il apparaît.

Le projet ne cherche pas à réinventer la roue, mais à lui ajouter des pneus modernes : les bibliothèques existantes sont utilisées partout où elles sont mûres, derrière des contrats stables permettant de les remplacer plus tard.

2. Manifeste

Principes

1. L'humain garde l'autorité. L'IA propose, l'auteur choisit, épingle et retouche. Aucune génération ne remplace une décision de création.
2. L'intention est un objet de première classe. Une ambiance, un rythme, une émotion visée sont stockés, versionnés, et pilotent le rendu, le gameplay et les budgets.
3. La simulation est déterministe et rejouable. C'est ce qui permet de comparer, de revenir en arrière et de tester des variantes à l'identique.
4. L'apparence est séparée de la vérité du monde. Collisions, règles et persistance ne dépendent jamais d'un modèle génératif.
5. L'incertitude est mesurée, pas ignorée. Chaque sortie neuronale ou générative porte une confiance, utilisée pour décider, composer et informer l'auteur.
6. Le non-déterminisme est visible et maîtrisable. Graines, modes figés, provenance de chaque élément généré.
7. Les moteurs d'exécution sont interchangeables. Si changer de moteur 3D oblige à toucher au projet, l'architecture a échoué.
8. Le rendu IA est optionnel. Le moteur reste utilisable en 3D classique sur du matériel modeste.
9. Divulgation progressive. L'artiste travaille au niveau de l'intention ; l'expert peut toujours descendre à la couche technique.
10. Open source. SEQUA est publié sous MPL 2.0 tant que le projet est porté par ses auteurs. Les dépendances du cœur sont permissives ; tout composant propriétaire n'entre que comme plugin facultatif (voir §10.2).
11. Multiplateforme par conception. Windows, Linux et macOS sont compilés et testés dès le premier jour ; les fonctions les plus lourdes (IA, génération) peuvent arriver plateforme par plateforme, mais l'architecture ne suppose jamais une seule plateforme.

Test d'identité

Avant d'ajouter une fonctionnalité, on pose la question :

Est-ce seulement la version IA de quelque chose qui existe déjà dans un moteur classique ?

Si oui, elle est reportée ou abandonnée. « Générer une texture depuis une description » existe partout. « Rejouer à l'identique une session avec une règle modifiée » ou « peindre une ambiance sur une région avec carte de confiance » sont rares. Ce test sert à resserrer le périmètre sans perdre l'essence du projet.

3. Architecture générale

                        SEQUA STUDIO
   (intentions, ressenti, modes de jeu, comparaison, direction)
                              |
                       commandes / état
                              v
                         SEQUA CORE
   +----------------------------------------------------------+
   |  Projet et scène de référence   |  Couche d'intention     |
   |  Simulation déterministe        |  Enregistrement / rejeu |
   |  Orchestrateur de rendu         |  Confiance et budgets   |
   +----------------------------------------------------------+
                              |
                              v
                          SEQUA 3D
   +----------------------------------------------------------+
   |  Contrat de données (NeuralFrameContext, état du monde,  |
   |  commandes, mesures)  |  Synchronisation de la scène     |
   |  Négociation des capacités  |  Adaptateurs               |
   +----------------------------------------------------------+
                              |
        +---------------------+---------------------+
        v                     v                     v
   +-----------+        +-----------+        +----------------+
   | Moteur 3D |        | Moteur 3D |        | Moteur 3D      |
   | Godot     |        | Unreal    |        | Maison (futur) |
   +-----------+        +-----------+        +----------------+
                              |
                    rendu : 3D / neuronal / génératif
                              v
                  compositeur temporel -> affichage
                    (et mesures renvoyées à Studio)

Responsabilités

Partie	Responsabilité
SEQUA Studio	Création, direction artistique, ressenti, modes de jeu, comparaison, débogage temporel, collaboration
SEQUA Core	Format de projet, scène de référence, simulation déterministe, enregistrement et rejeu, intentions, orchestrateur, confiance
SEQUA 3D	Contrat de données, synchronisation de la scène vers le moteur, négociation des capacités, adaptateurs, traduction des commandes et des mesures
Moteurs 3D	Exécution du rendu et de l'affichage, production des tampons demandés, remontée des mesures
Rendus (3D, neuronal, génératif)	Produire l'apparence selon les consignes de l'orchestrateur

4. SEQUA Studio

Studio est le produit que l'utilisateur voit et juge. Il vise à rapprocher la création de jeu vidéo d'un travail d'auteur : on dirige un monde, on ne règle pas des paramètres.

4.1 Couche d'intention

Chaque région, moment ou objet peut porter une intention : ambiance (« refuge », « tension montante »), références visuelles, palette, rythme, contraintes de conservation.

• Studio traduit l'intention en paramètres concrets (éclairage, matériaux, génération, budgets de calcul).
• Un mode « couche technique » reste accessible : on voit et on peut modifier ce que l'intention a produit.
• Pour que l'intention ne soit pas une promesse magique, elle repose sur un vocabulaire restreint, relié à des paramètres mesurables et validé par des tests (voir §12).

4.2 Laboratoire de ressenti (game feel)

Saut, caméra, arrêt sur impact, tolérance de saisie, inertie : on les règle en jouant, avec des courbes manipulables directement. Grâce à la simulation déterministe, une session enregistrée peut être rejouée à l'identique avec d'autres réglages, côte à côte.

4.3 Atelier des modes de jeu

• Les règles s'écrivent sous forme de règles composables et lisibles (cartes de règles, machines à états visuelles), compréhensibles par des non-programmeurs.
• Voyage dans le temps : revenir en arrière, brancher une version alternative d'une règle, comparer les deux sur les mêmes actions du joueur.
• Tests de jeu par agents (étape ultérieure) : des joueurs simulés testent un mode et rapportent stratégies dominantes, impasses et courbe de difficulté. Ils complètent les joueurs humains sans les remplacer.

4.4 Vue de réalisateur

Une frise des moments de l'expérience, avec une courbe de tension. Elle couvre les séquences de gameplay, pas seulement les cinématiques.

4.5 Rendu : contrôle et lisibilité

• Peindre le mode de rendu : sur une région ou un objet, on choisit 3D, neuronal ou génératif, avec transition douce.
• Surimpression de confiance : voir où le rendu IA s'écarte de la vérité structurelle.
• Contraintes visibles : préserver silhouette, collisions, identité ; les violations s'affichent là où elles se produisent.
• Travailler par budget : on fixe un budget (millisecondes, Go de VRAM) et un profil de GPU cible, et Studio montre comment l'orchestrateur le répartit, y compris pour un matériel qu'on ne possède pas.
• Verrouiller et versionner l'apparence : ce qui plaît est épinglé et la régénération n'y touche plus ; chaque changement se compare, s'accepte ou se refuse.
• Débogueur temporel : remonter la timeline image par image, voir lesquelles étaient générées, rejetées car périmées, ou remplacées par la 3D.
• Comparaison de rendus : classique, amélioré, génératif, côte à côte avec la même caméra.

4.6 L'IA comme collaboratrice

• Elle propose plusieurs variantes ; l'auteur choisit, épingle et retouche.
• Tout élément généré garde sa provenance (l'intention qui l'a produit, la graine, le modèle) et reste modifiable de façon non destructive.
• Pas de simple zone de texte « génère-moi un niveau » : les contrôles déterministes restent la base, la génération est une aide.

4.7 Collaboration

Commentaires, revues, branches de direction créative et comparaison d'intentions d'une version à l'autre, pour que programmeurs, artistes, game designers et directeurs de création travaillent sur le même projet sans passer par des outils techniques.

4.8 Technologie de l'interface : Studio web, conteneur remplaçable

Studio est une application web écrite en TypeScript, indépendante de tout moteur. Elle ne communique avec le Core que par un protocole (WebSocket plus schéma partagé, voir §5.6). Comme elle ne dépend d'aucun conteneur particulier, le conteneur est un détail remplaçable.

Conteneurs possibles

Conteneur	Licence	Usage
Navigateur de l'utilisateur	aucune	Le Core C++ sert Studio localement. Solution de la phase 1 : rien à embarquer
Webview du système (bibliothèque webview/webview, MIT)	permissive	Application de bureau légère ; moteurs web différents selon la plateforme
CEF (Chromium Embedded Framework)	BSD	Comportement identique partout, mais lourd à distribuer
Interface native C++ (Dear ImGui, RmlUi)	MIT	Outils de débogage et modes dégradés

Qt et les composants à licence restrictive sont exclus du cœur (voir §10.2).

Séparation de l'état et de l'affichage. L'interface est une vue d'un modèle sérialisable (modes de rendu, contraintes, budgets, verrous, intentions). Elle n'a jamais de logique de produit propre.

Disposition du poste de travail. Le jeu s'exécute dans sa propre fenêtre, qui peut occuper un second écran en plein écran, tandis que Studio, dans une webview ou un navigateur, occupe le premier. Cette disposition est le mode de travail de référence : elle donne au jeu toute sa résolution et sa fluidité, sans passer par un flux vidéo vers une page web.

Intégration de la vue dans l'interface (étape ultérieure). Pour afficher la vue du moteur dans Studio lui-même, les pistes sont un flux vidéo local vers la page, ou une composition native de la webview et de la vue du moteur. Sous Linux, superposer une fenêtre native à une page web est délicat avec Wayland (à vérifier). Cette intégration est donc un objectif de la phase 3, pas un prérequis.

Composants dessinés par le GPU. Frise de réalisateur, courbes de ressenti, graphes de règles et surimpressions sont des composants maison (WebGPU ou WebGL2, avec repli si WebGPU est indisponible). Les panneaux courants (inspecteurs, formulaires, docking) reposent sur des bibliothèques web existantes avec un système de design propre à SEQUA. Un moteur d'interface complet maison n'est pas prévu.

5. SEQUA Core

5.1 Projet et scène de référence

Le projet est une description de données appartenant à SEQUA, sans logique propre à un moteur. Il contient objets, règles, intentions, contraintes, budgets, références visuelles et historique. Les moteurs 3D reçoivent cette description via SEQUA 3D et l'exécutent ; ils ne sont jamais modifiés directement.

Les assets s'appuient sur des formats ouverts (glTF, USD) avec des extensions SEQUA pour les intentions et contraintes.

5.2 Représentation du monde en quatre niveaux

Niveau	Contenu	Garantie
L0 Structurel	Volumes, topologie, collisions, dimensions, logique	Déterministe et toujours disponible
L1 Géométrique	Meshes, textures, matériaux, lumières	Rendu traditionnel
L2 Neuronal	Détails reconstruits, apparence enrichie, représentations neuronales	Guidé par les données de scène
L3 Génératif	Apparence et éléments générés à la demande	Contraint par la structure du monde

Chaque objet possède une identité persistante, un transform, des collisions, un état logique, des propriétés sémantiques, des règles d'interaction et une représentation visuelle interchangeable. Exemple : un arbre a une collision et une position déterministes, mais son apparence peut être un mesh, un asset neuronal ou une génération conditionnée.

5.3 Simulation déterministe, enregistrement et rejeu

• Fréquence de simulation fixe, indépendante de l'affichage.
• Toutes les entrées du joueur sont enregistrées avec leur horodatage de simulation.
• Une session se rejoue à l'identique, avec d'autres règles, d'autres réglages de ressenti ou un autre moteur 3D.
• Les modèles neuronaux et génératifs sont exclus de la boucle de simulation : ils n'influencent jamais l'état du monde.
• L'apparence étant purement locale, des joueurs différents peuvent avoir des rendus différents sans désynchronisation de la simulation (avantage pour le jeu en réseau).

5.4 Orchestrateur de rendu adaptatif

C'est le composant qui réalise le « Adapt » de SEQUA.

Fonctions :

• détecter les capacités réelles du GPU, mesurer la VRAM et la charge ;
• établir un budget de calcul et sélectionner le pipeline ;
• répartir les tâches entre CPU et GPU ;
• surveiller les temps d'inférence, réduire la qualité IA ou revenir à la 3D classique en cas de surcharge ;
• s'appuyer sur la confiance (§5.5) pour décider où dégrader.

Modes de rendu :

1. Classic : rendu 3D conventionnel.
2. Neural Enhancement : 3D plus amélioration neuronale.
3. Hybrid Generative : génération visuelle localisée.
4. Generative World : apparence d'une partie du monde générée à partir d'une description structurelle et temporelle.

Rendu adaptatif spatial : les modes coexistent dans une image et se choisissent par objet, matériau, région ou couche. Exemple : personnage et arme en 3D classique, ennemis en 3D plus reconstruction, forêt générée, brouillard neuronal, interface en 2D.

Difficulté connue : une région générée ne fournit ni profondeur, ni identifiants, ni éclairage cohérent avec le reste. Il faut gérer l'occlusion (un personnage 3D devant un arbre généré), les ombres portées et les raccords entre régions. C'est le point le plus risqué de l'orchestrateur et il fait partie du prototype.

5.5 Quantifier l'incertitude

C'est le « Quantify Uncertainty » du nom, mis en œuvre concrètement :

• Chaque sortie neuronale ou générative est accompagnée d'une carte de confiance par pixel ou par région.
• La confiance est calculée par vérification en boucle fermée : un estimateur de profondeur et de segmentation est exécuté sur l'image produite puis comparé à la vérité L0 (profondeur réelle, identifiants d'objets).
• Elle sert à trois décisions : l'orchestrateur dégrade ou bascule en 3D là où elle est basse ; le compositeur fond les régions selon elle ; Studio l'affiche à l'auteur.
• Elle répond à un risque de gameplay, pas seulement visuel : un arbre généré sans collision ou un mur dessiné là où il n'y en a pas trompent le joueur.

5.6 Contrat de données

Le contrat est l'interface qui compte : il survit au remplacement des bibliothèques parce qu'il ne reprend aucun concept d'un moteur particulier.

Du Core vers le rendu (NeuralFrameContext) : couleur, profondeur, normales, vecteurs de mouvement, albedo, identifiants d'objets, masque sémantique, caméra, éclairage, état temporel, paramètres artistiques et intentions, index de frame.

Du rendu vers le Core et Studio : image produite, carte de confiance, temps de calcul, VRAM utilisée, version de l'état du monde utilisée.

Règles :

• Le contrat se définit à partir de prototypes, pas dans l'abstrait ; on prévoit de le réviser plusieurs fois pendant la phase 1.
• Les données restent résidentes sur le GPU autant que possible. Le passage de textures entre l'API graphique (Vulkan, DirectX) et le moteur d'inférence (CUDA, TensorRT) sans copie CPU est le point où les abstractions fuient le plus ; il est testé en tout premier.

5.7 Synchronisation temporelle

Chaque résultat généré est associé à un horodatage, une caméra, une version de l'état du monde, les transformations des objets et l'historique temporel utilisé. Les résultats périmés sont rejetés ou limités à un rôle d'enrichissement. La simulation et les interactions critiques n'attendent jamais le modèle génératif.

Techniques envisagées : génération par petits blocs, contexte glissant, attention causale, KV cache, reprojection, compensation de mouvement, correction par le renderer 3D.

6. Moteur neuronal et génératif

Trois sous-systèmes, utilisables via des plugins interchangeables.

Neural Reconstruction Engine

Amélioration de résolution, reconstruction de détails, débruitage, reconstruction temporelle. Ce terrain est déjà occupé par les solutions des fabricants (DLSS, FSR, XeSS). Il reste utile comme base technique et comme mode de repli, mais n'est pas le différenciateur du projet.

Neural Appearance Engine

Enrichissement de matériaux, détails de surface, végétation, atmosphère, éclairage neuronal, transformation d'apparence avec contraintes de conservation (silhouette, identité, collisions, palette). C'est ici que se joue la valeur : une apparence guidée par la sémantique et l'intention, et non un simple gain de résolution. C'est le premier module IA à développer en profondeur.

Generative Video Engine

Génération à partir d'une vidéo de référence, conditionnement par la caméra et les données de scène, mémoire temporelle, génération de frames ou de petits blocs, prise en compte des événements du monde.

Deux voies : une voie neuronale rapide pour le gameplay (image par image, guidée par la 3D) et une voie de génération par blocs pour les environnements et transitions complexes. Un débit vidéo élevé n'implique pas une faible latence interactive : débit, latence du premier bloc et latence input-to-photon se mesurent séparément.

7. SEQUA 3D et moteurs 3D

On distingue deux choses :

• SEQUA 3D est l'interface : du code propriété de SEQUA, qui ne dépend d'aucun moteur. Elle définit ce que SEQUA demande à un moteur 3D et ce qu'il doit renvoyer.
• Les moteurs 3D (Godot, Unreal, un futur moteur maison) sont les vrais moteurs d'exécution. Ce sont des implémentations de SEQUA 3D, rien de plus.

Pour éviter toute confusion, le mot « backend » est réservé au calcul GPU (IComputeBackend).

7.0 Ce que contient SEQUA 3D

• Le contrat de données (voir §5.6).
• La synchronisation de la scène : le projet SEQUA est poussé vers le moteur à sens unique ; le moteur n'est jamais modifié directement.
• La négociation des capacités : chaque moteur déclare ce qu'il sait produire (identifiants d'objets, vecteurs de mouvement, albedo, profondeur, normales…). L'orchestrateur et Studio s'adaptent à cette déclaration au lieu de supposer que tout existe.
• L'interface d'adaptateur (I3DEngineAdapter) que chaque moteur implémente.
• La traduction des mesures (temps de calcul, VRAM, confiance) vers un format commun.

7.0.1 Précautions

• Interface étroite. SEQUA 3D ne doit exposer aucun concept propre à un moteur (nœuds Godot, acteurs Unreal) et ne doit pas viser le plus petit dénominateur commun : ce qu'un moteur ne sait pas faire est signalé par la négociation des capacités, pas supprimé de l'interface.
• Un petit agent côté moteur reste inévitable. Pour lire les tampons de rendu ou recevoir les commandes, il faut du code qui s'exécute dans le moteur (extension native Godot, module Unreal). Cet agent est interne, minimal, sans logique de produit, et n'est pas ce que l'utilisateur voit. C'est la seule partie qui ressemble à un plugin.
• Le Core ne connaît pas le moteur. Sa simulation, ses intentions et son orchestrateur ne dépendent que du contrat, ce qui garde la porte ouverte à d'autres usages que la 3D (simulation, visualisation).

7.1 Ordre prévu

1. Godot (phase 1) : licence permissive, code modifiable, bon candidat pour les premiers essais. Le moteur y est utilisé comme moteur d'exécution, pas comme éditeur.
2. Unreal (phase 2) : sert de test d'isolation. Critère de réussite : la même couche SEQUA tourne sur Godot et sur Unreal avec seulement un adaptateur d'hôte à écrire. Si l'adaptateur Unreal oblige à modifier le Core ou Studio, le contrat de données est mal conçu.
3. Moteur maison (long terme) : les parties du moteur que SEQUA juge utile de maîtriser (rendu, simulation, outils) sont progressivement intégrées dans SEQUA.

7.2 Responsabilité de l'adaptateur

Chaque adaptateur produit les tampons du contrat qu'il déclare savoir produire, quels que soient les moyens de son moteur. Exemple à vérifier dans la version utilisée : Unreal dispose d'un G-buffer et d'un stencil exploitable pour les identifiants d'objets ; Godot en rendu Forward+ n'a pas de G-buffer classique, donc l'albedo et les identifiants d'objets demanderont des passes supplémentaires.

7.3 Risques propres à cette architecture

• Double scène : une version dans SEQUA, une dans le moteur, qui divergent. Parade : le projet SEQUA est la seule source de vérité, synchronisée à sens unique vers le moteur par SEQUA 3D.
• Pipeline d'assets : importation depuis glTF/USD et export vers chaque moteur 3D à maintenir.
• Viewport : latence et intégration de la vue en direct dans Studio (voir §4.8).

8. Gestes signature

Chaque pilier du projet est défini par une interaction qui n'existe pas, ou pas ainsi, dans un moteur classique. Ces gestes sont implémentés dès le départ, même grossièrement.

Pilier	Geste signature
Intention	On peint une ambiance sur une région (« refuge vers menace ») ; éclairage, apparence et rendu y répondent
Ressenti et modes	On enregistre une session, puis on la rejoue à l'identique avec une règle ou un réglage différent, côte à côte
Incertitude	La carte de confiance s'affiche en surimpression ; l'orchestrateur bascule sur la 3D là où elle est basse
Adaptation	On choisit un profil de GPU cible et on voit le budget se réallouer entre les modes de rendu
Isolation	On change de moteur d'exécution (Godot vers Unreal) sans toucher au projet (phase 2)

9. Prototype fondateur : le squelette

Au lieu d'une coupe verticale étroite, la première version relie tous les piliers par un chemin minimal de bout en bout : Studio produit un projet, le Core simule de façon déterministe et enregistre, SEQUA 3D transmet au moteur 3D qui rend, et les mesures (confiance, budget) reviennent dans Studio. Chaque maillon est fin, mais le chemin est complet.

Scène de démonstration

Une petite scène de forêt à la première personne avec un micro-mode de jeu, rendue en trois sorties synchronisées (3D classique, 3D améliorée par IA, génératif) avec la même caméra, les mêmes collisions et le même état du monde.

Scénario de démonstration

Une personne non technique :

1. peint une ambiance sur une région dans Studio ;
2. voit le rendu changer sur Godot, avec la carte de confiance en surimpression ;
3. règle le ressenti d'un mouvement et d'une règle, rejoue sa session, compare les deux versions ;
4. change de profil de GPU et observe la réallocation du budget.

La phase 2 y ajoute : même projet, moteur 3D Unreal.

Pilier à approfondir en premier

Le rendu avec confiance (Neural Appearance et carte de confiance), car c'est le plus risqué techniquement. Les autres piliers existent sous une forme minimale mais réelle.

Réel et simulé

Pour tenir plusieurs piliers avec des moyens limités, certaines parties seront simulées au début (par exemple l'intention pilotera d'abord un petit nombre de paramètres fixes, et les agents de test viendront plus tard). Tout ce qui est simulé est marqué comme tel, pour ne pas confondre prototype et validation.

Critères de réussite

• L'environnement devient visuellement plus riche sans perte de correspondance entre géométrie, collisions, objets et état physique.
• Un rejeu déterministe est identique bit à bit côté simulation.
• La carte de confiance détecte effectivement les écarts avec la vérité L0 (arbre généré sans collision, objet déplacé).

Critères d'arrêt (à fixer avant de commencer)

À définir par des seuils chiffrés, par exemple : cohérence temporelle mesurée trop faible, consommation de VRAM excédant le profil visé, dérive géométrique au-dessus d'un seuil. Si un seuil est franchi, on change d'approche plutôt que de poursuivre.

10. Stratégie : réutiliser avant de construire

Domaine	Brique de départ	Remplaçable par
Moteur 3D (derrière SEQUA 3D)	Godot, puis Unreal	Moteur maison
Physique	Jolt	—
ECS	EnTT	Solution propriétaire
Inférence	ONNX Runtime, TensorRT	Backends spécialisés
Entraînement	PyTorch	—
Génération	ComfyUI, diffusers, pipelines temps réel type StreamDiffusion	Plugins IVideoGenerationPlugin
Amélioration de résolution	SDK des fabricants (DLSS, FSR, XeSS), éventuellement via une couche d'unification	Modèle propre
Shaders	Slang	—
Assets	glTF, USD	Formats propriétaires
Profilage	Tracy et outils GPU natifs	—
Interface Studio	Application web TypeScript, conteneur remplaçable (§4.8)	Autres conteneurs
Protocole et contrat	Protobuf ou FlatBuffers (types générés en C++ et TypeScript)	—
Build	CMake (C++), Vite (TypeScript)	—

Pour le prototype : un seul chemin technique (Vulkan, Slang, GPU NVIDIA). Les autres APIs et fabricants s'ajoutent une fois la thèse prouvée, via IComputeBackend.

Le moteur comme générateur de données d'entraînement : le moteur produit gratuitement des paires parfaites (tampons de rendu et image de référence), ce qui permet d'entraîner des modèles légers propres au projet. Référence à vérifier : Enhancing Photorealism Enhancement (Intel, 2021), qui utilisait les tampons de rendu d'un jeu pour guider l'amélioration d'image.

10.1 Langages

Pour limiter la charge cognitive, SEQUA utilise deux langages de produit :

Rôle	Langage
Tout le natif : Core, SEQUA 3D, agents côté moteur 3D, colle GPU et inférence	C++20/23
Studio	TypeScript
Shaders (domaine étroit)	Slang
Entraînement et expérimentation des modèles (hors produit)	Python

Justification du C++ : Jolt, EnTT, Slang, ONNX Runtime et CUDA y sont natifs ; l'extension Godot (GDExtension) et le module Unreal y sont écrits ; aucune frontière de langage côté natif, ce qui simplifie notamment le partage de textures GPU entre rendu et inférence.

Contreparties assumées et compensations : pas de garantie mémoire du compilateur, donc C++ moderne sans pointeurs propriétaires bruts, analyseurs statiques (clang-tidy), sanitizers (ASan, UBSan) en intégration continue, avertissements stricts.

Règles de déterminisme en C++ (simulation et rejeu) :

• désactiver -ffast-math et les fusions multiplication-addition (-ffp-contract=off) ;
• aucune dépendance à std::unordered_map ou à un ordre d'itération non défini dans la simulation ;
• bibliothèque mathématique déterministe, indépendante de la plateforme ;
• résultats indépendants de l'ordonnancement des threads ;
• générateur aléatoire propre à SEQUA, avec graine explicite ;
• mode de déterminisme multiplateforme de Jolt à activer (à vérifier dans la version retenue).

Python reste hors de la boucle d'exécution : en phase 1, ComfyUI ou diffusers tournent comme processus séparé ; les modèles sont ensuite exportés vers le runtime.

10.2 Licences et dépendances

Licence de SEQUA : MPL 2.0. Toute modification des fichiers de SEQUA reste ouverte, et les jeux créés avec SEQUA restent libres de choisir leur licence. Les versions déjà publiées restent sous cette licence. Pour garder de la souplesse sur les versions futures, la politique de contributions (certificat d'origine DCO ou accord de contributeurs) se choisit tôt, avant d'accepter des contributions externes. Un avis juridique est conseillé le moment venu.

Politique de dépendances

• Le cœur n'utilise que des dépendances permissives (MIT, BSD, Apache 2.0, zlib) ; la compatibilité de chaque version retenue est à confirmer.
• Tout composant propriétaire n'entre que comme plugin facultatif : Unreal (licence propriétaire, adaptateur seul ouvert), CUDA, TensorRT et DLSS (NVIDIA uniquement, derrière IComputeBackend).
• Poids des modèles : ils ne sont pas embarqués dans le dépôt. Par défaut, seuls des modèles sous Apache 2.0 ou MIT sont proposés ; les autres sont téléchargés par l'utilisateur, avec sa propre acceptation de licence.
• Qt, Ultralight, Sciter et tout composant à licence restrictive sont exclus du cœur. WebView2 est exclu car propriétaire et limité à Windows.

10.3 Multiplateforme

Le multiplateforme s'entend comme une architecture et une intégration continue : le projet compile et passe ses tests sur Windows, Linux et macOS à chaque modification. Les fonctions IA lourdes arrivent plateforme par plateforme et fabricant par fabricant, via des plugins. macOS est la plateforme la plus délicate pour le calcul GPU (Metal plutôt que Vulkan natif) et sera traité en conséquence.

API et plugins prévus

IRendererPlugin, INeuralRendererPlugin, IVideoGenerationPlugin, IWorldGeneratorPlugin, IComputeBackendPlugin, I3DEngineAdapter.

Le remplacement d'un modèle ou d'un moteur ne doit pas nécessiter de réécrire le jeu.

11. Compatibilité matérielle

Le moteur doit fonctionner sans génération IA.

Profil	VRAM indicative	Fonctionnalités
Entry	6 à 8 Go	3D classique, reconstruction légère
Mainstream	8 à 12 Go	Amélioration neuronale compacte
Advanced	12 à 16 Go	Rendu neuronal plus avancé
High-end	16 à 24 Go	Rendu hybride, génération limitée
Enthusiast	24 à 32 Go et plus	Modèles génératifs plus lourds

Ces profils ne sont pas des garanties : les besoins réels (modèles, caches, activations, résolutions) seront mesurés.

Fonctions nécessaires : chargement à la demande, quantification adaptée, streaming des modèles, gestion de VRAM, déchargement des modèles inutilisés, repli en 3D, tests sur plusieurs fabricants.

12. Génération du monde et persistance

Le World Generation System produit des environnements sous contraintes :

1. topologie ;
2. placement des objets ;
3. collisions et chemins ;
4. propriétés sémantiques et physiques ;
5. génération visuelle ;
6. enrichissement neuronal ;
7. mise à jour selon les événements.

Chaque région possède un identifiant, une graine, un état physique et logique, une description sémantique, une intention, des références visuelles et un historique. Les modifications du joueur survivent à la régénération : une maison détruite ne réapparaît pas intacte. Les éléments épinglés par l'auteur ne sont jamais écrasés.

Vocabulaire d'intentions

Pour éviter une interface qui promet de la magie, le vocabulaire initial est volontairement court (quelques ambiances, quelques rythmes), chacun relié à des paramètres mesurables et vérifié par des tests (perception, comparaison de variantes, retours d'utilisateurs). Il s'étend ensuite selon les résultats.

13. Feuille de route indicative

L'ordre compte plus que les durées, qui dépendent de l'équipe (à décider, voir §16) et sont à fixer après le premier prototype.

Phase	Contenu	Résultat
0. Fondations	Contrat de données, passage GPU rendu vers inférence, format de projet minimal	Données qui circulent de bout en bout
1. Squelette sur Godot	Les gestes signature (intention, rejeu, confiance, budget) sous forme minimale, scène de forêt	Démonstration complète du concept
2. Isolation	Adaptateur Unreal, même projet	Preuve que le Core est indépendant du moteur
3. Approfondissement	Neural Appearance, composition spatiale, atelier de modes, tests par agents	Studio crédible pour de vrais projets
4. Monde génératif	Generative Video Engine, World Generation System	Monde semi-génératif persistant
5. Maîtrise du moteur	Intégration progressive de composants maison dans SEQUA	Moteur d'exécution propre

14. Objectifs de performance initiaux

Indicateur	Objectif
Simulation	60 à 120 Hz
Affichage	60 FPS
Latence commandes (voie neuronale rapide)	moins de 50 ms visée
Latence commandes (voie génération par blocs)	objectif séparé, à mesurer ; non interactif au sens strict
Résolution minimale	1080p
Résolution cible	1440p
Résolution avancée	4K
Changement de pipeline	sans interruption du gameplay
Fonctionnement sans IA	obligatoire

Métriques suivies séparément : latence input-to-photon, latence du premier bloc généré, débit vidéo, stabilité temporelle, fréquence de simulation, exactitude du rejeu et précision de la carte de confiance. Ces objectifs sont des hypothèses à valider par prototype.

15. Décisions à préserver

1. SEQUA n'est pas un plugin d'un autre moteur ; il possède le projet, la scène de référence et le contrat de données.
2. Studio est le cœur du produit, centré sur l'intention artistique et la finesse de gameplay.
3. La simulation reste déterministe et rejouable.
4. L'humain garde l'autorité ; l'IA propose.
5. L'incertitude est quantifiée et utilisée.
6. Les moteurs 3D et les modèles IA sont interchangeables ; SEQUA 3D est la seule porte entre SEQUA et un moteur.
7. Le rendu génératif est optionnel ; le runtime de base ne dépend pas du cloud.
8. La représentation logique du monde est indépendante de son apparence.
9. Le rendu est adaptatif et spatial.
10. Les bibliothèques existantes sont réutilisées derrière des contrats stables.
11. Chaque fonctionnalité passe le test d'identité.
12. La compatibilité multi-fabricant est une exigence d'architecture, activée après la preuve de concept.
13. Les parties simulées d'un prototype sont toujours marquées comme telles.
14. SEQUA est open source sous MPL 2.0 ; le cœur n'a que des dépendances permissives.
15. Le projet est multiplateforme par conception, avec intégration continue sur Windows, Linux et macOS.
16. Studio est une application web dont le conteneur est remplaçable ; il ne parle au Core que par protocole.
17. Deux langages de produit seulement : C++ et TypeScript.

16. Principaux risques

Risque	Réponse
Périmètre trop large pour l'équipe	Squelette minimal de bout en bout, un pilier approfondi à la fois, test d'identité
Éditeur très coûteux à construire	Importer les scènes existantes (glTF, USD) et concentrer l'effort sur les couches nouvelles
Intention artistique trop floue	Vocabulaire restreint relié à des paramètres mesurables et validé par des tests
Double scène entre SEQUA et le moteur	Projet SEQUA unique source de vérité, synchronisation à sens unique
Fuite des abstractions (échange GPU entre rendu et inférence)	Testé en premier ; contrat de données issu de prototypes
Composition spatiale difficile (occlusion, ombres, raccords)	Inclus dans le prototype ; confiance utilisée au raccord
Latence générative excessive	Deux voies, simulation indépendante, repli 3D
Incohérence temporelle	État versionné, historique, validation des frames
Contenu généré trompeur pour le gameplay	Vérification en boucle fermée contre L0, carte de confiance
Consommation de VRAM	Modèles compacts, quantification, chargement à la demande
Dépendance à un modèle ou à un moteur	Plugins, adaptateurs et interfaces stables
Différences entre GPU	Abstraction de calcul et backends spécifiques après la preuve de concept
Contrôle artistique et reproductibilité	Graines fixes, mode figé, provenance de chaque élément généré
Licences et données d'entraînement	Politique de licences des modèles (§10.2), provenance des données, étiquetage du contenu généré
Sûreté mémoire du C++	Analyseurs statiques, sanitizers en intégration continue, C++ moderne
Déterminisme perdu par un compilateur ou une plateforme	Règles de §10.1, tests de rejeu comparés entre plateformes en intégration continue
Webviews de plateformes différentes (comportements divergents)	Conteneur remplaçable, repli de rendu, CEF si l'homogénéité devient indispensable
Contributions externes et licence	MPL 2.0 ; choisir tôt entre DCO et accord de contributeurs

17. Décisions ouvertes

• Équipe, compétences, budget et calendrier.
• Plateforme et fabricant de référence pour les premiers prototypes (la cible reste multiplateforme).
• Conteneur de Studio pour la distribution de bureau (webview du système ou CEF) et méthode d'intégration de la vue du moteur (flux ou composition native).
• Format de schéma du contrat (Protobuf ou FlatBuffers).
• Moteur d'inférence open source pour le multi-fabricant (ONNX Runtime, ncnn…).
• Physique : Jolt par FFI ou autre, selon un test de déterminisme.
• Premier GPU de référence et modèle neuronal de départ.
• Scène de benchmark et seuils des critères d'arrêt.
• Objectifs de latence réalistes par voie de rendu.
• Premier vocabulaire d'intentions et méthode de validation.
• Politique de contributions (DCO ou accord de contributeurs) et politique de distribution des poids de modèles.

Décisions prises : licence MPL 2.0 ; deux langages de produit (C++ et TypeScript) ; Studio web avec conteneur remplaçable ; multiplateforme par conception.

Conclusion

SEQUA Engine est une plateforme de création où l'auteur dirige un monde par l'intention, le ressenti et les règles, au-dessus d'un noyau déterministe et rejouable, avec un rendu adaptatif et mesuré par sa propre incertitude. Les moteurs d'exécution et les modèles IA sont des composants interchangeables, pas les fondations du projet.

Le premier jalon n'est pas de générer un monde entier. C'est de démontrer, par un squelette complet de bout en bout, qu'une personne peut peindre une ambiance, voir le monde y répondre sans perdre sa cohérence, rejouer et comparer des variantes de gameplay à l'identique, et changer de moteur d'exécution sans toucher à son projet. C'est cette preuve qui justifiera ensuite l'investissement dans la génération vidéo, la génération de monde et un moteur propre.

---

Note de validation

Les chiffres de performance, noms de projets, dates et références de recherche mentionnés sont à vérifier à partir de leurs publications et dépôts officiels avant toute décision technique ou budgétaire. Les budgets par frame, profils GPU, comportements des moteurs (Godot, Unreal) et choix de bibliothèques sont des hypothèses de conception, pas des résultats mesurés.