リアルタイムベクターグラフィックス向け Rive Renderer、オープンソース化
(rive.app)- Riveが自社開発した Rive Renderer をオープンソースとして公開し、Riveコンテンツ・アニメーション・ランタイムに最適化された単一のレンダリング基盤を、あらゆるプラットフォームで利用できるようにした
- レンダラーの目標は、ベクターグラフィックスと鮮明なテキストを大量に描画しつつ、120fpsアニメーション と高いアンチエイリアシング品質を維持すること
- 従来は Skia や HTML Canvas API など複数のレンダラーに依存していたため、あるバックエンドにない機能は全プラットフォームでリリースしにくかった
- 単一レンダラーにより、blur, drop shadow, glow, tapered stroke のような効果を複数のランタイムへ、より一貫して追加できる
- 実装は、アンチエイリアスされたベクターパスを 三角形パッチ に還元し、GPUの並列三角形ラスタライズパイプラインを活用する方式で、iOS・Android・Webで有効化でき、Unity・Unrealランタイムにはすでに統合されている
Rive Renderer公開と開発の背景
- Rive Renderer は、Riveコンテンツ、アニメーション、ランタイムのために自社開発されたレンダラー
- ベクターグラフィックスやテキストを画面上に大量描画する状況でも、120fps のアニメーションと高品質なアンチエイリアシングを目指している
- 社内開発には 2年 を要し、Rive Editorでデザイナーが制作する段階から、ランタイムでユーザーが見て操作する段階まで、体験全体をより直接的に制御できるようになった
- ランタイムで高速に動作するコンテンツだけを意図的に生成するよう最適化しており、デザイナーは実装上の性能面をあまり気にせず制作に集中できる
複数レンダラー構成の限界と単一レンダラーの効果
- 初期のRiveは、Skia や HTML Canvas API といった既存のオープンソースレンダリングソリューションを利用していた
- ユーザーが望むレンダラーを簡単に接続できる bring-your-own-renderer 構成は引き続きサポートされる
- しかし、一貫性があり最適化された自社レンダラーがなければ、製品ロードマップや新機能開発はプラットフォームごとの制約に縛られざるを得なかった
- 複数レンダラーを使う構成では、特定の機能があるレンダラーに存在しない場合、Riveが動作するすべてのバックエンドで使えず、その機能をリリースしにくかった
- 単一レンダラーによって追加しやすくなる効果には、blurs, drop shadows, glows, tapered strokes などが含まれる
実装方式とプラットフォーム対応
- Rive Rendererは、アンチエイリアスされたベクターパスを固有の 三角形パッチ に還元する幾何学的アプローチに基づいている
- デスクトップおよびモバイルGPUに標準搭載されている大規模並列の三角形ラスタライズパイプラインを活用する
- 特定の三角分割方式によって、3Dハードウェアを用いて Bézier曲線 を描画する
- サードパーティ製レンダラーの利用も引き続き可能だが、Rive固有の機能と全体的な体験のためには Rive Renderer の利用が推奨される
- iOS、Android、Webでは 公式案内 に従って Rive Renderer を有効化できる
- コードは GitHub で公開されており、Unity と Unreal のランタイムには統合済みで、今後さらに統合が進められる予定
1件のコメント
Hacker Newsの反応
さっき GDCブースにいたが、UI/UXデザイナーがゲーム内でより多くの作業を自分でできるようにするプログラムとして、本当に良さそうに見えた
普段はデザイナーがFigmaで数日作業したあとプログラマーに渡し、プログラマーがあれこれ理由を挙げて実装できないと返して、往復が続く
Unreal EngineにはAAAゲーム向けの優れたUIフレームワークが不足しているのでさらに深刻だが、このツールのワークフローは今まで見た中で最高で、Unreal EngineとBlueprintsにも自然になじむようだ
個人的には、UI/UXデザイナーがプログラマーの助けなしに作業できそうなのが大いに期待できる。ゲームプログラマーはたいていUI作業を嫌うし
仕事をしようとして席に着くときと、ゲームをしようとして席に着くときの心構えの違いで説明できそうだ
現代版がひどすぎると叫ぶ年寄りのように感じた、ほぼ初めての瞬間だった
GPUテッセレーションで 2Dベクターグラフィックス をレンダリングする研究は盛んだが、Raph Levienの仕事のような流れの技術を実際の製品として出すのはかなりすごい
Riveを使ったことはないので、かっこいいアニメーション制作専用なのか、それとも即時モードGUIライブラリのような 動的UI も作れるのか気になる
https://rive.app/game-ui
https://rive.app/blog/how-age-of-learning-uses-rive-to-a-b-t...
かなり複雑なUIをRiveで作ったことはあるが、外部イベントに応じて要素をプログラム的に追加したり、UIテキストを変更したりする領域はまだ試せていない
この試みはすでに Flash でやっていたのでは、と思う。Macromedia/Adobeはプレイヤーを無料で配布し、ツールで課金していたが、Riveもプレイヤーをオープンソースで公開し、エディタで課金しようとしているように見える
RiveはUnityやUnrealのような別プラットフォームを使うゲーム開発者、たとえばシネマティックのようなものを埋め込みたい層を狙っているようで、その点は少し違う
それでもオープンソースのプレイヤーがあるというのは、Riveが体験全体を支配したいということでもあり、Flashを思い出させる
発表時からずっと待っていた。以前はSkiaを使っていて、アプリ全体とレンダリング出力はFlutterで作られていた。いまのFlutterにはSkiaよりもFlutter固有の問題に最適化された新しいレンダリングエンジン Impeller がある
以前ImpellerチームにRiveレンダラーをどう見ているか尋ねたとき、ベクターグラフィックスには素晴らしいが、Impellerはテキストを適切に表示するなどUI関連のレンダリング問題まで扱う必要があるため、一対一で比較する対象ではないと言っていた
このレンダラーがオープンソースになったので、両チームが互いに学べることを願う
Riveの製品も会社も好きだし、オープンソースも好きだが、これはRive Editorでコンテンツを作る必要があるRiveランタイムの一部である レンダリング抽象化レイヤー をMITライセンスで公開したということだ
オープンソース化の目的と、その周囲にどんなより大きなコミュニティを作りたいのかが気になる
レンダラーだけを導入して恩恵を受けるほかのプロジェクトが思い浮かぶかも気になる
個人的にも関心がある。現在canvasAPIとpixiを使っているが、16msのフレーム予算内で2D描画の限界にしばしばぶつかる
[0] https://github.com/rive-app/rive-renderer
個人の趣味プロジェクトで使ってみたくなるほど本当に素晴らしく見える
moveTo、lineToのような、ある程度標準化された Cairo/Skia/canvas/NanoVG API が提供されているようなので、学習にそれほど大きな労力がかからないことを期待している少なくともここには
lineToが見える: https://github.com/rive-app/rive-renderer/blob/main/renderer...このレンダリング性能が Skia や Pathfinder と比べてどうなのか気になる。Pathfinder はハードウェアが対応していれば、パスを三角形に変換する段階を GPU コンピュートで処理することもできる
より包括的なコンピュートベースの 2D レンダリング手法としては Vello もある
第一印象では、性能はハードウェア、とりわけ pixel local storage のサポートに大きく左右されそうだ。今まで見た限りでは Apple Silicon が理想的なポイントにある。タイル単位のビニングとソートをハードウェアが支援し、タイル内でフラグメントシェーダー実行を直列化しても問題なく動作する
他のハードウェアでは、そのような呼び出しの直列化コストはずっと大きくなると予想している
Vello 側で深いベンチマークをまだ行っていない理由の一つは、性能面の話がまだ固まっていないからだ。現状ではデバイスアトミック演算で境界ボックスを集約する問題があり、セグメント縮約にモノイドを使うプロトタイプ実装[2]がかなり改善した結果を示している
さらに
f16演算も計画しており、とくにモバイルでは大きな効果があるかもしれない。複数の prefix sum 段階にはサブグループを使う予定で、サブグループは WebGPU に追加されつつある[3]全体として、このレンダラーがオープンソースとして公開されたことをうれしく思うし、高速 GPU ベクターグラフィックスレンダリングで活動が活発になっているのも歓迎したい。いつか CPU パスレンダリングが時代遅れと見なされる未来を見たいし、今回の公開はその方向にさらに近づけるものだ
[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
何をしているか分かっている人たちが選んだ堅実な技術選択に見え、性能と品質を自分で確かめてみる価値は十分にある
こうした GPU 優先レンダラーはアプローチが少しずつ異なり、品質・性能・ハードウェア/ドライバー対応・統合の難しさという多次元空間の中で、それぞれが最良となる領域を持っている可能性が高い。4つのうち1つが気に入らなければ、残りも見てみる価値がある
個人的に本当にうれしい
この半年ほど、基本的なモバイルアプリを持つヘルスケア企業から、ゲーム性の強い企業や製品まで、さまざまな顧客に Lottie や従来の解決策の代わりに Rive 採用 を勧めてきた。ようやく軌道に乗り、「導入準備完了」の状態になったと見ている
それらの議論で最後まで潜在的な懸念として残っていたのは、最新レンダラーがクローズドで、まだ最終形ではないという点だった
今回の決定と Rive チーム全体の取り組みによって、この分野が今後も改善されていきそうで楽しみだ。シャドウやブラーのような機能もリリースされれば非常に興味深いだろう
Lottie はファイル形式としてかなり定着しつつあり、ワークフローもよく整備されていて、比較的シンプルだ
Rive は何がそこまで優れていて、あえて強く勧めるほどなのか気になる
リポジトリ: https://github.com/rive-app/rive-renderer
関連: https://news.ycombinator.com/item?id=39754770 (Build System Schism: The Curse of Meta Build Systems)
この問題には決定的な解法がないまま、それを解決しようとするソフトウェアが作られ続けているように見える
少し奇妙なのは、ピクセルサンプリング関数と色空間の尺度が与えられれば、どのベクターグラフィックのシーンにも客観的に正しいレンダリングが1つ存在するはずだからである。各出力ピクセル値は、その関数とシーンの畳み込みに最も近い表現可能な色であるべきであり、シーンは R^2 から R への関数、色は線形色体系で表現できる
GPUコンピュートと、曲線テッセレーションまたは曲線の正確な記号積分を数値的に計算する際の誤差限界をうまく扱えば、達成は可能に見える
また、このような解法は、より高速なレンダリングのために近似の度合いを調整できるようにするのも簡単そうに見える
ただ十分にまともな並列コンピュータさえあればそれほど難しくなかったはずだが、現実にはGPUインフラがサポートするハックの山の特定の組み合わせに合わせてレンダリングロジックを適応させる必要があり、それぞれに非常に独特な制約とトレードオフがある
近いうちに出るGPUフレンドリーなストローク拡張の論文を気に入ると思う。要点はまさに、曲線の特定の曲率尺度に対する正確な記号積分を、誤差限界付きの数値手法として扱うことにある
興味があれば、今でも Vello main の
shader/flatten.wgslコードで見ることができる