Capítulo 8 — Formatos de Exportação

ONDE

Barra de menus → Export → 3D Formats → Export PLY… (⌘E). Modo Simple: etapa do assistente Export → cartão de formato „PLY". Tamanho: tipicamente 100 % (valor de referência). Compatível com: SuperSplat, PolyCam, todos os visualizadores 3DGS.

TÉCNICO

PLY é o formato de armazenamento canônico para 3D Gaussian Splatting. O RadianceKit grava um arquivo binário little-endian com o layout de propriedades 3DGS padronizado: por Gaussiana, uma posição de três componentes, três normais sempre definidas como zero, três coeficientes SH DC (f_dc_0..2) para a cor RGB de base, seguidos por até 45 coeficientes SH adicionais (f_rest_0..44) na ordem transposta channel-major definida pelo artigo Kerbl-2023 (primeiro todos os coeficientes do canal R, depois todos de G, depois todos de B), seguidos por opacidade logit (valores brutos pré-sigmoide), três escalas em log-space e uma rotação em quaternion wxyz. O grau SH máximo exportado é limitado ao mínimo entre o desejo do usuário e o grau realmente aprendido; o padrão é 3 (45 coeficientes restantes). Antes da escrita, o tamanho do payload é calculado em inteiro de 64 bits para capturar overflow em nuvens extremamente grandes. O arquivo é gravado atomicamente, o que em nuvens grandes ocupa temporariamente o dobro do espaço em disco.

ONDE

Barra de menus → Export → 3D Formats → Export Compressed PLY…. Modo Simple: cartão de formato „Compressed PLY". Tamanho: aprox. 10–20 % em relação ao PLY (5 a 10 vezes mais compacto). Compatível com: SuperSplat, motor PlayCanvas, visualizadores baseados na web.

TÉCNICO

A variante PlayCanvas do formato PLY com quantização em blocos (chunked). As Gaussianas são agrupadas em blocos de 256. Por bloco, os limites mín/máx para posição, escala e cor são armazenados separadamente no cabeçalho; as Gaussianas individuais referenciam seus valores em relação a esses limites e são comprimidas para 32 bits cada: posição e escala com empacotamento de 11-10-11 bits, rotação como quaternion „Smallest-Three" de 2-10-10-10 bits, cor como RGBA 8-8-8-8. Coeficientes SH mais altos são quantizados com apenas 8 bits por componente (três bytes por coeficiente e Gaussiana). O próprio formato ainda é PLY com cabeçalho ASCII e, portanto, fundamentalmente validável com ferramentas PLY, mas as propriedades de vértice são declaradas como campos uint. O grau SH é por padrão 0 (sem coeficientes restantes), para maximizar a compressão — graus SH mais altos podem ser escolhidos explicitamente.

ONDE

Barra de menus → Export → 3D Formats → Export SPZ…. Modo Simple: cartão de formato „SPZ". Tamanho: aprox. 10 % em relação ao PLY (90 % menor). Compatível com: Niantic Scaniverse, Niantic Spatial Fields, MetalSplatter.

TÉCNICO

O formato SPZ v2 da Niantic. As posições são empacotadas como ponto fixo de 24 bits (o que dá aprox. 0,25 mm de resolução), as escalas como quantização de 8 bits em espaço logarítmico, as rotações como Smallest-Three de 8 bits (na v2 só xyz são armazenados, w é derivado no decodificador a partir da norma do quaternion), opacidades como valores sigmoidizados de 8 bits. O SH DC é armazenado com uma fórmula de empacotamento específica do SPZ (dc_raw * 0.15 * 255 + 0.5 * 255), bandas SH mais altas com 5 bits (banda 1) ou 4 bits (bandas 2-3) por coeficiente. O blob binário empacotado completo é então comprimido com gzip padrão (RFC 1952), resultando em um formato de contêiner gzipado com bytes mágicos 1f 8b. O RadianceKit chama o gzip do sistema para isso, porque a API zlib embutida da Apple gera um framing proprietário da Apple que não seria compatível com os leitores SPZ do Spatial Fields ou MetalSplatter. O gzip do sistema continua podendo ser executado (spawn) dentro do sandbox do macOS.

ONDE

Barra de menus → Export → 3D Formats → Export SOG…. Modo Simple: cartão de formato „SOG". Tamanho: aprox. 5–6 % em relação ao PLY (15 a 20 vezes mais compacto — a opção menor). Compatível com: motor PlayCanvas, editor SuperSplat.

TÉCNICO

