Rive Renderer para gráficos vectoriales en tiempo real pasa a ser open source

 (rive.app)
2 puntos por GN⁺ 2024-03-21 | 1 comentarios | Compartir por WhatsApp
  • Rive publicó como open source su Rive Renderer, lo que permite usar una única base de renderizado en todas las plataformas, adaptada al contenido, las animaciones y los runtimes de Rive
  • El objetivo del renderizador es mantener animaciones a 120fps y una alta calidad de antialiasing incluso al dibujar muchos gráficos vectoriales y texto nítido
  • Antes dependía de varios renderizadores, como Skia y la API de HTML Canvas, por lo que si una función no existía en un backend era difícil lanzarla en todas las plataformas
  • Gracias a un renderizador único, se pueden agregar de forma más consistente en varios runtimes efectos como blur, drop shadow, glow y tapered stroke
  • La implementación reduce rutas vectoriales con antialiasing a parches triangulares y aprovecha el pipeline paralelo de rasterización de triángulos de la GPU; puede activarse en iOS, Android y Web, y ya está integrado en los runtimes de Unity y Unreal

Lanzamiento de Rive Renderer y contexto de su desarrollo

  • Rive Renderer es un renderizador creado por Rive para su contenido, animaciones y runtimes
  • Apunta a ofrecer animaciones de 120fps y una calidad de antialiasing limpia incluso en situaciones donde se dibujan muchos gráficos vectoriales y texto en pantalla
  • Su desarrollo interno tomó 2 años, y ahora Rive puede controlar de forma más directa toda la experiencia, desde el momento en que los diseñadores crean algo en Rive Editor hasta cuando los usuarios lo ven e interactúan con ello en el runtime
  • Se optimizó para generar intencionalmente contenido que funcione rápido en el runtime, de modo que los diseñadores puedan concentrarse más en crear y menos en cómo implementar el rendimiento

Límites de una arquitectura con varios renderizadores y efecto de un renderizador único

  • En sus inicios, Rive usaba soluciones de renderizado open source ya existentes, como Skia y la API de HTML Canvas
  • La arquitectura bring-your-own-renderer, que permite a los usuarios conectar fácilmente el renderizador que prefieran, se seguirá soportando
  • Pero sin un renderizador propio consistente y optimizado, la hoja de ruta del producto y el desarrollo de nuevas funciones inevitablemente quedaban atados a las restricciones de cada plataforma
  • En una estructura con varios renderizadores, si una función faltaba en uno de ellos, no podía funcionar en todos los backends donde corre Rive, por lo que era difícil lanzar esa función
  • Entre los efectos que se vuelven más fáciles de añadir con un renderizador único están blurs, drop shadows, glows y tapered strokes

Forma de implementación y soporte de plataformas

  • Rive Renderer se basa en un enfoque geométrico que reduce rutas vectoriales con antialiasing a parches triangulares únicos
    • Aprovecha el pipeline masivamente paralelo de rasterización de triángulos presente de forma nativa en las GPU de escritorio y móviles
    • Usa hardware 3D para dibujar curvas Bézier mediante un método específico de triangulación
  • Seguirá siendo posible usar renderizadores de terceros, pero para las funciones propias de Rive y la experiencia general se recomienda usar Rive Renderer
  • En iOS, Android y Web se puede activar Rive Renderer siguiendo la guía oficial
  • El código está publicado en GitHub; ya está integrado en los runtimes de Unity y Unreal, y hay más integraciones previstas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-21
