Show HN: Gaussian Splatting 3D en tiempo real en WebGL

 (antimatter15.com)
4 puntos por GN⁺ 2023-09-12 | 1 comentarios | Compartir por WhatsApp
  • Un visor WebGL con el que puedes abrir y manipular directamente en el navegador escenas de 3D Gaussian Splat, y cuyo código de implementación está publicado en GitHub
  • Soporta teclado, mouse, trackpad, táctil e incluso gamepad, cubriendo ampliamente entornos de entrada de escritorio y móviles
  • El control de cámara se divide en desplazamiento, rotación orbital, inclinación y roll, y permite explorar la misma escena de distintas maneras según el dispositivo de entrada
  • Con las teclas numéricas y -, +, p es posible cambiar entre vistas de cámara precargadas, recorrer cámaras y reanudar la animación predeterminada
  • Puedes arrastrar y soltar archivos .ply para convertirlos a .splat, y cargar configuraciones de cámara con cameras.json

WebGL 3D Gaussian Splat Viewer

  • WebGL 3D Gaussian Splat Viewer es un visor de 3D Gaussian Splat creado por Kevin Kwok
  • El código está publicado en Github

Controles por dispositivo de entrada

  • Movimiento con teclado

    • Flecha izquierda/derecha: mover a izquierda/derecha
    • Flecha arriba/abajo: mover hacia adelante/atrás
    • Space: saltar

  • Ángulo de cámara

    • a / d: girar la cámara a izquierda/derecha
    • w / s: inclinar la cámara arriba/abajo
    • q / e: roll de la cámara en sentido antihorario/horario
    • i / k, j / l: rotación orbital

  • Trackpad

    • Scroll: rotación orbital arriba/abajo/izquierda/derecha
    • Pinch: mover hacia adelante/atrás
    • Ctrl + scroll: mover hacia adelante/atrás
    • Shift + scroll: mover arriba/abajo o izquierda/derecha

  • Mouse

    • Clic y arrastrar: rotación orbital
    • Clic derecho o arrastrar arriba/abajo junto con la tecla Ctrl/Cmd: desplazamiento

  • Táctil

    • Un dedo: rotación orbital
    • Pellizco con dos dedos: mover hacia adelante/atrás
    • Rotación con dos dedos: girar la cámara en sentido horario/antihorario
    • Deslizamiento con dos dedos: mover a izquierda/derecha y arriba/abajo

  • Gamepad

    • Funciona si hay un control de juego conectado

