LifePlay-Revival/Docs/Migration/etat/ST/STG/STG-B2q-DIAG.md

Fiche STG-B2q-DIAG — Niveau N3 — Modèle prévu claude-opus-5-5 | utilisé claude-opus-5-5 — Agent orchestrateur STG (session principale) — Skills lp-lot, sk-protocol

STG-B2q-DIAG : personnages assis éliminés par le rendu (2026-10-14)

Fiche B2q, confiée à STG par Big Boss (CAM est pris par B2p ; le sujet touche le maillage des Person). DIAG en lecture seule, sans UE et sans écriture hors de ce livrable. Lot STG, registre STG-TACHES.md.

Faits donnés par Big Boss :

• COMMUN-6, 05:28-05:32, au bar : la PNJ d'en face, puis le joueur assis, disparaissent selon l'angle de C2. hidden=0, et aucune ligne T-occ : le rayon caméra → tête était libre.
• COMMUN-7, 07:48, au café (« Having a meal ») : « Bridget a disparu ». Le joueur est assis fnt_new048, place _67 (journal : OccupyingFnt _67 dès 07:47:45, currentAnimation=fnt_new048-f-0-sit, meshZ=-80.4) ; la capture montre une chaise vide.

Point de départ : hypothèse de CAM (etat\CAM\CAM-COMMUN6-DIAG.md § 8), reprise et vérifiée ci-dessous.

1. Sources

Repère	Fichier
E1	moteur UE 5.8, Engine\Source\Runtime\Engine\Private\Components\SkeletalMeshComponent.cpp l. 3417-3495 (USkeletalMeshComponent::CalcBounds)
E2	idem, SkinnedMeshComponent.cpp l. 2169-2175 (CalcBounds) et l. 2225-2300 (CalcMeshBound)
P	etat\portage55\L6f\L6f_dump_Person.txt : graphes de Person (UserConstructionScript l. 1-12, NewProxy l. 1851-1955)
C	etat\CAM\CAM-T4_LPDumpComponents_20261011-004910.txt : composants SCS de Person (PenisSM, HairSM, DirtyTalkSM, parents CharacterMesh0)
A	Content\BPs\Person.uasset : table des noms (grep -c -a)
I	Config\DefaultEngine.ini l. 30
J	journal en cours de COMMUN-7 (café)

2. Ce qui est établi

2.1 Comment UE 5.8 calcule les bornes de rendu d'un SkeletalMesh (E1, E2)

USkeletalMeshComponent::CalcBounds appelle CalcMeshBound(RootBoneTranslation, bHasValidBodies, …). Dans CalcMeshBound, les cas sont examinés dans cet ordre :

1. composant invisible, ou bComponentUseFixedSkelBounds : bornes de l'asset ;
2. composant leader en bornes fixes : bornes de l'asset du leader ;
3. leader avec bUseBoundsFromLeaderPoseComponent : bornes du leader ;
4. asset physique avec corps : AABB des corps, qui suivent les os, donc la pose ;
5. leader avec asset physique : idem, sur les corps du leader ;
6. sinon, bornes importées de l'asset (pose de référence, debout), décalées de la seule translation de l'os racine ;

puis BoxExtent *= BoundsScale, autour du même centre.

Sans asset physique, les bornes ne suivent donc pas la pose : seul le déplacement de l'os racine les déplace.

2.2 Les maillages des Person

• Pas d'asset physique sur bridget_gp ni michael (CAM § 8 : aucun import PhysicsAsset). Les corps tombent dans le cas 6.
• Composants (C) :
  • le corps est CharacterMesh0, hérité de ACharacter ;
  • PenisSM et HairSM lui sont attachés. UserConstructionScript leur donne le corps comme leader pose (P l. 1-12) ;
  • DirtyTalkSM est un widget.
• Vêtements, cheveux et accessoires ajoutés par Person::NewProxy (P l. 1851-1955) : sur chaque nouveau composant, SetBoundsScale(3.0), SetCastShadow(false), SetRenderCustomDepth(true), bUseAttachParentBound = true, puis SetLeaderPoseComponent(Mesh). Ces composants prennent donc les bornes du corps, et leur BoundsScale 3 est sans effet (les bornes du parent sont reprises telles quelles). Conséquence : quand le corps est éliminé, tout disparaît avec lui (vêtements, cheveux). C'est bien « la chaise vide ».
• Corps (CharacterMesh0) : aucun graphe de Person ne règle ses bornes. La table des noms (A) ne contient ni bComponentUseFixedSkelBounds, ni bUseBoundsFromLeaderPoseComponent, ni bIncludeComponentLocationIntoBounds. Ses 3 occurrences de BoundsScale s'expliquent par SetBoundsScale / NewBoundsScale, ses 2 de bUseAttachParentBound par le nœud de NewProxy. Une valeur de BoundsScale stockée sur le gabarit du corps n'est pas exclue sans lecture MCP. Estimé : 1 (défaut).
• r.AllowOcclusionQueries=True (I) : les requêtes d'occlusion sont actives.
• Aucun C++ du projet ne touche aux bornes ni au culling (grep de BoundsScale, bUseAttachParentBound et LeaderPose dans Source/ : 0).

