HUD や LookDev 用のカラーチャートを画面から一定の位置に配置したい場合が時々あります。特に KATANA は LookDev にも使用するので頻出機能と言えるでしょう。

画面の一定の場所にオブジェクトを配置するためには、カメラの移動はもちろん画角の変更にも合わせて位置を調整する必要があります。こういう時に活躍するのがエクスプレッションです。

。。。。と思っていろいろ試したのが、KATANA のエクスプレッションは思っていた以上に制限がきついのかもしれません。エクスプレッションとして記述できるのは式だけなようで、代入文すらも使用するとエラーになってしまいます。たとえば

getNode(“CameraCreate”).fov

のように他のパラメータを参照するだけなら OK ですが

v = getNode(“CameraCreate”).fov
v

というように、代入文を使用するとエラーになってしまいます。うーーーん。。。これは。。。

それから、transform.translate.x のようにスカラ型のパラメータに対して式を設定することはできたのですが、transform.translate のような vector 型のパラメータに対して式を設定しようとしてもエラーになってしまいます。

getNode(“CameraCreate”).transform.translate

のように直接値を取得する分にはうまくいっているので、何か方法はあると思うのですが。

とりあえず力業で画面への固定配置をおこなってみました。球を画面右寄りに固定配置しています。立方体と比べると、カメラの画角が変わることで立方体の見た目は大きく変わっているのに対し球は画角の変化による歪みだけで画面上の大きさは変化していないです。そして、三次元空間上で比べると球の位置と大きさが変化していることがわかります。

ただ、、、うーん。これだとちょっと実用的ではないのでもう少し調べる必要がありそうです。

キーフレームアニメーション、コンストレインと来たら次にやることは只一つ、エクスプレッションです。

コンストレインは単純にあるパラメータと別のパラメータを繋げることには適していますが、複数のパラメータを元にあるルールに沿って計算した値を使って別のパラメータを動かすような用途には使うことができません。

たとえばルックデブ用セットアップで良くある、カメラから見た特定の位置に常にカラーチャートやグレーボールを配置したいような場合です。この場合、画角によってオブジェクトの三次元空間上の位置を変更しなければいけないです。このようなときにエクスプレッションを使用します。

エクスプレッションに関しては User Gide には詳細な記述は無いようで、Developer Guide の Python Expressions あたりを参照すれば良さそうです。Python Expression とは言っているのですが、どうもネイティブな Python をそのまま使っているわけではなく、ある程度制限があるようです。

エクスプレッションを適用するには、エクスプレッションを適用したいパラメータ上で右クリックをして Expression を選ぶと、パラメータに式を記述することができるようになります。

今回はカメラの FOV に応じて値を示すメモリが上下するようなサンプルを作成してみました。下図がそのノード構成になります。

gage と value で /root/world/geo/fov 以下にオブジェクトを生成するようにし、Transform3D ノードで fov 階層を適切な場所に移動しています。

value の Y 位置が CameraCreate ノードで作成したカメラの fov 値を参照しているため、カメラの画角が変わると value の位置も変わります。

この例では単純に fov 値を取得しているだけですが、ここに式を記述することでもっと複雑なこともできます。

キーフレームアニメーションが出来たらコンストレインがしたくなります(よね?）。

コンストレインも 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 に繋ぎます。

そしてレンダリング。

レンダリングかくにん。よかった！