Chapitre 8 — Formats d'export

OÙ

Barre de menu → Export → 3D Formats → Export PLY… (⌘E). Mode débutant : étape Export → carte de format « PLY ». Taille : typiquement 100 % (valeur de référence). Compatible avec : SuperSplat, PolyCam, toutes les visionneuses 3DGS.

TECHNIQUE

PLY est le format canonique de stockage pour le 3D Gaussian Splatting. RadianceKit écrit un fichier binaire little-endian avec la disposition standard de propriétés 3DGS : par gaussienne, position à trois composantes, trois normales toujours à zéro, trois coefficients DC-SH (f_dc_0..2) pour la couleur RGB de base, puis jusqu'à 45 coefficients SH supplémentaires (f_rest_0..44) dans la disposition channel-major transposée définie par le papier Kerbl 2023 (d'abord tous les coefficients du canal R, puis tous ceux du G, puis tous ceux du B), suivis de l'opacité logit (valeurs pré-sigmoïde brutes), trois échelles en log-space et une rotation quaternion wxyz. Le degré SH maximal exporté est plafonné au minimum entre le souhait utilisateur et le degré réellement appris ; le défaut est 3 (45 coefficients « rest »). Avant l'écriture, la taille du payload est calculée en entier 64 bits pour intercepter les dépassements sur les nuages très volumineux. Le fichier est écrit atomiquement, ce qui occupe brièvement le double de l'espace disque pour les grands nuages.

OÙ

Barre de menu → Export → 3D Formats → Export Compressed PLY…. Mode débutant : carte de format « Compressed PLY ». Taille : environ 10–20 % par rapport au PLY (compression 5× à 10×). Compatible avec : SuperSplat, moteur PlayCanvas, visionneuses web.

TECHNIQUE

La variante PlayCanvas du format PLY avec quantification par chunks. Les gaussiennes sont regroupées par chunks de 256. Par chunk, des bornes min/max pour position, échelle et couleur sont stockées séparément dans l'en-tête ; les gaussiennes individuelles référencent leurs valeurs relativement à ces bornes et sont compressées sur 32 bits chacune : position et échelle en packing 11-10-11 bits, rotation en quaternion « smallest-three » 2-10-10-10 bits, couleur en 8-8-8-8 RGBA. Les coefficients SH plus élevés sont quantifiés sur 8 bits seulement par composante (shCoeffCount * 3 uchar par gaussienne). Le format reste un PLY à en-tête ASCII et est donc fondamentalement validable avec les outils PLY, mais les propriétés vertex sont déclarées comme champs uint. Le degré SH est par défaut à 0 (aucun coefficient « rest ») pour maximiser la compression — des degrés SH plus élevés peuvent être choisis explicitement.

OÙ

Barre de menu → Export → 3D Formats → Export SPZ…. Mode débutant : carte de format « SPZ ». Taille : environ 10 % par rapport au PLY (90 % plus petit). Compatible avec : Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.

TECHNIQUE

Le format SPZ-v2 de Niantic. Les positions sont empaquetées en fixed-point 24 bits (ce qui donne environ 0,25 mm de résolution), les échelles en quantification 8 bits en log-space, les rotations en smallest-three 8 bits (en v2 seuls xyz sont stockés, w est dérivé par le décodeur depuis la norme du quaternion), les opacités en valeurs 8 bits sigmoïdes. DC-SH est stocké avec une formule de packing spécifique SPZ (dc_raw * 0.15 * 255 + 0.5 * 255), les bandes SH plus élevées sur 5 bits (bande 1) ou 4 bits (bandes 2-3) par coefficient. Tout le blob binaire empaqueté est ensuite compressé avec gzip standard (RFC 1952), ce qui donne un conteneur gzip avec les magic bytes 1f 8b. RadianceKit appelle pour cela le gzip système, parce que l'API zlib intégrée d'Apple produit un framing propriétaire Apple qui ne serait pas compatible avec les lecteurs SPZ de Spatial Fields ou MetalSplatter. Le gzip système reste appelable même à l'intérieur du sandbox macOS.

OÙ