2.3 Les poses assises

• Assis, le corps joue l'animation de meuble dans l'Anim BP (anim=bp:Daily_F_C currentAnimation=fnt_new048-f-0-sit), et le composant est relevé (meshZ -80,4 au lieu de -90). Les bornes restent celles de la pose debout, autour de la racine.
• Ce DIAG n'établit pas de combien le corps s'écarte de la racine dans ces animations. Le journal ne relève ni les os en XY ni les bornes. Les relevés M1d (COMMUN-6) ne donnent que des hauteurs, en scène de couple.

3. Cause (estimée, forte)

Le corps assis est éliminé parce que ses bornes, celles de la pose debout autour de la racine, ne contiennent plus le corps. Les animations de meuble déplacent le bassin et non la racine. Deux mécanismes sont possibles, selon l'angle :

• occlusion : les bornes sont derrière la table, le comptoir ou le dossier, alors que le corps dépasse et est visible. La requête d'occlusion les juge cachées et élimine le maillage entier, vêtements compris. C'est le plus probable au bar et au café (tables), en C2 qui tourne autour ;
• frustum : les bornes sont hors du champ alors que le corps y est.

hidden=0 et l'absence de T-occ sont compatibles avec les deux. Trancher entre eux, et mesurer l'écart, demande le témoin du § 5.

À exclure, peu probable :

• la distance d'affichage (MaxDrawDistance / CullDistance) : le joueur assis est proche ;
• le LOD : un maillage n'est pas éliminé par le LOD ;
• VisibilityBasedAnimTickOption : il arrête l'animation, pas l'affichage.

Observation annexe (hors B2q) : l'assiette et le sandwich qui flottent près de l'épaule de la PNJ au café sont un accessoire de place mal attaché. Mineur ; à noter pour plus tard.

4. Correctif proposé (C++ sans asset ; rien n'est écrit sans GO)

Id	Geste	Coût d'écriture	Coût de rendu	Risque
B2q-a (recommandé)	BoundsScale adaptatif du corps. Toutes les 0,5 s, pour chaque Person_C visible de la pièce, on calcule l'écart entre le bassin (hip, sinon pelvis, sinon l'os 0) et le centre des bornes du corps, puis le facteur S = max(1, (écart + rayon des bornes) / rayon des bornes), borné à 4. On ne l'applique qu'en cas de changement de plus de 10 % : SetBoundsScale(S), UpdateBounds(), MarkRenderStateDirty(). Une ligne de journal par changement. Debout, S = 1 : pas de surcoût. Assis, couché ou en meuble, S couvre le corps déplacé. Les vêtements suivent (bUseAttachParentBound).	≈ 50 lignes C++ (DirectControl ou Debug, fichier STG), N3, VAL, 1 build	seulement pour les personnages assis : leurs bornes sont jusqu'à 4 fois plus grandes, donc ils sont un peu plus souvent dessinés hors champ ou cachés (ombres comprises). Faible pour une dizaine de corps ; à mesurer au bar (stat unit avant/après)	faible : les bornes de rendu ne servent ni aux collisions ni aux tracés
B2q-b (repli, plus simple)	BoundsScale = 3 fixe sur le corps de toutes les Person (balayage toutes les 2 s, comme le propose CAM)	≈ 30 lignes	constant, sur tous les personnages, même debout	faible ; il peut ne pas suffire si l'écart dépasse ≈ 1,2 m
B2q-c	Asset physique pour bridget_gp et michael : des bornes exactes qui suivent les os	2 gros assets dans l'éditeur, hors alpha	nul	les corps entrent dans les tracés Visibility (sondes C2, T-occ)
B2q-d	r.AllowOcclusionQueries=False	1 ligne de config	global (tout le jeu)	ne règle pas le cas frustum ; non recommandé

bIncludeComponentLocationIntoBounds (suggéré par Big Boss) n'ajoute à la boîte que le point d'origine du composant (E2 l. 2173-2175, E1 l. 3472-3487). Cela ne couvre pas un corps déplacé : non retenu.

5. Témoin proposé (T-cull, à mettre dans le même build ; recommandé même avec B2q-a)

Dans LPDebugSubsystem (relevé des personnes, actif avec -LPPersonsLog), toutes les 0,5 s, pour chaque Person_C non cachée à moins de 15 m de la caméra :

