CityGaussian: renderizado en tiempo real y de alta calidad de escenas a gran escala con Gaussianas

 (dekuliutesla.github.io)
1 puntos por GN⁺ 2024-04-03 | 1 comentarios | Compartir por WhatsApp
  • CityGaussian (CityGS) es un método de ECCV 2024 que extiende 3D Gaussian Splatting (3DGS) a escenas a escala urbana, con el objetivo de lograr tanto eficiencia de entrenamiento como calidad de exploración en tiempo real
  • Resuelve la limitación de que las escenas a gran escala son difíciles de manejar de una sola vez mediante una combinación de entrenamiento de divide y vencerás y una estrategia de nivel de detalle (LoD)
  • Aprovecha información previa global de la escena y selección adaptativa de datos de entrenamiento para alinear con mayor eficiencia los resultados entrenados por bloque y fusionarlos de forma fluida
  • Comprime los Gaussian primitives fusionados para crear varios niveles de detalle y, durante el renderizado, selecciona y agrega el nivel de detalle adecuado por bloque
  • Sin LoD, representar MatrixCity con 25 millones de Gaussianas solo alcanza 18 FPS en una A100, pero CityGS con LoD logra renderizado en tiempo real con un promedio de 36 FPS

Estructura de entrenamiento y renderizado para 3DGS a gran escala

  • 3D Gaussian Splatting (3DGS) ha mostrado fortalezas en reconstrucción de escenas 3D en tiempo real y síntesis de nuevas vistas, pero el entrenamiento de escenas a gran escala y el renderizado en tiempo real en múltiples escalas siguen siendo costosos
  • CityGaussian aborda este problema en dos etapas
    • Entrenamiento de divide y vencerás: divide la escena a gran escala en bloques para entrenarla de forma eficiente
    • Estrategia LoD: usa solo el nivel de detalle necesario según la escala de observación para acelerar el renderizado
  • La información previa global de la escena y la selección adaptativa de datos de entrenamiento mejoran la eficiencia del entrenamiento y ayudan a fusionar de manera más natural los fragmentos de escena separados
  • Los Gaussian primitives fusionados pasan por un proceso de compresión para formar múltiples niveles de detalle
  • En la etapa de renderizado, se usan estrategias de selección y agregación de nivel de detalle por bloque para permitir una generación de imagen rápida incluso en múltiples escalas

Rendimiento y materiales públicos

  • Sin aplicar LoD, la escena MatrixCity se representa con 25 millones de Gaussianas y se mide en 18 FPS sobre una A100
    • Se considera que esta velocidad dificulta ofrecer una experiencia de desplazamiento fluida
  • CityGS con LoD permite renderizado en tiempo real incluso en escalas muy distintas, con un promedio de 36 FPS en una A100
  • En experimentos con escenas a gran escala, CityGS muestra calidad de renderizado de nivel de punta y soporta renderizado consistente en tiempo real en escenas grandes de distintas escalas
  • Materiales públicos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-03
