リグの情報をジオメトリキャッシュに埋め込んで、その情報を元にシェーダのパラメータを指定したいような場合がよくあります。たとえば皺用ディスプレイスメントとか色を変化させるような場合ですね。

この場合、AttributeSet ノードを使用してアトリビュートを上書きすることで実現できます。

今回はマテリアルの色を上書きしてみます。

AttributeSet ノードを作成した後、パラメータを上書きしたいノード(/root/materials/zombie_Mtl)を指定し、上書きしたいアトリビュートを attributeName で指定します。これは Attributes タブから簡単に探すことができます。

今回は base という float 値なので attributeType を float にし、numberValue は 1×1 で値を 0.0 にします。

すると、元の suaface_shader ノードでは 1.0 を指定して赤色になっていたジオメトリが黒色になりました。
値は他のパラメータと同様アニメーションカーブをアサインできたり、Expression で他のところから値を取得することができるので、好きなところから値を参照することができます。

これまで作ってきたような単純な例ならいいのですが、本番で使おうとするとこの何十倍も複雑なシーンを扱わなければいけなくなります。

そんなときでも Node Graph を整理するための便利ノードが幾つか用意されています。

Backdrop ノード

ノードを処理単位で枠で囲ってコメントを書くことができるノードです。これは通常のノードを作るのと同様、Tab→Backdrop でも作成できますし、囲いたいノードを選択した状態で Edit→Fit Backdrop Node to Selected Nodes でも作成できます。

作成後、ダブルクリックでノードの編集用ダイアログが開き、そこでメッセージや色の指定ができます。

Grouping ノード

Node Graph の一部をグループ化して、見た目上一つのノードとして扱うことができるノードです。

グループ化したいノードを選択してから ‘g’ キーを押すと、シュルシュルッと一つのノードにまとまります。

見た目は一つのノードですが、内部の構成はそのまま残っていてノードの + ボタンを押すと中を確認することができます。

Dot ノード

これは既に使っていますね。ノード間を接続しているエッジを曲げたり分岐したりするのに使います。Tab→Dot で作成できます。

これらのノードを使用して Node Graph の構成を綺麗に保つことはとても大事です。試行錯誤中はどうしてもノードが汚くなってしまいがちですが、そのままでは他の人が見た時にどこで何の処理をしているのか把握するのが難しくなってしまいますし、作った本人ですら時間が経つと細かい内容を忘れてしまいます。

そのようなことが無いよう、常日頃から綺麗なノード構成になるよう心掛けておくことが大事です。心の乱れはグラフの乱れ、グラフの乱れは作品の乱れ。南無～

レンダリングシーンのデバッグ目的やシーンの最適化をおこなうときに、レンダラにどのようなデータが渡っているのかを確認するためにレンダラが直接解釈できるファイルに出力するのは皆さんよくやりますよね。

KATANA から Arnold にどのような情報が渡っているかを確認する場合、スクリプトを使って .ass ファイルを出力することができます。

これには Python タブで

filename = r'/home/chiyama/Documents/katanta/lookdev/turntable/turntable.0001.ass'
node = NodegraphAPI.GetNode('Render')
NodeDebugOutput.WriteRenderOutput(node, 'arnold', filename=filename)

のようなコードを実行します。これでカレントフレームを Render ノードでレンダリングする際の .ass ファイルが出力されます。

このファイルを Arnold でレンダリングするためには kick コマンドを使用します。kick コマンドを始め Arnold でレンダリングするのに必要なプログラムは全て KtoA に含まれているようで、

$ /opt/KtoA-2.2.1.0-kat3.0-linux/bin/kick turntable.0001.ass

のようにしてレンダリングできます。

.ass ファイルはテキストファイルなのでエディタで編集可能です。今回は試しに出力先のパスとレンダリング解像度を変えてレンダリングしてみました。

図の通り、KATANA 無しでコマンドラインからレンダリングをすることができています。

ちなみに、このような方法で出力した .ass ファイルにはジオメトリデータが全て展開された形で出力されてしまうため、ファイルサイズが大きくなりがちです。今回の例では約 1MB になりました。

キャラクタ部分は Alembic ファイルになっているので、そのまま Arnold に渡してくれると嬉しいのですが。KATANA の仕組み上しょうがないのかなと思いつつ、ちょっと惜しいです。

あと、ジオメトリやシェーダの情報がエンコードされた形式で出てしまうのでその部分の詳細情報が確認できないのが残念です。もしかしたら Arnold の機能で plain text 形式に変換できるのかもしれませんが。

