0310d28b5e
Premier commit du cinquième front. Trois parties : - `unity/MyInfoMateVR/` : le projet Unity (6000.0.83f1, URP, Meta XR SDK 205), un APK unique pour tous les clients. Menu flottant à sélection au regard, appairage, chargement de scène GLB, POI, cache de contenu, télémétrie. - `unity-overlay/` : les mêmes scripts à recopier sur un projet Unity neuf, avec les pièges rencontrés consignés dans son README. - `viewer/` : viewer et éditeur de scène web autonome (Vite, TypeScript, three.js), partagé avec les autres fronts. - `docs/` : état des lieux, setup Unity, décisions d'architecture et plan d'exécution en 9 étapes. La scène est décrite par un `scene.json` poussé par `adb push` : l'app le préfère à celui embarqué dans l'APK. Les binaires (GLB, textures de l'échantillon Sponza, DLL Meta XR) passent par Git LFS dès ce premier commit — les y faire entrer après coup demanderait de réécrire l'historique. Les artefacts régénérés par l'éditeur et par CMake (`Library/`, `.utmp/`, Burst debug) sont ignorés. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
81 lines
4.4 KiB
Markdown
81 lines
4.4 KiB
Markdown
# vr-app — canal VR MyInfoMate (Meta Quest)
|
|
|
|
Repo du **cinquième front** de l'écosystème : l'application Unity qui tourne sur casque Meta Quest,
|
|
et toute la documentation du module VR (back-office compris).
|
|
|
|
Nommage aligné sur les autres repos : `manager-app`, `tablet-app`, `visitapp-web`, `vr-app`.
|
|
|
|
## Contenu
|
|
|
|
| Chemin | Rôle |
|
|
|---|---|
|
|
| `docs/00-phase1-etat-des-lieux.md` | **À lire en premier.** Relevé du code existant des 4 repos, ce qui est réutilisable, ce qui manque, points de friction |
|
|
| `docs/01-phase0-setup-unity.md` | Guide d'installation Unity + Meta XR, pas à pas, pour quelqu'un qui n'a jamais ouvert Unity |
|
|
| `docs/02-decisions.md` | Les 6 arbitrages d'architecture du module (modèle de contenu, placement, viewer, kiosk, périmètre V1, personnages) |
|
|
| `docs/03-phase2-conception.md` | Manifeste de scène, modèle de données, contrat d'API, flux de génération, structure Unity et viewer web |
|
|
| `docs/04-phase3-plan.md` | **Le plan d'exécution.** 9 étapes, chacune avec ce que je génère / ce que tu fais / le critère de validation |
|
|
| `unity-overlay/` | **Les fichiers Unity que je génère**, à recopier sur le projet une fois créé par Hub. Voir son README |
|
|
| `tools/` | Générateur du repère de calibration (`make_calibration_glb.py`) |
|
|
| `unity/` | Le projet Unity lui-même — l'APK unique, tous clients |
|
|
| `viewer/` | **Le viewer et l'éditeur de scène web** (étape S3), autonome. Voir son README |
|
|
|
|
## Où vit le reste
|
|
|
|
- Décisions déjà arrêtées sur le canal VR (pricing, moteur, types de section, POI sur GLB) :
|
|
`../DOCS/v2/vr-quest-unity-plan.md`
|
|
- Infrastructure dont ce module dépend (crédits, jobs, fournisseurs IA, personnages) :
|
|
`../DOCS/v2/studio-plan.md`
|
|
- Kanban : `../DOCS/kanban/cards/5-planifie/320-*` et `330-*`
|
|
|
|
## Statut
|
|
|
|
**S0 terminé. S1 quasiment bouclé — 11/09/2026.** Le projet Unity existe (`unity/MyInfoMateVR/`,
|
|
Unity 6000.0.83f1, URP, Meta XR SDK 205), l'APK se construit, s'installe et tourne sur un Quest 2
|
|
en Horizon OS v207.
|
|
|
|
| Critère S1 | État |
|
|
|---|---|
|
|
| 1. Le monde s'affiche, on tourne la tête dedans | ✅ |
|
|
| 2. Le marqueur par coordonnées coïncide avec le repère du GLB | ✅ **aucun miroir — `GltfSpace.Axis = NegateX` confirmé** |
|
|
| 3. Personnage debout, à la bonne taille, animé, qui regarde le visiteur | ✅ |
|
|
| 4. Cercle de navigation infranchissable | ❌ **on franchit toujours le cercle** — mesure tête/rig corrigée, contrainte toujours sans effet. Non bloquant pour S2, à reprendre |
|
|
|
|
### Les nombres que S1 devait produire
|
|
|
|
Mesurés sur **Sponza** (50 Mo, glTF multi-fichiers), pas sur un monde Marble :
|
|
|
|
| Mesure | Valeur |
|
|
|---|---|
|
|
| Chargement du décor | **1,4 à 1,8 s** — l'écran de progression est un détail, pas un sujet |
|
|
| Chargement du repère / du personnage | 33-248 ms / 54-96 ms |
|
|
| Images par seconde | **72/72 tenues**, mais `App=12,4 ms` sur 13,9 disponibles et **GPU au niveau maximum** |
|
|
| Poids réel d'un monde Marble | ❌ **toujours inconnu** — crédits Marble insuffisants |
|
|
|
|
➡️ Lecture : un décor de 50 Mo bien texturé **sature déjà un Quest 2**. Le budget de scène devra
|
|
être défini, et la question KTX2 côté serveur reste ouverte tant que le poids d'un vrai monde
|
|
Marble n'est pas connu.
|
|
|
|
Les assets de test sont des GLB libres (Khronos glTF Sample Assets : Sponza, CesiumMan) déposés
|
|
dans `StreamingAssets/` — **non commités**, jetables, et sans valeur pour la mesure de poids.
|
|
|
|
Les pièges rencontrés et leurs corrections sont consignés dans
|
|
[unity-overlay/README.md](unity-overlay/README.md).
|
|
|
|
### S2 — validé le 11/09/2026
|
|
|
|
| Livrable S2 | État |
|
|
|---|---|
|
|
| La scène est construite depuis `scene.json`, plus depuis du code | ✅ |
|
|
| Modifier le JSON et relancer **sans recompiler** déplace l'objet | ✅ manifeste poussé par `adb push`, lu en priorité sur celui de l'APK |
|
|
| Un `world.kind` non supporté affiche une phrase lisible, pas une scène vide | ✅ testé avec `"kind": "panorama"` |
|
|
| Un hotspot apparaît et joue son audio au raycast | ⏳ le `scene.json` d'exemple n'a pas d'audio |
|
|
|
|
Le manifeste se pousse ainsi, l'app le préfère à celui embarqué :
|
|
|
|
```
|
|
adb push scene.json /sdcard/Android/data/com.unov.myinfomatevr/files/scene.json
|
|
```
|
|
|
|
Prochaine étape : **S3** de [04-phase3-plan.md](docs/04-phase3-plan.md) — le viewer web et son
|
|
éditeur. C'est le jalon « démo vendable », et le plan y place un go/no-go explicite.
|