Opiniones en Hacker News

  • Acabo de estar en el stand de GDC y, como programa para permitir que los diseñadores de UI/UX hagan más cosas directamente en los juegos, se veía realmente bueno.
    Normalmente, un diseñador trabaja varios días en Figma y luego se lo pasa a un programador, quien responde que no se puede implementar por tal o cual razón, y así empieza un ida y vuelta.
    Esto se agrava porque Unreal Engine carece de un buen framework de UI adecuado para juegos AAA, pero el flujo de trabajo de esta herramienta es el mejor que he visto hasta ahora y parece integrarse de forma natural con Unreal Engine y Blueprints.
    Personalmente, me entusiasma porque parece que los diseñadores de UI/UX podrán trabajar sin ayuda de programadores. Además, en general a los programadores de juegos no les gusta trabajar en UI.

    • Si fuera diseñador de UI/UX, creo que me habría gustado trabajar en juegos. El software de productividad ya tiene muchos paradigmas y abstracciones profundamente arraigados, así que cuando intentas cambiarlos los usuarios se quejan; en los juegos, en cambio, las nuevas decisiones de UI/UX a menudo se reciben con curiosidad más que con molestia.
      Parece que esto se puede explicar por la diferencia de mentalidad entre sentarse a trabajar y sentarse a jugar.
    • Estoy de acuerdo en que el traspaso entre diseño y programación es tedioso, pero me da curiosidad saber en qué consideran que UMG se queda corto. Después de acostumbrarme, implementar UI me resultó bastante divertido.
    • Es una lástima que la UI/UX de Unreal Engine se haya vuelto tan mala últimamente. Hace poco jugué UT99 con unos amigos y me sorprendió de nuevo lo potente, intuitiva y flexible que era la UI dentro del juego, desde la configuración hasta el menú del navegador de servidores.
      Fue casi la primera vez que me sentí como un viejo gritando que la versión moderna es pésima.

  • Hay mucha investigación activa sobre renderizar gráficos vectoriales 2D mediante teselación en GPU, y es bastante genial ver que una tecnología en la línea del trabajo de Raph Levien llegue a un producto real.
    Nunca he usado Rive, así que me pregunto si sirve solo para crear animaciones vistosas o si también permite hacer UI dinámicas como las que uno construiría con una biblioteca GUI de modo inmediato.

  • Me parece que este experimento ya se hizo con Flash. Macromedia/Adobe liberaba el reproductor gratis y cobraba por las herramientas, y Rive parece querer publicar el reproductor como open source y cobrar por el editor.
    Rive es un poco distinto porque parece apuntar a desarrolladores de juegos que usan otras plataformas como Unity o Unreal, por ejemplo quienes quieren embeber cosas como cinemáticas.
    Aun así, que exista un reproductor open source sugiere que Rive quiere controlar toda la experiencia, lo que me recuerda a Flash.

    • Flash era excelente. Hace mucho que hacía falta construir un Flash mejor, y Rive parece un buen intento de crear un nuevo Flash.
    • Buena comparación, y también es importante que esto sea solo el renderer. Es bueno que se haya publicado bajo licencia MIT, pero me pregunto cuántas herramientas open source habrá para crear contenido compatible y qué tan fácil será crear exportadores desde otros formatos de herramientas existentes.
    • Me hace pensar cuánto mejor podría haber sido Flash si el reproductor y el formato de archivo hubieran sido abiertos, y las herramientas de terceros no hubieran tenido que recurrir a ingeniería inversa.
    • Antes existía Scaleform, y parece haber sido discontinuado junto con Flash: https://en.wikipedia.org/wiki/Scaleform_GFx

  • Lo he estado esperando desde que lo anunciaron. Antes usaban Skia, y toda la app y la salida de renderizado estaban hechas con Flutter. Ahora Flutter tiene un nuevo motor de renderizado, Impeller, más optimizado que Skia para problemas específicos de Flutter.
    Cuando antes le pregunté al equipo de Impeller cómo veían el renderer de Rive, dijeron que es excelente para gráficos vectoriales, pero que Impeller también debe lidiar con problemas de renderizado relacionados con UI, como mostrar texto correctamente, así que no son una comparación uno a uno.
    Ahora que este renderer es open source, espero que ambos equipos puedan aprender el uno del otro.

    • Corríjanme si me equivoco. ¿Las fuentes no se renderizan ya como gráficos vectoriales? ¿TTF y OTF no son formatos vectoriales?

  • Me gustan el producto y la empresa Rive, y también me gusta el open source, pero esto es publicar bajo licencia MIT una capa de abstracción de renderizado que forma parte del runtime de Rive, para el cual hay que crear contenido con Rive Editor.
    Me pregunto cuál es el objetivo de abrirlo como open source y qué comunidad más grande quieren construir alrededor.
    También me pregunto si se les ocurre algún otro proyecto que pudiera beneficiarse de adoptar solo el renderer.

    • Parece que quieren seguir ganando dinero con el editor propietario, mientras ofrecen un renderer open source para facilitar la distribución y la creación de ecosistema. Si logran que otros apunten a este renderer, cuanto mejor sea el renderer, más les conviene.
      A mí personalmente también me interesa. Actualmente uso canvasAPI y pixi, y a menudo me topo con los límites del dibujo 2D dentro de un presupuesto de 16 ms por frame.
    • Según GitHub, este repositorio incluye el código del renderer y ejemplos que muestran cómo interactuar directamente con él.
      [0] https://github.com/rive-app/rive-renderer
    • No hace falta necesariamente un editor especial para crear gráficos vectoriales. Muchos proyectos, desde juegos hasta toolkits de UI, necesitan un renderer de gráficos vectoriales, y por eso existen bibliotecas como Skia, Cairo y ahora Rive.
    • Parece una estrategia inteligente para “no convertirse en Macromedia Flash”.

  • Se ve tan genial que me dan ganas de usarlo en un proyecto personal de hobby
    Parece que ofrece una API Cairo/Skia/canvas/NanoVG más o menos estandarizada, con cosas como moveTo y lineTo, así que espero que no requiera demasiado esfuerzo aprenderla
    Al menos aquí se ve lineTo: https://github.com/rive-app/rive-renderer/blob/main/renderer...

  • Me da curiosidad cómo se compara este rendimiento de renderizado con Skia o Pathfinder. Pathfinder, si el hardware lo soporta, también puede procesar en cómputo GPU la etapa de convertir rutas en triángulos
    Como enfoque más integral de renderizado 2D basado en cómputo, también está Vello

    • Me gustaría hacer benchmarks cuidadosos. Este renderer parece lo suficientemente competitivo, pero hacer benchmarks es realmente difícil si se quieren obtener resultados significativos
      Mi impresión inicial es que el rendimiento dependerá mucho del hardware, en particular del soporte de pixel local storage. Por lo que he visto hasta ahora, Apple Silicon es el punto ideal. El hardware soporta binning y ordenamiento por tiles, y funciona bien incluso serializando la ejecución del fragment shader dentro de un tile
      En otro hardware, esperaría que el costo de serializar esas llamadas sea mucho mayor
      Una de las razones por las que en Vello todavía no hemos hecho benchmarks profundos es que la historia de rendimiento aún no está completa. Actualmente hay un problema al recolectar bounding boxes con operaciones atómicas de dispositivo, y una implementación prototipo[2] que usa monoides para la reducción de segmentos muestra resultados bastante mejorados
      Además, tenemos planeado usar operaciones f16, lo que podría dar grandes beneficios, especialmente en móviles. Para varias etapas de sumas acumuladas planeamos usar subgrupos, y los subgrupos están entrando en WebGPU[3]
      En general, me alegra que este renderer se haya publicado como open source, y también me alegra ver más actividad en renderizado rápido de gráficos vectoriales en GPU. Me gustaría ver algún día un futuro en el que el renderizado de rutas en CPU se considere anticuado, y esta publicación nos acerca más en esa dirección
      [1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...
      [2]: https://github.com/linebender/vello/issues/259
      [3]: https://github.com/gpuweb/gpuweb/issues/4306
    • Viendo la tecnología GPU usada y los nombres de los committers del repositorio, estoy bastante seguro de que puede competir al menos tanto con Skia como con Pathfinder. No sé bien respecto de Vello
      Parecen decisiones técnicas sólidas, elegidas por gente que sabe lo que hace, y sin duda vale la pena comprobar directamente su rendimiento y calidad
      Estos renderers con enfoque GPU-first tienen abordajes ligeramente distintos, y es muy probable que cada uno tenga áreas donde sea el mejor dentro de un espacio multidimensional de calidad, rendimiento, soporte de hardware/drivers y dificultad de integración. Si uno de los cuatro no te convence, vale la pena revisar los demás
    • Hay que hacer benchmarks nuevos. Desde las pruebas iniciales, Rive Renderer se volvió más rápido: https://twitter.com/guidorosso/status/1595187838454140928
    • Al menos una de las implementaciones de runtime que revisé estaba implementada sobre Skia. Parece soportar varios backends posibles

  • Personalmente, me alegra muchísimo
    Durante unos 6 meses estuve impulsando la adopción de Rive en lugar de Lottie y soluciones anteriores con varios clientes, desde empresas de salud con apps móviles nativas hasta empresas y productos muy metidos en juegos. Ahora por fin creo que está encaminado y en estado de “listo para adoptar”
    En esas conversaciones, lo último que quedaba como posible preocupación era que el renderer más reciente estaba cerrado y todavía no tenía su forma final
    Con esta decisión y el trabajo general del equipo de Rive, espero que este espacio de problemas siga mejorando. Funciones como sombras y blur también serán muy interesantes cuando se lancen

    • Quizá sea una pregunta básica, pero ¿por qué Rive?
      Lottie ya se está consolidando bastante como formato de archivo, tiene flujos de trabajo bien establecidos y es relativamente simple
      Me da curiosidad qué hace Rive mucho mejor como para justificar impulsarlo con tanta fuerza

  • Repositorio: https://github.com/rive-app/rive-renderer

  • Este problema parece seguir generando software que intenta resolverlo, sin que exista una solución definitiva.
    La razón por la que resulta un poco extraño es que, si se tienen una función de muestreo de píxeles y una métrica de espacio de color, existe un renderizado objetivamente correcto para cualquier escena de gráficos vectoriales. Cada valor de píxel de salida debería ser el color representable más cercano a la convolución de esa función con la escena, y la escena puede representarse como una función de R^2 a R, mientras que el color puede expresarse en un sistema de color lineal.
    Parece alcanzable si se manejan bien el cómputo en GPU y los límites de error al calcular numéricamente la teselación de curvas o la integración simbólica exacta de curvas.
    Además, una solución así también parece fácil de adaptar para ajustar el nivel de aproximación y lograr un renderizado más rápido.

    • Creo que es correcto. El renderizado 2D está bastante bien definido. El problema es la abrumadora complejidad del ecosistema GPU.
      Si solo tuviéramos una computadora paralela decente, no sería tan difícil, pero en la práctica hay que adaptar la lógica de renderizado a combinaciones específicas de montones de hacks que soporta la infraestructura GPU, y cada una tiene restricciones y compromisos muy particulares.
      Creo que te va a gustar un próximo paper sobre expansión de trazos amigable con GPU. El punto central es precisamente tratar la integración simbólica exacta de cierta métrica de curvatura de una curva mediante métodos numéricos con límites de error.
      Si tienes curiosidad, ya puedes verlo en el código shader/flatten.wgsl de la rama main de Vello.
    • Entonces parece que habría que escribir directamente una biblioteca de gráficos vectoriales