LifePlay-Revival/Docs/Migration/etat/REL/STM1/STM1-SPEC-02.md

Fiche STM1-SPEC-02 — Niveau N2 — Modèle prévu opus medium | utilisé claude-opus-5-5 — Agent session « Medium · STM1 » (pas de sous-agent) — Skills sk-protocol

STM1-SPEC-02 : montrer l'eau en mode carte par défaut (étude, cible build 2 ou suivante) (2026-10-20)

Ordre : Big Boss (local_104ff22d), priorité normale. Résultat de T2 cité par Big Boss : « point 1à3 ok » (en carte classique, la Tamise apparaît, fond bleu dans le fleuve) ; cause établie : mode par défaut, pas de régression 5.8. Décision de l'utilisateur, citée par Big Boss : « Garde le mode par défaut et fais étudier un plan d'eau sous le fleuve (fiche STM1) pour une build suivante. » Étude seule : sans copie UE, sans IMPL. La trace [LPCity] reste en place.

Résultat : étude faite ; recommandation : O-B (maillage d'eau par ville, tiré d'OSM et recalé sur la carte existante, posé par un sous-système C++ sans toucher au GI ni aux 281 cartes). Commencer par un pilote sur Londres. Aucune option n'est engagée sans accord de l'utilisateur.

1. Rappel des faits (établis : CART-03, CART-04)

• Mode par défaut (ClassicMap = false) : le sol de toute la ville, fleuve compris, est le Plane de MapMarkers (PavementMat : beige, texture pavement, TilingRate 50 000). La carte se dessine par-dessus avec StreetMapMasked : si VertexColor.R > 0,9, texture road, sinon vert foncé.
• Mode classique : MapMarkers masque le Plane ; la carte (StreetMapClassic) a un trou sur le fleuve, et le fond bleu sombre y donne l'« eau ».
• Données : 0 polygone d'eau dans les 280 UStreetMap. L'importeur actuel lit pourtant les voies d'eau fermées (natural=water, waterway=*, water=*, certaines landuse : Plugins/StreetMap/Source/StreetMapImporting/OSMFile.cpp:342-378) : les villes ont été importées avant cette prise en charge, ou leurs fichiers n'en contenaient pas. L'importeur ne lit pas les relations (multipolygones). Or les grands fleuves (la Tamise : water=river en multipolygone) et les mers (trait de côte natural=coastline) passent par là. Un réimport simple ne suffirait donc pas.
• Projection des cartes : sinusoïdale (Sanson-Flamsteed), relative à la moyenne des latitudes et longitudes du fichier .osm d'origine (StreetMapFactory.cpp:57-80, OSMFile.AverageLatitude/Longitude), en centimètres (OSMToCentimetersScaleFactor = 100). Cette origine n'est pas conservée dans l'asset (seulement BoundsMin/BoundsMax, StreetMap.h:173-177), et les .osm sources sont absents (RECH-01 A3). Toute couche ajoutée doit donc être recalée.

2. Options comparées

Option	Principe	Pour	Contre	Coût (estimé)	Risque
O-A : masque d'eau par ville dans le matériau du sol	texture noir et blanc par ville (eau = blanc), rasterisée hors ligne depuis OSM ; instance dynamique de PavementMat qui mélange pavé et couleur d'eau selon le masque ; posée au changement de ville	gère les trous (îles) et les côtes sans triangulation ; un seul plan	mémoire : 281 textures (1 024² BC4 ≈ 0,7 Mo, soit ≈ 200 Mo au paquet ; 2 048² ≈ 560 Mo) ; bords flous à grande échelle ; matériau à modifier (Bu_Base est partagé)	moyen	moyen : taille du paquet, netteté
O-B (recommandée) : maillage d'eau par ville	un StaticMesh plat par ville (/Game/Heavy/StreetMap/Water/<Ville>), construit hors ligne depuis les polygones d'eau OSM (relations comprises), dans la projection de la carte ; posé 1 à 2 cm au-dessus du Plane par un sous-système C++ quand la carte change (même détection que la trace POSE) ; matériau d'eau simple (bleu, rugosité basse)	bords nets ; quelques Mo au total ; aucune modification du GI, des 281 cartes ni des matériaux existants ; masquable en mode classique ; villes sans eau : pas d'asset	outil hors ligne à écrire (lecture des relations, recalage, triangulation avec trous) ; un asset de plus par ville avec eau	moyen à élevé (pilote ≈ 2-3 j, toutes les villes + 2-3 j)	moyen : recalage ; scintillement avec le Plane si l'écart en Z est trop faible
O-C : réimporter les 280 UStreetMap avec l'eau	ajouter les relations à l'importeur, réimporter, régénérer les maillages Static	données propres dans UStreetMap.Waters	change les bâtiments et les routes (OSM d'aujourd'hui ≠ 2020) : indices de bâtiments, CityExpansion, sauvegardes, mods ; 280 maillages à refaire (classe ERR-018) ; en mode par défaut, StreetMapMasked peindrait l'eau en vert (R = 0,26 ≤ 0,9)	élevé	élevé : régression de données de jeu
O-D : déduire l'eau à l'exécution	capture de dessus de la carte, puis zones vides et vastes = eau	aucune donnée ajoutée	confond terrains vides, places et cours avec l'eau ; coût de capture au chargement	moyen	élevé : faux positifs
O-E : plan d'eau sous un Plane percé	variante d'O-A : Plane masqué (opacité) là où il y a de l'eau, plan bleu dessous	réutilise le fond	même masque qu'O-A, plus un plan ; matériau masqué sur un plan de la taille de la ville	moyen	moyen
O-F : carte classique par défaut	—	gratuit	écartée par l'utilisateur (« Garde le mode par défaut »)	—	—

