- RenderFormer は、三角形メッシュベースのシーンで グローバルイルミネーション 効果まで直接実装するニューラルレンダリングパイプライン
- シーンごとの 個別学習やファインチューニング工程が不要
- レンダリングを シーケンス・ツー・シーケンス変換 として定義し、三角形トークンをピクセルパッチトークンへ直接変換
- Transformerベース でパイプライン全体が設計され、最小限の事前制約のみを適用
- ラスタライズやレイトレーシング を使わずに画像を生成
紹介
- RenderFormer は、三角形ベースのシーン表現 から直接画像をレンダリングするニューラルパイプライン
- グローバルイルミネーション効果 が完全に適用された画像を出力
- シーンごとに個別の 訓練またはファインチューニングが不要な 構造で動作
アプローチ
- 既存の 物理ベースレンダリング 方式とは異なり、レンダリングを シーケンス・ツー・シーケンス変換問題 として再定義
- 三角形および反射特性を含むトークン列を、それぞれ小さなピクセルパッチに変換された出力トークン列へ変換
パイプライン構造
- RenderFormer は 2段階構造 で構成
- ビュー非依存段階: 三角形間の照明伝達現象をモデリング
- ビュー依存段階: 光線束を表すトークンをピクセル値へ変換。このとき前段の三角形シーケンスがガイドとして機能
- 両段階とも Transformer構造 を基盤とする
- 最小限の 事前制約のみ を与えて学習
技術的特徴
- レンダリング時に ラスタライズ、レイトレーシング などの従来手法を一切使用しない
- Transformer の シーケンス変換能力 を積極的に活用
結論
- 既存のニューラルレンダリング技術 と比べ、別途の事前準備やシーンごとの調整なしに 柔軟かつ高品質 な画像を生成するアプローチ
1件のコメント
Hacker Newsの意見
いちばん印象的なのは速度です。同じシーンで RenderFormer は 0.076 秒で終わるのに対し、Blender Cycles は 3.97 秒（あるいはより高い設定では 12.05 秒）かかっています。それなのに構造的類似度指数（SSIM）は 0.9526 で、ほとんど差がないレベルです。論文の表 2 と表 1 を参照することを勧めます。これが実際に意味するのは、3D デザイナーが Web やネイティブアプリで on-device transformer モデルによるインスタントなレンダープレビューを、はるかに高品質で見られるようになるということです。ただし、上の結果は A100 GPU 上で PyTorch の最適化なしに測定された値であり、一般ユーザー向け GPU ではここまで速くはないでしょうが、それでも従来のレンダリングより十分な速度向上は期待できると思います。あるいは Web ベースのシステムなら、A100 をバックエンドに接続してブラウザへ結果画像をストリーミングする方式も可能です。ただし限界も明確です。シーンが複雑になるほど精度は落ち、とくに複雑な影（粒子や髪の毛を含む）では誤差が出やすいため、最終レンダリングは依然として従来手法で処理しないと、AI ベースの画像・動画でよく見られるアーティファクトを避けられません。それでも、もし速度向上が十分に大きければ、映画尺のプレビューレンダリングが必要な大手アニメーションスタジオで、音楽やストーリーのレビュー用途などに使えるのではと期待しています
研究者たちが意図的に事実を歪めたとは思いませんが、もし Blender Cycles がそのクラスの GPU であの性能なら、論文中のすべてのシーンを 4 秒以内でレンダリングできる水準です。論文で使われたシーン自体の複雑さが低いうえに、Blender を 4,000 回反復サンプリングする設定にしていて、実際には数百回でほぼ最終品質に達し、それ以降はほとんど効果がありません。その結果、GPU リソースを不必要に消費していることになります。また Blender の初期レンダリング準備工程をレンダリング時間に含めている一方で、transformer の初期化時間は除外しているように見えます。各システムで 2 フレーム目のレンダリングにかかる時間も気になります。私の予想では Blender のほうがずっと速いはずです。とはいえ論文の結果自体は興味深いものの、Blender の設定とタイミング比較の部分には微妙な差があります
示されているシーン基準だと、76ms はむしろ遅いほうです。もちろん今後ずっと速くなるとは思いますが、既存の従来型レンダリングより優れていると評価するのはまだ早い、という感想です
論文での時間比較はやや不正確です。レイトレーシングではサンプル数の平方根に応じて誤差が減少します。論文では参照画像を生成する際に非現実的に高いサンプル数を使っていますが、実際のオフラインレンダラーはこれより 10〜100 倍少ないサンプリングで済ませます。論文のような高サンプルで作った画像は品質比較用としてはよいですが、それで時間比較をするのは一般的ではありません。結果が厳密ではないので、同程度に近似値を出す別のレンダリングアルゴリズムと比較するほうが公平です。最近のリアルタイムパストレーサーとデノイザーの組み合わせなら、コンシューマー向け GPU で 16ms 以内に、もっと複雑なシーンをレンダリングできます。とくに transformer モデルは三角形数とピクセル数の両方に対して時間が二乗で増えます。最新の機械学習研究で改善があるかもしれませんが、従来の path tracer の O(log n triangles), O(n pixels) のスケーリングに勝つのは難しいでしょう（実際には隣接ピクセル間の一貫性のおかげで、ピクセル数の増加にはそれほど敏感ではありません）
速度が優れているという主張には驚きました。論文をざっと見ましたが、Blender Cycles が A100 の CPU を使ったのか、CUDA カーネルを使ったのか確認しづらかったです。単一フレームならレンダラーの起動時間が一部含まれていた可能性があります。もしシーケンスレンダリングなら、フレームあたりの時間は大幅に減るはずです。そして別の方が言及していた三角形の複雑度（O(n^2) スケーリング）も確実に影響するでしょう
論文では「Attention レイヤーのランタイム複雑度はトークン数、つまりこの場合は三角形数に比例して二乗で増加する。そのためシーン内の三角形数を最大 4096 個に制限した」と述べています
ディープラーニングは、グローバルイルミネーションのレンダリング画像のデノイズ（ノイズ除去）にも非常にうまく使われています。従来のレイトレーシングで粗いグローバルイルミネーション画像を出力し、ニューラルネットワークがその出力画像のノイズを除去する方式です。関連リンク: Open Image Denoise
映画業界で実際に物理ベースレンダラーを開発している友人がいて、この業界の仕事の進め方や話を聞くのはいつも興味深いです。今こういう人材を採用している会社がどこなのか気になります。AI 企業も、トレーニング用環境の構築目的でレンダリングエンジニアを採用しているのでしょうか。もし経験豊富なレンダリング研究者／業界エンジニアの採用を希望している方がいれば、私の友人は SNS をやっていないので、つないであげることはできます
例のどれもカメラの後ろにあるオブジェクトを見せていないのが不思議です。こうした例の構成上の限界なのか、あるいはアプローチ自体の限界なのかは分かりませんが、反射やライティングを考えると、カメラ後方は非常に重要な要素です
またしても "the bitter lesson" を実感する瞬間です。いまやグラフィックスレンダリングの分野にもこの流れが適用されるわけです。NeRF はレイトレーシングベースの事前分布を、Gaussian splat はラスタライズベースの事前分布を部分的に使っていましたが、この方式はそうしたドメイン固有の事前分布や専門知識をすべて捨てて、データと attention だけで解こうとしています。こういうやり方こそが結局は未来なのだろうという気がします
GPU を中心に、レンダリングとコンピュートが相互に循環してつながる構造が完成した点が印象的です
結果は悪くないのですが、ややぼやけた感じがあります。ニューラルネットワークと古典的レンダラーのあいだで、レンダリング時間の比較がもう少しあればよかったと思います
アニメーション（とくに Animated Crab と Robot Animation）には、AI アート特有のアーティファクトが目立ちます。オブジェクトやカメラが動くと、モデルの周囲で不自然に渦巻くような現象です
論文では時間比較について多少の議論があります。Blender Cycles（パストレーシング）と比べると、少なくとも 4K 三角形以下のシーンではニューラル方式のほうがはるかに高速です。ただしそれ以上に複雑なシーンにはあまり向かないかもしれません（attention のランタイムが三角形数の二乗で増加するためです）。論文リンク: RenderFormer 論文 PDF。私としては、ニューラル方式を間接照明だけに使い、従来のラスタライザーでベース画像を作って、Global Illumination だけをニューラルで重ねる形も現実的な方法かもしれません
もしかすると理解不足かもしれませんが、こうしたシーンが結局は予想どおりの形でレンダリングされるのだとしたら、なぜこの方式に、もっと単純で直接的な方法より利点があるのか気になります（より速いわけでもないなら、あえて使う理由があるのかという疑問です）
実際、この方式は見た目以上におもしろい効果を出せるかもしれません。たとえばシーンをひとつの input weight の塊と見なしてそこにノイズを加えたり、異なるシーン同士を interpolate（補間）して予想外の結果を得たりできるでしょう
結局のところ、この方式は "Cool Research" に近いと思います。実用性は低いです。三角形が増えるほどコストが二乗で膨らむからです。そのため論文でもシーンごとに 4096 個に制限しています
別のコメントでも言われているように、この方式のほうが速いのは事実です。グローバルイルミネーションは直接的な方法だと本当に遅いので
新鮮な研究だという印象です。transformer は自然言語だけでなく、さまざまな連続的データ入力とトークン間相関を特徴とするドメイン全般に適用できる点で、今後の非テキスト領域への応用研究が楽しみです。Hacker News のユーザーたちは、transformer に特によく合いそうな非テキスト領域として何が面白いと思うのか気になります
とても独創的で興味深いアイデアだと思います。三角形集合ベースのシーン記述を 2D ピクセル配列へ変換する transformer を訓練し、その結果として既存のグローバルイルミネーションレンダラーの出力とほぼ同じ画像を即座に生成できるわけです。この 5 年ほどの研究を見れば、こういうことが可能だという事実自体にもう驚くべきではないのかもしれませんが、それでもなお非常に印象的です。transformer アーキテクチャの汎用性を強く感じます。速度も非常に速く、Blender の出力とほぼ同じで、モデルサイズは約 1B パラメータ、fp16 か 32 かは不明ですがファイルサイズは 2GB とかなり大きいです。もっとリアルなシーンのデモも見てみたいですが、今すぐ自分の Mac にダウンロードして試せる点も気に入っています