みなさんこんにちは。去年の秋からつくってきた苺栽培マシーンで苺がモリモリ育ってきて、続々と収穫が始まっています。できた苺の甘さを測るのも大事だよねということで、糖度計も買って収穫の度に糖度を測ってみました。これまでは苺を食べても甘いとか美味しいといった感想がメインでしたが、糖度計によって糖度を数値化した結果、それを元に味の濃さや酸っぱさなどを家族でワイワイ議論して、まるで苺ソムリエのようになっています。こんなところでも計測と数値化の影響が出るとは思わなかったので、予想外の効果に驚いています。

venvを共有する問題点

前回までで、複数のアーティストがチームでMayaの作業をするための環境構築を行いました。作成したプログラムをパッケージ管理システムを使ってvenvで管理することで、Maya本体を汚すことなくツールの配布ができるようになり、ツールの管理も自動化することができました。

しかし、全てのユーザーでひとつのvenvを共有する今の方法は、あまり賢い方法とは言えません。環境を共有するということは、何らかの理由で環境が壊れてしまうと、全てのユーザーに影響を及ぼしてしまうことを意味します。また、Windows特有の問題として、どこかでファイルが開かれていると、そのファイルを更新・削除することができないため、ツールを更新する際にトラブルになってしまう可能性が高いです。特に数人～数十人が作業をしている日中は、この問題が起こる可能性が高いでしょう。

また、ファイルサーバ上に実行ファイルを置くことでファイルサーバへの負荷が高まったり、Mayaの起動に時間がかかってしまうという問題もあります。一般的にローカルPCにあるファイルにアクセスするよりも、ファイルサーバ上にあるファイルにアクセスする方が数倍～数十倍ほど遅いですし、ユーザーがMayaを立ち上げる度に数十～数百、下手したら千個くらいのファイルにネットワーク経由でアクセスすることになるのは見過ごせません。試しに前回作成したvenvで確認したところ、1,300個ほどのファイルがあるようです。もちろん、これら全てにアクセスするわけではないですが、立ち上げたばかりのシンプルな環境でもこれくらいのファイルがあるというのは気にしておいた方が良さそうです。

venvをローカルに置く

この問題を解決するために、venvを各ユーザーのローカル環境に作成します。パッケージ管理システムも何もない状態で、venvの環境を全ユーザーのローカル環境につくるとなると悪夢でしかないですが、幸いにも我々は既にツールの配布や環境構築を自動化しているため、それほど苦労せずに移行することができます。

ネックになるのは環境の構築と更新されたツールの配布なので、これを自動化します。とはいえ、ツール更新の度にユーザーにアナウンスして「インストールしてください」と言っても作業をしてくれる人はまずいないでしょう。では、どうしましょうか。

幸いにも我々はMayaを立ち上げるためにランチャー（の超簡易版）を作成しており、ユーザーは必ずそれを実行するという通り道が存在します。作業を始める際に必ず通る道があるので、そこにトリガーを仕込めばユーザーに意識させることなく秘密裏に環境構築と更新をすることができます。

ルールを更新する

venvをローカル環境に置くにあたってルールを更新します。現在のルールは以下の通りでした:

-実行ファイルやパッケージはファイルサーバ上に置く
-venvもサーバ上に置き、作業者全員で共有する
-ツール類の置き場は T: にマウントする
-T:\Toolsに実行ファイル類を置く
-T:\PJ\（プロジェクト名）以下にプロジェクト関連の設定やvenvを置く
-T:\wheelhouseにパッケージ類を置く
-プロジェクトデータは P: にマウントする
-使用するMayaのバージョンは2023

これを以下のように更新します:

-実行ファイルやパッケージはファイルサーバ上に置く
-C:\PJ\（プロジェクト名）以下にvenvを置く ← NEW!!
-ツール類の置き場は T: にマウントする
-T:\Toolsに実行ファイル類を置く
-T:\PJ\（プロジェクト名）以下にプロジェクト関連の設定を置く ← NEW!!
-T:\wheelhouseにパッケージ類を置く
-プロジェクトデータは P: にマウントする
-使用するMayaのバージョンは2023

venvの場所をローカル環境に移動しているだけですね。

環境構築を自動化する

前回は手動で環境構築を行いました。これも自動化しておきます。特に難しいことをする必要はなく、手で行なっていた処理をBAT化するだけで対応できます。

Maya2023.batに環境構築機能を組み込んだものが以下の内容になります。

@echo off

REMプロジェクト固有の設定
set PJNAME=launcherTest
set ENVNAME=venvMaya2023

REMシステム共通の設定
set TOOLS_BASE=T:
set VENV_BASE=C:

REM設定から決まる各種変数
set VENV_PATH=%VENV_BASE%\PJ\%PJNAME%\%ENVNAME%
set VENV_PYTHON=%VENV_PATH%\Scripts\python.exe
set WHEELHOUSE=%TOOLS_BASE%\wheelhouse

REMローカル環境にプロジェクト用フォルダをつくる
mkdir %VENV_BASE%\PJ\%PJNAME%

REMローカル環境にvenvをつくる
%TOOLS_BASE%\Tools\python-3.9.7\python -m venv %VENV_PATH%
%VENV_PYTHON% -m pip install --upgrade pip

REM venvにパッケージをインストールする
%VENV_PYTHON% -m pip install -r %~dp0%ENVNAME%.txt --find-links %WHEELHOUSE%

REM venvを有効にしてMayaを起動する
set MAYA_UI_LANGUAGE=en_US
set PYTHONPATH=%VENV_PATH%\Lib\site-packages

"C:\Program Files\Autodesk\Maya2023\bin\maya.exe"

前回同様、特に難しいことをする必要もなく、プログラムを書くこともなく、簡単なBATファイルを書くだけで実現できてしまいました。

動作確認

実際に実行してみると、初回起動時に C:\PJ\launcherTest\venvMaya2023 が作成され、パッケージ類もインストールされることが確認できます。もちろん、Maya本体の環境には一切手を入れていないので、Mayaを直接起動すれば素のままで実行することができます。

二回目以降もMayaの起動前に毎回venvの作成とパッケージのインストール処理を実行します。実際にはすでに環境がつくられていれば何もしないので、数秒～十数秒のロスで済みます。とはいえ現場からはわかりやすいツッコミ所なので、改善を求められること必至です。今後改善していくことにしましょう。

まとめ

今回はローカルマシンにvenvをつくって、プロジェクト用の環境を自動的にセットアップできるようにしました。この方法であれば、PCをセットアップする際に最低限の作業で済み、ツールや運用ルールの変更があった場合でも、システム管理者が面倒を見なくても自動的に環境を更新することができます。さらに環境を整備していけば、例えばレンダラのバージョンアップの度に全てのPCにレンダラをインストールして回るような作業もなくすことができますし、プロジェクトごとにレンダラを切り替えるといったことも簡単にできるようになります。

第52回の公開は、2023年3月を予定しております。

痴山紘史

日本CGサービス（JCGS） 代表

大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。新人パパ。娘かわいい。