Opiniones en Hacker News

  • Por el nombre del dataset del video, Matrix city, es muy probable que se haya extraído de la demo de Matrix de Unreal Engine 5 publicada hace unos años
    Los puntos de vista son muy parecidos, así que se ve fotorrealista, pero no parece venir de fotos reales
    Buscando un poco más, efectivamente era eso: https://city-super.github.io/matrixcity/

    • Como Epic compró hace tiempo la empresa de fotogrametría Quixel, es muy probable que al crear Matrix city hayan usado una biblioteca de assets escaneados a partir de fotos
      Curiosamente, eso haría que el artículo original esté reconstruyendo de nuevo algo que ya era una reconstrucción de objetos reales
    • Algunos assets de la demo The Matrix Awakens se publicaron como paquetes separados en el Marketplace de Unreal Engine: [1] mapa, [2] edificios, multitudes y vehículos
      El mapa de MatrixCity es distinto, pero se parece en cierta medida al mapa de Matrix Awakens. También se puede comprobar en este análisis de diseño [3], escrito por el líder técnico del proyecto Matrix Awakens
      Y, si se profundiza más, en la sección MatrixPlugin del codebase en GitHub [4] se indica explícitamente que usaron el proyecto city-sample
      [1] https://www.unrealengine.com/marketplace/en-US/product/city-...
      [2] https://www.unrealengine.com/marketplace/en-US/learn/city-sa...
      [3] https://quentinmarmier.artstation.com/projects/xYeKNO
      [4] https://github.com/city-super/MatrixCity
    • Si se usan datos de un motor de juegos, se pueden obtener poses de cámara exactas correspondientes a cada imagen
      Eso hace que entrenar NeRF o Gaussian Splatting sea un poco más fácil, porque no hay error de optimización de la pose de cámara
      Es la misma razón por la que los primeros papers de NeRF usaban la famosa excavadora Lego amarilla renderizada con Blender
    • Si ya existe una escena completamente modelada en Unreal Engine, me pregunto si no se podrían generar splats sin una etapa de entrenamiento al crearlos
      Para una escena como Matrix city, no parece necesario pasar mucho tiempo entrenando solo para reproducir los datos
    • No todos los videos son de Matrix City; algunos son lugares reales

  • El fin de semana estuve uniendo meshes de tiles 3D de Google Maps con Gaussian Splats y, aunque no es exactamente lo mismo, el efecto fue bastante parecido y útil
    Ejemplo 1 con código enlazado: https://twitter.com/kfarr/status/1773934700878561396
    Ejemplo 2: https://twitter.com/3dstreetapp/status/1775203540442697782

    • Está buenísimo; me pregunto si hay un GitHub con el código
      En el primer enlace aparece un error en las herramientas de desarrollador
      Uncaught (in promise) Error: Failed to fetch resource [https://tile.googleapis.com/v1/3dti](<https://tile.googleapis.com/v1/3dti>;)...
    • Estaba probando cosas con Aframe y contornos de edificios de OSM, pero este enfoque se ve mucho mejor
      Voy a revisar aframe-loader-3dtiles-component
    • Para quienes no usan xitter, estaría bueno que también pusieran aquí el enlace al repositorio de código

  • “La velocidad promedio es de 36 FPS (probado en A100)” suena a que es en tiempo real si tienes una GPU de US$8k

    • Es el viejo tiempo real estilo SIGGRAPH
      Cuando un paper de gráficos dice que alcanzó velocidad en tiempo real, siempre hay que volver a verificar si realmente es tiempo real o si significa “640x480 a 20 fps en el hardware más caro que se puede comprar”
      Si bajas el estándar lo suficiente, cualquier cosa puede ser en tiempo real
    • Parece ser el primer 3DGS que usa LOD y bloques, así que quizá haya margen de optimización
      Puede llegar a servir para casos como producción virtual, pero no parece ser para móviles
    • Me recuerda a los benchmarks de GPUs de antes, que cuando salían por primera vez corrían a 10 fps y luego eso cambiaba con el tiempo
      https://www.techpowerup.com/forums/attachments/all-cards-png...
    • Lamentablemente, mucha investigación de 3DGS/NeRF es así
      Si quieres algo que corra incluso en una laptop de hace 10 años, y hasta sin GPU, mira https://github.com/pierotofy/OpenSplat. Lo hice yo
    • Creo que la próxima generación de GPUs de consumo, la 5090, será el doble de rápida que una A100 y no costará US$8k
      Así que no parece un problema insuperable

  • ¿Alguien puede convencerme de que el 3D Gaussian Splatting no es un callejón sin salida?
    El renderizado es demasiado lento por un factor de un solo dígito, y los datos también son demasiado grandes por un factor de un solo dígito. Se siente como volver a ver el enfrentamiento entre rasterización y ray tracing.
    La rasterización siempre será más rápida que el ray tracing, y si el ray tracing se vuelve 10 veces más rápido, la rasterización también se volverá 10 veces más rápida.
    Generar geometría y materiales tradicionales a partir de una nube de puntos gaussianos podría ser interesante. Pero la fotogrametría ya existe desde hace bastante tiempo.
    Intentar renderizar en tiempo real una ciudad enorme con splats no se siente como “la dirección correcta”.
    Es genial, divertido e interesante, pero no estoy seguro de que vaya a ser realmente útil. No soy experto, así que lo pregunto en serio.

    • Hay muchísimas posibilidades. Es un enfoque similar a las tecnologías patentadas que usa Unreal Engine, pero distinto.
      La mayor parte de la investigación actual no se centra en el rendimiento, y todavía ni siquiera hay consenso sobre un formato unificado, incluida la compresión.
      Las posibilidades de optimización son muy claras, y también es fácil ajustarlo para distintos dispositivos. Es parecido al LOD de nubes de puntos o al culling de mallas.
      El rendimiento de los splats puede ser una ventaja competitiva temporal de los visores, pero así como la descompresión de video u otros estándares 3D se difundieron como open source, es muy probable que en unos años ver splats en alta calidad y a alto framerate sea un requisito básico en la mayoría de los dispositivos.
      La siguiente pregunta es para qué se va a usar esto.
    • No es más lento por un factor de un solo dígito. Incluso ahora, en Unreal o Unity se alcanzan fácilmente 200~400 fps.
      Más de 100 fps en el navegador: https://current-exhibition.com/laboratorio31/
      900 fps: https://m-niemeyer.github.io/radsplat/
      Los motores tradicionales tienen 30 años de investigación y desarrollo acumulados, así que tomará tiempo que las herramientas y la optimización se pongan al día.
      Dicho eso, si uno mira de dónde vienen los papers, hay mucho de Apple y Meta, y parece una tecnología destinada a impulsar la era del metaverso/cómputo espacial que ambas empresas están empujando.
      La capacidad de llevar contenido de muy bajo costo de producción, como videos de iPhone, a entornos 3D desplazará mucha investigación y desarrollo de los métodos tradicionales.
    • La fotogrametría tiene dificultades con ciertos materiales, como las superficies reflectantes.
      También es muy difícil capturar detalles finos como estructuras delgadas o cabello. 3DGS es fuerte en esas áreas.
      También hay investigación en curso para mejorar sus debilidades actuales, incluidos métodos de extracción de mallas que puedan usarse en pipelines gráficos tradicionales.
    • En términos de realismo para reconstruir el mundo real en 3D realista, actualmente hay muy pocas cosas comparables.
      La fotogrametría solo funciona bien cuando los datos de superficie son limpios, pero los Gaussian splats son fuertes con datos semivolumétricos como pelaje, vegetación, partículas y superficies rugosas.
      También encajan bien con superficies brillantes y reflectantes, volúmenes con fuertes propiedades de superficies subdivididas y materiales con gran dependencia del punto de vista.
    • Lo importante es de qué sería un callejón sin salida.
      Si el caso de uso es algo equivalente a una foto 3D completa, es bastante genial y un uso suficientemente justificado.
      Si es para motores de juegos 3D, creo que es difícil manipular dinámicamente las primitivas básicas de la forma que requiere un motor de juegos. Los intentos seguirán, pero desde esta perspectiva los gaussianos parecen más un formato de renderizado final que una representación intermedia útil.
      Para usarlos de forma práctica en un motor, habría que inventar algo que cubra ese espacio intermedio, y todavía quedan muchas preguntas.
      No sé qué otros usos tendrá, pero el mundo no está compuesto solo por juegos 3D y efectos visuales.

  • Hay tantas cosas que llevan el nombre de Gauss, y siguen apareciendo nuevas como Gaussian splatting, que resulta curioso ver de nuevo cuánto influyó Gauss en tantos campos.
    No lo inventó directamente, pero sí contribuyó mucho a esas matemáticas.

  • Me interesa ver con qué licencia se publicará.
    Quiero ver un juego open source que use esto.

    • Más allá del rendimiento, para usarlo realmente en juegos primero habría que encontrar una forma generalizada de hacer que la escena sea dinámica.
      Hay muchos casos en la historia que parecían prometedores como alternativa a las mallas de triángulos, hasta que se descubrió que no había una forma eficiente de animarlos y desaparecieron.
    • Básicamente esto es una nube de puntos muy grande compuesta por puntos de formas extrañas, así que es realmente difícil.
      Los objetos dentro de la nube de puntos no tienen metadatos intrínsecos como “silla, mesa, persona”, por lo que cualquier interacción es muy difícil.
      No es imposible, pero por ahora no es práctico.
      Además, tampoco está tan optimizado para renderizado en tiempo real. Aunque se hayan podado muchos puntos, usar una malla de baja resolución es mucho más eficiente.

  • Esto no se ve mucho mejor que algo como Cities: Skylines.
    No hay zoom in ni zoom out, y siempre muestra solo un encuadre muy limitado. ¿Me estoy perdiendo algo?

    • Las otras respuestas parecen haber contestado sin pensarlo ni investigarlo realmente.
      El paper hace referencia repetidas veces a MatrixCity, y https://city-super.github.io/matrixcity/, que encontró otra persona arriba, también afirma que son datos completamente sintéticos.
      Según entiendo, fueron extraídos de Unreal Engine.
    • Esto no es renderizado de juegos, sino reconstrucción 3D.
    • Creo que fue renderizado a partir de fotos.
    • Esto no es un motor de juegos, sino una conversión de fotos reales a una vista 3D gaussiana.

  • Estoy aprendiendo con pygame y me da curiosidad cómo se agrega desenfoque de movimiento a un juego
    Por ejemplo, al hacer Mario con pygame, quisiera que Mario se viera borroso cuando salta
    Podría crear una versión borrosa de Mario promediando 9 píxeles, pero no sé si eso es lo que suelen hacer en otros juegos
    Muchos juegos también se ven muy nítidos sin desenfoque de movimiento, así que me pregunto si realmente se usa
    En el cine es un elemento bastante importante, y también me viene a la mente que para obtener un desenfoque de movimiento cinematográfico hay que filmar a 25 fps

    • Basta con renderizar los vectores de movimiento de los objetos en otra textura de renderizado
      Es decir, se calcula la velocidad de cada objeto, se renderiza como color y luego se usa en una etapa de posprocesamiento para definir la intensidad y la dirección del efecto de desenfoque
      Puede que se necesite movimiento relativo a la cámara. En el caso de Mario quizá no, pero en un FPS querrías que los bordes de la pantalla se desenfoquen cuando la cámara avanza

  • Material relacionado: https://city-super.github.io/octree-gs/

  • Es un enfoque bastante avanzado para renderizar escenas más grandes con 3D Gaussians, así que quiero probarlo pronto cuando publiquen el código