Escalando aplicaciones React-Three-Fiber más allá del Hola Mundo

WebGL es una tecnología del navegador que permite utilizar la GPU para construir aplicaciones basadas en gráficos 3D con JavaScript. Ha estado presente durante bastante tiempo, casi 12 años, y su uso ha cambiado mucho durante ese tiempo. Todo comenzó al principio con algunos usuarios avanzados que construían demos geniales de gráficos 3D, que mostraban la tecnología pero aún no brindaban valor a los usuarios. Sin embargo, después de un tiempo, comenzamos a construir aplicaciones reales que utilizaban WebGL para mejorar la experiencia del usuario en casos de uso específicos, que respondían a una necesidad empresarial específica y mejoraban la experiencia del usuario. Sin embargo, esas experiencias aún se entregaban como aplicaciones especiales, una sección aislada de un sitio web con una escena clara del resto, no algo que usarías todos los días.

Esto cambió con el tiempo y hoy en día WebGL se utiliza en todo tipo de aplicaciones que usamos a diario y profesionalmente, incluso. Piensa en Google Maps o Figma. Ni siquiera sabes que WebGL está ahí, pero está utilizando la GPU para acelerar el renderizado, tanto para aplicaciones 3D como 2D, y es lo que hace posible la aplicación en primer lugar. Entonces, dado que WebGL es tan ampliamente utilizado hoy en día, ¿podemos decir que los gráficos 3D en la web son actualmente una mercancía, algo fácil de construir? Bueno, para responder a esta pregunta, creo que tenemos que analizar cuál es el ecosistema de herramientas actual disponible para ello.

Un ejemplo de esto es 3.js, una biblioteca que acelera el desarrollo de aplicaciones WebGL al proporcionar utilidades y envolver su API, brindando una API más similar al DOM. Hoy en día, incluso podemos usar React junto con 3.js para construir aplicaciones WebGL. Y esto realmente ha impulsado su adopción recientemente.

De hecho, gracias a una biblioteca llamada React ReFiber, ahora podemos usar React de manera declarativa para construir aplicaciones y escenas utilizando 3.js. El poder de React radica en que permite reutilizar fácilmente componentes y vincular tus datos sin mutaciones imperativas. Lo realmente poderoso de React ReFiber es el ecosistema que se ha construido a su alrededor. Hay muchos proyectos de código abierto que facilitan algunas tareas comunes de renderizado 3D, como el procesamiento posterior, el diseño, la física y la accesibilidad. Incluso hay algunas bibliotecas de componentes, como Tri, que proporcionan técnicas de renderizado avanzadas, como iluminación, skyboxes, sombras y controles de teclado y mouse como componentes reutilizables de React.

Esto es realmente poderoso, ya que permite a todos construir aplicaciones geniales con muy pocas líneas de código. Por ejemplo, esta demostración realmente muestra lo que puedes hacer con ella. Física, controles de mouse, materiales avanzados y reflejos. El código necesario para construir algo como esto parece mucho, pero en realidad es sorprendentemente bajo. De hecho, esta demostración tiene alrededor de 60 líneas de código. Esto es posible porque puede reutilizar mucho código de la biblioteca de componentes.

