Capítulo 8 — Formatos de exportación

DÓNDE

Barra de menú → Export → 3D Formats → Export PLY… (⌘E). Modo Simple: paso del asistente Export → tarjeta de formato „PLY". Tamaño: típicamente 100 % (valor de referencia). Compatible con: SuperSplat, PolyCam, todos los visores 3DGS.

TÉCNICO

PLY es el formato de almacenamiento canónico para 3D Gaussian Splatting. RadianceKit escribe un archivo binario little-endian con el diseño de propiedades 3DGS estandarizado: por cada Gaussiana una posición de tres componentes, tres normales siempre fijadas a cero, tres coeficientes SH DC (f_dc_0..2) para el color RGB base, seguidos de hasta 45 coeficientes SH adicionales (f_rest_0..44) en la disposición transpuesta channel-major definida por el artículo Kerbl-2023 (primero todos los coeficientes del canal R, luego todos los de G, luego todos los de B), seguido de la opacidad logit (valores brutos pre-sigmoide), tres escalas en espacio logarítmico y una rotación en cuaternión wxyz. El grado SH máximo exportado se recorta al mínimo entre el deseo del usuario y el grado realmente aprendido; el valor por defecto es 3 (45 coeficientes restantes). Antes de escribir se calcula el tamaño de la carga útil en enteros de 64 bits, para detectar el desbordamiento en nubes extremadamente grandes. El archivo se escribe de forma atómica, lo que en el caso de nubes grandes ocupa brevemente el doble de espacio en disco.

DÓNDE

Barra de menú → Export → 3D Formats → Export Compressed PLY…. Modo Simple: tarjeta de formato „Compressed PLY". Tamaño: aprox. 10–20 % respecto a PLY (compresión de 5 a 10 veces). Compatible con: SuperSplat, motor PlayCanvas, visores basados en web.

TÉCNICO

La variante de PlayCanvas del formato PLY con cuantización por chunks (bloques). Las Gaussianas se agrupan en chunks de 256. Por cada chunk se almacenan por separado los límites min/max para posición, escala y color en el encabezado; las Gaussianas individuales referencian sus valores en relación con estos límites y se comprimen a 32 bits cada una: posición y escala con empaquetado 11-10-11 bits, rotación como cuaternión „smallest-three" de 2-10-10-10 bits, color como RGBA 8-8-8-8. Los coeficientes SH superiores se cuantizan con solo 8 bits por componente (tres bytes por coeficiente y Gaussiana). El formato en sí sigue siendo PLY con encabezado ASCII y por tanto en principio validable con herramientas PLY, pero las propiedades de vértice están declaradas como campos uint. El grado SH por defecto es 0 (sin coeficientes restantes), para maximizar la compresión — se pueden elegir explícitamente grados SH superiores.

DÓNDE

Barra de menú → Export → 3D Formats → Export SPZ…. Modo Simple: tarjeta de formato „SPZ". Tamaño: aprox. 10 % respecto a PLY (90 % más pequeño). Compatible con: Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.

TÉCNICO

El formato SPZ v2 de Niantic. Las posiciones se empaquetan como punto fijo de 24 bits (lo que da aprox. 0,25 mm de resolución), las escalas como cuantización de 8 bits en espacio logarítmico, las rotaciones como smallest-three de 8 bits (en v2 solo se almacenan xyz, w se deriva en el decodificador a partir de la norma del cuaternión), las opacidades como valores de 8 bits sigmoidizados. El SH DC se almacena con una fórmula de empaquetado específica de SPZ (dc_raw * 0.15 * 255 + 0.5 * 255), las bandas SH superiores con 5 bits (banda 1) o 4 bits (banda 2-3) por coeficiente. El blob binario empaquetado completo se comprime a continuación con gzip estándar (RFC 1952), lo que da un formato contenedor gzipeado con bytes mágicos 1f 8b. RadianceKit invoca para ello el gzip del sistema, porque la API zlib integrada de Apple genera un encapsulado propietario de Apple que no sería compatible con los lectores SPZ de Spatial Fields ni MetalSplatter. El gzip del sistema puede seguir invocándose incluso dentro de la sandbox de macOS.

DÓNDE

Barra de menú → Export → 3D Formats → Export SOG…. Modo Simple: tarjeta de formato „SOG". Tamaño: aprox. 5–6 % respecto a PLY (compresión de 15 a 20 veces — la opción más pequeña). Compatible con: motor PlayCanvas, editor SuperSplat.

TÉCNICO

