How feasible is it to build web games with this? I’d like to build something with this treating it like you would Pixi.js, it looks to me like it’d be as performant if not better but with the amazing advantage of having a vector asset pipeline built into the system. Using vector graphics with Pixi, especially when rendering in a web worker, is a pain in the ass.
Rive Renderer for real-time vector graphics is now open source
71–80 of 134 posts
Re: Rive Renderer for real-time vector graphics is now open source
#72Earlier quoted context omitted.
Seems so: https://rive.app/blog/rive-as-a-lottie-alternative
I'm not sure how intellectually honest that is. 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.
> The animation of the walking bird is 246kB MP4.
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.
Re: Rive Renderer for real-time vector graphics is now open source
#73This problem seems to create a continuous stream of software attempting to solve it with no definitive solution.
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.
Re: Rive Renderer for real-time vector graphics is now open source
#74That's exciting! Congrats on the release.
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!
Re: Rive Renderer for real-time vector graphics is now open source
#75So does this mean someome can create a free editor I can use for basic animation that I don't have to pay $25 for the rest of my life to use? 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?
We've really been spoiled by modern software competition. 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.
It's the market distortion created by people who work for free and expect to get stuff for free
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.
Re: Rive Renderer for real-time vector graphics is now open source
#76This problem seems to create a continuous stream of software attempting to solve it with no definitive solution. 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 fu…
Sounds like you should write a vector graphics library.
Re: Rive Renderer for real-time vector graphics is now open source
#77Earlier quoted context omitted.
I'm not sure how intellectually honest that is. 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.
What's a static animation?
Probably he/she meant just a video file (as opposed to computing the vectors at runtime)
Re: Rive Renderer for real-time vector graphics is now open source
#78Earlier quoted context omitted.
Flash was great, someone creating a better Flash has been long overdue. I think Rive looks like a great attempt at a new Flash.
The Flash tooling is still around, actually. It's now called Adobe Animate and targets existing web standards.
Did that pivot ever really work?
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.
Re: Rive Renderer for real-time vector graphics is now open source
#79Earlier quoted context omitted.
Correct me if I’m wrong, but aren’t fonts rendered from vector graphics already? TTF and OTF are vector formats, correct?
Fonts begin as vector graphics, but every single character on your screen isn't rendered as a tiny, individual vector graphic. Text rendering libraries use a lot of optimizations to cache rasterized glyphs because they're reused all over your screen. 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 complication…
Thank you for your insight!
Re: Rive Renderer for real-time vector graphics is now open source
#80Earlier quoted context omitted.
We have customers shipping full UI with Rive! Games have been adopting us (some cool AAA titles already in progress) and products too. https://rive.app/game-ui https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
Bevy but not Godot?
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?