Hemos visto muchas demostraciones geniales como esta recientemente en Twitter, y se han realizado muchas charlas en conferencias sobre cómo comenzar con esta nueva tecnología de color. Pero, ¿esto significa que ahora puedo construir fácilmente mi Figma o mi Google Maps solo usando esas bibliotecas y escribiendo unas pocas líneas de código? Bueno, desafortunadamente, no realmente. Por ejemplo, si observamos algo que implementa algo similar a lo que hace Google Maps, como procedural.js, podemos ver cómo rápidamente se convierte en una biblioteca gigante con más de 10,000 líneas de código. Esto se debe a que si deseas desarrollar algo que sea más intensivo en datos y use gráficos 3D, tienes muchos desafíos que superar. Por ejemplo, debes cargar y descargar eficientemente muchos datos, triángulos y texturas que representan el terreno. Debes transmitir tus datos en mosaicos desde un servidor y debes manejar los niveles de detalle entre los niveles de zoom para que, si te alejas, obtengas una resolución más baja de tu escena que se pueda renderizar. Y también deseas una verificación rápida de colisiones para tus interacciones basadas en el mouse. Desafortunadamente, la respuesta a esas preguntas no es algo que realmente encontrarás en un libro de desarrollo web. Es algo que es mucho más común entre los desarrolladores de juegos, no los desarrolladores web. Los desarrolladores de juegos utilizan diferentes lenguajes y herramientas, como C++, por lo que no hay mucho en la web que puedas encontrar. Pero todo este conocimiento interno es lo que hizo posibles los juegos de mundo abierto en primer lugar. Por ejemplo, algoritmos que simplifican dinámicamente una escena compleja cuando la observas desde una distancia. El uso de este tipo de trucos es crucial cuando estás lidiando con cantidades masivas de datos. Si observas aplicaciones complejas en la web, como Figma, en realidad están haciendo exactamente lo mismo bajo el capó. Si ralentizas artificialmente tu computadora y te acercas a un documento complejo de Figma, verás cómo se está renderizando de manera asíncrona y te muestra primero la resolución más baja mientras se carga. Volvamos a verlo. Te acercas y ves cómo puedes obtener una versión pixelada primero y luego se carga cuando está lista sin bloquear el hilo principal ni las interacciones del usuario. El uso de muchas técnicas como estas es lo que hace posible Figma y no lo hace dolorosamente lento. Desafortunadamente, desarrollar este tipo de trucos no es fácil. Implica escribir mucho código hecho a medida para tus datos, para tu caso de uso específico, por lo que es difícil de reutilizar y codificar en una biblioteca. Podemos decir que por esta razón, construir aplicaciones como estas es en realidad un problema de datos. Necesitas estructuras de datos eficientes para representar tus datos. Necesitas algoritmos eficientes para obtener la información que necesitas de las estructuras de datos. También necesitas una representación indexada de datos, como árboles binarios, para acelerar tus algoritmos. También necesitas transmisión para poder cargar datos de manera dinámica desde la web. Lo más importante es que debes preprocesar la mayor cantidad de datos posible para que, cuando se carguen, estén listos para ser renderizados en la máquina cliente sin necesidad de un procesamiento adicional.

Hemos visto los desafíos que implica construir aplicaciones gráficas 3D complejas en navegadores. Quiero mostrarles mi experiencia al respecto al discutir un escenario del mundo real de una aplicación gráfica 3D compleja.

Estoy trabajando en el motor de renderizado de un nuevo producto llamado Flux. Es un editor CAD colaborativo en línea basado en el navegador. Similar a Figma, pero enfocado en ingeniería electrónica y placas de circuito impreso.

En Flux, queremos poder manejar documentos de ingeniería muy complejos. Necesita renderizar escenas muy complicadas con muchos componentes. Cada componente consta de formas 2D y objetos 3D. Queremos que los usuarios puedan diseñar circuitos electrónicos complejos e incluso mostrarlos en 3D, manteniendo siempre una experiencia de usuario fluida.

Nuestra aplicación está construida con React, 3JS y React 3 Fiber. Comparado con Figma y Google Maps, Flux presenta sus propios desafíos. De hecho, queremos poder admitir documentos muy grandes con hasta 10,000 componentes electrónicos. Queremos que cada parte electrónica tenga muchas formas diferentes en su interior, como círculos, rectángulos, texto y modelos 3D. El documento completo tampoco se puede ver de una vez. Queremos que el usuario pueda hacer zoom y verlo todo sin que haya una disminución en el rendimiento. También queremos proporcionar, como se mencionó anteriormente, una vista 3D de su documento, no solo 2D, por lo que los trucos como el almacenamiento en caché de mosaicos no pueden funcionar. Y también queremos una selección en tiempo real para que las interacciones del mouse sean rápidas y ágiles. Todo esto debe poder ejecutarse a 60 cuadros por segundo, incluso en dispositivos móviles y hardware de gama baja.