• une ligne de mesure par changement de pose de meuble (currentAnimation ou OccupyingFnt) : T-cull mesure <Person> anim=<fnt…> bassin a %.0f cm du centre des bornes (dans=%d) ; bornes %.0f x %.0f x %.0f ; BoundsScale %.2f ; physAsset=%d ;
• une ligne d'alerte si le bassin est à l'écran (ProjectWorldLocationToScreen dans le viewport) et que le corps n'a pas été rendu depuis 0,2 s (WasRecentlyRendered(0.2f) faux) : T-cull : <Person> non rendue, bassin a l'ecran, a %.0f cm du centre des bornes (dans=%d), occlusion=%d.

Ces lignes chiffrent l'écart réel des poses assises et tranchent entre occlusion et frustum (dans=0 avec le centre des bornes hors du champ : frustum). Elles diront aussi si B2q-a suffit. Coût : ≈ 35 lignes, 1 build ; journal seulement.

5b. Complément (Big Boss, café, 07:48-07:49)

L'utilisateur rapporte : « les deux ont disparu ». Les deux personnages assis à la même table (le joueur et la PNJ) disparaissent en même temps, sous un même angle de C2. Cela va dans le sens du § 3 : deux corps assis à la même table ont chacun leurs bornes debout centrées sur leur racine, et les deux boîtes passent ensemble derrière le même plateau ou hors du champ au même angle. Une cause propre à un personnage (vêtement, animation, hidden) est moins probable. Le mécanisme occlusion par la table reste le plus probable ; le témoin T-cull le tranchera (dans=0 et occlusion=1 attendus pour les deux à la même heure).

6. Estimation et ordre proposé

