CDLOD : Exploration approfondie et stabilisation avant passage à CBT

[bpodwinski]

Contexte

World42 utilise actuellement un CDLOD/quadtree côté CPU avec génération de terrain via Web Workers.
Avant d’envisager une refonte majeure vers une approche GPU-driven (CBT), il est nécessaire de pousser l’implémentation actuelle au maximum afin d’identifier précisément ses limites réelles (CPU, latence, qualité visuelle, mémoire) et de disposer d’une base de comparaison solide.

Objectif

Améliorer et instrumenter le CDLOD existant pour :

• maximiser la stabilité et la qualité visuelle
• réduire la charge CPU / GC et la latence
• comprendre clairement ce que le CDLOD peut (ou ne peut pas) résoudre
• disposer d’une base mesurée avant une transition vers CBT

---

Structure cible (organisation du code)

Objectif : séparer décision LOD, planification, génération, cache, et debug

Proposition de modules (à adapter à l’arborescence actuelle) :

• systems/lod/

  • LodController.ts : point d’entrée appelé chaque frame, orchestre les étapes (metrics → scheduling → apply)
  • LodMetrics.ts : calcule SSE, hystérésis, règles anti-cracks, seuils
  • LodScheduler.ts : budgets par frame, priorités, annulation jobs obsolètes
  • LodCache.ts : cache LRU + pooling (meshes/buffers/chunks), politique d’éviction
  • LodDebug.ts : overlay, compteurs, timings, journaux d’événements
  • workers/
    • LodWorker.ts : wrapper worker, envoi/réception, lifecycle
    • worker-protocol.ts : schémas messages (BUILD/APPLY, transferrables, generationId)

• game_objects/planet/

  • quadtree/ : structure de nœuds, adressage (face/level/x/y), voisinage
  • chunks/ : représentation runtime (mesh, bounds, state machine: Idle/Requested/Ready/Active)
  • terrain/ : génération (noise, sampling), matériaux, shaders, skirts/geomorph

---

Axes de travail

1) Métriques LOD et stabilité

• Remplacer le critère distance par une métrique Screen-Space Error (SSE)
• Ajouter une hystérésis split/merge pour éviter les oscillations et le flapping
• Mettre en place une stratégie anti-cracks (règle 2:1 et/ou skirts)

2) Transitions visuelles

• Réduire/supprimer le popping via geomorph ou transition progressive
• Éviter les “trous” pendant les transitions en rendant le split non bloquant (ne pas attendre tous les enfants)

3) Orchestration et budget

• Implémenter un vrai LodScheduler avec budget par frame (apply/build)
• Prioriser les tâches (dans le champ, proche caméra, importance écran)

4) Optimisations Workers

• Passer aux transferrables (TypedArrays + transfert d’ArrayBuffer)
• Ajouter l’annulation des jobs obsolètes (ex: generationId)
• Permettre un split progressif (enfants chargés indépendamment)

5) Cache et mémoire

• Ajouter un cache LRU + pooling des chunks/meshes pour limiter le churn
• Définir une politique d’éviction (budget mémoire / nb max chunks)

6) Culling spécifique planète

• Culling horizon (occlusion par la sphère) robuste et conservatif
• Culling frustum basé sur bounds fiables (fallback conservatif si non prêt)

7) Instrumentation & Debug

• Overlay/debug : chunks actifs, profondeur moyenne, splits/merges
• Stats workers : files (build/apply), jobs en vol, annulations
• Timings : build (worker), apply (main), GC/pics frame
• Mode “replay” caméra (chemin déterministe) pour comparer les itérations

---

Portée

• CDLOD CPU conservé (pas de refonte GPU complète à ce stade)
• Travail d’optimisation, stabilisation et mesure (pré-CBT)

Résultat attendu

• CDLOD plus robuste, plus stable et objectivement mesuré
• Identification claire des goulots d’étranglement (CPU/GC/latence/mémoire/visuel)
• Décision éclairée :
  • CDLOD optimisé suffisant,
  • ou nécessité réelle d’un passage à CBT GPU-driven