Rive Renderer for real-time vector graphics is now open source
rive.app
rive.app
Truthfully the program they have looks fantastic at empowering UI/UX designers to do more with games.
I'm not sure if everyone is aware, but the normal flow is that a UI/UX designer will spend days in Figma; give the output to a programmer and the programmer will (often) say that it's impossible to implement for X,Y reason.
What follows is a back and forth between the programmer and the designer until eventually a design exists that can be implemented.
This is compounded by the fact that there's no good UI framework in Unreal engine, at least not for AAA games.
So, while I have not done a feasibility test yet, the workflow of this tool is definitely the best I've seen and seems to integrate seamlessly with Unreal Engine and blueprints.
I'm personally really excited, because with this it's possible for a UI/UX designer to work without the aid of a programmer.
(also, game programmers tend to hate doing UI).
Games are great for user experience, because gamers are, by definition, looking for an experience. They aren't there to get work done, they want to have fun. So a fun interaction paradigm, with creative visuals, sound effects, various game-related skeuomorphisms: all of that is what they want.
User interaction, on the other hand, is about keeping the software from standing between the user and what the user wants to do. A large part of this job is insisting that developers don't do surprising things, but rather, stay within the lanes of expected interactions for the platform. There's room for creativity and novelty, but the budget for those must be spent carefully.
I've never used Rive so I'm wondering if its strictly for making cool animations or if it can be used for building dynamic UI's (the kind that you might use an immediate mode gui lib for)?
Incidentally, I recently opened a PR to add Metal to Godot via https://github.com/godotengine/godot/pull/88199
While I've built some fairly complex UI with Rive, one area I haven't explored is programmatically adding elements or say changing UI text based on external events.
It's not really my area, but best of luck to you!
I know Adobe renamed Flash, and I haven't talked to anyone in the cartoons space since then, but it seems like innovation/attention to the Flash toolchain died with the player.
If the goal is to render vectors I imagine it is more complicated due to quirks in how Macromedia triangulated their vectors, but someone has done it before http://blog.bwhiting.co.uk/index.php/2014/03/17/introducing-...
When I asked the Impeller team before what they thought of the Rive renderer, they said that it is great for vector graphics but Impeller needs to also deal with all of the UI related rendering challenges like displaying text properly, so they're not a one to one comparison. Hopefully with this renderer being open source now, both teams can learn from each other.
It also gets extraordinarily complex when you have to handle text layout, kerning, languages that read in different directions, styles, and all of the other complications that come with font rendering.
TrueType fonts even support a small virtual machine to process tiny code programs related to font rendering. It's an incredibly deep topic.
Or even WebAssembly (though more of an experiment than anything): https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-sha...
Performance optimizations mentioned in the other comments is not the sole reason. Another one is visual quality.
Direct rendering of these vector glyphs would look good on high DPI displays and/or for very large font sizes. For normal-looking text on typical displays you won’t achieve great results without hinting: https://en.wikipedia.org/wiki/Font_hinting
Another quality related problem is subpixel rendering https://en.wikipedia.org/wiki/Subpixel_rendering Just like hinting, hard to solve while directly rendering vector shapes.
But this is an MIT license for Rive's rendering abstraction layer, a subset of the Rive runtime that requires the Rive Editor to build content for.
I'm just curious about the goals for open sourcing this and what your hope and plan is for the larger community you'd like to build around it. Can you think of perhaps another project that would benefit from adopting just the renderer? Thanks!
Plenty of projects from games to UI toolkits need a vector graphics renderer, which is why libraries like Skia and Cairo (and now Rive's) exist.
Vector graphics can absolutely require specialized editors to be built. SVG editors are an example of this.
I suppose, continue to make money with the proprietary editor, but have an open source renderer to deploy and enable an ecosystem, where other people target this renderer, as it might be superior. I am definitely interested, I routinely hit the limit of 2D drawing with my limited 16ms per frame (currently I use the canvasAPI and pixi).
From github[0]: This repository contains the renderer code and an example for how to interface with it directly.
It looks like the somewhat standardised Cairo/Skia/canvas/NanoVG API (moveTo, lineTo, etc.) is provided so should hopefully take not much effort to learn, I'm hoping.
(I do see lineTo here at the very least. https://github.com/rive-app/rive-renderer/blob/main/renderer... )
--
This optimizes the smoothness of animation, is fast enough to render fullscreen pages on top of pages of high dpi text at 120fps (on a decent GPU), and the antialiasing quality is always full precision in the (0..255) color channels.
If you want more niche text-specific features like hinting and clear text, those aren’t supported because they don’t animate smoothly and/or don’t work as well with colors other than black and white.
I recommend trying all the options for your specific needs and finding what works best!
These are solid tech choices by people who know what they're doing... definitely worth the effort to check its performance and quality out for yourself.
These GPU-first renderers all have slightly different approaches and each probably occupies a best-in-class niche for some multidimensional space of quality x performance x hardware/driver support x ease of integration. If you're not happy with one of the four, the others are all worth checking out.
Couldn't Vello be embed / used by Skia, Cairo et al, if those renderers wanted to use GPU Compute instead of CPU's for preprocessing?
My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher.
One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction, and that looks like a nice improvement. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]).
Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future.
[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...
I've been pushing over the past six months or so for multiple clients, from healthcare companies with basic mobile apps to deep gaming companies / products, to adopt Rive over Lottie and other past solutions, as I think it's finally hit its stride and is "ready-for-adoption".
This was the last piece that came up in some of those discussions as a potential concern (latest renderer being "closed source" / not quite final).
Really excited to see this problem space continue to improve thanks to this decision and the work the Rive team is doing in general (drop shadows, blur, etc. are all going to be very exciting as they ship)!
Lottie is becoming fairly established as a file format and the workflow is well established and fairly simple.
What does Rive do significantly better warranting pushing for it?
heh, relevant: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
It's kind of strange, because there is a single objectively correct rendering for any vector graphics scene given a pixel sampling function and colorspace metric (the one where each output pixel's value is the closest representable color to the convolution of that function with the scene, expressed as a function from R^2 to R and a linear color scheme respectively), and it seems like it would be achievable with GPU compute and some care with error bounds on either curve tessellation or numerical computation of the exact symbolic integrals of curves.
And it also seems easy to make such a solution have a tunable level of approximation to have faster rendering.
You'll likely enjoy our upcoming GPU-friendly stroke expansion paper - the core of it is exactly numerical methods with error bounds for the exact symbolic integrals of (certain curvature metrics) of curves. And the code is in Vello main (shader/flatten.wgsl) if you're curious and want to look at it now.
What I always found is the 'good' renderers were a small part of a massive project (totally impractical to add as a dependency) and the small, standalone ones weren't necessarily 'good'. I think I found one (nanoVG IIRC) that could have probably been beaten into submission with some hacking but that was around the same time I was winding down my involvement in Blender.
A quick peek at the code seem like this is exactly what I needed those 15 years ago and it just so happens I have some python bindings that could be easily be ported over to this if anyone is interested.
It's hilarious how so much new tech is just barely scratching the surface of what Flash offered in terms of a creative production tool. Every passive consumer fixates on Flash the plug-in and has no idea how incredible the tool was.
"Using vector graphics with Pixi, especially when rendering in a web worker, is a pain in the ass."
Yes it is.
For the 10,000 foot view, watch our presentation at the WebGL/WebGPU meetup at GDC!
Edit* $39 per month if you don't pay for an entire year in one go. Wtf haha, anyone actually paying this for basic solo-dev work?
Once upon a time middleware like this would have been "Call Us" with a custom 5 figure license and royalties.
Now it's not even an hour of a single developer's time cost per month and you get complaints.
Of course you'll need to backup your data, but honestly that's good practice anyway. I just search Google to ensure the service makes it easy to unsubscribe and easy to export your data.
Many projects have phases where you use certain tools extensively—no sense in continuing to pay for say an online video editor on the months you aren't, well, editing any video.
It seems like OSS is more and more bigcorp making money anyway so probably that perception will keep shifting until we're back to normal conditions and OSS developers will be able to earn a salary from their work.
I mentioned compilers used to cost money, and new programmers today might not even realize it.
Implying a good editor (aka Rive) might be worth paying for if it's unique or early.
Lets say I wanted to create a more complex animation. That might take me 2 days. But I've been forced to pay for the entire month and I need to pay forver to have access to it if I cancel.
That's what you're paying $39 a month for.
Not too long ago people were paying $8500 per platform to play back static video. Or about 18 years of Rive access.
More likely, I see perhaps other projects with vector-rendering needs (in-game UIs, video creation tools, svg tools, etc) perhaps studying or adopting the render to make their own graphics more performant.
But to answer your question on "who pays for this?" I can raise my hand and say "I do!" and it's a great value. But just like Copilot probably isn't the best monthly investment if you're not doing quite a bit of coding, Rive probably isn't the best investment if you aren't doing quite a bit of animation.
Out of curiosity, how much do you expect to make for your basic solo-dev work?
Very often I find that devs' attitude when it comes to their own work is "I deserve a six figure salary/equivalent sales" but when it comes to other people's work, that flips to "software should be free". I have zero idea where the salaries are supposed to come from then.
Lets say I wanted to make a simple ball bouncing animation using Rive for my app. That would take me around 8 minutes to make. Rive editor is an online tool so I'd have to pay $39 constantly to have access to it if I wanted to adjust it at some point as the data is stored online.
Lets say I wanted to create a more complex animation. That might take me 2 days. But I've been forced to pay for the entire month and I need to pay forver to have access to it if I cancel.
Would love to see somebody try to re-implement some limited Canvas2D API but using Rive Renderer as a backend. Would likely be faster and more flexible in some ways (e.g. I've found that Canvas2D clipping is not anti-aliased in some browsers).
I didn't know about rive but it looks like a better framer / lottie.
Especially with an OSS renderer with an eye to performance.
I tried out the bevy integration (definitely the best implementation of ECS, anywhere) and there's a working (still unmerged) fork but it's still using vello.
Looking forward to see more!
The animation of the walking bird is 246kB MP4. Bigger than Rive, sure, but it essentially takes no heap or runtime, which is at least 195kB of WASM.
The walking bird animation could probably be optimized much further through automatic decisions that the encoders can take.
You shouldn't use either Lottie or Rive for static animations.
I mean, that fundamentally misses the point of vector graphics, no?
I could also argue that a screenshot of a rendered SVG icon takes no heap or runtime, which would also completely miss the point of why a designer would want vector icons. JPGs and MP4s alike are not infinitely scalable.
It’s tough. We’re chatting on a website with no graphics besides a low resolution letter Y logo. The most exciting UX development maybe ever in the history of computing is a chat interface. On mobile, it’s all scrolling through rectangles. It’s not looking good for the designers.
Only if you think that the job of a designer in the software industry is to add graphics.
By similar logic, the past hundred years have been bad for architects because there are no more stone gargoyles added to buildings.
I guess that depends on your use case. If you only have this animation on your website, then probably no. But if you load and run the rive engine anyway, because you build a game with it - then why not also use it for "static animations", if the result can be way sharper?
>As Duolingo’s products grow and evolve to reach even more learners around the world, Lottie animations help us keep users engaged, delighted, and always learning.[0]
>We thought the answer might lie in an alternative to a game engine —something that can help us take a limited number of assets and turn those into a virtually unlimited number of combinations. This is how we learned about Rive![1]
For me, that’s very much the unimpressive part.
https://github.com/rive-app/rive-renderer/tree/main/renderer...
Actually, I think this is exactly what "hyperbolic" means
Using the pen tool for all your shapes is about as efficient as using Photoshop's pencil tool to set every pixel yourself, or writing your entire app in assembly.
> Looks kinda interesting but I am not gonna touch anything that thinks an acceptable set of drawing tools is "pen and a couple of basic shapes", I quit pulling out every single point by hand in Illustrator a decade ago and my art and my job satisfaction has been much better for it.
How do you work differently now?
Lately I've been thinking it's time to move on to Moho or Toon Boom though, I've been wanting to make stuff move, and I'm real tired of Adobe leaving all kinds of annoying broken edges unfixed for years.
They have tools but you'd have to pay for them, big bucks