by 遅ればせながらRedshiftを導入しました。少し触った感想など書いてみたいと思います。
速い！ キレイ！ 以上！
……だけというのもアレなので、C4D本体レンダラーと比較してみたりしましょうか。テストに使ったシーンファイルはギャラリーや過去記事に上げているやつと同じですが、こちらはライトやマテリアルなど若干調整しています。また、レンダリング後の画像に対する色調整などは行っていません。
レンダリングスピード
こちら、C4D本体のフィジカルレンダラー、GIはプライマリがQMC、セカンダリがライトマップで、レンダリング時間はCore i9 9900Kで29分です。Team Renderで分散すればもっと速いのですが、今回は比較のためスタンドアロンで。
一方のRedshift、最初に挙げた画像のレンダリング設定は、GIはプライマリがBrute Force、セカンダリがIrradiance Point Cloudで、レンダリング時間はRTX 2080で7分です。7分！ 4倍ぐらいの差がついていますね。
で、この7分という数字だけでもかなり驚きなのですが、Denoiseを使ってパストレーシングのノイズを消すことを前提に設定を調整するとタイムはもっと短縮できます。
こちらの画像がそのDenoiseを使った例で、レンダリング時間はなんと2分です。2分！
なおC4DとRedshiftのGIモードですが、名称は違いますが原理としてはどちらも同じものです。プライマリのQMCとBrute Forceはスクリーン上のすべてのピクセルでパストレーシングを行うモード、セカンダリのライトマップとIrradiance Point Cloudはジオメトリのサーフェイス上に間隔を開けて配置したサンプリングポイントごとにサンプリングを行うモードです。ちなみにV-RayだとそれぞれBrute ForceとLight Cacheという名称になっています。
レンダリングのクオリティ
続いてレンダリングのクオリティのほうを、細部をクローズアップして見てみます。C4Dと、RedshiftのDenoiseなしで7分のほうで比較します。
この例では、入り隅や壁の継ぎ目の細い溝で差が出ています。C4Dのほうは明暗にムラがあってガタガタしていますが、Redshiftのほうはスムーズできれいですね。
この差はおそらくセカンダリGI、C4DのライトマップとRedshiftのIrradiance Point Cloudの機能差によるものです。
RedshiftのIrradiance Point Cloudには「Retrace」という機能があり、ジオメトリのディテール部分ではセカンダリにIrradiance Point Cloudを参照せずBrute Forceを使うことでアーティファクトの発生を防ぐらしいです（V-RayのLight Cacheにも同様の機能があります）。
これはC4Dのライトマップのプレビュー表示なのですが、こういう具合にモザイク状にサンプルが配置されていて、プライマリのQMCはこれに対してパストレーシングを行います（実際に参照される値にはマテリアルが反映されていると思います）。ライトマップの設定ではサンプル数を最大値まで上げているのですが、今回のようなインテリアのシーンではこの程度の誤差が残ってしまいます。RedshiftのIrradiance Point Cloudのほうは、プレビュ表示では荒いパストレーシング状なのですが、あちらもフィルタがかかった後にはだいたいこんな感じになっていると思います。
さて、ジオメトリ間にそれなりのスペースがある部分ではプライマリのQMCが飛ばすサンプルレイは広い範囲に拡散されるため、その先のセカンダリ＝ライトマップから参照されるサンプルも平均化され、結果的にアーティファクトは現れにくくなります。ところが入り隅や溝のようなディテール部分ではジオメトリが近接しているので、Retrace機能のないC4Dでは直近のライトマップの値をQMCがほぼそのまま拾ってしまい、ライトマップの誤差がアーティファクトとして現れてしまうわけです。
ライトマップの半径を大きくしたりフィルタをかけて強制的にスムーズにすることもできるのですが、それをやるとライトリークやディテール抜けのリスクがあるため、解決策としては心許ない感じです。このへんがC4Dのライトマップ機能の限界ということになるかと思います。
あ、イラディアンスキャッシュですか……以下余談になりますが、イラディアンスキャッシュをセカンダリGIとして使えるのは僕が知る限りではC4Dぐらいです（あと昔のfinalRender）。なんでなのかと考えてみると、イラディアンスキャッシュはジオメトリが込み入ってくるとガクンと計算が重くなるからなんじゃないかと思います。今回のシーンの場合、植栽と玉砂利がイラディアンスキャッシュとかなり相性が悪く、セカンダリにQMCを使った場合と同じぐらいの遅さになります。ディテールをテクスチャや写真合成で表現していた時代にはよかったのですが、すべて3Dジオメトリで表現することも多い現在の状況には合わなくなってしまった技術ではないかと思います。ちなみにRedshiftでもプライマリGIではイラディアンスキャッシュが使えますが、ディテール描写に弱く動画でフリッカーが起きやすい傾向があるのはC4Dと同様のようです。
Denoiseの特性
気を取り直してRedshiftの話を続けます。
Denoiseを使うとパストレーシングの宿命ともいうべき粒子状ノイズを消すことができるので、そのぶんBrute Forceなどのサンプル全般の値を下げてレンダリング時間を短縮することができます。とはいえこの機能にも代償がないわけではなく、細部で多少、クオリティの落ちるところがあります。
これはDenoiseありでレンダリング2分とDenoiseなしでレンダリング7分の比較です。左がDenoiseありのほうです。
左上、鏡の縁のあたりに、Denoiseではもやっとしたアーティファクトが出ています。一見するとトーンは平坦でなんでもない感じのところなのですが、もしかすると鏡に映り込んでいる部分はDenoiseのアルゴリズムが苦手とするものなのかもしれません。
右上、溝の線がところどころ溶けていますね。ごく細い線をノイズと見なして消すかどうか、悩んでいる感じがします。
下段、玉砂利の陰影がかなり変わっていて、影がノイズと判断されて消されているためか、石の大きさが半分ぐらいに細かくなったように見えます。こういうのもDenoiseが苦手なパターンのようです。
もうひとつ、なかなか興味深い例を。
壁の部分、木目のテクスチャは損なわれずにそのまま出ているのですが、表面を横切っているバンプマッピングの線だけがほとんど消えてしまっています。木目のテクスチャはノイズと認識せず、バンプマップによる細い線はノイズとして消してしまっているのはちょっと不思議ですね。輝度だけでなくRGBの間にそれなりの差があれば、ノイズではなく模様として認識するんでしょうか。
動画でDenoiseを使う場合にはこれらの要素に加えて、時間的な変化によってノイズがパカパカ出たり引っ込んだりすることもあり得るので、万能とは言いがたいですが、なにしろレンダリングスピードは稼げるので、使えるときには使っていきたい機能ではありますね、Denoise。
そのほかの感触
これまでレンダリング結果の話ばかりしていましたが、ほかにもRedshiftにはいいところがいろいろあります。
まず、テクスチャプレビュやライトプレビュがちゃんと出る。サードパーティレンダラーだと割とダメなのがある中、ちゃんとやっています。
マテリアル周りもうまいこと統合されています。簡単なマテリアルであればノードベースのエディタ（Shader Graph）を使わなくても編集できますし、C4DマテリアルをRedshiftマテリアルに一括コンバートできます。C4D固有のシェーダも内部でビットマップにベイクすることで使用可能です（ただしテクスチャプレビュが出なくなったりはするようです）。
そしてレンダリングのリアルタイムプレビュー、Renderview。操作にリアルタイムで反応するのでこちらのGIモードはフルBrute Forceだと思うのですが、明るさなどに関してはほかのモードとの差がほぼないようで、ちゃんとあてになります。そしてこちらにもDenoiseが効くので、ノイズがジャリジャリで何がどうなってるのかわからんということもありません。快適！
Renderviewについてひとつだけ難を挙げるとすると、Renderviewの表示にはC4D本体のカラーマネジメントが反映されないらしく、広色域ディスプレイではかなり色が濃くでてしまいます。まあディスプレイの広色域モード自体がメリットより厄介ごとのほうが多いような感じもするので、うちではこれを期にsRGBモードでの運用に切り替えようかと思っています。解決！
まとめ
とりとめのないただの感想文になってしまいましたが、Redshiftはレンダリングが速くてアーティファクトの心配も少なく、予想以上に快適でした。これで初年度$500、次年度から$250ですんで、そりゃーみんな乗り換えるわーという納得のパフォーマンスでした。なぜか日本語ドキュメントは代理店や開発元でなく個人の有志が公開しているっぽいのですが、ちゃんと開発元公認だそうです。