264 lines
No EOL
17 KiB
Markdown
264 lines
No EOL
17 KiB
Markdown
# 11 — Audit d'optimisation UE 5.5 (lot O0)
|
||
|
||
> Chantier ouvert le 2026-10-02, après la migration (V1.1). Objectifs fixés par l'utilisateur :
|
||
> ressources obsolètes ou gourmandes, goulots d'étranglement, organisation des dossiers, optimisations
|
||
> propres à UE5, suppression du superflu, outils et exemples Fab.
|
||
> Ce document est le **lot O0** : mesures en lecture seule, aucune modification du projet. Les lots O1
|
||
> et suivants (§6) suivent `10_Protocole_Operations.md`.
|
||
|
||
---
|
||
|
||
## 1. Méthode et outils
|
||
|
||
| Mesure | Outil | Résultat |
|
||
|---|---|---|
|
||
| Inventaire des 8 563 assets (classe, taille, tags, références) sans chargement | `Tools/AuditAssets.py` (registre d'assets, exécuté par `-run=pythonscript`) | `Saved/Audit/assets.jsonl` |
|
||
| Noms d'assets cités par les données et les Blueprints | croisement avec le texte de `Content/Modules` et les tables de noms de `BPs`, `UI`, `Scenes` | `Saved/Audit/candidats_jamais_nommes.json` |
|
||
| Composition du build livré | build Shipping V1.1 (`LifePlay_Build_5.5_Shipping`) | §3 |
|
||
| Performances en jeu | profileur CSV + suivi mémoire LLM : `LifePlay_profil_O0.bat` (build L7cdj) | **à faire par l'utilisateur** (§5) |
|
||
|
||
Contrainte découverte, déterminante pour toute suppression ou réorganisation : **le jeu désigne la
|
||
plupart des assets par leur nom court** (`Clothes4.txt`, `.lpworld`, `.lpcharacter`), et les retrouve
|
||
en parcourant le registre par classe (`GetAssetsByClass`). Un asset sans référence dans le registre
|
||
peut donc être utilisé en jeu. Seules 5 lignes de données citent un chemin `/Game/` complet (lunettes
|
||
de `New3/Clothes`).
|
||
|
||
## 2. Contenu du projet (6,44 Go, 24 912 fichiers)
|
||
|
||
| Classe | Nombre | Taille source | Constat |
|
||
|---|---:|---:|---|
|
||
| `SkeletalMesh` | 1 057 | **4,08 Go** | 100 % à **un seul LOD** ; **54 536 morph targets** au total |
|
||
| `AnimSequence` | 1 705 | 819 Mo | `New2/Anims2` 481, `New3/Anims` 418, `New2/Daily` 344, `Daz/Anims` 313 |
|
||
| `Texture2D` | 2 969 | 810 Mo | majoritairement ≤ 1024 ; 68 en 2K/4K (visages, corps) |
|
||
| `SoundWave` | 419 | 208 Mo | presque tous dans `New2` |
|
||
| `MaterialInstanceConstant` | 1 180 | 132 Mo | — |
|
||
| `StaticMesh` | 650 | 128 Mo | 637 à un seul LOD ; `fnt_decor14` 180 000 triangles |
|
||
| Blueprints, widgets | 100 | 116 Mo | `GI` 50 Mo, `Person` 20 Mo |
|
||
|
||
Répartition des maillages squelettiques :
|
||
|
||
| Dossier | Maillages | Taille | Morph targets |
|
||
|---|---:|---:|---:|
|
||
| `Heavy/Clothes4` (vêtements) | 940 | 2,43 Go | **45 936** (≈ 49 par vêtement) |
|
||
| `Heavy/Daz` (corps, cheveux) | 22 | 633 Mo | 5 257 (`bridget_gp` : 1 070, 132 Mo) |
|
||
| `Heavy/New2` | 44 | 543 Mo | 1 570 |
|
||
| `Heavy/New3` | 36 | 360 Mo | 1 675 |
|
||
| `Heavy/New4` | 15 | 113 Mo | 98 |
|
||
|
||
Les vêtements portent chacun une copie des morphs du corps pour suivre la morphologie : c'est le
|
||
premier poste de taille, et un coût par personnage à l'exécution (§4).
|
||
|
||
Textures :
|
||
- **835 textures non streamées** (`NeverStream`) et **794 sans mipmaps**, dont 541 icônes de
|
||
`New3/UI` (normal pour de l'interface).
|
||
- Le reste concerne des textures 3D (`Clothes4/Materials` 43, `New2/Furniture` 41, `Daz/Michael` 34,
|
||
`New4/Hairs` 17, `New2/Beasts` 13) : sans mipmaps, elles scintillent à distance et occupent toujours
|
||
leur pleine résolution en mémoire vidéo.
|
||
- Toutes les textures sont dans le groupe `World`, y compris l'interface ; seules 37 sont en
|
||
compression normal map.
|
||
|
||
## 3. Build livré (Shipping V1.1 : 3,17 Go)
|
||
|
||
| Poste | Taille | Constat |
|
||
|---|---:|---|
|
||
| `LifePlay/Content/Heavy` (cuit) | 2,50 Go | paquets **non compressés** (`bCompressed=False`, pas de pak) |
|
||
| `LifePlay-Win64-Shipping.pdb` | **207 Mo** | symboles de débogage livrés par erreur (inutiles au joueur) |
|
||
| `LifePlay-Win64-Shipping.exe` | 140 Mo | inclut tous les plugins moteur activés |
|
||
| `Engine/Plugins/NNE` (débruiteur IA, ONNX Runtime) | **119 Mo** | inutilisé par LifePlay ; activé par défaut par le moteur |
|
||
| `DirectML.dll`, `d3d12SDKLayers.dll` | 19 Mo | DirectML : dépendance de NNE ; SDK Layers : couche de débogage D3D12 |
|
||
| `Engine/Plugins/Interchange` | 12 Mo | import d'assets, inutile en jeu |
|
||
| `LifePlay/Content/Movies` | 79 Mo | vidéo d'intro |
|
||
| `LifePlay/Content/Modules` | 14 Mo | données texte (doivent rester en fichiers nus) |
|
||
|
||
Plugins moteur présents dans le build sans usage connu en jeu : `NNE`, `Interchange`, `Fab`, `Bridge`,
|
||
`SpeedTreeImporter`, `MovieRenderPipeline`, `Paper2D`, `USDCore`, `HairStrands`… Plusieurs viennent des
|
||
dépendances de `McpAutomationBridge` (outil d'éditeur, ERR-024) ou de l'activation par défaut du moteur.
|
||
|
||
## 4. Goulots probables (à confirmer par la mesure du §5)
|
||
|
||
| # | Hypothèse | Indice | Mesure qui tranchera |
|
||
|---|---|---|---|
|
||
| G1 | **Coût CPU des personnages** : jusqu'à des centaines de PNJ générés, chacun avec corps, cheveux et vêtements à morphs, animés à chaque image même hors champ | 339 personnages générés en 2 h (V1) ; aucun LOD, aucune optimisation de fréquence d'animation | temps du thread de jeu et d'animation (CSV) selon le nombre de PNJ visibles |
|
||
| G2 | **Morph targets** : 45 936 sur les vêtements, recalculés pour chaque personnage | `bridget_gp` 1 070 morphs | temps GPU/CPU de déformation, mémoire `Meshes` (LLM) |
|
||
| G3 | **Tick des Blueprints** `GI` et `Person` (interpréteur du DSL, IA) | 606 fonctions dans `GI` | temps du thread de jeu hors animation |
|
||
| G4 | **Mémoire vidéo** : textures non streamées et maillages sans LOD | §2 | LLM `Textures`, `Meshes` |
|
||
| G5 | **Temps de chargement** : 2,5 Go de paquets non compressés, chargés par chemin | build Shipping | durée du démarrage et des changements de lieu (journal) |
|
||
|
||
## 5. Mesure en jeu à réaliser
|
||
|
||
Dans `D:\Game\LifePlay_Build_5.5_L7cdj\Windows`, lancer **`LifePlay_profil_O0.bat`** (et non
|
||
`LifePlay.exe`) puis jouer environ **15 minutes** :
|
||
1. charger une partie avancée (nombreux contacts), rester 2 minutes sur la carte de la ville ;
|
||
2. un lieu intérieur peuplé, 2 minutes ;
|
||
3. un lieu extérieur peuplé (parc, plage), 2 minutes ;
|
||
4. une scène avec plusieurs personnages ;
|
||
5. quitter normalement.
|
||
|
||
Résultats : `Windows\LifePlay\Saved\Profiling\CSV\*.csv` (temps par image, thread de jeu, rendu, GPU,
|
||
par tranche de 9 000 images) et `Saved\Profiling\LLM\*.csv` (mémoire par catégorie). Ils serviront de
|
||
**référence** : chaque lot O1+ sera mesuré à l'identique, avant et après.
|
||
|
||
## 6. Leviers classés et lots proposés
|
||
|
||
| Lot | Levier | Gain attendu | Risque | Changement de comportement |
|
||
|---|---|---|---|---|
|
||
| **O1** | Build : désactiver les plugins moteur inutiles au jeu (`NNE`, `Interchange`, `Fab`, `Bridge`…), ne plus livrer le `.pdb` ni les couches de débogage D3D12 | **≈ 350 Mo** sur 3,17 Go, exécutable plus petit, démarrage plus court | faible (vérifier que `ControlRig`, `IKRig`, `HairStrands` ne sont pas utilisés par les assets) | aucun |
|
||
| **O2** | Paquets compressés (IoStore + Oodle) pour `Content`, `Modules` restant en fichiers nus | taille du jeu et temps de chargement (à mesurer : souvent −30 à −50 %) | moyen : la version de l'auteur était en fichiers nus ; vérifier que les mods n'ajoutent que du texte | aucun pour le joueur |
|
||
| **O3** | Fréquence d'animation des PNJ : `VisibilityBasedAnimTickOption` (pas d'animation hors champ), optimisation de fréquence (URO), voire Animation Budget Allocator. Appliqué par un sous-système C++, sans modifier `Person` | thread de jeu (G1), proportionnel au nombre de PNJ | faible | PNJ hors champ figés (invisible au joueur) |
|
||
| **O4** | Textures 3D sans mipmaps (≈ 130) : génération des mipmaps et streaming ; textures d'interface dans le groupe `UI` | mémoire vidéo, scintillement à distance | faible | rendu plus net à distance |
|
||
| **O5** | LOD des maillages squelettiques (corps, cheveux, vêtements) par la réduction intégrée d'UE5 | GPU et mémoire avec beaucoup de PNJ | moyen : les morphs doivent suivre sur les LOD ; contrôle visuel | légère simplification à distance |
|
||
| **O6** | Morph targets inutilisés des vêtements : retirer ceux qu'aucune donnée ni aucun Blueprint ne pilote | taille (2,4 Go de vêtements) et coût de déformation | élevé : il faut la liste exacte des morphs pilotés (`.lpcharacter`, `MorphTags`, `Person`) | aucun si la liste est exacte |
|
||
| **O7** | Organisation : déplacer les sauvegardes de développement de `Content/Saves` (14 125 fichiers, 239 parties, non versionnées) hors du projet ; plan de nommage des dossiers `Heavy/New`, `New2`… | lisibilité, éditeur plus rapide à indexer | les déplacements d'assets demandent des redirecteurs et un contrôle des 5 chemins `/Game/` des données | aucun |
|
||
| **O8** | Supprimer les 258 assets jamais nommés ni référencés (animations `Daz/Anims`, icônes `New3/UI`…) | **60 Mo seulement** (1 %) | moyen : un nom peut être construit par concaténation dans un Blueprint | aucun si l'analyse est juste |
|
||
|
||
Conclusion de l'audit statique : **supprimer des assets rapporte peu** (O8). Les vrais gains de taille
|
||
sont dans le **build** (O1, O2) et dans les **morphs des vêtements** (O6). Les gains de fluidité sont
|
||
dans **l'animation et la déformation des personnages** (O3, O5, O6), à confirmer par la mesure du §5.
|
||
|
||
Ordre recommandé : O1 (sans risque, gain immédiat), puis mesure §5, puis O3 et O4, puis O2, O5, O6 selon
|
||
les résultats ; O7 et O8 en dernier.
|
||
|
||
## 7. Fonctions UE5 utiles, déjà dans le moteur
|
||
|
||
| Fonction | Usage pour LifePlay |
|
||
|---|---|
|
||
| Unreal Insights, profileur CSV, LLM | mesure (§5) |
|
||
| Size Map, Asset Audit, Reference Viewer (éditeur) | vérifier les dépendances avant O1, O7, O8 |
|
||
| Réduction de maillage squelettique intégrée | LOD des personnages (O5) |
|
||
| Animation Budget Allocator (plugin moteur), URO, `VisibilityBasedAnimTickOption` | coût d'animation des PNJ (O3) |
|
||
| Significance Manager (plugin moteur) | prioriser les PNJ proches |
|
||
| IoStore, compression Oodle | taille et chargement (O2) |
|
||
| Texture streaming, groupes de LOD de texture | mémoire vidéo (O4) |
|
||
|
||
Nanite ne s'applique pas aux personnages en 5.5 dans un cadre stable (maillages squelettiques) ; les
|
||
maillages statiques de LifePlay sont légers, sauf `CentralLondon` (1,08 million de triangles) et
|
||
`fnt_decor14` : Nanite pourrait être évalué pour ces deux-là seulement.
|
||
|
||
## 8. Fab
|
||
|
||
Recherche publique « optimization » (2026-10-02, sans connexion) : la plupart des outils sont payants
|
||
(10 à 150 €) et génériques. Ils reprennent pour l'essentiel les fonctions du §7 : optimisation du tick,
|
||
Significance, outils de mesure, instanciation. Candidats à examiner, au choix de l'utilisateur :
|
||
- gratuits : *Ultimate Optimization Toolkit* (IchiQ), *Optimization Tools plugin* (Creative Elicya) ;
|
||
- adaptés aux nombreux PNJ : *Significance Optimizer* (MateoPlugins), *Flex Significance*
|
||
(GameRec Studios), *Open World NPC Optimization* (Sergio Cavalli) ;
|
||
- gestion des assets : *Project Optimization Toolkit* (Leartes Tools).
|
||
|
||
Règles :
|
||
- l'ajout d'un produit à la bibliothèque Fab se fait par l'utilisateur, avec son compte ;
|
||
- tout plugin tiers est évalué **dans une copie du projet**, jamais livré sans lot dédié ;
|
||
- il ne doit jamais devenir une dépendance du build sans accord.
|
||
|
||
Recommandation : commencer par les fonctions du moteur (§7), qui couvrent les besoins identifiés sans
|
||
dépendance nouvelle.
|
||
|
||
## 9. Résultats de la mesure en jeu (2026-10-02)
|
||
|
||
Build L7cdj (Development), `LifePlay_profil_O0.bat`, ≈ 12 minutes de jeu sur une machine AMD Ryzen 7 5800H avec carte graphique Radeon :
|
||
4 tranches complètes de 9 000 images (36 004 images). Données archivées dans
|
||
`D:\Game\LifePlay_Backup_5.5\O0_profil_20261002`, journal `Saved/Logs/portage/O0_profil_20261002.log`.
|
||
|
||
> Lancement : la capture CSV doit être démarrée par `-ExecCmds="csvprofile repeat=20, csvprofile frames=9000"`.
|
||
> L'option `-csvCaptureFrames` sur la ligne de commande démarre la capture avant l'initialisation du rendu, et le
|
||
> moteur s'arrête (`IsRayTracingAllowed() may only be called once RHI is initialized`).
|
||
|
||
### 9.1 Régime normal : aucun goulot
|
||
|
||
| Mesure (médiane par tranche) | Valeur |
|
||
|---|---|
|
||
| Temps d'image | **16,7 ms** : le jeu est plafonné à 60 images/s et tient ce plafond |
|
||
| Thread de jeu | 3,9 à 4,4 ms |
|
||
| Thread de rendu | 7,8 à 8,5 ms (dont ≈ 9 ms d'attente, `EventWait`) |
|
||
| GPU | 7,3 à 11,1 ms |
|
||
|
||
Il reste environ deux fois de marge sur chaque thread. Les hypothèses G1, G2 et G4 (§4) ne se vérifient
|
||
pas en régime normal sur cette machine.
|
||
|
||
### 9.2 Le vrai problème : les à-coups du thread de jeu
|
||
|
||
| Seuil | Images concernées (sur 36 004) |
|
||
|---|---:|
|
||
| > 33 ms | 262 |
|
||
| > 50 ms | 159 |
|
||
| > 100 ms | 112 |
|
||
| > 250 ms | 43 |
|
||
| > 1 s | 3 (chargement de partie : 31,5 s ; application des réglages : 5,4 s ; 1,7 s) |
|
||
|
||
- Les images longues durent **de 0,5 à 0,9 s**, à intervalles irréguliers, plusieurs fois par minute ; le
|
||
thread de jeu en est la cause, le rendu restant à 8 ms.
|
||
- Dans ces images, le temps va aux **minuteries Blueprint** (`TimerManager`, 38 s cumulées) et aux nœuds
|
||
`Delay` (`FlushLatentActions`, 9 s cumulées).
|
||
- Ce sont les traitements de `GI` déclenchés par minuterie : passage du temps, IA, recherche de scènes,
|
||
génération de personnages avec lecture de fichiers texte et chargement synchrone de maillages.
|
||
|
||
**Nouvelle priorité : G6, à-coups des traitements Blueprint sur minuterie.** Le CSV ne nomme pas les
|
||
fonctions Blueprint. L'étape suivante est une trace Unreal Insights avec les événements nommés
|
||
(`-trace=cpu,frame,loadtime -statnamedevents`), pour identifier les fonctions de `GI` en cause et les
|
||
chargements synchrones.
|
||
|
||
### 9.3 Mémoire (fin de session, LLM)
|
||
|
||
| Catégorie | Mo |
|
||
|---|---:|
|
||
| Total processus | 3 546 |
|
||
| Textures | 624 |
|
||
| **Physique (Chaos)** | **463**, dont 124 de structures d'accélération et 92 de maillages de collision (trimesh) |
|
||
| UObject | 226 |
|
||
| Cibles de rendu | 215 |
|
||
| Maillages | 75 |
|
||
|
||
La physique occupe presque autant que les textures. Hypothèse : collisions détaillées du maillage de la
|
||
ville (`CentralLondon`, 1,08 million de triangles) et des meubles. Ce poste devient le levier mémoire n° 1.
|
||
|
||
### 9.4 Lots révisés
|
||
|
||
| Ordre | Lot | Justification |
|
||
|---|---|---|
|
||
| 1 | **O1** build (plugins, `.pdb`) | inchangé : gain sûr de ≈ 350 Mo |
|
||
| 2 | **O9** (nouveau) : trace Insights des à-coups, puis correction ciblée (chargement asynchrone, étalement des traitements) | seul défaut ressenti en jeu |
|
||
| 3 | **O10** (nouveau) : collisions (ville et meubles) | 463 Mo de physique |
|
||
| 4 | O4 textures, O2 compression | mémoire vidéo, taille |
|
||
| — | O3, O5, O6 (animation, LOD, morphs) | **reportés** : aucun goulot mesuré en régime normal ; à remesurer sur une machine plus modeste |
|
||
|
||
## 10. Bibliothèque Fab de l'utilisateur (lue le 2026-10-02 sur fab.com)
|
||
|
||
La bibliothèque compte environ 3 000 produits, dont 302 outils et plugins. Produits utiles au chantier,
|
||
**déjà possédés** :
|
||
|
||
| Produit | Éditeur | Intérêt pour LifePlay |
|
||
|---|---|---|
|
||
| Ultimate Optimization Toolkit | IchiQ | mesure et débogage des performances (O9) |
|
||
| Optimization Tools plugin | Creative Elicya | outils d'optimisation de niveau |
|
||
| Asset Analytics | Mohsen Tabasi | analyse du poids et de l'usage des assets (O7, O8) |
|
||
| Dash — Advanced Asset Manager | Polygonflow | gestion et recherche d'assets (O7) |
|
||
| Assets Auto Organizer | Beta Projects | réorganisation des dossiers (O7) : **à n'utiliser qu'avec redirecteurs et vérification**, le jeu cherchant les assets par nom |
|
||
| Asset Naming Convention Keeper ; Asset Sanitizer | Tobosoksini Games ; MallHockE | conventions de nommage (O7) |
|
||
| Ultimate UE5 Project Organizer | Iron Cauldron | modèle d'arborescence (O7) |
|
||
| **MetaHuman Crowd Sample** | Epic Games | **exemple officiel de foule optimisée** (budget d'animation, LOD) : référence pour O3/O5 |
|
||
| AssetDump: Agents-readable assets | fallingsappy | export lisible des assets pour un agent : pourrait compléter `AuditAssets.py` |
|
||
|
||
Rien n'a été acheté, réclamé ni téléchargé. Chaque outil retenu sera évalué dans une copie du projet,
|
||
dans un lot dédié, avec l'accord de l'utilisateur.
|
||
|
||
## 11. Lot O1 : build allégé (2026-10-02)
|
||
|
||
| Modification | Fichier |
|
||
|---|---|
|
||
| 20 plugins moteur limités à l'éditeur (`"TargetAllowList": ["Editor"]`) : `NNEDenoiser`, `NNERuntimeORT`, `Interchange`, `InterchangeAssets`, `InterchangeTests`, `Fab`, `Bridge`, `MetaHumanSDK`, `SpeedTreeImporter`, `HairStrands`, `MovieRenderPipeline`, `Paper2D`, `USDCore`, `ChaosVD`, `LiveLink`, `ConcertMain`, `ConcertSyncClient`, `ConcertSyncCore`, `Takes`, `PythonScriptPlugin` | `LifePlay.uproject` |
|
||
| Leur contenu n'est plus cuit (`+DirectoriesToNeverCook`) : sans cela, la cuisson échoue sur les pipelines `Interchange` | `Config/DefaultGame.ini` |
|
||
| Build sans symboles de débogage (`-nodebuginfo`) | commande de build |
|
||
|
||
Justification : `Tools/AuditScriptDeps.py` (dépendances des 8 563 assets, lecture seule) montre que le contenu n'utilise
|
||
que 24 modules de code, dont aucun des plugins retirés. L'éditeur et l'outil MCP les gardent.
|
||
|
||
Piège : la cuisson incrémentale (`-iterate`) garde le contenu déjà cuit des plugins retirés ; il a été déplacé vers
|
||
`D:\Game\LifePlay_Backup_5.5\O1\_cuisson_retiree`.
|
||
|
||
| Build Shipping | Avant (V1.1) | Après (O1) |
|
||
|---|---:|---:|
|
||
| Taille | 3 246 Mo | **2 859 Mo (−387 Mo, −12 %)** |
|
||
| Fichiers | 24 249 | 23 901 |
|
||
| Paquets du jeu | 8 561 | 8 561 |
|
||
| `NNE`, `Interchange`, `.pdb`, `DirectML.dll` | présents | absents |
|
||
|
||
Build : `D:\Game\LifePlay_Build_5.5_O1`. Validation en jeu : **en attente**. |