ハリウッドVFX業界就職の手引き

ハリウッドVFX業界就職の手引き
鍋潤太郎氏による、海外のVFX業界で働くための手引き。お薦めです。

2016年7月7日木曜日

Shotgunを使ってみる その4

木村でございます。「Shotgunを使ってみる」と題した連載の最終回は前回予告しました通り、Shotgunのイベント・フレームワークについて説明したいと思います。ところで前回、このブログで初めてプログラムのコードを掲載したわけですが、ブログのコラムの横幅が狭くてすぐコードが折り返されてしまう、ということが判明しました。非常に見づらいのでこのブログのデザインを変更した方がいいのかもしれませんが、ちょっと今回はこのまま行きたいと思います。ちなみに巷にはコードの表示部分に横スクロール・バーのついたものとかありますが、あれどうやってるんですかね。JavaScriptとか入れないといけないんでしょうか。

さて、本題のイベント・フレームワークですが、まずそもそもこれがなんなのかを説明しないといけないでしょう。Shotgunのウェブ・アプリケーションやAPIを使って様々なデータを変更すると、Shotgunはそれをイベントとして記録しています。そしてこのイベントが発生した時に、ユーザーが定義した独自の動作を行わせるようにすることができるのです。これはGUIのあるプログラムが、ユーザーがマウスやキーボードを使ってなんらかの動作をした時に、それをイベントとして受け取り、動作するのと似たような仕組みです。

ただし、Shotgunはこうしたイベントに対するコールバックのカスタム定義をサーバー側で受け付けているわけではありません。ではどうするかというと、イベントが発生した際、そのイベント・シグナルをネットを通してユーザー側に送り、ユーザーはそのイベントを受け付けるデーモン(コンピュータ上でバックグラウンド・プロセスとして走るプログラム)を自分のコンピュータ上で走らせて、コールバック・プログラムを呼び出すのです。すなわち、この機能を利用するためには、ユーザー側がアプリケーション・サーバーを用意する必要があります。と言ってもアプリケーション・サーバーはPythonさえ起動できればいいので、それほど高性能である必要はありません。

Shotgunのイベント・フレームワークは前回紹介したAPIだけでは利用することができません。GitHubにイベント・フレームワークのリポジトリがありますので、そこからダウンロードしてきて利用します。

https://github.com/shotgunsoftware/shotgunEvents

このフレームワークの基本的な仕組みは、Shotgunの以下のドキュメントに記載されています。

"How to write event driven triggers"

では実際にイベント・機能を利用してみましょう。

インストールと設定

ダウンロードしたら、srcというフォルダにあるshotgunEventDaemon.pyというスクリプトがデーモンとして走るプログラムになります。このプログラムはユーザーが別個定義したプラグインを走らせることができるようになっており、そのサンプルがexamplePluginsというフォルダにありますので、これを参考にして書くのが手っ取り早いでしょう。shotgunEventDaemon.pyを起動させるには設定ファイルが必要ですが、これもやはりサンプルがあり、同じフォルダに入っているshotgunEventDaemon.conf.exampleというファイルがそれです。このファイルをshotgunEventDaemon.confという名前でコピーし(オリジナルは保存しておき、再度設定しなおさなければならい時などに参照するといいでしょう)、中身を書きかえます。最低限度書き換えなければならないのは、以下の4つの項目です。
  1. server
  2. paths
  3. name
  4. key
1はご自分のShotgunサイトのURLを指定します。2にはプラグインの置いてある場所を指定しますが、複数の場所に分けている場合は、コンマで区切って指定します。3と4は前回ご説明したAPIを使うときに必要なScriptの名前とアプリケーション・キーです。つまり、このイベント・フレームワークを使う場合も最低限度1つはアプリケーション・キーが必要になる、ということです。

設定ファイルの書き換えが済んだら、プラグインを用意します。ここではとりあえずサンプルにあるstatusFlipDownstreamTasks.pyというプラグインを見てみましょう。これはディペンデンシィが設定されているタスクに働くプラグインです。下流のタスクのステータスがwgt(ウェイティング)の時、上流のタスクのステータスが全てfin(終了)になったら、下流タスクのステータスをwgtからrdy(作業が始められる状態)に切り替える、というものです。これは例えば、ライティングのタスクのダウンストリーム・タスクにコンポジットなどを設定しておけば、ライティングの作業が終了した時に、コンポジット・アーティストに彼らの作業が始められる合図を送ることができます。

