Session 132duodecimus (suite 13b) — Phase C portes : UV slide + collision Bullet

Bugs fixes apres test utilisateur de la suite 13

Fix 1 : UV qui glisse au lieu de se compresser

Dans DoorControl.updateMeshes(), on met aussi a jour le buffer TexCoord.
Quand le panneau se reduit (yBot remonte vers le plafond couloir), le V_bas
de l’UV remonte proportionnellement, gardant l’echantillonnage texture
intact. La texture donne alors l’illusion de glisser vers le haut derriere
le linteau au lieu d’etre compressee.

ratio = (yBot_courant - corridorFloorY) / (corridorRoofY - corridorFloorY)
              0 = ferme,  1 = ouvert
V_bot_courant = V_bot_initial + ratio * vMaxFull
V_top_courant = V_top_initial (= V_bot_initial + vMaxFull) -- inchange

Quand la porte est completement ouverte, V_bot atteint V_top -> le quad
collapse simultanement en hauteur ET en UV : pas de compression visible.

L’UV initial est lu depuis geo.userData.uvBaseFull (ou uvBase en fallback,
deja stocke par LevelSceneBuilder.makeDoorSegGeo). Le snapshot est fait au
premier setSpatial pour ne pas dependre d’un buffer eventuellement deja
modifie.

Fix 2 : collision Bullet sur portes fermees

L’ancienne approche WallCollision.addSegment() n’etait pas branchee a
Bullet (collision via RigidBodyControl sur le Node geometry). Les portes
sont dans un Node distinct doors -> aucune collision physique.

La solution : pour chaque porte, on construit un MeshCollisionShape
statique a partir du mesh ferme (panneaux a leur position initiale). Un
RigidBodyControl mass=0 est attache au Node et ajoute/retire du
PhysicsSpace a chaque frame selon canPass :

canPass = currentRoofY < (corridorFloorY - PLAYER_HEIGHT - 0.05f)
if (canPass)  PhysicsSpace.remove(rbc);
else          PhysicsSpace.add(rbc);

Le shape ne change jamais (il refleterait toujours l’etat ferme), mais ce
n’est pas un probleme : quand la porte est ouverte, on retire totalement
le RigidBody. Le mesh visuel continue de se deformer chaque frame (animation
de glissement), independamment du shape de collision.

Ajout d’un champ statique DoorControl.PHYSICS_SPACE alimente par
GameAppState.setupPhysics() avec le PhysicsSpace de BulletAppState. Le
cleanup le remet a null pour eviter les fuites entre niveaux.

Bug 2 (cotes zone 30) : remis a plus tard

La porte zone 30 est plus complexe (plusieurs ZDoorWalls, eventuellement
recoin). Quand elle est ouverte les cotes disparaissent en laissant un
trou noir. Hypotheses :

• Le plafond polygonal mobile couvre des points hors de la « niche » de
  porte et masque l’interieur quand il monte.
• Des walls intermediaires non-ZDoorWall partagent un edge avec un
  ZDoorWall et sont skippes a tort par le filtre doorEdgesGlobal.
• L’intersection des polygones de la zone-porte et des couloirs voisins
  cree un Z-fighting / face culling problematique.

Pour corriger cela proprement, il faut inspecter le binaire du niveau A
zone 30 (edges, walls, ZDoorWalls). Cette analyse est differee a la
prochaine iteration de Phase C.

Fichiers modifies

• DoorControl.java : ajout slide UV dans updateMeshes(), RigidBody
  Bullet dans setSpatial(), PHYSICS_SPACE statique.
• GameAppState.java : alimente DoorControl.PHYSICS_SPACE apres
  BulletAppState.init. Cleanup nettoie la ref.

Tests prevus

• Niveau A premiere porte (zone 5) : doit s’ouvrir au contact, glissement
  fluide vers le haut sans compression de la texture chevron.
• Joueur ne traverse plus la porte fermee.
• Joueur peut passer une fois la porte suffisamment ouverte (yBot remonte
  au-dessus de tete + epsilon).
• Porte zone 30 : a analyser cas par cas, probablement encore le bug visuel
  des cotes.