La idea es simple. Partimos de una escena real, la reconstruimos con Gaussian Splatting y la llevamos a Unity para reproducir una trayectoria equivalente y generar un vídeo simulado comparable con el original. No montamos un simulador completo de dron. Hicimos algo más concreto y bastante más fácil de defender: construir un proxy visual de una escena real y comprobar si aguanta una comparación seria.

A partir de esta idea, hemos estado trabajando en el artículo «Assesing Gaussian Splatting Virtual Environments for Drone Vision under Real and Simulated Trajectories».

El punto de partida

El trabajo parte de un problema bastante conocido. Probar sistemas de visión en entornos reales sale caro, cuesta repetir condiciones y controlar variables es un dolor. Los simuladores clásicos ayudan, pero suelen depender de modelado manual, motores gráficos y escenas que se parecen a la realidad lo justo para no pasar vergüenza. Aquí el enfoque fue otro: capturar una escena real y reconstruirla directamente con una técnica de renderizado neuronal, en este caso 3D Gaussian Splatting.

Captura de la escena real

Primero se grabó un vídeo de la escena que se quería reconstruir. La captura se hizo con un smartphone de gama media, no con una cámara profesional. La elección no fue casual. Se buscó una configuración más cercana a un sensor RGB ligero, del tipo que podría llevar una plataforma aérea pequeña, aunque el experimento se hizo en interior y sin vuelo real.

Durante la grabación se recorrió la escena desde varios puntos de vista. El objetivo era cubrir bien las superficies visibles y los objetos principales, con suficiente solapamiento entre imágenes.

Extracción de frames y reconstrucción geométrica

Después se extrajeron los fotogramas del vídeo con Sharp Frames. Esos frames pasaron a una tubería fotogramétrica con realityScan y COLMAP. En esta fase no se generó todavía el entorno virtual final. Lo que se obtuvo fue una base geométrica coherente: poses de cámara calibradas y una descripción 3D dispersa de la escena.

COLMAP actuó como base para estimar las poses. realityScan ayudó a estabilizar la alineación a lo largo de toda la secuencia. El resultado fue una colección de vistas alineadas sobre la que ya se podía entrenar una representación más rica.

Generación de la escena con Gaussian Splatting

Con la reconstrucción alineada, el siguiente paso fue importar el proyecto en Lichfield Studio para generar la escena final con Gaussian Splatting. Aquí cambia el tipo de representación. La escena ya no se modela como una malla ni como una nube de puntos tradicional. Se representa como un conjunto de gaussianas 3D anisotrópicas con posición, escala, orientación, opacidad y apariencia.

Durante el entrenamiento, esas gaussianas se ajustan para que sus proyecciones coincidan con las imágenes observadas y con las poses de cámara recuperadas antes. En este caso se usó la estrategia de optimización basada en MCMC de Lichfield Studio, con 30.000 iteraciones, armónicos esféricos de grado 3 y un máximo de 1.000.000 de gaussianas. El resultado fue una representación fotorrealista que ya podía renderizarse en tiempo real.

Importación en Unity

Una vez entrenado el modelo, se importó en Unity. Desde ese momento, el experimento dejó de depender de las imágenes originales de reconstrucción. La escena pasó a funcionar como entorno virtual renderizable bajo movimiento de cámara controlado. Ese detalle importa. No se comparó una reconstrucción estática, sino una escena capaz de generar nuevas vistas siguiendo una trayectoria concreta.

Recuperación de la trayectoria real

Después se grabó un segundo vídeo en la misma escena y con condiciones de luz parecidas. Ese segundo vídeo no sirvió para reconstruir la escena otra vez. Sirvió para recuperar la trayectoria de cámara que luego se iba a reproducir dentro del entorno virtual.

Los frames de esta segunda secuencia se insertaron en el proyecto de reconstrucción anterior y se alinearon contra el entorno ya reconstruido. Eso permitió estimar la trayectoria dentro del mismo sistema de coordenadas de la escena virtual, que es bastante más estable que calcularla de forma independiente a partir de un clip corto. Después se conservaron solo las imágenes de esa secuencia de trayectoria.

Conversión de la ruta para Unity

Las poses de cámara se exportaron desde COLMAP y se transformaron a un JSON compatible con Unity mediante un script propio. La conversión adaptó el sistema de coordenadas de COLMAP al de Unity y guardó una pose por frame, con posición y rotación en cuaterniones. Luego, Unity reprodujo esa ruta frame a frame con un controlador específico de cámara.

Ajuste final dentro del motor

Hizo falta un ajuste final manual dentro de Unity para mejorar la correspondencia entre la vista real y la simulada. Se tocaron la pose inicial, la escala de la ruta y parámetros ópticos de cámara, como el ángulo de apertura. El motivo es sencillo: una trayectoria coherente en coordenadas de escena no garantiza una equivalencia visual perfecta entre la cámara inferida en reconstrucción y la cámara usada al renderizar. La matemática ayuda, pero no hace milagros.