Barre de menu → Export → 3D Formats → Export SOG…. Mode débutant : carte de format « SOG ». Taille : environ 5–6 % par rapport au PLY (compression 15× à 20× — l'option la plus petite). Compatible avec : moteur PlayCanvas, éditeur SuperSplat.

TECHNIQUE

« Spatially Ordered Gaussians » — un format PlayCanvas qui stocke le nuage GPU-ready dans plusieurs images WebP sans perte. Toutes les gaussiennes sont d'abord triées spatialement par code Morton 3D (Z-order 30 bits, 10 bits par axe), ce qui procure aux images une cache locality ultérieure dans le renderer. Puis les positions sont quantifiées en valeurs 16 bits avec transformation log symétrique (pour une meilleure dynamique) et réparties en deux images RGBA (means_l.webp pour les 8 bits inférieurs, means_u.webp pour les supérieurs). Les rotations sont encodées en smallest-three avec 3×8 bits plus un mode 2 bits dans une image RGBA (le mode atterrit en alpha sous la forme 252 + largest). Les échelles et le DC-SH sont quantifiés via un codebook à 256 entrées chacun (réparti par percentiles sur toutes les valeurs), les indices atterrissent dans scales.webp et sh0.webp. Les cinq images plus un meta.json avec codebooks et bornes sont empaquetés dans un fichier ZIP (encodeur custom, parce que le sandbox bloque le zip système) et enregistrés avec l'extension .sog.

Attention sandbox : SOG est la seule option de format qui requiert un binaire externe. L'étape d'encodage WebP appelle cwebp depuis /usr/local/bin/cwebp ou /opt/homebrew/bin/cwebp. Si aucun binaire cwebp n'est trouvé, le code retombe sur un encodage PNG brut — mais : le fallback PNG ne fonctionne pas dans SuperSplat. Dans la version App Store, évaluez la disponibilité selon la variante de build ; dans la variante développeur, cwebp doit être installé via Homebrew (brew install webp).

OÙ

Barre de menu → Export → 3D Formats → Export glTF…. Mode débutant : carte de format « glTF ». Taille : comparable au PLY. Compatible avec : visionneuses glTF avec extension KHR_gaussian_splatting (draft standard Khronos).

TECHNIQUE

Écrit un fichier binaire .glb autoporteur (pas de fichier bin séparé) conformément à la spécification d'extension KHR_gaussian_splatting. Les positions sont stockées comme données vertex POSITION glTF classiques (float3), tous les autres attributs (rotation en float4, échelle en float3, opacité en float, coefficients SH en float3 × shCoeffCount) résident dans des attributs vertex supplémentaires et sont référencés via l'extension. Important : glTF utilise un système de coordonnées droite Y-up, COLMAP/3DGS travaille en Y-down/Z-forward. L'exporteur applique donc une rotation de 180° autour de l'axe X — les positions sont réécrites en (x, -y, -z), les quaternions ajustés en (w, x, -y, -z). Cela donne une représentation géométriquement correcte, droite (non en miroir) dans les visionneuses glTF. Les chunks JSON et binaires sont paddés sur 4 octets comme l'exige le standard GLB.

OÙ

Barre de menu → Export → 3D Formats → Export .splat…. Mode débutant : carte de format « .splat ». Taille : exactement 32 octets par gaussienne. Compatible avec : gsplat.js, visionneuses web (référence antimatter15), la plupart des démos 3DGS dans le navigateur.

TECHNIQUE

Le format .splat antimatter15 — 32 octets par gaussienne, pas d'en-tête, pas d'indirection. Disposition par entrée : 3 × float32 position (coordonnées monde), 3 × float32 échelle (transformée exp depuis le log-space du buffer interne), 4 × uint8 couleur RGBA (coefficient DC-SH mis à l'échelle avec SH_C0 = 0.282... et clampé sur [0,255]), 4 × uint8 quaternion (w,x,y,z, normalisé et encodé dans la plage octet comme 128 + 128*q). Seul le DC-SH est stocké — les bandes SH plus élevées sont rejetées. Cela rend le format extrêmement compact mais coûte les variations de couleur dépendantes de la vue qui apparaissent sur les reflets ou les hautes lumières spéculaires. L'ordre d'écriture est exactement l'ordre d'index du nuage (aucun tri spatial), les visionneuses web comme gsplat.js rendent à partir de cela.

OÙ

Barre de menu → Export → Media → Export Web Viewer…. Mode débutant : carte de format « Web Viewer ». Taille : données splat encodées base64 (≈ 4/3 d'overhead) + environ 5 KB de shell HTML/JS. Compatible avec : tout navigateur moderne avec WebGL2 (tous les desktops, iOS 15+, Android 5+).

TECHNIQUE

Empaquette le nuage de gaussiennes avec un renderer WebGL2 écrit entièrement en inline dans un unique fichier .html. Aucune dépendance CDN, pas de WASM, pas de second fichier. Le nuage est d'abord encodé en interne en binaire .splat (même logique 32 octets qu'en E6), puis embarqué en base64, puis décodé par atob dans le navigateur. Le renderer intégré effectue son propre tri WebGL2, le contrôle d'orbite à la souris et un tri CPU par frame ; tout le code JS (shaders, mathématiques, boucle) est visible dans le HTML produit. La convention d'axes à la frontière stockage-renderer est exactement la même qu'en E5 : position (x, -y, -z), quaternion (w, x, -y, -z). Un overlay de branding peut être affiché en option (commutateur du free-tier). Comme tout est inline, le fichier fonctionne aussi directement depuis le protocole file:// — aucun serveur web local nécessaire pour tester.

OÙ

Barre de menu → Viewport → Record Turntable Video OU barre de menu → Export → Media → Export Orbit Video…. Mode débutant : carte de format « Orbit Video » avec slider de durée 3–30 s. Taille : dépend de durée, résolution, débit. Compatible avec : toutes les plateformes (H.264 et HEVC sont les standards Apple).

TECHNIQUE

Rend le nuage de gaussiennes le long d'une orbite caméra paramétrique et encode chaque image via AVAssetWriter en un fichier MP4 ou MOV. La configuration de l'orbite contrôle la vitesse de rotation (tours), distance, élévation, FOV, durée et facteur ease-in/out. Par image, la matrice d'ajustement monde (calculée par le renderer pour faire tourner les coordonnées internes vers le monde orbital Y-up) est multipliée par la caméra, puis le miroir Y spécifique à MetalSplatter est appliqué. La cible de rendu offscreen est passée via IOSurface en CVPixelBuffer pour l'encodeur. L'encodeur prend en charge H.264 et HEVC, un débit configurable et des résolutions de 480p à 8K. Avant la première image, le renderer attend 200 ms pour que le tri initial des splats soit terminé. Cet export est GPU-bound — en 8K avec des millions de gaussiennes, le temps de rendu par image atteint plusieurs secondes, soit des durées totales de rendu de 10–30 minutes pour 6 s de vidéo.

OÙ

Barre de menu → Export → Photogrammetry → Export SfM (transforms.json)…. Taille : typiquement 1–10 KB (uniquement poses + intrinsics, pas d'images, pas de gaussiennes). Compatible avec : nerfstudio, Brush, gsplat, OpenSplat, Meshroom, tous les entraîneurs 3DGS feed-forward modernes.

TECHNIQUE

Écrit le format transforms.json de nerfstudio avec une liste de poses caméra plus des intrinsics partagés. Par caméra, la matrice de vue (en interne RadianceKit : World-to-Camera en convention COLMAP) est inversée, puis les vecteurs de base Y et Z caméra-locaux sont retournés pour convertir vers la convention nerfstudio (style OpenGL, caméra regardant le long de -Z, +Y vers le haut). La matrice 4×4 finale finit en tableau imbriqué row-major de doubles dans le champ transform_matrix de chaque frame. Les intrinsics sont stockés au top-level (focale x/y, point principal x/y, largeur/hauteur d'image, camera_model = "OPENCV", plus les coefficients de distorsion k1, k2, p1, p2) — sauf si l'exporteur détecte plusieurs ensembles d'intrinsics distincts, auquel cas ils sont écrits par frame. Les chemins d'images sont écrits comme images/<filename> relatifs au fichier JSON ; l'utilisateur doit créer un dossier images/ voisin avec les photos d'entraînement.

OÙ

Barre de menu → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Taille : les trois fichiers binaires ensemble typiquement 4–8 Mo — points3D.bin domine (une ligne par point 3D du nuage sparse), images.bin et cameras.bin chacun nettement sous 100 KB. Compatible avec : COLMAP lui-même, Nerfstudio, Postshot, Meshroom, tous les outils qui attendent un dossier COLMAP sparse/.

TECHNIQUE

Écrit la disposition standard COLMAP sparse/0/ avec trois fichiers binaires : cameras.bin, images.bin, points3D.bin. La référence de format est la documentation officielle COLMAP. cameras.bin contient la liste dédupliquée des intrinsics (les caméras avec mêmes intrinsics et taille d'image sont fusionnées en une seule entrée) ; le modèle caméra utilisé est OPENCV (modèle 4), avec fx/fy/cx/cy et les quatre coefficients de distorsion k1/k2/p1/p2. images.bin liste par image la pose comme quaternion wxyz plus translation, suivis de l'ID caméra et du nom de fichier ; aucune correspondance 2D-3D n'est stockée. points3D.bin contient le nuage SfM avec position, couleur (RGB 0-255) et valeurs par défaut pour la reprojection et la longueur de track. Tout est écrit en little-endian. Le réimport dans RadianceKit passe par le menu File → « Import COLMAP/Metashape Workspace… » (voir Q3 dans le chapitre des backends SfM).