3. Option recommandée O-B : esquisse de SPEC (à affiner après le pilote)

1. Données (hors ligne). Source : extraits OSM sous licence ODbL :
   • extraits régionaux Geofabrik (*.osm.pbf) ou requête Overpass sur la boîte de chaque ville, pour l'eau intérieure : natural=water, water=*, waterway=riverbank, relations type=multipolygon ;
   • polygones de mer prétraités d'OpenStreetMap Data (water-polygons-split) pour les villes côtières. Tout téléchargement se fait sur accord explicite de l'utilisateur (règle de sûreté), avec la source exacte notée (règle des crédits).
2. Recalage (point critique). L'origine perdue se retrouve par appariement : bâtiments nommés de l'UStreetMap (Londres : 12 092) contre les mêmes noms dans l'extrait OSM. Pour chaque paire : RelLat = Lat + y/k, RelLon = Lon − x/(k·cos Lat), avec k = 40 075 036 / 360 × 100 cm/°. On prend la médiane, et le contrôle d'acceptation est un résidu médian inférieur à 2 m. La même formule projette ensuite chaque sommet d'eau (StreetMapFactory.cpp:57-80).
3. Maillage. Triangulation des polygones avec trous (îles) : ConstrainedDelaunay2 de GeometryCore, disponible dans le moteur (estimé, à vérifier). Un StaticMesh par ville, une section, sans collision, créé par un commandlet de LifePlayEditorTools (dans la lignée de LPCheckStreetMap), sous instantané.
4. Pose en jeu. Un sous-système C++ (modèle LPCityTraceSubsystem) :
   • quand le maillage de la carte change, il charge /Game/Heavy/StreetMap/Water/<Ville> s'il existe ;
   • il l'attache à StreetMap_Static (même transformation), avec un décalage de Z au-dessus du Plane ;
   • il le cache si ClassicMap est vrai, au choix de l'utilisateur, puisque le fond fait déjà office d'eau dans ce mode. Aucune révision du GI (contrainte B2 respectée). Z exact du Plane : à lire en PIE (non lu, CART-04 § 5).
5. Matériau. Un matériau d'eau neuf, opaque et simple (couleur, rugosité, normale animée en option), sans toucher à Bu_Base ni à StreetMap*.
6. Pilote : Londres seule. Captures avant et après sur la vue de COMMUN-14 ; résidu de recalage ; aucune régression (trace [LPCity], POSE inchangée).
7. Généralisation : passage en lot sur les villes qui ont de l'eau, puis revue visuelle par échantillon (10 villes, dont 3 côtières).

4. Effet sur les 281 villes, coût, risques, licence

• Effet : seulement les villes avec de l'eau. Les autres restent identiques ; la ville factice 000Dummy est exclue. Les données de jeu (UStreetMap, bâtiments, sauvegardes) ne changent pas.
• Coût (estimé) :
  • pilote Londres : commandlet et recalage ≈ 1,5-2 j, sous-système ≈ 0,5 j, essai ≈ 0,5 j ;
  • toutes les villes : données et lot ≈ 1 j, revue ≈ 1-2 j ;
  • taille ajoutée au paquet : quelques Mo.
• Risques :
  1. recalage imprécis (eau décalée sur les quais) : contrôle du résidu, ville par ville ;
  2. côtes : polygones de mer volumineux, à découper à la boîte de la ville ;
  3. scintillement avec le Plane : écart en Z et priorité de tri ;
  4. Content/Heavy n'est pas suivi par git (.gitignore:17) : les nouveaux assets se sauvegardent par instantané et se distribuent avec le contenu lourd, comme les cartes ;
  5. OSM d'aujourd'hui ≠ OSM de 2020 : des berges réaménagées peuvent ne plus coller aux bâtiments d'origine (effet attendu faible pour les fleuves).
• Licence ODbL : attribution obligatoire, « © OpenStreetMap contributors », lien vers la licence, dans les crédits avec la source exacte. Elle est déjà due pour les 280 cartes actuelles, ce qu'il faut vérifier (RECH-02 § 3). Les maillages d'eau sont dérivés d'OSM. Comme travail produit (« Produced Work »), le jeu peut garder sa licence. En cas de lecture comme base dérivée, les polygones d'eau resteraient sous ODbL et seraient fournis sur demande. La règle du doc 27 n'est pas concernée (données géographiques).

5. Décisions attendues de l'utilisateur (aucune prise ici)

1. Option : O-B (recommandée), O-A ou O-E.
2. Pilote Londres d'abord : oui ou non.
3. Eau visible aussi en mode classique : oui (plus lisible) ou non (fond actuel).
4. Accord pour télécharger les extraits OSM (sources et tailles annoncées avant le téléchargement).

6. Incertitudes, écarts, fichiers

• Non vérifié : disponibilité et API exacte de ConstrainedDelaunay2 en 5.8 ; transformation du Plane à l'exécution ; volume des extraits ; présence réelle de la Tamise en relation dans l'OSM actuel (attendu, non lu).
• Fichiers écrits : D:\Game\LifePlay-master 5.8\Docs\Migration\etat\REL\STM1\STM1-SPEC-02.md (A) ; STM1-TACHES.md (M).

Tours : ≈ 4 / 40 (déclaré ; FicheStats.py fait foi).

À verser : doc de la carte — l'origine de projection des cartes StreetMap n'est pas stockée : toute couche ajoutée se recale par appariement des bâtiments nommés (formule § 3.2).

Suite : Big Boss doit présenter les décisions du § 5 à l'utilisateur ; ensuite, fiche IMPL du pilote Londres (commandlet, sous-système, matériau) sous instantané, pour la build 2. État : SPEC d'étude close.