- Rive hat seinen selbst entwickelten Rive Renderer als Open Source veröffentlicht und stellt damit eine einheitliche Rendering-Basis bereit, die auf allen Plattformen für Rive-Inhalte, Animationen und Runtimes genutzt werden kann
- Ziel des Renderers ist es, auch bei vielen Vektorgrafiken und scharfem Text Animationen mit 120 fps sowie hohe Anti-Aliasing-Qualität beizubehalten
- Bisher war Rive auf mehrere Renderer wie Skia und die HTML Canvas API angewiesen; Funktionen, die in einem Backend fehlten, ließen sich dadurch nur schwer auf allen Plattformen veröffentlichen
- Dank eines einheitlichen Renderers lassen sich Effekte wie blur, drop shadow, glow, tapered stroke konsistenter über mehrere Runtimes hinweg hinzufügen
- Die Implementierung reduziert anti-aliased Vektorpfade auf Dreiecks-Patches und nutzt die parallele Dreiecks-Rasterisierungs-Pipeline der GPU; sie kann auf iOS, Android und Web aktiviert werden und ist bereits in die Unity- und Unreal-Runtimes integriert
Veröffentlichung des Rive Renderers und Hintergründe der Entwicklung
- Der Rive Renderer ist ein intern entwickelter Renderer für Rive-Inhalte, Animationen und Runtimes
- Auch in Situationen, in denen viele Vektorgrafiken und Text auf dem Bildschirm gezeichnet werden, zielt er auf Animationen mit 120 fps und saubere Anti-Aliasing-Qualität ab
- Die interne Entwicklung dauerte 2 Jahre und ermöglicht Rive eine direktere Kontrolle über die gesamte Experience – vom Moment, in dem Designer im Rive Editor etwas erstellen, bis zu dem Moment, in dem Nutzer es in der Runtime sehen und damit interagieren
- Durch Optimierungen sollen gezielt nur Inhalte erzeugt werden, die in der Runtime schnell laufen, sodass Designer sich weniger um die Performance-Implementierung kümmern müssen und sich stärker auf die Erstellung konzentrieren können
Grenzen einer Struktur mit mehreren Renderern und Wirkung eines einheitlichen Renderers
- In der Anfangszeit nutzte Rive bestehende Open-Source-Rendering-Lösungen wie Skia und die HTML Canvas API
- Die Bring-your-own-renderer-Struktur, mit der Nutzer den gewünschten Renderer leicht anbinden können, wird weiterhin unterstützt
- Ohne einen konsistenten und optimierten eigenen Renderer waren Produkt-Roadmap und Entwicklung neuer Funktionen jedoch zwangsläufig an plattformspezifische Einschränkungen gebunden
- In einer Struktur mit mehreren Renderern funktioniert eine bestimmte Funktion, wenn sie in einem Renderer fehlt, nicht auf allen Backends, auf denen Rive läuft; dadurch war es schwierig, solche Funktionen zu veröffentlichen
- Zu den Effekten, die sich mit einem einheitlichen Renderer leichter hinzufügen lassen, gehören blurs, drop shadows, glows, tapered strokes
Implementierung und Plattformunterstützung
- Der Rive Renderer basiert auf einem geometrischen Ansatz, der anti-aliased Vektorpfade auf eigene Dreiecks-Patches reduziert
- Er nutzt die massiv parallele Dreiecks-Rasterisierungs-Pipeline, die in Desktop- und Mobil-GPUs standardmäßig vorhanden ist
- Mit einer bestimmten Triangulierungsmethode werden Bézier-Kurven über 3D-Hardware gezeichnet
- Die Nutzung von Drittanbieter-Renderern bleibt weiterhin möglich, für Rive-spezifische Funktionen und die Gesamterfahrung wird jedoch der Rive Renderer empfohlen
- Auf iOS, Android und Web kann der Rive Renderer gemäß der offiziellen Anleitung aktiviert werden
- Der Code ist auf GitHub veröffentlicht, ist in die Unity- und Unreal-Runtimes integriert, und weitere Integrationen sind geplant
1 Kommentare
Hacker-News-Kommentare
Ich war gerade am GDC-Stand, und es sah wirklich nach einem großartigen Programm aus, mit dem UI/UX-Designer in Spielen mehr direkt selbst erledigen können.
Normalerweise arbeitet ein Designer ein paar Tage in Figma, übergibt es dann an einen Programmierer, und der antwortet aus verschiedenen Gründen, dass es nicht umsetzbar sei – dann geht das Hin und Her los.
Bei Unreal Engine ist das noch schlimmer, weil es an einem guten UI-Framework für AAA-Spiele mangelt. Der Workflow dieses Tools ist der beste, den ich bisher gesehen habe, und es scheint sich natürlich in Unreal Engine und Blueprints einzufügen.
Persönlich bin ich sehr gespannt, weil es so aussieht, als könnten UI/UX-Designer ohne Hilfe von Programmierern arbeiten. Spieleprogrammierer hassen UI-Arbeit im Allgemeinen ohnehin.
Das lässt sich wohl mit der unterschiedlichen Geisteshaltung erklären, wenn man sich hinsetzt, um zu arbeiten, oder wenn man sich hinsetzt, um zu spielen.
Das war einer der ersten Momente, in denen ich mich wie ein alter Mann fühlte, der schreit, dass die moderne Version völlig miserabel sei.
Es gibt viel aktive Forschung zum Rendern von 2D-Vektorgrafik per GPU-Tessellation, und es ist ziemlich cool, dass eine Technologie in der Linie von Arbeiten wie denen von Raph Levien als echtes Produkt herauskommt.
Ich habe Rive nie benutzt, daher frage ich mich, ob es nur für die Erstellung schicker Animationen gedacht ist oder ob man damit auch dynamische UIs bauen kann, wie man sie aus einer Immediate-Mode-GUI-Bibliothek erwarten würde.
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
Ich habe mit Rive ziemlich komplexe UIs gebaut, aber den Bereich, Elemente programmatisch je nach externen Events hinzuzufügen oder UI-Text zu ändern, habe ich noch nicht erkundet.
Ich habe das Gefühl, dass dieses Experiment schon mit Flash durchgeführt wurde. Macromedia/Adobe haben den Player kostenlos verteilt und für die Tools Geld verlangt; Rive scheint ebenfalls den Player als Open Source zu veröffentlichen und für den Editor Geld verlangen zu wollen.
Rive ist etwas anders, weil es offenbar auf Spieleentwickler abzielt, die andere Plattformen wie Unity oder Unreal verwenden, etwa um Dinge wie Cinematics einzubetten.
Trotzdem erinnert es an Flash: Ein Open-Source-Player bedeutet, dass Rive die gesamte Experience kontrollieren will.
Darauf habe ich seit der Ankündigung gewartet. Früher wurde Skia verwendet, und die gesamte App sowie die Rendering-Ausgabe waren mit Flutter gebaut. Inzwischen hat Flutter mit Impeller eine neue Rendering-Engine, die stärker auf Flutter-spezifische Probleme optimiert ist als Skia.
Als ich früher das Impeller-Team fragte, wie sie den Rive-Renderer sehen, sagten sie, er sei hervorragend für Vektorgrafik, aber Impeller müsse auch UI-bezogene Rendering-Probleme behandeln, etwa Text korrekt darzustellen, weshalb es kein Eins-zu-eins-Vergleich sei.
Da dieser Renderer nun Open Source ist, hoffe ich, dass beide Teams voneinander lernen können.
Ich mag das Rive-Produkt und das Unternehmen, und ich mag auch Open Source, aber hier wurde eine Rendering-Abstraktionsschicht unter MIT-Lizenz veröffentlicht, die Teil der Rive-Runtime ist und Inhalte voraussetzt, die mit dem Rive Editor erstellt werden.
Ich frage mich, was das Ziel der Open-Source-Veröffentlichung ist und welche größere Community man darum herum aufbauen möchte.
Außerdem frage ich mich, ob mir andere Projekte einfallen, die davon profitieren könnten, nur den Renderer zu übernehmen.
Mich interessiert das auch persönlich. Derzeit nutze ich canvasAPI und pixi, stoße aber innerhalb des 16-ms-Frame-Budgets häufig an Grenzen beim 2D-Zeichnen.
[0] https://github.com/rive-app/rive-renderer
Sieht wirklich so gut aus, dass ich es gern für ein privates Hobbyprojekt ausprobieren würde.
Es scheint eine einigermaßen standardisierte Cairo/Skia/canvas/NanoVG-API mit Dingen wie moveTo und lineTo zu geben, daher hoffe ich, dass das Lernen nicht allzu aufwendig wird.
Zumindest ist hier lineTo zu sehen: https://github.com/rive-app/rive-renderer/blob/main/renderer...
Ich frage mich, wie diese Rendering-Performance im Vergleich zu Skia oder Pathfinder aussieht. Pathfinder kann, wenn die Hardware es unterstützt, auch den Schritt, der Pfade in Dreiecke umwandelt, per GPU-Compute erledigen.
Als umfassenderer Compute-basierter Ansatz für 2D-Rendering gibt es außerdem Vello.
Nach erster Einschätzung dürfte die Performance stark von der Hardware abhängen, insbesondere von der Unterstützung für pixel local storage. Nach allem, was ich bisher gesehen habe, ist Apple Silicon der Sweet Spot. Die Hardware unterstützt Binning und Sortierung pro Tile, und selbst eine Serialisierung der Fragment-Shader-Ausführung innerhalb eines Tiles funktioniert gut.
Auf anderer Hardware erwarte ich, dass die Kosten für eine solche Serialisierung der Aufrufe deutlich höher ausfallen.
Einer der Gründe, warum wir bei Vello noch kein tiefgehendes Benchmarking gemacht haben, ist, dass die Performance-Geschichte noch nicht abgeschlossen ist. Derzeit gibt es ein Problem damit, Bounding Boxes über atomare Operationen auf dem Gerät zu sammeln, und eine Prototyp-Implementierung[2], die Monoide zur Segment-Reduktion verwendet, zeigt deutlich bessere Ergebnisse.
Außerdem sind f16-Operationen geplant, was besonders auf Mobilgeräten große Vorteile bringen könnte. Für mehrere Präfixsummen-Schritte sind Subgroups vorgesehen; Subgroups werden gerade in WebGPU aufgenommen[3].
Insgesamt freue ich mich, dass dieser Renderer als Open Source veröffentlicht wurde, und auch darüber, dass es mehr Aktivität rund um schnelles GPU-Vektorgrafik-Rendering gibt. Ich würde gern irgendwann eine Zukunft sehen, in der CPU-Pfad-Rendering als überholt gilt, und diese Veröffentlichung bringt uns diesem Ziel näher.
[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
Es wirkt wie eine solide Technologiewahl von Leuten, die wissen, was sie tun, und es lohnt sich definitiv, Performance und Qualität selbst zu prüfen.
Diese GPU-first-Renderer verfolgen jeweils etwas andere Ansätze, und wahrscheinlich hat jeder von ihnen in dem mehrdimensionalen Raum aus Qualität, Performance, Hardware-/Treiberunterstützung und Integrationsaufwand seinen eigenen Bereich, in dem er am besten ist. Wenn einem einer der vier Punkte nicht gefällt, lohnt es sich, auch die anderen anzusehen.
Persönlich freut mich das sehr.
In den vergangenen etwa sechs Monaten habe ich bei mehreren Kunden, von Healthcare-Unternehmen mit nativen Mobile-Apps bis hin zu stark auf Games ausgerichteten Firmen und Produkten, die Einführung von Rive anstelle von Lottie und älteren Lösungen vorangetrieben. Inzwischen sehe ich es endlich auf Kurs und als „bereit für die Einführung“.
In diesen Diskussionen war der letzte verbliebene potenzielle Vorbehalt, dass der neueste Renderer geschlossen und noch nicht in seiner finalen Form war.
Dank dieser Entscheidung und der allgemeinen Arbeit des Rive-Teams bin ich zuversichtlich, dass sich dieser Problembereich weiter verbessern wird. Funktionen wie Schatten und Blur werden sehr spannend, wenn sie erscheinen.
Lottie ist als Dateiformat schon ziemlich etabliert, die Workflows sind gut eingespielt und es ist vergleichsweise einfach.
Ich frage mich, was Rive so viel besser macht, dass man es unbedingt vorantreiben sollte.
Repository: https://github.com/rive-app/rive-renderer
Relevant: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
Dieses Problem scheint keine endgültige Lösung zu haben; stattdessen entsteht immer weiter Software, die es zu lösen versucht.
Etwas merkwürdig ist das, weil es für jede Vektorgrafikszene ein objektiv korrektes Rendering gibt, sobald eine Pixel-Sampling-Funktion und eine Farbraum-Metrik gegeben sind. Jeder Ausgabepixelwert sollte die nächstliegende darstellbare Farbe zur Faltung dieser Funktion mit der Szene sein, und die Szene lässt sich als Funktion von R^2 nach R darstellen, Farben in einem linearen Farbsystem.
Mit GPU-Compute und einem guten Umgang mit Fehlergrenzen bei der Kurven-Tessellation oder bei der numerischen Berechnung exakter symbolischer Integrale von Kurven scheint das erreichbar zu sein.
Außerdem scheint es bei einer solchen Lösung einfach zu sein, den Näherungsgrad für schnelleres Rendering anpassen zu können.
Hätten wir einfach nur einen brauchbaren Parallelrechner, wäre es wohl nicht so schwierig; tatsächlich muss man die Rendering-Logik aber an eine bestimmte Kombination aus Hacks anpassen, die die GPU-Infrastruktur unterstützt, und jeder davon hat sehr eigene Einschränkungen und Trade-offs.
Das demnächst erscheinende Paper zu GPU-freundlicher Stroke-Expansion dürfte dir gefallen. Im Kern geht es genau darum, exakte symbolische Integrale für bestimmte Krümmungsmaße von Kurven mit numerischen Methoden samt Fehlergrenzen zu behandeln.
Wenn du neugierig bist, kannst du das schon jetzt im Code
shader/flatten.wgslauf dem main-Branch von Vello sehen.