Mostly to show projects on-device/being interacted with. We also designed this version of the site back before we had responsive layouts, dynamic text, data binding, etc. We will eventually update it to be designed entirely in Rive, but we're first prioritizing launching features like Libraries, Scripting, and a better way to handle Accessibility features.
Chris Dalton, who leads Rive's rendering team, set out to reinvent how graphics handle soft edges. Here's the unfiltered story behind Vector Feathering.
Sure, I think it's probably generous from the user count point of view but incredibly limited from the number of files. And it seems you have to use provided fonts in the free tier... I think Rive should offer the Editor free like Unity and then charge for additional services like console support, dedicated support, troubleshooting, etc. as that's much more common business model for game middleware. The same applies to Unreal Engine where Switch/PS5/Xbox support is gated behind the respective access to the official dev portal and Epic's own Perforce rather than GitHub. And Perforce support for example should be promoted for pro tiers.
I see a banner mentioning "Rive for Game UI" which is great to see but really the whole platform should be a Flash replacement. It shouldn't just be for doing UIs in games or animated content, it could be used to make full 2D games. Flash was so popular because of its versatility. There were middleware taking Flash content directly into game UIs (ScaleForm) and there is middleware supporting WebKit for game UIs (Coherent labs). Both of these have extensive scripting support (respectively ActionScript and JavaScript) allowing UI designers and coders to create reactive and flexible content, even procedural content like lists of things etc.
By the way, the only way from mobile to get to the downloads link on the main site is only behind the online editor login. I get why but I thought at first that the Editor was online only because of that.
I think that perhaps what you’re missing is that most of those tools charge for the runtime in some capacity. We took a different approach. The Rive Runtime and file format is free and open source, the editor is how we monetize. Users can have confidence that they will forever have access to the runtime and their files. Anybody can build an editor.
Regarding file limits, stay tuned for some announcements there.
Regarding Flash, yep that’s where we’re headed (and most of the use cases on the site should support that). We have some big features launching this year like audio, fluid layouts, and scripting. The banner was added because we’ve been attending game conferences and the game ui market segment is something we’re highlighting right now. Game UI is in dire need of better tools and it’s a market segment we can quickly lead with our current feature set.
Can you talk a bit about text rendering? How does it compare to slug? [1] Would it be suitable for rendering text heavy applications? (like, say, a PDF viewer, a code editor, web browser, etc).
The Rive renderer takes an animation-first approach to all path rendering, including text. Meaning, every glyph is redrawn from raw bezier curves with full precision antialiasing, every frame. (Just like any other path.)
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!
How is antialiasing implemented in the Rive renderer? It doesn't appear to be using MSAA. I took a look at the source code, I found some shaders that mention coverage and AA, but I cannot figure out how it works.
Bevy is written in Rust and according to https://github.com/rive-app/rive-bevy/, the backend used for the integration uses Vello (also Rust), not the Rive renderer. Could be that integrating Vello into the C++-based Godot would be finicky. With the Rive renderer open-sourced, maybe both Rive and Godot will see an integration using the Rive renderer?
For one thing, Rive is built for runtime and interactivity. Unlike Lottie, which is built on the After Effects format to basically generate vector gifs.
Also, even with compression, Rive files are smaller. One immediate benefit (amongst many) is the low impact on memory that an intrinsically tiny format like Rive has. See my thread with a Lottie engineer here https://x.com/guidorosso/status/1603189817382010882?s=46&t=_...
Hey this is super cool. I'm the co-founder of Rive and would love to chat about what features you were lacking! We're launching text soon, which I imagine is part of it. But I'd love to know more and see if we can help with future projects. Feel free to email me at guido at rive.app
