Philosophy of Hiroshi
キーフレームアニメーションが出来たらコンストレインがしたくなります(よね?）。
コンストレインも KATANA 上ではノードとパスで指定することができます。コンストレインの種類に関してはマニュアルを見てみてください。
試しに、Teapot の回転から板の回転への接続をしてみました。
見ての通り、板の回転が Teapot に追従しています。ちなみに、コンストレイン元のオブジェクトを手で編集しても、コンストレイン先のオブジェクトがリアルタイムに更新されるわけではないようです。編集終了後、何らかのタイミングで更新されるようです。
ちなみに、今回はメインの流れから分岐してコンストレインを試したので、本流側のレンダリングをおこなうシーン上ではコンストレインはおこなわれていないです。
このように、ちょっと別のラインを作って試すことができるのはノードベースで処理しているメリットですね。
ターンテーブル用のリグを作成したり、ショットでライティングをおこなう場合には KATANA 上でもキーフレームアニメーションが必要になってきます。ということで、キーフレームアニメーションをおこなってみます。
まあ、正直ここはマニュアルを見ればわかるのでそちらをどうぞと言いたいくらい、あんまり特筆すべきことも無いのです。笑。
アニメーションをつけるときに他の DCCTool と大きく異なるのがオートキーモードの扱いです。KATANA では、オートキーはパラメータ毎のモードとして管理され、オンにしたパラメータのみ自動的にキーが打たれます。
オートキーでない場合、パラメータ上で右クリック→Key でキーが打たれます。
作成されたアニメーションカーブは Curve Editor で確認・編集できます。キーフレームが打たれたパラメータには Curve Editor 上で表示・非表示を切り替えるためのアイコンが出てくるので、それを使います。
アニメーションの細かい調整は Curve Editor でおこないます。
ある方から昨日の記事について情報を頂いたので追記します。
昨日の記事では、テクスチャをアサインしてレンダリングして色が合いましたねということでサラッと流してしまっていたのですが、内部でどのように扱われて色が合ったのか理解しておく必要がありますよねというご指摘をいただきました。確かにそうなので説明をします。
そして。チョロッと機能説明をすればサラッと終るかと思ったら、いろいろ調べ始めたらなかなかの沼に;;色管理恐ろしす。そして、改めて自分色管理周りわかってないなぁと実感することしきりです。
まず、KATANA はあくまでもレンダラが処理するシーンデータを作るためのフロトエンドでしかなく、シーンデータを生成してしまった後はレンダリング時に何か処理をすることは無いという前提があります。そのため、 KATANA で作成した image ノードで指定されたファイルの中身がどのように解釈されるかは、Arnold の Image ノード次第ということになります。
ここで、KATANA の image ノードでは、指定されたファイルの色空間をどのように解釈するか指示するパラメータとして color_space があります。
通常は auto を指定すればよいです。ここで指定された値は KATANA が自動的に何かを解釈してレンダラに指示をするという意味ではなく、文字通り “auto” という値を Arnold の image ノードに渡すという意味になります。
“auto” が渡されたときに Image ノードがどのように解釈するかはArnold のマニュアルに書いてあります。
The default value ‘auto’ will use sRGB for integer (8 or 16 bit) formats and linear otherwise.
8bit や 16bit の整数型フォーマットであれば sRGB を想定し、そうでなければリニアな画像が格納されているものとして扱うとのことです。今回は 8bit の png ファイルを指定したので、ここで sRGB → リニア 変換がおこなわれます。
その後、Arnold 内ではリニアなデータとして扱われ、画像がレンダリングされます。
レンダリングされた画像はそのままでは人間が見た時に望んだ色には見えないため、LUT を適用します。この LUT がデフォルトでは sRGB なので、最終的に見慣れたカラーチャートが表示されたのです。
ちなみに、Arnold 内部で色空間がどのように扱われるのか知らなかったので調べてみたところ、OCIO Color Manager が管理しているようです。
おそらく、Color Manager 関連の指定を何もしない場合は Built-in Color Manaer が適用され、sRGB linear が内部で使用する色空間ということになるのかなと思います。
この指定は NetworkMaterial ノードで Add Terminal をすると追加することができ、どうもこれを使っていろいろするらしいというところまでは調べました。具体的な使用方法は今後の課題です。ちょっとこの辺りはちゃんと調べてみないとわからないところだらけです。
lookDev をするための準備ができたので、本格的な lookDev 環境を作っていきます。そのためにはカラーチャートやグレーボール、クロームボールを作る必要があります。
グレーボールやクロームボールはこれまでの知識でできそうですが、カラーチャートはオブジェクトにテクスチャを貼らなければいけないので新しい知識が必要になります。
ということで、テクスチャを貼ってみます。
まずは PrimitiveCreate ノードを作り、type を poly plane にします。そして、貼り付ける画像に合わせて scale 値を入力します。
続いてマテリアルです。 NetworkMaterial ノードと ArnoldShadingNode を作り、それぞれ colorchart_Mtl と surface_shader と名前をつけます。
そして、surface_shader の nodeType を standard にし、Kd を 1 にします。
続いて、surface_shader の out を colorchart_Mtl の arnoldSurface に接続し、マテリアルをアサインします。ここまではほとんど”KATANA+Arnold でシェーディング&ライティング“でやったのと同じ内容ですね。
更にもう一つ ArnoldShadingNode を作り、名前を colorchart_file とし、 filename でカラーチャート画像へのパスを指定します。
そして、 colorchart_file ノードの出力側をクリックして out を選び、surface_shader の入力側をクリックして Diffuse>Kd_color を選んで接続します。
これでレンダリングをおこなってみます。
元のカラーチャートの色も再現できていますし、バッチリです 🙂
レンダリングが一通りできるようになったので LookFile を用いた Look Development をおこなってみます。
まずは Look File を作ります。
Look File を作るのは LookFileBake ノードの役割です。 LookFileBake ノードには入力が二つあり、orig にはマテリアル等をアサインする前のジオメトリをつなぎ、default にはマテリアルアサイン後のジオメトリを繋ぎます。LookFileBake ノードはこの二つの入力の差分を見て、どのような処理をするのか解析します。
図のグラフは、これまで作成したうちのアセットとマテリアル部分を切り出して LookFileBake に繋げたものです。
ちなみにスクリーンショット中でグラフを分岐するのに使っているのは Dot というノードです。
LookFileBake ノードでは、どのパスを処理するのかを CEL で指定し、LookFile の出力先を saveTo で指定します。今回は CEL に passes を使用し、/root/world を指定しています。
準備が整ったら Write Look File を押すとファイルの保存先が聞かれたうえで Look File(.klf ファイル) が作成されます。
これで LookFile ができたので、これを使ってマテリアルをアサインしてみます。
ここで使うのは LookFileAssign ノードと LookFileResolve ノードです。最初、LookFileResolve ノードの存在を見落としていて思った通りの結果にならずハマりました。。。
LookFileAssign ノードにオリジナルのジオメトリを入力し、 CEL と先ほど作成した LookFile のパスを指定するとシェーダ情報が再現されます。LookFileResolve は特にパラメータを指定しなくても良いです。
ではレンダリングをしてみます。
これで LoodDev 情報とショットで使用するグラフを分離することができました。これ以降は LookDev はアセットワークとして行い、LookFile を使うことでショット側ではアセットワークとは独立して作業を進めることができます。
レンダリングした履歴を取っておいて、パラメータの調整をしながら比較したい時があります。
この時に便利なのが Catalog タブと、Monitor の Swipe です。
まず、レンダリングの履歴は Catalog タブで確認できます。Monitor から Catalog の内容を確認したい場合は Monitor 上で Tab キーを押します。
Catalog 上で、サムネイルの左側の部分を左クリックもしくは右クリックをすると、Monitor の Front と Back を指定できます。
更に、Monitor 上で Swipe タイプを選ぶと Front/Back をスワイプしながら比較することができます。
ライティングもできるようになったことですし、次にやることと言ったら HDR 画像を使用した Image-based Lighting(IBL) と相場は決まっています(よね?)。
ということで HDR 画像を使用した IBL を試します。
これはとても簡単で、GafferThree ノードで Arnold HDRI Skydome Light を作成し、Material タブの arnoldSurfaceShader で filename を指定するだけです。
HDRI 画像は HDRI HAVEN の San Giuseppe Bridge と Vignaioli Night を使用しています。
レンダリング結果は以下の通りです。何となくそれっぽくレンダリングされています。
ただ、この結果が本当に正しいのかはよくわからないですね。このあたりの検証環境をもうちょっときちんと作ってやる必要がありそうです。
昨日は LightCreate ノードと Material ノードを使ってライティングをおこないました。
実は KATANA にはライトの管理をもっと簡単に行うための GafferThree ノードがあって、実際の現場でも専らこれが使われているそうです。そこで、今日は GafferThree ノードを取り上げます。ドキュメントは “Getting to Grips with the GafferThree Node” にあります。
まず、GafferThree ノードを作って Gaffer Object Table 上で右クリック→Add→Light でライトを追加します。
続いてライトにシェーダを追加します。作成したライトを選択し、Material タブ上で Add Shader プルダウンから arnold→light を選びます。そして arnoldLightShader を skydome_light に変更します。
このあたりの手続きは LightCreate と Material でやっていたのと同じですね。
そして、昨日のライトのかわりに GafferThree ノードを Merge に繋ぎます。
そしてレンダリング。
レンダリングかくにん。よかった！
KATANA といえば lookdev&Lighting ツールということで、ついにシェーディングとライティングをおこなってみます。
本当はマテリアルとライトで二回に分けて記事を稼ごうかとわかりやすくしようかと思ったんですが、マテリアルをアサインした場合はこれまで使っていた素のマテリアルと違ってライトを置いてやらないと反応してくれず、真っ黒になってしまうのでこの二つは一緒におこなう必要がありました。おかげで長いです。書くのもむちゃんこ疲れました、、、
そのため、今回は極力手順を簡単にするために、arnold の car paint シェーダを使用し、ライティングはドームライトのみを用いるようにします。
まずはマテリアルの作成からおこないます。マテリアルの作成には
の二つを使用します。NetworkMaterial がいわゆるマテリアル本体で、オブジェクトへのアサインをおこなう場合もこれを指定します。ArnoldShadingNode はマテリアル中のシェーダーノードで、具体的な計算内容やパラメータを扱います。
上記二つのノードを作成したら、最初にマテリアルのインターフェースを作成します。NetworkMaterial のパラメータ内で Add Terminal をクリックし、arnold グループから surface を選びます。こうすることで、ノードへの入力口(Port)が作成されます。下図で arnoldSurface と表示されているのが作成した Port です。
続いて ArnoldShadingNode 中で nodeType を car_paint にします。これで、このノードは car paint shader として機能するようになります。
マテリアルが定義できたので、メインキャラクタにアサインします。まずはメインキャラクタのツリーとマテリアルのツリーをマージし、MaterialAssign ノードでマテリアルをアサインします。ここでももうおなじみの CEL を使用します。Statement にアサインするジオメトリを指定し、materialAssign でアサインするマテリアルを指定します。図では見えないですが、ツリー中に /root/materials/NetworkMaterial があるので、それを中ボダンドラッグアンドドロップで指定できます。
続いてライトを作成します。こちらも二つ、
の二つのノードを作成します。LightCreate は名前の通りライト(になるノード)を作成し、Material でライトの機能を作るイメージです。ライトの機能は別になっているため、LightCreate だけではレンダリング時にライトとして作用しません。
Material では Add Shader で arnold グループから light を選びます。更に、arnoldLightShader として skydome_light を選びます。
私は、Material ノードはシェーダと MaterialNetwork を一つにまとめたもので、よく使って簡単な構成なマテリアルを作る際に一々 MaterialNetwork などをいろいろ作らなくても良いように用意されたノードで、同様なことはこれが無くても実現できるものだと理解しています。
続いて、先ほどと同様ノードにマテリアルをアサインします。
ここまで来たらあと一息です。長かったです。。。。(-。-)y-゜゜゜
全てのノードをエイヤっ!!とマージします。
左がカメラ、真ん中がマテリアルをアサインしたメインキャラクタ、右側がライトです。これまでの流れが追いかけることができていればもう簡単ですね。
では待望のッ!!レンダリングをしてみましょうッ!!
できました!!やったね!!
昨日の記事で、まだご紹介していなかったノードが映りこんでしまっていたのでついでにご紹介します。
オブジェクトへのアトリビュートの付与と同様、カメラについても Arnold 特有のアトリビュートを追加して細かく調整することができます。
これには ArnoldCameraSettings ノードを使用します。下図を見ての通り、たくさんのプロパティを編集することができます。どのカメラに対して適用するかは、昨日も出てきた CEL で指定します。今回はパスを直接指定できる Path タイプのステートメントを使用してみます。
登録はとても簡単で、Scene Graph から目的のオブジェクトをマウス中ボタンドラッグアンドドロップで放り込むことでできます。
試しに exposure を変えてみます。左がデフォルト、右が +1 したものです。見ての通り美白肌が一段と強調されています。