Lookdev 環境も作り、チェック用のターンテーブルも作成したら後やることと言ったら連番画像のレンダリングです。

KATANA は標準では GUI から連番画像のレンダリングには対応しておらず、コマンドラインからのバッチレンダリングをおこないます。

バッチレンダリングをおこなうためには KATANA にバッチレンダリング用の引数を渡して実行する必要がありますが、”KATANA+Arnold でレンダリング” でArnold を有効にするために起動用の sh スクリプト経由で KATANA を立ち上げるようにしています。そこで、このスクリプトを少し改変して引数も受け付けるようにします。

#!/bin/sh
export KATANA_ROOT=/opt/Katana3.0v6
export DEFAULT_RENDERER=arnold
export KTOA_ROOT=/opt/KtoA-2.2.1.0-kat3.0-linux
export "KATANTA_TAGLINE=With KtoA 2.2.1.0"
export KATANA_RESOURCES=$KTOA_ROOT
export PATH=$KATANA_ROOT/bin:$KTOA_ROOT/bin:$PATH
export PYTHONPATH=${KTOA_ROOT}/python:$PYTHONPATH
$KATANA_ROOT/bin/katanaBin "$@"

最後の行を編集しているだけです。これで OK です。

レンダリング先の出力設定は RenderOutputDefine ノードでおこないます。

outputName に Render ノードで指定する出力名(今回は beauty としました)、type は今回は color、 colorSpace は sRGB にします。そして、カメラはシーン中にある、レンダリングに使用したいものを選びます。

locationType を file にすると renderLocation で出力先ファイル名を指定できるようになります。指定先ファイル名は /path/to/render.####.exr という形式で指定します。

出力先指定が出来たら Render ノードの設定をおこないます。

そして、ここは注意事項なのですが私の環境では一度 Render ノードでレンダリングをおこなわないと出力先として RenderOutputDefine で指定した outputName が表示されなかったです。

レンダリングをおこなうなどして beauty が選択可能になったことを確認したらファイルを保存します。

さて、レンダリングです。ターミナル上で

$ ~/katana.sh –batch –katana-file=./turntable.katana –render-node=Render -t 1-100

のように実行します。パスやフレームレンジは適宜読み替えてください。

Arnold のレンダリングログが出力され、レンダリングが始まります。ちなみに、この実行モードは Batch モードといい、KATANA の GUI を使用するためのライセンス(インタラクティブライセンス)とは別のバッチライセンスが必要になります。