このプラグインのコード中には以下のような一文が出てきます。

reg.registerCallback('$DEMO_SCRIPT_NAME$', '$DEMO_API_KEY$', flipDownstreamTasks, matchEvents, None)

これはプラグインをコールバックとして登録するためのもので、$DEMO_SCRIPT_NAME$と$DEMO_API_KEY$は、それぞれ設定ファイルに記述したのと同じスクリプト名とアプリケーション・キーで書き換えます。flipDownstreamTasksは実際の動作を定義した関数へのリファレンスで、自分で内容をカスタマイズする場合は、この関数の動作を変更すればいいわけです。この関数へは引数としてShotgunクラスのインスタンスが渡りますから、あとは通常のAPIと同じ書き方で、Shotgunのデータベースにアクセスすることができます。

デーモンを走らせる

設定とプラグインの用意ができたら、デーモンを走らせます。ますはプログラムをフォアグランドで走らせて、動作チェックをするといいでしょう。

sudo ./shotgunEventDaemon.py foreground

プラグインがロードされたのを確認したら、Shotgunのウェブ・アプリケーション上から何かタスクを複数作り、ディペンデンシィを設定してステータスを変えてみてください。問題なく動作したら、Ctrl + Cでデーモンを止め、今度はバックグラウンドで走らせます。

sudo ./shotgunEventDaemon.py start

終了させるときには同様のコマンドで引数をstopにします。

イベント・ハンドラ、そしてShotgunの問題点

イベント・ハンドラを使ったカスタマイズは、ユーザーの入力に対して様々な動作を定義できる、非常に柔軟性の高い機能ですが、その一方でいくつか問題もあります。

まず、ユーザー側でデーモンを走らせるアプリケーション・サーバーが必要になる、ということ。自前でパイプラインのためのサーバーを維持するような余裕がないのでShotgunを使いたい、と思っていた人たちにしてみれば、これはかなりマイナス点です。

そしてもう一つがサポートの問題です。実は私があるクライアントのために、Shotgunのイベント・ハンドラのスクリプトを書いてこの機能を利用していたところ、ある朝全てのプロジェクトのデータのステータスがリセットされてしまう、という大問題が発生しました。この時の問題は、Shotgunから送られてきたイベント・シグナルに特定のデータが紐づけられていなかった場合、逆に全てのデータに対して処理が行われてしまう、というプラグイン側のバグで、コールバック関数の実際の処理の前に以下の一文が必要だったのです。

if not event['entity']:
    return

ただ、私の書いたプラグインはもともとサンプル・プラグインをもとにしており、そのサンプルにも書かれていなかったので、ことが起こるまで何が問題だったのか気づかなかったのです。

クライアント会社のマネージャーがすっ飛んできて状況を説明され、Autodeskに連絡を取ったところ、バックアップされたデータをリストアできるはずだが、まだ日本でやったことがないのでしばらく待ってくれ、と言われました。しかしプロダクションの作業は刻々と進んでいたため、結局私の方でイベントのログをAPIを通じてShotgunから引き出し、問題が発生したであろう時間帯に起こった全てのステータスを変更するイベントの操作を逆に戻していくスクリプトを書いてなんとか事なきを得ました。

断っておきますが、この時のAutodeskの対応が決して悪かったわけではありません。即座に謝罪し、海外のShotgunの実働部隊に対応してもらうようすぐに連絡を取ってくれましたし、我々がもう少し待てれば、実際にデータをリストアしてもらえたと思います。

その一方で私がすっきりしなかったのは、こちらでカスタマイズしたスクリプトが直接的な原因で問題が発生した場合、Autodeskはどこまで責任を取る用意があるのだろうか、ということでした。今回のバグは、元々のサンプルス・クリプトにあったものが原因でしたが、もしそうでない場合、「それはそちらの責任ですよね」といった話にもなりかねないという気がしたのです。そうなるとあえて問題を避けるために吊るしのままで使うか、問題に自分たちで対処する覚悟を決めてカスタマイズするか、ということになります。であるならば、最初から自分たちでパイプラインを構築したほうがいい、という考え方もあるでしょう。Shotgunのようなツールを使う場合、この辺りが今後の肝になってくるのではないか、というのが私が今回感じたことでした。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。