1. T-cull et B2q-a dans le même build (COMMUN-8 ou suivant), avec une VAL statique : ≈ 85 lignes, N3, 1 build.
2. Essai :
   • le bar (C2 autour de la PNJ d'en face, puis du joueur assis) ;
   • le café, assis à fnt_new048 ;
   • un personnage couché ;
   • stat unit avant et après, au bar.
3. Si une disparition persiste avec une ligne T-cull à dans=1, la cause n'est pas les bornes : ouvrir une fiche Ombres/occlusion.

7. Fichiers à commiter

Docs/Migration/etat/ST/STG/STG-B2q-DIAG.md.

Tours : 14

8. Complément après l'essai COMMUN-8 : B2q-a insuffisant au café (2026-10-14)

Demande de Big Boss : l'utilisateur dit « manque l'homme » (café, vers 09:09) ; l'homme assis est invisible, son téléphone flotte. DIAG en lecture seule, sans UE.

8.1 Ce que dit le journal (établi)

Source : D:\Game\LifePlay_Build_5.8_COMMUN-8_Development\Windows\LifePlay\Saved\Logs\LifePlay.log (10 128 lignes à la lecture).

• Bar, chambre (B2q-a a suffi) : bassin à 13-123 cm du centre des bornes selon le meuble (fnt_chair06 : 123 cm, une autre place : 47 cm) ; S monte à 1,5-4 et l'écart est couvert.
• Café (cafe___vin01, chargé à 09:07:11, places fnt_new048 _59, _60, _66, _67) : bassin à 290 cm (hommes, anim. fnt_new048-m-0-sit) et 297 cm (femmes, -f-0-sit) du centre des bornes. Les mesures sont identiques pour les quatre personnes de même sexe, au cm près. S plafonne à 4, et les alertes T-cull : … non rendue … dans=0, centre a l'ecran=0 sont fréquentes : PlayerCharacter 86, Person_C_2147481930 34, …906 2, …954 1.
• Les capsules (LPDebug persons) sont sur les places : PlayerCharacter en (-3131768, -14967061) sur _59, …930 sur _60, la chaise sous chacun (visibleComp = la place, -41,1). Le téléphone flotte « à sa place » sur la capture. Le corps est donc à la place, et c'est le centre des bornes qui est à ≈ 3 m.
• Fait nouveau, qui corrige le § 2.2 du DIAG : à la première vue de chaque personne, la ligne B2q-a part de BoundsScale 3.00 (5 lignes 3.00 -> …, dont 3 3.00 -> 1.00). Le corps a déjà BoundsScale 3 dans le jeu d'origine : c'est le réglage du gabarit ou d'un Blueprint (le même 3 que NewProxy). L'estimation « 1 (défaut) » du § 2.2 était fausse. B2q-a ramène les personnes debout à 1 : c'est une baisse par rapport à l'origine (risque R3 de la VAL réalisé). Elle est sans dommage visible debout, puisque le bassin est à 13-16 cm du centre, mais il faut la corriger.

8.2 Pourquoi le centre des bornes est à 3 m (estimé, fort)

Sans asset physique, les bornes sont celles de l'asset, décalées de RootBoneTranslation, la translation de l'os racine dans la pose courante (§ 2.1 ; moteur SkeletalMeshComponent.cpp l. 3449-3470). La capsule et le corps sont sur la place, et les bornes sont à 290 ou 297 cm, avec une valeur fixe par animation (hommes 290, femmes 297, sur 4 places différentes). Lecture : l'animation de meuble fnt_new048-*-0-sit déplace l'os racine d'≈ 3 m, et l'os du bassin compense en sens inverse. Le corps reste sur la place, mais UE croit que le maillage a suivi la racine. C'est la même cause que pour les écarts plus petits (fnt_chair06 : 123 cm). L'amplitude dépend de l'animation, sans doute de la façon dont elle a été créée ou convertie : racine au pivot du groupe de meubles. Non établi : la position de l'os racine n'est pas au journal. Le témoin du § 8.4 l'écrira.

Plafond nécessaire avec B2q-a : le facteur s'applique de façon uniforme aux trois axes. Un écart de 290 cm le long de l'axe mince des bornes (demi-étendue 13 cm, épaisseur du corps en pose de référence) demande S ≈ (290 + 13) / 13 ≈ 23, soit des bornes de ≈ 6 × 29 × 41 m. À ce niveau, la personne n'est plus jamais éliminée : la culling est de fait coupée pour elle.

8.3 Correctif proposé B2q-b (rien n'est écrit sans GO)

Id	Geste	Coût d'écriture	Coût de rendu	Risque
B2q-b1 (recommandé pour l'alpha)	Dans FitPersonBounds : (1) plancher = l'échelle d'origine de chaque personne, relevée à la première vue (3 dans le jeu d'origine) : plus jamais en dessous, ce qui corrige la baisse de B2q-a ; (2) plafond porté à 25 ; le facteur est calculé comme aujourd'hui, au besoin réel par axe.	≈ 15 lignes, N3, VAL, 1 build	seulement pour les personnes dont la pose sort des bornes (au café, toutes les assises) : elles ne sont plus jamais éliminées (frustum ni occlusion), ombres comprises. Au café, 4 à 6 corps Daz (≈ 50-100 k triangles chacun) toujours dessinés. Estimé faible à modéré ; à mesurer par les lignes LPDebug hitch au café (COMMUN-8 contre le build suivant)	faible : aucun effet sur collisions ni tracés ; journal inchangé (une ligne par changement de plus de 10 %)
B2q-b2 (après l'alpha, juste)	Recentrer les bornes sur le bassin : réécrire RootBoneTranslation du corps avec la position du bassin (en espace composant) après l'évaluation de l'animation et avant le calcul des bornes ; les bornes suivent alors le corps à S = 3	≈ 30 lignes, mais l'ordre des ticks (animation, puis bornes, puis notre ticker) n'est pas établi sans essai ; N4	nul	moyen : RootBoneTranslation est recalculé à chaque évaluation ; l'écriture peut être écrasée ou arriver trop tard (une image de retard)
B2q-b3 (après l'alpha)	Asset physique minimal créé en mémoire (un corps sphérique sur l'os du bassin, PhysicsAssetOverride), collision du corps mise à NoCollision : les bornes suivent les os (cas 4 du § 2.1)	≈ 40 lignes, N4	nul	élevé sans essai : création des corps physiques, entrée dans les tracés Visibility si la collision n'est pas coupée à temps, chemin bHasValidBodies à vérifier
B2q-b4	Corriger les animations de meuble (racine au siège)	assets, hors alpha	nul	conversion de toutes les fnt_*

Recommandation : B2q-b1 pour l'alpha (simple, sûr, coût borné aux seules personnes assises loin de leur racine), plus le témoin du § 8.4. B2q-b2 sera étudié après l'alpha si le coût mesuré gêne.

8.4 Témoin complété (même build, ≈ 5 lignes)

La ligne T-cull mesure donnera aussi la distance de l'os racine (os 0) au bassin et au composant : … racine a %.0f cm du bassin, a %.0f cm du composant. Une racine à ≈ 3 m du bassin et du composant établit le § 8.2.

8.5 Cas d'essai à ajouter (build suivant)

• Café : assis au comptoir ou à une table fnt_new048, avec les PNJ assis ; tourner C2 tout autour. Plus aucune disparition, plus aucune alerte T-cull … non rendue ; B2q-a : … BoundsScale 3.00 -> 2x.xx et racine a ≈ 290-300 cm du bassin.
• Debout : aucune ligne B2q-a … -> 1.00 (plancher à l'échelle d'origine).
• Coût : lignes LPDebug hitch au café, comparées à COMMUN-8.