Cámara y manejo de archivos

  • Control de vistas de cámara

    • 0-9: cambiar a una de las vistas de cámara precargadas
    • - o +: recorrer las cámaras cargadas
    • p: reanudar la animación predeterminada

  • Arrastrar y soltar

    • Archivo .ply: convertir a .splat
    • cameras.json: cargar cámaras

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-12
Opiniones en Hacker News

  • Está muy bueno, pero los controles confunden
    No es el movimiento típico con WASD y rotación de la vista con el mouse; al arrastrar con el mouse uno se mueve hacia adelante/atrás y orbita alrededor de un punto específico, A/D mueve a izquierda/derecha, y W/S sirve para mirar arriba/abajo
    La lista completa de controles está en el README: https://github.com/antimatter15/splat#controls

    • Soy el autor; perdón porque los controles de la cámara son incómodos. Con gusto acepto pull requests para cambiarlos por algo más razonable
      La intención original era poder moverse solo con las flechas, girando en el lugar y caminando hacia adelante y atrás
    • Se parece bastante a los controles de FPS de N64, por ejemplo GoldenEye
      La estructura es hacer el “movimiento principal” con las flechas/joystick para avanzar/retroceder y girar a izquierda/derecha, y el “movimiento secundario” con WASD/botones C para desplazarse lateralmente y mirar arriba/abajo
    • Como referencia, me gustó bastante el esquema de control usando solo el mouse
    • Si soy sincero, los controles son tan poco intuitivos y horribles que me quedé trabado antes de poder apreciar la demo de renderizado

  • Está increíble. Yo también estoy trabajando en portar gaussian-splatting [0] a WebGPU
    Al igual que otras implementaciones que he visto hasta ahora, esta parece cometer el mismo error al proyectar elipsoides en proyección en perspectiva. Primero calcula la covarianza en 3D y luego la proyecta a 2D[1], pero ese enfoque solo es correcto para proyección paralela/ortográfica; aplicado a proyección en perspectiva da resultados incorrectos
    En la proyección en perspectiva hay tres efectos adicionales. El desplazamiento por paralaje cambia la forma de la elipse proyectada, la rotación del elipsoide puede cambiar su posición aparente y producir una traslación adicional, y una sección cónica puede ser no solo una elipse sino también una parábola o una hipérbola
    Parece que el primer efecto se corrige manualmente con esta matriz[2], pero los otros dos efectos no entran en los cálculos en las implementaciones que he visto hasta ahora. Para hacerlo correctamente no habría que calcular la covarianza 3D, sino obtener el cono límite del elipsoide cuyo vértice es la posición de la cámara y luego intersectarlo con el plano de vista. La sección cónica resultante es el contorno exacto del elipsoide proyectado en perspectiva
    [0]: https://github.com/graphdeco-inria/gaussian-splatting
    [1]: https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...
    [2]: https://github.com/antimatter15/splat/blob/3695c57e8828fedc2...

    • En general, una gaussiana deja de ser una gaussiana real después de la proyección de cámara. Esto se debe a que la función de proyección de una cámara estenopeica es no lineal porque divide por z
      Pero si la gaussiana es pequeña respecto del tamaño de la imagen, se puede aproximar linealizando la función de proyección. Por eso el paper de Gaussian Splatting usa el jacobiano de la función de proyección, como en la ecuación 5[0]
      En la práctica, esta aproximación encaja muy bien. La matriz mencionada en tu tercer enlace es precisamente ese jacobiano, y no es una corrección manual sino algo matemáticamente válido. Ver [1] para la derivación
      [0] https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/3d_...
      [1] https://math.stackexchange.com/a/4716514/43771
    • Parece correcto. Es como tratar la proyección en coordenadas cartesianas como si fuera una transformación lineal, y transformar la gaussiana con eso
      Visto de otra manera, se aproxima la proyección suponiendo que toda la gaussiana está a una profundidad fija; si está lo suficientemente lejos, debería funcionar
      La transformación proyectiva de una gaussiana se ve bastante engorrosa, pero imagino que alguien ya lo habrá hecho. En coordenadas proyectivas parece posible, aunque la parte final de proyectar a coordenadas cartesianas es complicada
      Por cierto, proyectar solo el contorno también está mal. Cambia toda la distribución de densidad, y eso también afecta el contorno
    • No estoy familiarizado con la técnica de gaussian splat, pero me parece que en esencia es una malla de cuadriláteros con datos internos en los vértices
      Pensaba que la proyección de cuadriláteros ya era un problema resuelto; ¿podrías explicar un poco más en qué se diferencia de un arreglo simple de cuadriláteros?
    • Si se pudiera implementar la idea de intersección con el cono límite sin afectar el frame rate, creo que se vería más fluido en WebGPU. Aun así, sería interesante ver la diferencia comparada en las mismas condiciones con una implementación como esta

  • Al hacer zoom out se ven muchas aristas poligonales que no parece que deberían estar ahí
    Parece como si intentara dibujar “bultos” suaves, pero las coordenadas de textura estuvieran un poco desalineadas; me pregunto si es un bug o una parte intencional de la técnica

    • Es intencional
      Básicamente es una nube de puntos semidensa[1], pero en vez de puntos tiene bultos cuyo color, ángulo y tamaño se ajustaron para coincidir con las fotos de entrada. Por eso está optimizada para verse desde cierta distancia
      Piénsalo como un dibujo vectorial 3D. Si haces demasiado zoom o separas partes, el conjunto empieza a verse algo raro
      [1]https://www.researchgate.net/publication/326621750/figure/fi...

  • Hasta ahora solo había visto que Gaussian splatting se usara con datos fotográficos.
    ¿También se puede usar con otros datos gráficos? Dicho de otro modo, ¿tiene potencial para usarse en juegos?

    • Depende de la situación. Un enfoque de campo de radiancia como Gaussian splatting es, básicamente, fotografía 3D.
      Solo contiene color según la posición y la dirección geométricas, y no tiene conceptos de superficies, materiales ni transporte general de la luz, es decir, emisión, absorción, transmisión, reflexión o dispersión. En otras palabras, solo permite iluminación precalculada y escenas estáticas, y la animación es difícil.
      La industria parece estar moviéndose hacia métodos que permiten una mejor iluminación dinámica, como el renderizado basado en física (PBR) y el trazado de rayos/rutas.
      Además, por ahora la eficiencia espacial es extremadamente baja. Una escena que en un motor de renderizado tradicional ocuparía decenas de GB puede llegar a ocupar TB. Aunque podría mejorar con más optimización.
      Una excepción donde Gaussian splatting podría ser interesante es el contenido procedimental/generativo, quizá incluso con animación. En especial podría encajar bien con efectos volumétricos como humo, fuego, nubes o agua en movimiento, donde hoy se usan sistemas de partículas.
    • No hay motivo para que no sea posible. Al final no es más que una nube de puntos vistosa.
      Es fácil imaginar un juego de mundo abierto estilo Minecraft que use esto como motor base en lugar de vóxeles.

  • ¿Esta técnica también funciona con video?
    Viendo el README del trabajo de INRIA[1], parece que entrenan un modelo por cada escena estática; ¿eso deja fuera al video?
    [1] https://github.com/graphdeco-inria/gaussian-splatting

  • ¿Qué estoy viendo exactamente?

    • Gaussian splatting es una forma elegante de llamar a una nube de puntos que, en lugar de puntos, usa figuras con color.
      Es una técnica que existe desde hace mucho, pero si una nube de puntos tiene un millón de puntos, hay que manejarlos artísticamente uno por uno, así que no se usaba mucho.
      Es parecido al cabello 3D. El principio es simple: basta con renderizar mil millones de cabellos, pero hacerlo para que realmente se vea bien es difícil.
      Aquí se hace que un modelo de aprendizaje automático ajuste el ángulo, color, forma y tamaño de un millón de primitivas, por ejemplo cuadrados, círculos o triángulos, para que se parezcan a las fotos que le proporcionamos.
    • Básicamente es este trabajo: https://github.com/graphdeco-inria/gaussian-splatting — un enfoque algo distinto para renderizar escenas 3D.

  • ¿Esto usa el método propuesto por Kerbl y Kopanas en SIGGRAPH 2023?
    https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/

    • Sí. Pero esto implementa solo la parte de splatting/renderizado, no la parte de optimización que genera la reconstrucción inicial.

  • Es realmente impresionante. Las nubes de puntos también son interesantes, pero esto es mucho más sorprendente. Incluso corre a 60 fps en la laptop Lenovo que uso en la empresa.

    • También corre a 36 fps en un celular de gama media. No me lo esperaba.
      Aunque se ven muchos artefactos, sobre todo al mover la cámara.

  • Si logran hacer que esto funcione dentro de ThreeJS, creo que podrían dejar huella en la historia del 3D web.

  • Nunca había experimentado este tipo de control con el mouse en una vista 3D, así que estuve bastante confundido por un rato.