chiyamaリグの情報をジオメトリキャッシュに埋め込んで、その情報を元にシェーダのパラメータを指定したいような場合がよくあります。皺用ディスプレイスメントとか色を変化させるような場合ですね。ノードを使用してアトリビュートを上書きすることで実現できます。今回はマテリアルの色を上書きしてみます。タブから簡単に探すことができます。指定して赤色になっていたジオメトリが黒色になりました。他のところから値を取得することができるので、好きなところから値を参照することができます。chiyamaこれまで作ってきたような単純な例ならいいのですが、本番で使おうとするとこの何十倍も複雑なシーンを扱わなければいけなくなります。整理するための便利ノードが幾つか用意されています。ノードノードを処理単位で枠で囲ってコメントを書くことができるノードです。作成後、ダブルクリックでノードの編集用ダイアログが開き、そこでメッセージや色の指定ができます。一部をグループ化して、見た目上一つのノードとして扱うことができるノードです。キーを押すと、シュルシュルッと一つのノードにまとまります。ボタンを押すと中を確認することができます。ノードこれは既に使っていますね。ノード間を接続しているエッジを曲げたり分岐したりするのに使います。構成を綺麗に保つことはとても大事です。試行錯誤中はどうしてもノードが汚くなってしまいがちですが、そのままでは他の人が見た時にどこで何の処理をしているのか把握するのが難しくなってしまいますし、作った本人ですら時間が経つと細かい内容を忘れてしまいます。そのようなことが無いよう、常日頃から綺麗なノード構成になるよう心掛けておくことが大事です。心の乱れはグラフの乱れ、グラフの乱れは作品の乱れ。chiyamaレンダリングシーンのデバッグ目的やシーンの最適化をおこなうときに、レンダラにどのようなデータが渡っているのかを確認するためにレンダラが直接解釈できるファイルに出力するのは皆さんよくやりますよね。ファイルを出力することができます。filename=filename)のようなコードを実行します。ファイルが出力されます。コマンドを使用します。turntable.0001.assのようにしてレンダリングできます。ファイルはテキストファイルなのでエディタで編集可能です。今回は試しに出力先のパスとレンダリング解像度を変えてレンダリングしてみました。無しでコマンドラインからレンダリングをすることができています。ファイルにはジオメトリデータが全て展開された形で出力されてしまうため、ファイルサイズが大きくなりがちです。渡してくれると嬉しいのですが。仕組み上しょうがないのかなと思いつつ、ちょっと惜しいです。あと、ジオメトリやシェーダの情報がエンコードされた形式で出てしまうのでその部分の詳細情報が確認できないのが残念です。形式に変換できるのかもしれませんが。環境も作り、チェック用のターンテーブルも作成したら後やることと言ったら連番画像のレンダリングです。連番画像のレンダリングには対応しておらず、コマンドラインからのバッチレンダリングをおこないます。立ち上げるようにしています。そこで、このスクリプトを少し改変して引数も受け付けるようにします。"$@"最後の行を編集しているだけです。ノードでおこないます。カメラはシーン中にある、レンダリングに使用したいものを選びます。出力先ファイル名を指定できるようになります。いう形式で指定します。ノードの設定をおこないます。表示されなかったです。選択可能になったことを確認したらファイルを保存します。1-100のように実行します。パスやフレームレンジは適宜読み替えてください。レンダリングログが出力され、レンダリングが始まります。使用するためのライセンス(インタラクティブライセンス)とは別のバッチライセンスが必要になります。そんなこんなでレンダリングしてムービー化してみました。ターンテーブルとしてはいろいろとどうなの?というところはいろいろありますが(汗、とりあえずできました。チェック用シーンを作成するまでに必要な知識は全て整いました(多少、流れに合わせて調整が必要な部分はありますが)。そこで、これらの知識を活用して一通りの流れを作ってみました。化されたアセット(本来はアニメーションはついてないですが、今回は無かったのでアニメーションつきのもので代用しています)を読み込み、それに対してシェーダの設定をおこないます。作業中、確認のためにレンダリング用の設定が必要なので、それも事前に用意しておきます。ファイルの出力をおこなうようにします。ファイルを成果物として出力します。続いてチェック用のレンダリング画像を作成するシーンです。ファイルを読み込みます。リファレンスに使用するカラーチャートやボールを常に画面上の同じ位置にあるように配置します。見ての通り、チェック用アセットで読み込んでいるアセットとLookファイルの二つのファイルを差し替えるだけでよく、ターンテーブルはそのまま使用できます(厳密にはアセットのサイズごとにカメラを調整するような仕組みが必要ですが)。ショット用のシーンもチェック用のシーンとやることは同じです。シーンの内部をリファレンスに置き換えていくことで最終的なシーンまで構築できます。警察の方からご指摘いただいたので詳細情報の追加をします。これが少々複雑で、同時に複数の選択状態が存在します。これが結構厄介で、オペレーションをしているときの勘違いの元になって延々ハマる原因にもなっています。ハマるからと言ってソフトウェアの造りが悪いのかといったら全くそんなことは無く、これがあるから強力かつ使いやすいツールになっているので結局はきちんと理解して使いこなしましょうということになります。フラグがセットされた状態になります。確認できるシーンの見た目になります。フラグがセットされた状態になります。タブに表示され、パラメータの編集が可能になります。上でノードを選択した状態です。この時、ノードの外枠が黄色になります。内での選択状態で、ノードを移動したり削除することができます。一つ、マウスカーソルの位置も意味があります。中でのショートカットキーはマウスカーソルの位置にあるノードに対して効きます。押したことでこのノードが無効な状態になっています。フラグがセットされたノードのシーン内での選択です。タブはここで選択されたオブジェクトの情報を表示します。いうソフトに慣れるための大きな一歩になります。シーンを作っていると、思った通りの結果にならなかったり、シーンがどのような状態か知りたくなる時があります。似たようなことがあって、チュートリアル動画を見ていてもちょっとしたミスで思った通りの結果にならなくて解説をしている人がオロオロしながら原因を探る(そして動画が一時止まるw)ということが結構あります。この辺りはノードベースでシーンデータを扱っているツールの持つ難しさがある所だなと感じています。強力な手段を提供してくれています。探すときにも使いましたね。これが凄いのは、ノードを辿った時に変更前後を簡単に確認できることです。ノードで書いた処理の確認をするのに重宝します。※この記述は正確ではなかったです。まとめたので、そちらをご覧ください。これは名前の通りレンダラが出力したログを見ることができます。介してはいるものの、ほぼ直接と言っていいほどダイレクトにレンダラにアクセスしているため、ユーザーがおかしな操作をしてしまうと簡単に不正なレンダリング結果が出力されてしまいます。このような場合、レンダラのログを読むことで問題解決の糸口を掴むことができる場合が多いです。そのほかにもレンダリング時間や使用メモリ、その他詳細な統計情報も確認できるので、とても重要な情報源です。限らず、レンダラのログを読むだけでトラブルの原因を簡単に突き止めることができることってすごく多いんですよ。押すとノードをオンオフすることができます。オフにするとそのノードの処理はおこなわれないため、デバッグには重宝します。あとはノードベースを生かして一時的にノードを繋ぎ変えて処理をバイパスしたり別の処理を挟んだりすることができます。ソフトではできなくて、コンポジットソフトでおこなう操作に近い感覚です。chiyama必要な要素技術は一通り揃ったので、アセットチェック時に使用するシーンを作成してみます。ファイルで読み込みアセットとカメラを別々に回転させるあたりができればとりあえず使えそうです。カラーチャートとボールを作成します。いった階層に作成します。続いて、画面へのチャートの固定をおこないます。画面への固定は二段階に分けて処理しています。カメラと同位置にコンストレインします。次にそこからのオフセットとして画面への固定をおこないます。用いればよいようです。サイズにスケールをすることができます。この方法を使ってカラーチャートなどを画面に固定します。元に位置の計算をすることもできるので、画角が変わっても画面上の大きさや位置は変わらず固定することもできます。ファイルを読み込むと以下のようになります。これでカメラが動いても画角が変わってもカラーチャートは常に画面の特定の場所に固定されたままアセットを確認することができます。今日はここまでにして、シェーダのアサインやアニメーション、レンダリング周りの解説は明日おこないます。