Por lo tanto, cuando deseas superar desafíos como estos, es importante seguir una metodología de rendimiento. Quiero compartir con ustedes lo que he encontrado que son los puntos más importantes a seguir al escalar tu aplicación de React 3 Fiber. Y estos son los pasos que estamos siguiendo internamente para asegurarnos de que la aplicación se mantenga rápida. Intentamos limitar las representaciones de React 3 tanto como sea posible. Perfilar continuamente los tiempos de renderizado e interacción. Intentamos perfilar y reducir el uso de memoria tanto como sea posible. Utilizamos algoritmos eficientes y estructuras de datos para representar nuestros datos y para algunas tareas. Y por último, utilizamos mucha optimización de la GPU para aprovechar al máximo el hardware que tenemos a nuestra disposición. Las primeras cosas son las representaciones de Reactor. Como se describe en la documentación de React 3 Fiber, debes usar valores de transición, referencias y mutaciones imperativas en tu código que se ejecuta con frecuencia, lo cual a veces puede ser un poco engorroso, pero es la única forma de obtener una animación fluida sin pasar por las representaciones de Reactor. Incluso fuimos más allá de esta guía al optimizar nuestra solución de gestión de estado para usar almacenamiento por particiones y reducir el costo de las suscripciones.

Incluso si aplicas todas las optimizaciones a nivel de React, aún necesitas optimizar tu render loop. Utilizamos el concepto de presupuesto de cuadros. Esto significa que si deseas alcanzar 60 cuadros por segundo, tienes 15 milisegundos para renderizar toda tu escena. Por lo tanto, es crucial utilizar el perfilador de Chrome y ver qué está ocupando mucho tiempo en tu loop de cuadros y optimizar esas cosas primero. A veces, el resultado de esos perfiles puede ser inesperado. Descubrir que has introducido una llamada de función con demasiada complejidad en tu camino crítico.

Otra cosa que hacemos es el perfilado de memoria ya que mantener una huella de memoria baja es crucial cuando manejas grandes cantidades de datos. Utilizando el perfilador de Chrome, puedes tomar una instantánea de la memoria y ver qué está ocupando demasiado espacio. Utilizando este método, por ejemplo, pudimos notar cómo estábamos utilizando cientos de megabytes solo para almacenar UIDs basados en cadenas. Esto nos sugirió usar números en su lugar lo cual nos permitió ahorrar mucho espacio y hacer posible la carga de ciertos documentos.

Otra cosa que necesitas son algoritmos eficientes y estructuras de datos. Esto realmente ayuda, por ejemplo, a optimizar el raycasting que es el proceso de determinar qué objetos están presentes en tu escena en una posición dada. Esto es crucial para las interacciones del mouse ya que necesitas saber qué hay debajo del puntero del cursor. El enfoque ingenuo para este problema como también se implementa en React 3 Fiber es realizar una búsqueda lineal lo cual desafortunadamente puede ser muy costoso cuando tienes miles de objetos. Dado que esto es algo que debe ejecutarse en tiempo real, tener estructuras de datos más rápidas como R3 y BinaryTree realmente puede acelerar mucho tu aplicación.

