みなさんこんにちは。この1ヶ月で世の中は大きく様変わりし、CGWORLD.jpのテレワーク導入の実態調査（2020年4月実施）によると、テレワークの実施率が実に9割に達したとのことです。たった1ヶ月そこそこでここまで環境が大きく変わってしまうのは驚きです。私の身近でも請求書に捺印して原本を提出するという謎の慣習が今回を期に撤廃されるケースが増え、「え？やればできるじゃん......今までの苦労は一体？」と思うことも多いこの頃です（苦笑。
前回はパイプライン編の最初ということでパイプラインについて考えていきました。今回から実例を交えてお話を進めていきます。お話を進めるにあたって、皆さんの環境でも記事の内容を試すことができるよう、当社で開発しているパイプラインツールの試用版を用意しました。今後使用していくので、今回はパイプラインツールのインストールと、ランチャーの解説を行います。
※現在、当社パイプラインツールはWindowsのみの対応となっています。ご了承ください。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
パイプラインツールのインストール
まず、パイプラインツールを手元の環境にインストールします。以下のhttps://jcgs.co.jp/Trialにアクセスし、ページ下部にある 「本許諾に同意してダウンロード」 をクリックしてインストーラをダウンロードし、C:\JCGSに保存します。インストーラの置いてある場所にパイプラインツールの実行環境がつくられるので、置き場所には注意してください。
保存したら実行します。環境によってはインターネット上からダウンロードしたexeファイルを実行する際に警告が出る場合もあります。私の環境ではWindows Defenderが反応します。
この場合、詳細情報をクリックすると実行を選択することができます。もしくは、setup.exeのプロパティからセキュリティで許可するにチェックを入れるという方法でも実行できるようになります。
実行すると、必要なファイルのダウンロードや展開、環境構築が始まります。
ファイルのダウンロードや展開にはそこそこ時間がかかります。環境構築に必要な情報はインストーラが自動的に判断するため、途中で何かを入力する必要はありません。ほかの作業をしながら気長にお待ちください。初回の環境構築には30分程度を見ておくといいかなという感じです。
環境構築が無事におわるとランチャーが立ち上がります。ランチャーが立ち上がらない場合は何か不測の事態が起きているため、私までご連絡いただけるとありがたいです。
これで準備は完了です。次回以降の起動は、C:\JCGS以下に作成されているショートカットを使用します。ショートカットは4つ作成されていて、通常はJCGS_1.0.2209（バージョン番号は状況によって読み替えてください）を使用すればよいです。
[[SplitPage]]ランチャーを使ってアプリケーションを立ち上げる
ランチャー上部のプルダウンメニューから作業を行うプロジェクトを選択します。標準ではbaseProjectとtutorialの2つが登録されているので、tutorialを選択します。
続いて、使用するアプリケーションを選択します。リストの左側で大分類、右側でアイテムを選択します。アイテムをダブルクリックするか、ダイアログ下部のRunボタンを押すと起動します。
アプリケーションの初回起動時には実行環境を構築するための処理が走ります。一度環境構築が終われば次からはこの処理は行われないので、最初だけは少しお待ちください。パイプラインツールの更新などを行なった場合も、ランチャーが自動的に更新処理を行います。このようにすることで、誰でもいつでも同じ環境で作業を開始することができるようになっています。
環境構築が終わればアプリケーションが立ち上がります。
Mayaや3ds Max、Nukeなども同様に立ち上げることができます。これらを立ち上げると、自動的にJCGSメニューが追加されてアプリケーション上で使用するパイプラインツールにアクセスできるようになります。
ランチャーの機能
ランチャーは、パイプライン運用の上でとても重要な役割を担っています。ランチャーを使用しなくても、プロジェクトを運用する際に複数人の環境を整えるために工夫をしている方は多いでしょう。
例えば、 BATファイルをつくってそこからアプリケーションを起動しているケースもあると思います。少人数で顔を向き合わせながら仕事を進める場合、これでも十分回すことはできるかもしれません。それでも、BATファイルをローカルマシンにコピーしてしまったために更新が反映されなかったり、BATファイルが多すぎてどれを使えばいいのかわからなくなったりといったトラブルが多発しがちです。
また、プロジェクトごとに使用するプラグインを切り替えなければいけない場合も準備が大変です。あるプロジェクトではArnold、別のプロジェクトではSuperRender2.71を使い、また別のプロジェクトではSuperRender3.14を使うというケースはよくあります。別の種類のプラグインであればまとめてインストールしてしまえば対応できますが、異なるバージョンのプラグインをひとつの環境に同居させるのは大抵の場合不可能です。
この問題は作業用マシンに限りません。特に厄介なのはレンダーサーバです。複数のプロジェクトで共有されるレンダーサーバの場合、何らかの方法でDCCツール内で使用するプラグインのバージョンを切り替えるしくみを用意できなければ、プロジェクト専用にセットアップしたマシンを切り分けて使用しなければなりません。
このような管理をしていると手間がかかりますし、何より人的ミスが起きます。プロジェクトの途中でやむを得ず使用ツールのバージョンアップをした場合、必ずどこかの環境を更新し忘れて手戻りが発生するでしょう。
そのような、環境整備にまつわるモロモロを一手に引き受けるのがランチャーです。
例えば、当社のランチャーでは以下のようなことを行います。
-プロジェクト選択
-パッケージ管理
-環境変数管理
-アプリケーション実行環境構築
ランチャーからアプリケーションを立ち上げる際にプロジェクトと使用するアプリケーションを選択すると、実行に必要なソフトウェアや環境変数を準備します。そのため、レンダーサーバ上でも自動的に環境を構築してから処理を行うといったことも可能です。また、アプリケーション実行環境は1台のマシンに複数作成することができるため、prj_A用のMayaとprj_B用のMayaで異なるバージョンのプラグインを使用するといったこともできるようになっています。
技術的な詳細はCEDEC2017のTechnical Artist Bootcamp 2017 vol.1「Automation for TA」にてご紹介しているので、こちらを参照してください。
ランチャーはMayaなどのマシンにインストールされているアプリケーションに対して手を加えないので、ランチャーなしでアプリケーションを起動すれば基本的にインストールしたままの状態で実行することができます。そのため、様々なプラグインをインストールしたことで環境が壊れてしまい、アプリケーション本体のインストールからやり直しといったことも防げます。
まとめ
今回は当社で開発しているパイプラインツールをインストールし、ランチャーの立ち上げまで確かめました。また、ランチャーが何をしているか、ランチャーを使用することで得られるメリットについてご説明しました。プロダクションの規模によってどのようなパイプラインを構築するかは大きく変わってくるところではありますが、ランチャーやそれに似たしくみを用意しておくことで、日々の細かいストレスやミスから解放されます。
第23回の公開は、2020年6月を予定しております。
プロフィール