„Spatially Ordered Gaussians" — un formato de PlayCanvas que almacena la nube lista para GPU en varias imágenes WebP sin pérdida. Primero se ordenan espacialmente todas las Gaussianas mediante código de Morton 3D (orden Z de 30 bits, 10 bits por eje), lo que otorga a las imágenes una posterior localidad de caché en el renderizador. Luego las posiciones se cuantizan a valores de 16 bits con transformación logarítmica simétrica (para mejor rango dinámico) y se dividen en dos imágenes RGBA (means_l.webp para los 8 bits inferiores, means_u.webp para los superiores). Las rotaciones se codifican como smallest-three con 3×8 bits más 2 bits de modo en una imagen RGBA (el modo termina en el alfa como 252 + largest). Las escalas y el SH DC se cuantizan cada uno con un libro de códigos de 256 entradas (distribuido según percentiles sobre todos los valores), los índices terminan en scales.webp y sh0.webp. Las cinco imágenes más un meta.json con libros de códigos y límites se empaquetan en un archivo ZIP (codificador propio, porque la sandbox bloquea el zip del sistema) y se guardan con la extensión .sog.

Atención sandbox: SOG es la única opción de formato que requiere un binario externo. La etapa de codificación WebP invoca cwebp desde /usr/local/bin/cwebp o /opt/homebrew/bin/cwebp. Si no se encuentra ningún binario cwebp, el código recurre a la codificación PNG en bruto — pero atención: el fallback a PNG no funciona en SuperSplat. En la versión de App Store se evalúa la disponibilidad según la variante de compilación; en la variante de desarrollador cwebp debe estar instalado vía Homebrew (brew install webp).

DÓNDE

Barra de menú → Export → 3D Formats → Export glTF…. Modo Simple: tarjeta de formato „glTF". Tamaño: comparable con PLY. Compatible con: visores glTF con la extensión KHR_gaussian_splatting (borrador de estándar de Khronos).

TÉCNICO

Escribe un archivo binario .glb autocontenido (sin archivo bin anexo separado) conforme a la especificación de la extensión KHR_gaussian_splatting. Las posiciones se almacenan como datos de vértice POSITION regulares de glTF (float3), todos los demás atributos (rotación como float4, escala como float3, opacidad como float, coeficientes SH como float3 × shCoeffCount) se ubican en atributos de vértice adicionales y se referencian mediante la extensión. Importante: glTF usa un sistema de coordenadas Y-arriba de mano derecha, COLMAP/3DGS trabaja con Y-abajo/Z-adelante. El exportador aplica por ello una rotación de 180 grados alrededor del eje X — las posiciones se reescriben como (x, -y, -z), los cuaterniones se ajustan a (w, x, -y, -z). Esto da como resultado una representación geométricamente correcta, con la orientación adecuada (no invertida) en los visores glTF. Los bloques JSON y binarios se rellenan hasta la alineación de 4 bytes, como exige el estándar GLB.

DÓNDE

Barra de menú → Export → 3D Formats → Export .splat…. Modo Simple: tarjeta de formato „.splat". Tamaño: exactamente 32 bytes por Gaussiana. Compatible con: gsplat.js, visores basados en web (referencia antimatter15), la mayoría de las demos 3DGS en navegador.

TÉCNICO

El formato .splat de antimatter15 — 32 bytes por Gaussiana, sin encabezado, sin indirección. Diseño por entrada: 3 × float32 posición (coordenadas mundiales), 3 × float32 escala (transformada con exp a partir del espacio logarítmico del buffer interno), 4 × uint8 color RGBA (coeficiente SH DC escalado con SH_C0 = 0.282... y recortado a [0,255]), 4 × uint8 cuaternión (w,x,y,z, normalizado y codificado en el rango de bytes como 128 + 128*q). Solo se almacena el SH DC — las bandas SH superiores se descartan. Esto hace que el formato sea extremadamente compacto, pero cuesta los cambios de color dependientes de la vista, que ocurren en reflejos o brillos especulares. El orden de escritura es exactamente el orden de índice de la nube (sin ordenación espacial), los visores web como gsplat.js renderizan partiendo de eso.

DÓNDE

Barra de menú → Export → Media → Export Web Viewer…. Modo Simple: tarjeta de formato „Web Viewer". Tamaño: datos splat codificados en base64 (≈ 4/3 de sobrecarga) + aprox. 5 KB de shell HTML/JS. Compatible con: cualquier navegador moderno con WebGL2 (todos los escritorios, iOS 15+, Android 5+).

TÉCNICO

Empaqueta la nube gaussiana junto con un renderizador WebGL2 escrito completamente en línea en un único archivo .html. No hay dependencias de CDN, ni WASM, ni un segundo archivo. La nube se codifica internamente primero como binario .splat (misma lógica de 32 bytes que E6), luego se incrusta en base64, luego se decodifica en el navegador con atob. El renderizador integrado hace su propia ordenación WebGL2, control de órbita con el ratón y ordenación por CPU por fotograma; todo el código JS (shaders, matemáticas, bucle) es visible en el HTML de salida. La convención de ejes en el límite entre almacenamiento y renderizador es exactamente la misma que en E5: posición (x, -y, -z), cuaternión (w, x, -y, -z). Opcionalmente se puede mostrar una superposición de marca (interruptor del nivel gratuito). Como todo está en línea, el archivo funciona también directamente desde el protocolo file:// — no se necesita un servidor web local para probarlo.

