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

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 スクリプトで各種操作をおこなうという流れのようです。

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

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 値を取得しているだけですが、ここに式を記述することでもっと複雑なこともできます。