„Spatially Ordered Gaussians" — um formato PlayCanvas que armazena a nuvem pronta para GPU em várias imagens WebP sem perdas. Primeiro, todas as Gaussianas são ordenadas espacialmente por código Morton 3D (Z-order de 30 bits, 10 bits por eixo), o que confere às imagens maior localidade de cache no renderizador posteriormente. Depois, as posições são quantizadas com transformação logarítmica simétrica (para melhor faixa dinâmica) em valores de 16 bits e divididas em duas imagens RGBA (means_l.webp para os 8 bits inferiores, means_u.webp para os superiores). As rotações são codificadas como Smallest-Three com 3×8 bits mais 2 bits de modo em uma imagem RGBA (o modo vai para o alfa como 252 + largest). Escalas e SH DC são quantizados com um codebook de 256 entradas cada (distribuído com base em percentis sobre todos os valores), os índices vão para scales.webp e sh0.webp. As cinco imagens mais um meta.json com codebooks e limites são empacotados em um arquivo ZIP (codificador personalizado, porque a sandbox bloqueia o zip do sistema) e salvos com a extensão .sog.

Atenção sandbox: SOG é a única opção de formato que exige uma binária externa. A etapa do codificador WebP chama o cwebp a partir de /usr/local/bin/cwebp ou /opt/homebrew/bin/cwebp. Caso nenhum binário cwebp seja encontrado, o código recorre à codificação PNG bruta — porém: o fallback para PNG não funciona no SuperSplat. Na versão da App Store, a disponibilidade é avaliada de acordo com a variante de build; na variante de desenvolvedor, o cwebp precisa estar instalado via Homebrew (brew install webp).

ONDE

Barra de menus → Export → 3D Formats → Export glTF…. Modo Simple: cartão de formato „glTF". Tamanho: comparável ao PLY. Compatível com: visualizadores glTF com a extensão KHR_gaussian_splatting (padrão em rascunho da Khronos).

TÉCNICO

Grava um arquivo binário .glb autocontido (sem anexo bin separado) de acordo com a especificação da extensão KHR_gaussian_splatting. As posições são armazenadas como dados de vértice POSITION regulares do glTF (float3), todos os outros atributos (rotação como float4, escala como float3, opacidade como float, coeficientes SH como float3 × shCoeffCount) ficam em atributos de vértice adicionais e são referenciados via extensão. Importante: o glTF usa um sistema de coordenadas Y-up destro, enquanto COLMAP/3DGS trabalha com Y-down/Z-forward. O exportador, portanto, aplica uma rotação de 180 graus em torno do eixo X — as posições são reescritas como (x, -y, -z), os quaternions são ajustados para (w, x, -y, -z). Isso resulta em uma representação geometricamente correta e de mão certa (não espelhada) em visualizadores glTF. Os blocos JSON e binário são preenchidos (padding) para alinhamento de 4 bytes, conforme exigido pelo padrão GLB.

ONDE

Barra de menus → Export → 3D Formats → Export .splat…. Modo Simple: cartão de formato „.splat". Tamanho: exatamente 32 bytes por Gaussiana. Compatível com: gsplat.js, visualizadores baseados na web (referência antimatter15), a maioria das demos 3DGS no navegador.

TÉCNICO

O formato .splat do antimatter15 — 32 bytes por Gaussiana, sem cabeçalho, sem indireção. Layout por entrada: 3 × float32 posição (coordenadas no mundo), 3 × float32 escala (transformada com exp a partir do espaço logarítmico do buffer interno), 4 × uint8 cor RGBA (coeficiente SH DC escalado com SH_C0 = 0.282... e limitado a [0,255]), 4 × uint8 quaternion (w,x,y,z, normalizado e codificado no intervalo de byte como 128 + 128*q). Apenas o SH DC é armazenado — bandas SH mais altas são descartadas. Isso torna o formato extremamente compacto, mas custa as mudanças de cor dependentes da visão que ocorrem em reflexos ou realces especulares. A ordem de escrita é exatamente a ordem de índice da nuvem (sem ordenação espacial), visualizadores web como gsplat.js renderizam partindo disso.

ONDE

Barra de menus → Export → Media → Export Web Viewer…. Modo Simple: cartão de formato „Web Viewer". Tamanho: dados de splat codificados em base64 (≈ 4/3 de overhead) + aprox. 5 KB de shell HTML/JS. Compatível com: qualquer navegador moderno com WebGL2 (todos os desktops, iOS 15+, Android 5+).

TÉCNICO

Empacota a nuvem gaussiana junto com um renderizador WebGL2 totalmente inline em um único arquivo .html. Não há dependências de CDN, nem WASM, nem um segundo arquivo. A nuvem é primeiro codificada internamente como binário .splat (mesma lógica de 32 bytes que em E6), depois embutida em base64, depois decodificada com atob no navegador. O renderizador embutido faz sua própria ordenação WebGL2, controle de órbita com mouse e ordenação por CPU a cada frame; todo o código JS (shaders, matemática, loop) fica visível no HTML de saída. A convenção de eixos na fronteira entre armazenamento e renderizador é exatamente a mesma que em E5: posição (x, -y, -z), quaternion (w, x, -y, -z). Opcionalmente, uma sobreposição de marca (branding overlay) pode ser exibida (interruptor do nível gratuito). Como tudo está inline, o arquivo funciona também diretamente pelo protocolo file:// — não é necessário servidor web local para testar.