DÓNDE

Barra de menú → Viewport → Record Turntable Video O Barra de menú → Export → Media → Export Orbit Video…. Modo Simple: tarjeta de formato „Orbit Video" con control deslizante de duración 3–30 s. Tamaño: depende de la duración, resolución, tasa de bits. Compatible con: todas las plataformas (H.264 y HEVC son estándar de Apple).

TÉCNICO

Renderiza la nube gaussiana a lo largo de un recorrido de cámara en órbita paramétrico y codifica cada fotograma mediante AVAssetWriter en un archivo MP4 o MOV. La configuración de la órbita controla velocidad de giro (número de vueltas), distancia, elevación, FOV, duración y factor de ease-in/out. La exportación de Orbit Video se ejecuta en la PROPIA etapa de renderizado de RadianceKit con evaluación SH completa — píxel por píxel idéntica al viewport dentro de la app (WYSIWYG). Por cada fotograma se multiplica la matriz de adaptación al mundo (calculada por el renderizador, para rotar las coordenadas internas al mundo de órbita Y-arriba) con la cámara, aplicando a continuación una reflexión de conversión de cámara (órbita Y-arriba → COLMAP Y-abajo). El destino de renderizado fuera de pantalla se transfiere vía IOSurface a un CVPixelBuffer para el codificador. El codificador admite H.264 y HEVC, tasa de bits y resolución configurables desde 480p hasta 8K. Antes del primer fotograma el renderizador espera 200 ms, para que la ordenación inicial de splats esté completa. Esta exportación depende de la GPU — con 8K y millones de Gaussianas el tiempo de renderizado por fotograma es de varios segundos, por lo que son posibles tiempos totales de renderizado de 10 a 30 minutos para 6 s de video.

DÓNDE

Barra de menú → Export → Photogrammetry → Export SfM (transforms.json)…. Tamaño: típicamente 1–10 KB (solo poses + intrínsecos, sin imágenes, sin Gaussianas). Compatible con: nerfstudio, Brush, gsplat, OpenSplat, Meshroom, todos los entrenadores 3DGS feed-forward modernos.

TÉCNICO

Escribe el formato transforms.json de nerfstudio con una lista de poses de cámara más intrínsecos compartidos. Por cada cámara se invierte la matriz de vista (internamente en RadianceKit: mundo-a-cámara en convención COLMAP), y a continuación se reflejan los vectores base Y y Z locales de la cámara, para convertir a la convención de nerfstudio (estilo OpenGL, la cámara mira a lo largo de -Z, +Y está arriba). La matriz final 4×4 termina como un array anidado row-major de doubles en el campo transform_matrix de cada fotograma. Los intrínsecos se almacenan en el nivel superior (distancia focal x/y, punto principal x/y, ancho/alto de imagen, camera_model = "OPENCV", más los coeficientes de distorsión k1, k2, p1, p2) — excepto cuando el exportador detecta varios conjuntos de intrínsecos diferentes, en cuyo caso se escriben por fotograma. Las rutas de las imágenes se escriben como images/<filename> relativas al archivo JSON; el usuario debe crear una carpeta hermana images/ con las fotos de entrenamiento.

DÓNDE

Barra de menú → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Tamaño: tres archivos binarios juntos típicamente 4–8 MB — points3D.bin domina (una línea por punto 3D de la nube dispersa), images.bin y cameras.bin están cada uno claramente por debajo de 100 KB. Compatible con: el propio COLMAP, Nerfstudio, Postshot, Meshroom, todas las herramientas que esperan un directorio sparse/ de COLMAP.

TÉCNICO

Escribe el diseño estándar sparse/0/ de COLMAP con tres archivos binarios: cameras.bin, images.bin, points3D.bin. La referencia de formato es la documentación oficial de COLMAP. cameras.bin contiene la lista deduplicada de intrínsecos (las cámaras con intrínsecos y tamaño de imagen idénticos se fusionan en una única entrada); el modelo de cámara usado es OPENCV (modelo 4), con fx/fy/cx/cy más los cuatro coeficientes de distorsión k1/k2/p1/p2. images.bin lista por cada imagen la pose como cuaternión wxyz más traslación, seguida del ID de cámara y el nombre de archivo; no se almacenan correspondencias 2D-3D. points3D.bin contiene la nube de puntos SfM con posición, color (RGB 0-255) y valores por defecto para la reproyección y la longitud de track. Todo se escribe en little-endian. La reimportación en RadianceKit funciona a través del menú Archivo → „Import COLMAP/Metashape Workspace…" (véase Q3 en el capítulo del backend SfM).