Implement production vertical slice foundation
This commit is contained in:
1 parent
9d4a89f355
commit
a18e82eb44
104 files changed
+10595
-268
No files matched your search
@@ -0,0 +1,99 @@
|
||||
# 0010 — Bathymétrie à surface unique pour la V1
|
||||
|
||||
- Statut : accepté
|
||||
- Date : 2026-08-10
|
||||
- Remplace : aucun
|
||||
|
||||
## Contexte
|
||||
|
||||
Le sonar retenu représente le fond par une grille bathymétrique continue. Pour
|
||||
une ligne et une colonne données, cette structure ne peut stocker qu'une seule
|
||||
élévation autoritaire. Elle convient aux pentes, crêtes, chenaux, dépressions et
|
||||
reliefs ouverts, mais pas à un tunnel, une arche ou une grotte possédant
|
||||
plusieurs surfaces superposées au même emplacement horizontal.
|
||||
|
||||
Une représentation hybride pourrait combiner plusieurs couches, fragments de
|
||||
maillage, points volumétriques ou voxels locaux. Aucun site de la verticale
|
||||
n'exige encore cette complexité : les véritables grottes à plusieurs niveaux et
|
||||
les surplombs complexes sont hors périmètre de la V1.
|
||||
|
||||
## Décision
|
||||
|
||||
Le terrain navigable et les informations critiques du sonar de la V1 utilisent
|
||||
une bathymétrie à surface unique. Chaque cellule valide du scan possède au plus
|
||||
une hauteur de terrain reconstruite.
|
||||
|
||||
Les sites de la verticale sont conçus de sorte que :
|
||||
|
||||
- les routes nécessaires puissent être comprises depuis une carte de hauteur ;
|
||||
- aucun objectif n'exige de passer sous un surplomb naturel ou dans un tunnel ;
|
||||
- aucune preuve indispensable ne soit cachée par une seconde surface au même
|
||||
emplacement horizontal ;
|
||||
- une absence de mesure reste inconnue et ne soit pas comblée artificiellement ;
|
||||
- les limites de la zone jouable ne soient pas présentées comme un relief à
|
||||
interpréter.
|
||||
|
||||
Les épaves, le sous-marin, le navire et les accessoires restent de véritables
|
||||
modèles 3D pour le rendu et les collisions. Une épave peut présenter des
|
||||
ouvertures, des volumes, des éléments dressés et des zones interactives. Le
|
||||
sonar de la V1 n'a toutefois pas à reconstruire précisément son intérieur, son
|
||||
dessous ou plusieurs ponts superposés.
|
||||
|
||||
Les surfaces anormales et les épaves peuvent être signalées par des
|
||||
`SonarContact` distincts et par leur contribution visible à la surface
|
||||
extérieure. Une interaction, une observation visuelle ou un indice du dossier
|
||||
confirme ensuite leur nature. Le renderer sonar ne fabrique pas un volume
|
||||
intérieur pour compenser les limites de la bathymétrie.
|
||||
|
||||
Un surplomb purement décoratif reste autorisé s'il n'est ni une route, ni un
|
||||
abri nécessaire, ni le support d'une information de mission et si son absence
|
||||
ou sa simplification sur le sonar ne trompe pas le joueur. Cette exception est
|
||||
vérifiée lors de la revue du site et des tests humains.
|
||||
|
||||
Aucune interface générique pour plusieurs couches, aucun voxel local et aucun
|
||||
champ de distance ne sont ajoutés préventivement. Le contrat du scan conserve
|
||||
les valeurs réelles et les contacts nécessaires, sans prétendre résoudre un
|
||||
besoin futur non validé.
|
||||
|
||||
### Déclencheur d'une évolution
|
||||
|
||||
Un prototype de représentation hybride devient nécessaire seulement lorsqu'un
|
||||
site retenu exige au moins l'un des comportements suivants :
|
||||
|
||||
- naviguer au-dessus et au-dessous de surfaces superposées ;
|
||||
- lire au sonar l'entrée et la continuité d'une grotte ou d'un tunnel ;
|
||||
- distinguer plusieurs ponts, plafonds ou niveaux comme information de jeu ;
|
||||
- représenter une cible indispensable qu'une carte de hauteur rend ambiguë ou
|
||||
invisible.
|
||||
|
||||
Ce prototype comparera au minimum couches bathymétriques locales, fragments de
|
||||
maillage et représentation volumétrique bornée. Son adoption, ses données et
|
||||
son coût de persistance nécessiteront un nouvel ADR. Elle ne modifiera pas
|
||||
silencieusement le contrat de la V1.
|
||||
|
||||
## Conséquences
|
||||
|
||||
- La reconstruction sonar reste continue, compacte et compatible avec le
|
||||
langage visuel validé par le POC B.
|
||||
- Le level design de la verticale doit éviter les configurations que le sonar
|
||||
ne peut pas communiquer honnêtement.
|
||||
- Les épaves peuvent conserver une géométrie visuelle riche sans imposer un
|
||||
sonar volumétrique.
|
||||
- Certaines formes 3D seront simplifiées ou absentes de la carte sonar ; elles
|
||||
ne peuvent pas porter seules une information critique.
|
||||
- Les budgets de la tranche sonar ne comprennent ni voxelisation, ni
|
||||
reconstruction multi-couche, ni navigation dans une grotte.
|
||||
- Une future évolution dispose de déclencheurs concrets et devra prouver sa
|
||||
lisibilité avant d'élargir le format de scan.
|
||||
|
||||
## Alternatives considérées
|
||||
|
||||
- **Construire immédiatement un sonar hybride** : rejeté, car aucun objectif de
|
||||
la verticale ne justifie encore son coût de données, de rendu et de test.
|
||||
- **Utiliser des voxels pour tous les sites** : rejeté, car les essais du POC B
|
||||
ont montré une lecture plus confuse que la surface bathymétrique continue.
|
||||
- **Aplatir silencieusement une grotte complexe dans la carte** : rejeté, car le
|
||||
sonar donnerait une information trompeuse au joueur.
|
||||
- **Interdire toute géométrie 3D complexe aux épaves** : rejeté, car la limite
|
||||
concerne la représentation sonar et le level design critique, pas les modèles
|
||||
visuels ou les collisions locales.
|
||||
Reference in new issue
Block a user