Objectif

Voir comment des tuiles 3d triangulées peuvent être chargées dans hlg-vecmilmaps. Quelles problématiques peuvent se poser.

Intégration de la couche

L'intégration se fait facilement. Néanmoins les tuiles 3d possèdent des informations d'élévation, donc le relief doit être activé pour ne pas avoir de décalage.

Pour le moment la couche custom apparait au dessus de toutes les autres, mais le problème pourra rapidement être corrigé. Les geoCollections / open infra map pourront être amenées à apparaitre par dessus.

Par contre, pas de séparation possible entre le sol de la tuile 3d et les batiments / arbres. Exemple une ligne à haute tension open infra map ne peut pas être au dessus de la route mais masquée par un gros batiment. Si on la veut, elle apparaitra forcément devant le batiment (avec une erreur de perspective).

Où trouver la donnée ?

Ça me semble le plus gros problème. Actuellement la source majeure identifiée est Google via API. Nécessite une clé (billing account), quels sont les droits ?

documentation : Google 3d tiles

Le standard 3D Tiles est ouvert

C’est un standard défini par l’Open Geospatial Consortium (OGC) : Spec

Nuage de point Lidar vs Surface maillée

Peut-on obtenir des tuiles 3d triangulées à partir des données lidar de l'ign ? l'outil py3dtiles permet de convertir la donnée lidar en tuiles 3d au format Point Cloud qui est simplement une représentation de nuage de points, pas une surface maillée, encore moins texturée.

Pour obtenir des polygones triangulés à partir de données lidar, il faudrait un pipeline supplémentaire :

Générer un MNT/MNS (raster ou TIN) depuis le nuage de points, outils comme PDAL
Trianguler la surface (Delaunay)
Exporter en 3D Tiles format .b3dm (Batched 3D Model) ou .glb

Pour les textures, il faudrait en plus une orthophoto calée pour projeter la texture sur le maillage, ça relève de la photogrammétrie (Meshroom, OpenDroneMap, etc.).

Architecture de la chaîne de chargement

Data set

tileset.json (3D Tiles)
    └── référence des tuiles (.b3dm / .i3dm / .glb)
            └── contenu GLTF/GLB
                    ├── géométrie compressée DRACO  → DRACOLoader
                    └── textures compressées KTX2   → KTX2Loader

1. GLTFLoader — Le loader principal

GLTF (GL Transmission Format) est le format de conteneur utilisé par les tuiles 3D Tiles (dans les fichiers .glb ou encapsulé dans .b3dm/.i3dm).

tileset.json → tile.b3dm
                  ├── header B3DM (Batched 3D Model)
                  └── payload glTF binaire (= .glb)
                          ├── JSON descriptor (mesh, matériaux, scène)
                          ├── buffer binaire (géométrie, animations)
                          └── textures (images embarquées)

C'est le loader racine — les deux autres ne sont que des plugins qu'on lui greffe.

tiles.manager.addHandler(/\.(gltf|glb)$/g, gltfLoader); // ligne 151

2. DRACOLoader — Compression de géométrie

Draco (Google) est un codec de compression pour les maillages 3D (vertices, normales, indices…).

Sans Draco	Avec Draco
Float32Array brut	Quantification + entropie
100% taille	~5–15% taille

Le décodeur Draco est en WebAssembly → c'est pour ça qu'on charge un chemin externe :

dracoLoader.setDecoderPath("https://unpkg.com/three@0.183.0/examples/jsm/libs/draco/");
//                          ↑ charge draco_decoder.wasm à la demande

Le GLTFLoader vérifie si un mesh GLTF a l'extension KHR_draco_mesh_compression → si oui, délègue au DRACOLoader.

Est-ce nécessaire ici ? Seulement si les tuiles du tileset AGI HQ utilisent cette extension. Si le tileset n'a pas de géométrie Draco-compressée, ce loader ne sera jamais invoqué mais n'a aucun coût s'il reste inactif.

3. KTX2Loader — Compression de textures GPU

KTX2 (Khronos Texture) est un format de textures compressées côté GPU (contrairement à JPG/PNG qui décompressent en RAM).

JPG/PNG → décodé CPU → RAM → uploadé décompressé VRAM
KTX2    → transcode WASM → format natif GPU (BC7/ASTC/ETC2...) → VRAM compressée

Format GPU	GPU cible
BC7 / DXT	Desktop (NVIDIA, AMD, Intel)
ASTC	Mobile ARM (Mali, Apple GPU)
ETC2	Android

Le transcodeur Basis (aussi en WASM) détecte le GPU et choisit le bon format natif :

ktx2Loader.detectSupport(this.renderer); // interroge les extensions WebGL dispo
ktx2Loader.setTranscoderPath("https://unpkg.com/three@0.183.0/examples/jsm/libs/basis/");
//                            ↑ charge basis_transcoder.wasm

Le GLTFLoader délègue au KTX2Loader si une texture utilise l'extension KHR_texture_basisu.

Synthèse : a-t-on besoin des 3 ?

Loader	Rôle	Nécessaire si…
GLTFLoader	Parse les fichiers .glb/.gltf des tuiles	Toujours (c'est le format de base 3D Tiles)
DRACOLoader	Décode les géométries compressées	Les tuiles ont `KHR_draco_mesh_compression`
KTX2Loader	Décode les textures GPU	Les tuiles ont `KHR_texture_basisu`

En pratique pour ce tileset AGI HQ publié par NASA/AGI, il est probable que les deux extensions soient présentes (les tilesets "de démonstration" de haute qualité utilisent généralement la compression complète). Mais on ne peut en être sûr qu'en inspectant un .b3dm du tileset.

Point important : les deux WASM (Draco + Basis) ne sont chargés qu'à la demande — ils n'impactent pas le bundle initial, seulement si une tuile les requiert réellement.