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