- Rive publie en open source son Rive Renderer développé en interne, rendant disponible sur toutes les plateformes une base de rendu unique adaptée aux contenus, animations et runtimes de Rive
- L’objectif du renderer est de conserver des animations à 120 fps et une qualité d’anti-aliasing élevée, même en dessinant beaucoup de graphismes vectoriels et de texte net
- Jusqu’ici, Rive dépendait de plusieurs renderers comme Skia et l’API HTML Canvas, ce qui rendait difficile le lancement d’une fonctionnalité sur l’ensemble des plateformes lorsqu’un backend ne la prenait pas en charge
- Grâce à un renderer unique, des effets comme blur, drop shadow, glow, tapered stroke peuvent être ajoutés de façon plus cohérente sur plusieurs runtimes
- L’implémentation réduit les chemins vectoriels anti-aliasés en patchs triangulaires et exploite le pipeline GPU de rastérisation parallèle des triangles ; elle peut être activée sur iOS, Android et le Web, et est déjà intégrée aux runtimes Unity et Unreal
Publication du Rive Renderer et contexte de sa création
- Rive Renderer est un renderer développé en interne pour les contenus, animations et runtimes de Rive
- Il vise des animations à 120 fps et une qualité d’anti-aliasing propre, même dans des situations où beaucoup de graphismes vectoriels et de texte sont affichés à l’écran
- Son développement interne a pris 2 ans, et permet à Rive de contrôler plus directement l’ensemble de l’expérience, depuis la création par les designers dans Rive Editor jusqu’au moment où les utilisateurs voient le résultat et interagissent avec lui dans le runtime
- Le système est optimisé pour ne générer intentionnellement que des contenus capables de s’exécuter rapidement dans le runtime, afin que les designers aient moins à se préoccuper de la mise en œuvre des performances et puissent se concentrer sur la création
Limites d’une architecture à plusieurs renderers et effets d’un renderer unique
- À ses débuts, Rive utilisait des solutions de rendu open source existantes comme Skia et l’API HTML Canvas
- L’architecture bring-your-own-renderer, qui permet aux utilisateurs de brancher facilement le renderer de leur choix, reste prise en charge
- Mais sans renderer maison cohérent et optimisé, la feuille de route produit et le développement de nouvelles fonctionnalités restaient inévitablement contraints par les limites propres à chaque plateforme
- Dans une architecture reposant sur plusieurs renderers, lorsqu’une fonctionnalité n’existe pas dans l’un d’eux, elle ne peut pas fonctionner sur tous les backends où Rive s’exécute, ce qui complique fortement son lancement
- Parmi les effets qu’un renderer unique permet d’ajouter plus facilement figurent blurs, drop shadows, glows, tapered strokes
Implémentation et prise en charge des plateformes
- Rive Renderer repose sur une approche géométrique qui réduit les chemins vectoriels anti-aliasés en patchs triangulaires uniques
- Elle exploite le pipeline de rastérisation de triangles massivement parallèle fourni nativement par les GPU desktop et mobiles
- Elle dessine les courbes de Bézier sur du matériel 3D via une méthode de triangulation spécifique
- L’usage de renderers tiers reste possible, mais Rive recommande Rive Renderer pour profiter des fonctionnalités propres à Rive et de l’expérience globale
- Sur iOS, Android et le Web, il est possible d’activer Rive Renderer en suivant le guide officiel
- Le code est publié sur GitHub, déjà intégré aux runtimes Unity et Unreal, et d’autres intégrations sont prévues
1 commentaires
Avis sur Hacker News
Je viens de passer par le stand GDC, et ça a vraiment l’air excellent comme outil pour permettre aux designers UI/UX de faire davantage directement dans le jeu
D’habitude, le designer travaille plusieurs jours dans Figma puis transmet au programmeur, qui répond qu’on ne peut pas l’implémenter pour telle ou telle raison, et les allers-retours continuent
C’est encore pire avec Unreal Engine, qui manque d’un bon framework UI adapté aux jeux AAA, mais le workflow de cet outil est le meilleur que j’aie vu jusqu’ici, et il semble s’intégrer naturellement à Unreal Engine et Blueprints
Personnellement, j’ai beaucoup d’espoir parce qu’on dirait que les designers UI/UX pourront travailler sans l’aide des programmeurs. En général, les programmeurs de jeux n’aiment pas le travail sur l’UI
On peut sans doute l’expliquer par la différence d’état d’esprit entre s’asseoir pour travailler et s’asseoir pour jouer
C’était presque la première fois que je me suis senti comme un vieux qui crie que les versions modernes sont vraiment nulles
Il y a beaucoup de recherche sur le rendu de graphiques vectoriels 2D via la tessellation GPU, donc voir une technologie dans la lignée des travaux de Raph Levien arriver dans un vrai produit, c’est assez impressionnant
Je n’ai jamais utilisé Rive, donc je me demande si c’est réservé à la création de belles animations ou si on peut aussi faire de l’UI dynamique du genre qu’on construirait avec une bibliothèque GUI en mode immédiat
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
J’ai créé des UI assez complexes avec Rive, mais je n’ai pas encore exploré la partie où l’on ajoute programmatiquement des éléments selon des événements externes ou où l’on modifie le texte de l’UI
J’ai l’impression qu’on a déjà fait cette expérience avec Flash. Macromedia/Adobe distribuait gratuitement le player et faisait payer les outils ; Rive semble aussi vouloir open sourcer le player tout en faisant payer l’éditeur
Rive vise toutefois quelque chose d’un peu différent, à savoir les développeurs de jeux qui utilisent d’autres plateformes comme Unity ou Unreal et veulent par exemple intégrer des éléments comme des cinématiques
Malgré tout, le fait d’avoir un player open source donne l’impression que Rive veut contrôler l’expérience de bout en bout, ce qui rappelle Flash
J’attendais cela depuis l’annonce. Avant, ils utilisaient Skia, et l’application entière comme la sortie de rendu étaient construites avec Flutter. Désormais, Flutter dispose d’un nouveau moteur de rendu, Impeller, mieux optimisé que Skia pour les problèmes spécifiques à Flutter
Quand j’avais demandé à l’équipe Impeller ce qu’elle pensait du renderer Rive, on m’avait répondu qu’il était excellent pour les graphiques vectoriels, mais qu’Impeller devait aussi traiter des problèmes de rendu liés à l’UI, comme l’affichage correct du texte, donc que ce n’était pas une comparaison un pour un
Maintenant que ce renderer est devenu open source, j’espère que les deux équipes pourront apprendre l’une de l’autre
J’aime le produit Rive et l’entreprise, et j’aime aussi l’open source, mais ici il s’agit de publier sous licence MIT la couche d’abstraction de rendu qui fait partie du runtime Rive, lequel suppose de créer le contenu avec Rive Editor
Je me demande quel est l’objectif de cette mise en open source, et quel type de communauté plus large ils veulent construire autour
Je me demande aussi quels autres projets pourraient bénéficier du simple fait d’adopter le renderer
Personnellement, ça m’intéresse aussi. J’utilise actuellement canvasAPI et pixi, et je bute souvent sur les limites du dessin 2D dans un budget de 16 ms par frame
[0] https://github.com/rive-app/rive-renderer
Cela a l’air vraiment génial, au point de me donner envie de l’utiliser pour un projet perso.
Il semble proposer une API Cairo/Skia/canvas/NanoVG assez standardisée, avec des choses comme
moveToetlineTo, donc j’espère que la prise en main ne demandera pas trop d’efforts.Au moins, on y voit bien
lineToici : https://github.com/rive-app/rive-renderer/blob/main/renderer...Je me demande comment ses performances de rendu se comparent à Skia ou Pathfinder. Pathfinder peut aussi effectuer sur le GPU, via compute, l’étape de conversion des tracés en triangles quand le matériel le permet.
Pour une approche plus globale du rendu 2D basé sur compute, il y a aussi Vello.
À première vue, les performances semblent dépendre fortement du matériel, en particulier de la prise en charge de pixel local storage. D’après ce que j’ai vu jusqu’ici, Apple Silicon est le cas idéal. Le matériel y prend en charge le binning et le tri par tuiles, et la sérialisation de l’exécution des fragment shaders à l’intérieur d’une tuile fonctionne bien.
Sur d’autres matériels, je m’attends à ce que le coût d’une telle sérialisation soit bien plus élevé.
L’une des raisons pour lesquelles il n’y a pas encore eu de benchmark approfondi côté Vello, c’est que l’histoire des performances n’est pas encore complètement stabilisée. Il y a actuellement un problème de collecte des boîtes englobantes avec les opérations atomiques du device, et une implémentation prototype[2] utilisant un monoïde pour la réduction des segments montre des améliorations assez nettes.
Il est aussi prévu d’ajouter des opérations en f16, ce qui pourrait apporter un gros gain, surtout sur mobile. Pour plusieurs étapes de prefix sum, l’idée est d’utiliser des sous-groupes, et les sous-groupes sont en cours d’intégration dans WebGPU[3].
Globalement, je suis content de voir ce renderer publié en open source, et ravi de voir autant d’activité autour du rendu vectoriel GPU rapide. J’aimerais voir arriver un futur où le rendu de tracés sur CPU sera considéré comme dépassé, et cette publication nous en rapproche.
[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
Cela ressemble à des choix techniques solides faits par des gens qui savent ce qu’ils font, et cela vaut clairement la peine d’aller vérifier soi-même la qualité et les performances.
Ces renderers orientés GPU ont tous des approches un peu différentes, et il est très probable que chacun excelle dans une zone particulière d’un espace multidimensionnel mêlant qualité, performances, prise en charge matériel/pilotes et difficulté d’intégration. Si l’un des quatre ne vous convient pas sur un point, cela vaut la peine d’examiner aussi les autres.
Personnellement, je suis vraiment ravi.
Depuis environ six mois, je pousse mes clients — de sociétés de santé avec une simple appli mobile à des studios et produits de jeu bien plus poussés — à adopter Rive plutôt que Lottie et d’autres anciennes solutions. À mes yeux, c’est enfin sur de bons rails et prêt pour une adoption réelle.
Dans ces discussions, la dernière inquiétude potentielle qui restait était que le renderer le plus récent était fermé et pas encore dans sa forme finale.
Avec cette décision et le travail général de l’équipe Rive, je m’attends à ce que ce domaine continue de progresser. Des fonctionnalités comme les ombres et le flou seraient aussi très intéressantes une fois disponibles.
Lottie est déjà assez bien établi comme format de fichier, le workflow est bien en place et c’est relativement simple.
Je me demande ce que Rive fait tellement mieux pour qu’il vaille la peine d’être poussé à ce point.
Dépôt : https://github.com/rive-app/rive-renderer
En lien : https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
Il semble qu’il n’existe pas de solution définitive à ce problème, et que l’on continue simplement à créer des logiciels qui tentent de le résoudre.
Ce qui est un peu étrange, c’est que, si l’on dispose d’une fonction d’échantillonnage des pixels et d’une métrique d’espace colorimétrique, il n’existe qu’un seul rendu objectivement correct pour n’importe quelle scène en graphisme vectoriel. La valeur de chaque pixel de sortie devrait être la couleur représentable la plus proche de la convolution de cette fonction avec la scène, et la scène peut être exprimée comme une fonction de R^2 vers R, les couleurs pouvant être représentées dans un système colorimétrique linéaire.
Cela semble réalisable avec du calcul GPU, ainsi qu’une bonne maîtrise des bornes d’erreur lors de la tessellation des courbes ou du calcul numérique des intégrales symboliques exactes des courbes.
Une telle solution semblerait aussi facile à concevoir de façon à permettre d’ajuster le niveau d’approximation pour accélérer le rendu.
S’il existait simplement un ordinateur parallèle correct, ce ne serait pas si difficile, mais en pratique il faut adapter la logique de rendu à une combinaison précise de bricolages pris en charge par l’infrastructure GPU, chacun ayant ses contraintes et ses compromis très particuliers.
Vous aimerez sans doute le prochain article sur l’expansion de traits compatible GPU. L’idée centrale consiste précisément à traiter l’intégrale symbolique exacte d’une certaine mesure de courbure des courbes à l’aide de méthodes numériques avec bornes d’erreur.
Si cela vous intéresse, on peut déjà le voir dans le code
shader/flatten.wgslde la branche principale de Vello.