Otra cosa de la que debes tener en cuenta son las optimizaciones de la GPU. Las GPUs son procesadores paralelos realmente potentes pero debes tener en cuenta el cuello de botella de la CPU y la GPU. De hecho, la comunicación entre la CPU y la GPU no es gratuita. Cada vez que le pides a la GPU que haga algo, también llamado draw call, hay cierta sobrecarga. Por esta razón, quieres mantener tus draw calls lo más bajos posible, especialmente en dispositivos móviles de gama baja. Esto significa que si deseas dibujar, por ejemplo, 10,000 instancias del mismo objeto, una y otra vez, hacerlo de la manera ingenua, utilizando un bucle for, puede ser muy ineficiente. Puedes ver que si queremos renderizar 10,000 instancias del mismo objeto, obtendremos un rendimiento bastante pobre alrededor de 33 FPS. Afortunadamente, hay una forma de optimizar eso y se llama instanced rendering. Con esta técnica, puedes dibujar varias instancias del mismo objeto con una sola llamada a la GPU, reduciendo en gran medida el cuello de botella. Esto puede generar grandes mejoras de rendimiento en algunos casos, como aquí, por ejemplo, donde anteriormente estábamos limitados a un promedio de 33 FPS. Lo interesante del instanced rendering es que es muy personalizable. Incluso si estás limitado a tener la misma geometría y material para cada instancia, puedes programar cómo la GPU está procesando cada vértice y píxel e incluso pasar parámetros personalizados para cada uno. Por ejemplo, puedes darle a cada instancia una posición o tamaño diferente y programar en la GPU cómo interpretar esos parámetros. El instanced rendering fue crucial en Flux para optimizar nuestro renderizado de texto aunque requirió una configuración especial. Verás, el renderizado de texto desafortunadamente no está provisto por WebGL y es algo que debes manejar con tu propia solución personalizada.

También es bastante complicado, ya que implica formas y geometría que pueden tener muchos triángulos y vértices, lo que puede resultar costoso de dibujar. Para Flux, necesitábamos una solución que pudiera escalar a miles de caracteres en pantalla manteniendo cada carácter como una forma extruida en 3D. Por esta razón, una solución simple en 2D basada en sprites no hubiera funcionado. Necesitábamos geometría en 3D real.

Para optimizar nuestro renderizado de texto, necesitábamos utilizar el renderizado de instancias. Pero como dijimos anteriormente, el renderizado de instancias solo funciona cuando quieres repetir la misma geometría múltiples veces, y obviamente este no es el caso si tienes diferentes caracteres. Sin embargo, también dijimos que podemos personalizar cómo se muestra cada instancia proporcionando parámetros personalizados que pueden codificar cosas como posición y tamaño. Entonces nos preguntamos, ¿y si representamos el texto deseado como un parámetro de instancia? Si eso fuera posible, podríamos codificar nuestra cadena para mostrar en un parámetro de instancia y hacer que la GPU se encargue de dibujar cada carácter por sí mismo.

En este punto, también necesitábamos pasar a la GPU los datos sobre la geometría de cada carácter como secuencias de puntos en 3D. Lo hicimos utilizando texturas. Normalmente, las texturas se utilizan para adjuntar imágenes a las superficies, pero dado que después de todo son una gran matriz de números también podemos usarlas para codificar posiciones en 3D para que la GPU las utilice para representar caracteres como estos. Podemos utilizar los valores RGB para codificar nuestras posiciones XYZ para que podamos codificar la geometría en una textura. El resultado final es algo como esto en el ejemplo aquí. Podemos mostrar 20,000 caracteres en 3D al mismo tiempo con una sola llamada de dibujo y animar cada uno de forma independiente manteniendo una velocidad de fotogramas constante. Puedes preguntar, ¿cómo se habría comportado esto sin esas optimizaciones? Lo probamos y incluso con una fracción de los caracteres en la pantalla, era dolorosamente lento, dejando casi sin potencia de procesamiento para otras cosas más interesantes. En este punto, ya puedo escuchar a alguien diciendo que tal vez también tienes mucho texto para renderizar Y para todos ustedes, acabamos de publicar en NPM nuestro motor de renderizado de texto en 3D y 2D que proporciona un alto rendimiento y eficiencia con una API compatible con React. Simplemente envuelve tu escena con un componente proveedor y utiliza el componente InstancedText donde quieras. Gracias por seguir mi charla. Espero que te haya dado una visión general de lo que significa construir una aplicación compleja de WebGL con una gran cantidad de datos en la actualidad, y espero que mi experiencia que describí sea útil para tus desarrollos en el futuro.