そんなこんなでレンダリングしてムービー化してみました。ターンテーブルとしてはいろいろとどうなの?というところはいろいろありますが(汗、とりあえずできました。やったね!!

これまでの内容で、KATANA 上での Lookdev からチェック用シーンを作成するまでに必要な知識は全て整いました(多少、流れに合わせて調整が必要な部分はありますが)。

そこで、これらの知識を活用して一通りの流れを作ってみました。

まず、Lookdev 用のシーンです。

Lookdev 用のシーンでは、.abc 化されたアセット(本来はアニメーションはついてないですが、今回は無かったのでアニメーションつきのもので代用しています)を読み込み、それに対してシェーダの設定をおこないます。

作業中、確認のためにレンダリング用の設定が必要なので、それも事前に用意しておきます。

作業後、Look ファイルを出力する必要があるので、 Alembic_in と MaterialAssign の比較を行って Look ファイルの出力をおこなうようにします。

Lookdev アーティストは Node Graph の Lookdev 領域を主に操作し、Look ファイルを成果物として出力します。

続いてチェック用のレンダリング画像を作成するシーンです。

チェック用のターンテーブルを使用してレンダリングをおこなう場合はアセットと Look ファイルを読み込みます。

更に、リファレンスに使用するカラーチャートやボールを常に画面上の同じ位置にあるように配置します。

Node Graph を見ての通り、チェック用アセットで読み込んでいるアセットとLookファイルの二つのファイルを差し替えるだけでよく、ターンテーブルはそのまま使用できます(厳密にはアセットのサイズごとにカメラを調整するような仕組みが必要ですが)。

また、ショット用のシーンもチェック用のシーンとやることは同じです。作業するセクション毎にカメラやライトのデータを作りながら徐々に KATANA シーンの内部をリファレンスに置き換えていくことで最終的なシーンまで構築できます。

昨日の “KATANA シーンのデバッグ” で説明が正確でなかった部分を KATANA 警察の方からご指摘いただいたので詳細情報の追加をします。

昨日の記事では、Attributes タブで表示される内容は “現在選択中のノード” と記述していたのですが、KATANA ではこれが少々複雑で、同時に複数の選択状態が存在します。これが結構厄介で、オペレーションをしているときの勘違いの元になって延々ハマる原因にもなっています。

ハマるからと言ってソフトウェアの造りが悪いのかといったら全くそんなことは無く、これがあるから強力かつ使いやすいツールになっているので結局はきちんと理解して使いこなしましょうということになります。

まず、 Node Graph 上でノードの左側をクリック(もしくは v キーを押下)して青色表示になったのが、そのノードに view フラグがセットされた状態になります。これが現在 Scene Graph 上で確認できるシーンの階層だったり、Viewer で確認できるシーンの見た目になります。

次に、Node Graph 上でノードの右側をクリック(もしくは e キーを押下)して緑色表示になったのが、そのノードに edit フラグがセットされた状態になります。このフラグがセットされたノードの情報が Parameters タブに表示され、パラメータの編集が可能になります。

それから、Node Graph 上でノードを選択した状態です。この時、ノードの外枠が黄色になります。これは Node Graph 内での選択状態で、ノードを移動したり削除することができます。

Node Graph にはもう一つ、マウスカーソルの位置も意味があります。Node Graph 中でのショートカットキーはマウスカーソルの位置にあるノードに対して効きます。図の例では、TransformEdit ノード上で d を押したことでこのノードが無効な状態になっています。

最後に、view フラグがセットされたノードのシーン内での選択です。これは Viewer や Scene Graph 中で選択します。Attributes タブはここで選択されたオブジェクトの情報を表示します。

以上です。最初はいろいろ戸惑うこともありますし、Parameters で CEL を指定するときに全然関係ないノードの階層情報を見ていたせいで思った通りに処理がされなくてハマるということも多々あるのですが、これらをきちんと意識して使い分けることが KATANA というソフトに慣れるための大きな一歩になります。

KATANA でシーンを作っていると、思った通りの結果にならなかったり、シーンがどのような状態か知りたくなる時があります。

Gaffer でも似たようなことがあって、チュートリアル動画を見ていてもちょっとしたミスで思った通りの結果にならなくて解説をしている人がオロオロしながら原因を探る(そして動画が一時止まるw)ということが結構あります。この辺りはノードベースでシーンデータを扱っているツールの持つ難しさがある所だなと感じています。

そのようなときにも KATANA は強力な手段を提供してくれています。

まず、 Attributes タブです。OpScript でカメラの fov を探すときにも使いましたね。

これが凄いのは、ノードを辿った時に変更前後を簡単に確認できることです。

現在選択中のノード(※)のアトリビュートの情報を確認することができる上にノードベースで履歴を辿ることができるため、CEL の指定の失敗によって思った通りの情報が適用されていないような場合や、OpScript ノードで書いた処理の確認をするのに重宝します。

※この記述は正確ではなかったです。詳細情報を “KATANA 上での情報の表示” にまとめたので、そちらをご覧ください。

もう一つが Render Log です。これは名前の通りレンダラが出力したログを見ることができます。ユーザーは KATANA を介してはいるものの、ほぼ直接と言っていいほどダイレクトにレンダラにアクセスしているため、ユーザーがおかしな操作をしてしまうと簡単に不正なレンダリング結果が出力されてしまいます。このような場合、レンダラのログを読むことで問題解決の糸口を掴むことができる場合が多いです。

そのほかにもレンダリング時間や使用メモリ、その他詳細な統計情報も確認できるので、とても重要な情報源です。

KATANA や Arnold に限らず、レンダラのログを読むだけでトラブルの原因を簡単に突き止めることができることってすごく多いんですよ。デザイナーさんは全然読んでくれないんですけど 😉

それ以外にも、ノードを選択して ‘d’ を押すとノードをオンオフすることができます。オフにするとそのノードの処理はおこなわれないため、デバッグには重宝します。

あとはノードベースを生かして一時的にノードを繋ぎ変えて処理をバイパスしたり別の処理を挟んだりすることができます。これも普通の CG ソフトではできなくて、コンポジットソフトでおこなう操作に近い感覚です。

。。。。と、Lookdev 環境を作って記事にしようかと思ったらシーンのデバッグにドハマりした私からのご報告でした☆

必要な要素技術は一通り揃ったので、アセットチェック時に使用するシーンを作成してみます。
内容としては

• カラーチャート、グレーボール、クロムボールをカメラから見た特定の位置に固定
• アセットは Alembic ファイルで読み込み
• アセットとカメラを別々に回転させる

あたりができればとりあえず使えそうです。

まずはカラーチャートとボールを作成します。これらは後でカメラにコンストレインしたいので、/root/world/geo/chart/color_chart といった階層に作成します。コンストレインは chart 階層でおこないます。

続いて、画面へのチャートの固定をおこないます。

画面への固定は二段階に分けて処理しています。

最初に、/root/world/geo/chart をカメラと同位置にコンストレインします。次にそこからのオフセットとして画面への固定をおこないます。

fit_chart_to_screen が OpScript ノードです。オフセットとして位置情報を与えるには GroupBuilder を用いればよいようです。たとえば

local translation = {0, 100, 0} -- Move in +Y
local rotationY = {180, 1, 0, 0} -- Rotate a quarter turn around X axis
local scale = {0.5, 0.5, 0.5} -- Halve the size of the pony
-- Create a GroupBuilder and set some values
local gb = GroupBuilder()
gb:set("translate", DoubleAttribute(translation))
gb:set("rotateZ", DoubleAttribute(rotationY))
gb:set("scale", DoubleAttribute(scale))
-- Build a GroupAttribute and assign it to xform.group0
local groupAttr = gb:build()
Interface.SetAttr("xform.group0", groupAttr)

このようにすると、既存の姿勢から更に Y 方向に +100 移動、 X 軸で180度回転、1/2 サイズにスケールをすることができます。

この方法を使ってカラーチャートなどを画面に固定します。もちろん、昨日やったようにカメラの fov を元に位置の計算をすることもできるので、画角が変わっても画面上の大きさや位置は変わらず固定することもできます。

更にアセットとして Alembic ファイルを読み込むと以下のようになります。

これでカメラが動いても画角が変わってもカラーチャートは常に画面の特定の場所に固定されたままアセットを確認することができます。

今日はここまでにして、シェーダのアサインやアニメーション、レンダリング周りの解説は明日おこないます。

本格的に OpScript を触ってみます。多分、スクリプトを書くにあたって一番参考になるのは The Op API でしょう。こちらは C++ 用 API のドキュメントですが、ほぼそのまま Lua で使用できるようになっているようです。よくある言語間の読み替えをしていけば何とかなるんじゃないかとおもいます。

それからサンプルシーン(opscript_tutorial.katana) と OpScript Tutorials があればまあ何とかなるんじゃないかとメドを立ててとりあえず手を動かしてみましょう。

今回は KATANA で Expression でやったのと同じことを OpScript を使ってやってみることにします。

カメラからのパラメータを取得するときに、どのような名前でアクセスすればいいかは Attributes タブで確認できます。画角は geometry.fov で取得できそうです。

アトリビュートの取得方法は API ドキュメントを確認したら

Interface.GetAttr(アトリビュート名, パス):getValue()

でいけそうで、アトリビュートの更新はサンプルを見るとそのままのことが書いてあるので流用します。

ちなみに、Parameters タブ内の領域でもコードは書けるんですがものすごく書きづらいです。その場合は “Edit in External Editor” ボタンを押すと外部のエディタが立ち上がって、そちらで編集できます。エディタ上でファイルを保存すると即座に反映されるので便利です。

そんなこんなでできました。やってみれば簡単ですね♪

昨日の記事でハマったように、エクスプレッションは値を参照するくらいにしか使わず、複雑な処理は OpScript ノードを使用するということを教えて頂けたので、OpScript ノードを試してみます。

ちょっと厄介なことに OpScript ノードは Lua で書かないといけないみたいなんですよね。一つのアプリケーションに複数のスクリプト言語が同居しますか～。。

OpScript のチュートリアルで使うファイルは Help→Example Projects の Katana 203 – Scripting にあります。このファイルは $KATANA_HOME/demos/katana_files/opscript_tutorial.katana にあるので、そちらを直接開いてもいいようです。

(というか、Example Projects メニューの存在を初めて知ったよﾏﾏﾝ!!!!)

基本は CEL で処理対象をフィルタリングして、Lua スクリプトで各種操作をおこなうという流れのようです。

ちょっと今日は体力の限界なのでこのサンプルを眺めるだけでおしまい～