ONDE

Barra de menus → Viewport → Record Turntable Video OU Barra de menus → Export → Media → Export Orbit Video…. Modo Simple: cartão de formato „Orbit Video" com controle deslizante de duração de 3–30 s. Tamanho: depende de duração, resolução, taxa de bits. Compatível com: todas as plataformas (H.264 e HEVC são padrão da Apple).

TÉCNICO

Renderiza a nuvem gaussiana ao longo de um voo de câmera orbital paramétrico e codifica cada frame via AVAssetWriter em um arquivo MP4 ou MOV. A configuração da órbita controla velocidade de rotação (número de voltas), distância, elevação, FOV, duração e o fator de ease-in/out. A exportação do vídeo orbital passa pela própria etapa de renderização do RadianceKit com avaliação SH completa — pixel a pixel idêntico ao viewport dentro do app (WYSIWYG). Por frame, a matriz de ajuste de mundo (calculada pelo renderizador para girar as coordenadas internas no mundo orbital Y-up) é multiplicada com a câmera, e em seguida é aplicada uma espelhagem de conversão de câmera (órbita Y-up → COLMAP Y-down). O alvo de renderização offscreen é transferido via IOSurface para um CVPixelBuffer para o codificador. O codificador suporta H.264 e HEVC, taxa de bits configurável e resolução de 480p a 8K. Antes do primeiro frame, o renderizador espera 200 ms, para que a ordenação inicial dos splats esteja concluída. Essa exportação é limitada pela GPU — em 8K e milhões de Gaussianas, o tempo de renderização por frame chega a vários segundos, então tempos totais de renderização de 10–30 minutos para 6 s de vídeo são possíveis.

ONDE

Barra de menus → Export → Photogrammetry → Export SfM (transforms.json)…. Tamanho: tipicamente 1–10 KB (apenas poses + intrínsecos, sem imagens, sem Gaussianas). Compatível com: nerfstudio, Brush, gsplat, OpenSplat, Meshroom, todos os treinadores 3DGS feed-forward modernos.

TÉCNICO

Grava o formato transforms.json do nerfstudio com uma lista de poses de câmera mais intrínsecos compartilhados. Por câmera, a matriz de visualização (interna do RadianceKit: mundo-para-câmera em convenção COLMAP) é invertida, e em seguida os vetores de base locais da câmera Y e Z são espelhados, para converter na convenção nerfstudio (estilo OpenGL, câmera olha ao longo de -Z, +Y é para cima). A matriz 4×4 final é gravada como array aninhado row-major de doubles no campo transform_matrix de cada frame. Os intrínsecos são armazenados no nível superior (distância focal x/y, ponto principal x/y, largura/altura da imagem, camera_model = "OPENCV", mais os coeficientes de distorção k1, k2, p1, p2) — exceto quando o exportador detecta múltiplos conjuntos diferentes de intrínsecos, e então eles são gravados por frame. Os caminhos de imagem são gravados como images/<filename> relativos ao arquivo JSON; o usuário precisa criar uma pasta images/ irmã com as fotos de treinamento.

ONDE

Barra de menus → Export → Photogrammetry → Export SfM (COLMAP Workspace)…. Tamanho: três arquivos binários juntos tipicamente 4–8 MB — points3D.bin domina (uma linha por ponto 3D da nuvem esparsa), images.bin e cameras.bin ficam cada um bem abaixo de 100 KB. Compatível com: o próprio COLMAP, Nerfstudio, Postshot, Meshroom, todas as ferramentas que esperam um diretório sparse/ do COLMAP.

TÉCNICO

Grava o layout padrão sparse/0/ do COLMAP com três arquivos binários: cameras.bin, images.bin, points3D.bin. A referência de formato é a documentação oficial do COLMAP. cameras.bin contém a lista de intrínsecos deduplicada (câmeras com intrínsecos idênticos + tamanho de imagem são agrupadas em uma única entrada); o modelo de câmera usado é OPENCV (modelo 4), com fx/fy/cx/cy mais os quatro coeficientes de distorção k1/k2/p1/p2. images.bin lista, por imagem, a pose como quaternion wxyz mais translação, seguido do ID da câmera e do nome do arquivo; nenhuma correspondência 2D-3D é armazenada. points3D.bin contém a nuvem de pontos SfM com posição, cor (RGB 0-255) e valores padrão para reprojeção e comprimento de trilha. Tudo é gravado em little-endian. A reimportação no RadianceKit funciona através do menu Arquivo → „Import COLMAP/Metashape Workspace…" (veja Q3 no capítulo do backend SfM).