Digitalizar un espacio real: la brecha entre la demo y la realidad
Bitácora de investigación · Hyuga.ai
Hay un momento específico en el que algo hace clic. Ves una demo de un espacio digitalizado en 3D (una propiedad, un hotel, un local), y pensás: esto cambia todo para el sector inmobiliario y turístico.
Venimos de trabajar con esas industrias. Sabemos lo que cuesta mostrar un espacio. Sabemos lo que vale que alguien pueda recorrerlo sin estar ahí. Así que cuando vimos los primeros resultados de gaussian splat aplicados a espacios reales, la pregunta que nos surgió fue ¿por qué no lo está usando todo el mundo ya?
Dedicamos las siguientes semanas a intentar responderla.
Qué es gaussian splat
3D Gaussian Splatting (3DGS) es una técnica de rasterización para renderizar escenas fotorrealistas en tiempo real a partir de un conjunto limitado de imágenes. Fue presentada en 2023 en el paper 3D Gaussian Splatting for Real-Time Radiance Field Rendering (Kerbl et al.).
A diferencia del rendering tradicional, que dibuja triángulos en pantalla, 3DGS representa la escena como una colección de millones de gaussianas 3D, primitivas volumétricas, cada una definida por cinco parámetros: posición (XYZ), covarianza (una matriz 3x3 que describe forma y orientación), color (RGB), opacidad (α), y armónicos esféricos para capturar variaciones de color según el ángulo de vista.
El proceso típico arranca con Structure from Motion (SfM), usando herramientas como COLMAP, para estimar las poses de cámara y generar una nube de puntos sparse a partir de las imágenes. Cada uno de esos puntos se convierte en una gaussiana inicial. Después, un proceso de optimización por gradiente descendente ajusta los parámetros de cada gaussiana hasta que las vistas renderizadas coinciden con las fotos originales.
En qué se diferencia de otras técnicas
Frente a NeRF (Neural Radiance Fields): NeRF representa la escena con una red neuronal que hay que consultar pixel por pixel, lo que la vuelve lenta tanto para entrenar como para renderizar. 3DGS reemplaza esa red por una representación explícita: las gaussianas mismas son los datos. Resultado: entrenamiento en minutos en lugar de horas, y render en tiempo real sobre GPU de consumidor.
Frente a mallas poligonales (meshes) tradicionales: una malla es geometría discreta, vértices, aristas, caras. 3DGS no es geometría en ese sentido; es más cercano a una nube de puntos con volumen y transparencia. Esto le permite capturar detalles finos, transparencias parciales y geometrías complejas que a las mallas les cuestan, pero también significa que un splat no se puede imprimir en 3D directamente ni editar como una malla. Existen métodos para extraer mallas a partir de splats (SuGaR, GaussianSurfels), pero todavía son área de investigación activa.
Frente a nubes de puntos clásicas: una nube de puntos es un conjunto de coordenadas con color. Las gaussianas suman orientación, escala y opacidad, lo que les da continuidad visual; el resultado se ve como una superficie suave, no como puntos discretos.
La brecha
El problema es el cuando funcionan.
Las demos que circulan muestran espacios impecables, transiciones suaves, detalles de textura que parecen fotografías. Lo que no muestran es todo lo que hay detrás: el hardware específico, las horas de procesamiento, los intentos fallidos, las máscaras que hay que crear a mano, los pipelines que se caen a mitad del proceso.
Cuando intentás replicar esos resultados desde cero, encontrás algo muy distinto.
Capturar las fotos es más difícil de lo que parece. El tipo de lente importa. El ángulo importa. La superposición entre imágenes importa. Los errores en la captura se amplifican en cada etapa del procesamiento.
El procesamiento es pesado. Las herramientas tradicionales pueden tardar horas en correr. Algunas fallan directamente si el volumen de imágenes supera cierto umbral. Otras requieren configuración que, si no tenés experiencia, se convierte en un laberinto.
El hardware es un problema real. Generar un gaussian splat de calidad requiere GPUs que la mayoría de las personas no tiene. Comprar ese hardware tiene sentido si lo vas a usar todos los días, no si estás explorando si el proceso vale la pena.
Los resultados iniciales son pobres. El primer intento casi nunca produce algo presentable. Hay que refinar: máscaras, parámetros, iteraciones. Cada vuelta suma tiempo y complejidad.
Las herramientas que probamos
Pasamos por varios caminos distintos:
RealityScan: La opción más accesible en términos de fricción. Resultados rápidos, proceso relativamente guiado. La limitación principal que encontramos es que el output es menos flexible, hay menos control sobre los parámetros del proceso y menos margen para ajustar el resultado a un uso específico.
Metashape: Herramienta profesional con resultados notablemente mejores. El proceso es más robusto, el control es mayor. El problema es que es de pago, y el costo no es trivial para quien está en fase de exploración.
COLMAP: La opción open source. Más lenta, más exigente en setup, más dependiente de hardware con GPU. Pero también la que más control ofrece y la que no tiene barrera de costo de licencia. Es la herramienta que, con suficiente paciencia y el hardware adecuado, permite llegar más lejos.
Modelos de IA para Structure from Motion: Probamos varios de los modelos recientes que prometen reemplazar o acelerar la etapa de SfM con redes neuronales (feature matching, estimación de poses, generación de nubes de puntos densas). Funcionan bien con datasets chicos. Con datasets grandes, los volúmenes reales que necesita un espacio completo, empezamos a chocar con dos problemas: aumento del error a medida que crece el número de imágenes, y consumo de memoria que se dispara. Son una vía prometedora, pero todavía no resuelven el caso de uso de un espacio completo.
El mínimo que funcionó
Probamos prácticamente todo lo que se puede probar a nivel captura: imágenes convencionales sin distorsión, lentes fish-eye, y cámaras 360. Cada formato tiene sus ventajas y sus problemas; el matcheo de imágenes 360 tiene sus propios desafíos, las fish-eye introducen distorsiones que hay que corregir, las convencionales exigen un solapamiento muy preciso entre tomas.
El mejor resultado, en balance, llegó con cámara 360. No porque sea imprescindible, sino porque resuelve un trade-off concreto: evita tener que comprar hardware extremadamente específico, y al mismo tiempo libera al operador de tener que ser quirúrgico con el solapamiento entre fotos. Una cámara 360 captura todo el entorno en cada disparo, y desde esa captura se pueden proyectar ortogonalmente vistas convencionales para alimentar el pipeline. La curva de aprendizaje para producir una captura usable es mucho más corta.
La combinación que funcionó:
- Cámara 360 como mejor balance entre costo de hardware y tolerancia al error de captura
- Luz de día; y vale la pena explicar por qué: las etapas de SfM y matcheo dependen de detectar features (puntos distintivos) en cada imagen y emparejarlos entre vistas. Con poca luz hay menos textura visible, menos contraste, más ruido, y el matcheo falla o se vuelve inestable. No es un capricho estético: es una limitación del algoritmo.
- COLMAP para el procesamiento de imágenes y la generación de la nube de puntos sparse
- Pipeline de gaussian splat sobre esa base
No es una solución lista para producción. Es el piso. El punto desde el cual tiene sentido seguir iterando.
Lo interesante es que, con esas condiciones mínimas cubiertas, el salto en calidad fue significativo respecto a los intentos anteriores. No porque hayamos encontrado el método definitivo, sino porque eliminamos las variables que más ruido generaban.
Lo que sigue
Este artículo no cierra nada. Es el comienzo de una serie de investigaciones sobre cómo digitalizar espacios reales de forma que sea útil, replicable y viable para las industrias que podrían beneficiarse.
Las preguntas que nos quedan abiertas:
- ¿Cuál es el flujo de captura óptimo con cámara 360? ¿Qué patrones de movimiento generan mejor cobertura?
- ¿Cómo reducir el tiempo de procesamiento sin sacrificar calidad?
- ¿Hasta dónde pueden llegar los modelos de IA para SfM cuando se resuelvan los problemas de escala y memoria?
- ¿Existe algún pipeline que funcione bien sin GPU de alta gama?
- ¿Cuánto tiempo lleva, en la práctica, producir un resultado presentable para un cliente?
Seguimos investigando. En el próximo artículo vamos a ir más adentro del proceso de captura: lo que encontramos, lo que falló, y lo que empezó a funcionar.
Hyuga.ai · investigación en curso ¿Tenés experiencia con alguna de estas herramientas? Nos interesa comparar notas.