この記事はMaya アドベントカレンダー2022 14日目の記事です。
ポピューン！ という音を聞くために最近は生きてますCOYOTE TAチームのMです。
さて今回はMayaの処理負荷検証の話です。
弊社TAチームにはリグがメインスキルセットのメンバーがリーダーの山本含め数名おり、その中でも僕自身は自称社内随一のDCCツールオタク系TAなため、普通のリガーやMaya使いが知らないことをやたらよく知っており、表側メニューでパッと見つからないニッチな機能やノード、コマンドに関して社内やチーム内で質問されることがちょいちょいあるのですが
先日山本より
「Mayaで再生中のフレームレートを計測したいんですが、なんか出力する方法なんてありましたっけ・・？毎フレームのfpsをなんかこう、csvに出力する的な。。」
という質問があり、ﾝｰ・・・・計測はいくつかあるけど、FPSを出力・・しかも平均値ではなく各フレーム・・・・そんな機能あったっけ？無いよな？ってところから色々面白い知見があったので今回は僕のそのときの質問を受けてからの脳内のロジックを追っかける感じの記事となります。
（ちなみにfpsは秒間あたりの描画フレーム数の事なので、毎フレームのfps だと謎な表現となってしまうので毎フレームの処理負荷や処理時間と解釈しました。）
結論と言う名の、オチを先に読みたい人はここをクリック！！！
expressionのAlwaysを使うと強制的に毎フレームコマンドが実行される
それを逆手に取ってplaybackOptionsコマンドのfpsフラグをクエリすると毎フレームの実行FPSが返ってくる！！
あとはそれを外部ファイルにCSVで書き出してエクセルでグラフ作るなりシーン内に負荷ゲージ視覚的に作るなりお好きに・・・・
まず最初にMayaの標準で用意されているfps計測系ですと
- HUDに出せるFPS表示
- 評価ツールキットのパフォーマンス
くらいしかなく、他処理負荷系の場合
- DGプロファイラ
- プロファイラ
となりここらをまず利用する方向を考えてみました。
HUDのFPS表示
予想：MayaのHUD機能で常にビューポートの動作FPSが表示されているのでコレを取得できればフレーム毎に実動作FPSが取れるのでは・・・？
結果：HUDコマンドのpresetフラグ内になんかそれっぽい機能があるようなことが記述されているものの、肝心のFPSの数値が返ってくるような引数の記述が色々試したけどどうにも分からず断念。
が・・・！なんと執筆中に解決・・・・headsUpDisplay -q -sr HUDFrameRate で取得出来ますね・・・・ただ、計算の都合上（多分平均値で出してる？）再生の出だし部分ではFPSが極端に低くなることがあるので実際に使うかは微妙・・・・
（今回は話の流れ的に一旦コレは使わなかった世界線で話を進めます・・・）
評価ツールキットのパフォーマンス検証機能
予想：この機能を使うとDG,シリアル,パラレルモードそれぞれで平均フレームレートを計測してくれる。
この計算方法によっては毎フレームの負荷が分かるのでは・・・？
結果：しかし駄目・・・・！フレーム数を再生時間で割っただけ・・・！
evalutionToolkit.py 2345行目（Maya2023）
DGプロファイラ
各ノードの計算回数や計算時間、対象ノード全体に対する負荷割合等色々な情報が取れる上CSVで書き出せるものの、
計測フレーム毎の情報は取り出せない上、計測対象ノードも絞られている（絞られてないとカオスなことになるので絞られてる事自体は別に悪いことではないですが・・・・）ため、これも今回の目的には使えないなという判断。
普段の解析では凄く使ってますよ！
プロファイラ
名前的にDGプロファイラと若干かぶっているのでややこしいですが、Maya上で動いているノードだけではなく、バックグラウンドで動いているQT等の処理時間や、計算に使われているCPUの論理コアまで記録されるという超絶至れり尽くせりっぷり。
しかし、今回の場合あまりに細かく情報が取れすぎてしまうがゆえにこの情報から必要なものをピックしていくのがやや大変なため一旦後回し。（最悪コレを利用するつもりでした・・・）
ここまで考えるとHUDのFPSの値が取れない以上(※)手詰まり感がありましたが、その時電流走る———————！(ﾎﾟﾋﾟｭｰﾝ!
※：取れないていで読み進めてください・・・！この時点では取れないと思いこんでたのです！
毎フレームの現在時間を書き出せればフレーム間の経過時間が分かる。
強制的にフレーム毎に現在時間書き出しの実行・・・・毎フレーム強制・・・・？
expressionのalwaysが使えるじゃないか！！！！？
普段on Demandにしなさいと言われているあの！alwaysが使えるじゃないか！！！！！！！！
よっしゃ！ExpressionはMELしか使えないからMELコマンドで現在時刻取得のコマンドを使うで！
dateコマンドやな！セットOK！
ミリ秒が・・・ミリ秒がとれへん・・・・ミリ秒とるフラグも無いやん・・・・・
うう・・・・凄くいい発想だと思ったのにここへ来てコマンド自体の仕様に泣かされるとは・・・・
（なおalways使う発想に山本は爆笑してました。）
pythonならdatetimeモジュールでミリ秒まで取れるのに・・・・・expressionはMELしか動かないもんなぁ・・・・
注：察しのいい人ならアレ使えばいいじゃん？って思われると思いますが、この時の自分は気づいてなかったのです・・・・翌日気づきました。
と、一旦ここで少し諦めたものの、諦めきれないので色々考えていたら
そうだ！exprespyがあるじゃないか！
exprespy：PythonでExpressionを動かすノード。Githubで公開されています。
（https://github.com/ryusas/maya_exprespy)
と、取れたー！
取れたものの、流石本家expressionの理由なきalweys設定禁止！な佐々木さんらしく、DG評価が走るようにノードを組まないと実行されない仕様となっていたため、ちょっと仕込み方を分かってる人間じゃないの少しむずかしい事。
標準機能ではなくバージョンごとに別のmllファイルを読み込ませる必要がある事。（mllファイルってね・・・バージョンごとにビルド必要なので別ファイルなの・・・・・）
おそらくMaya上で走ってるPythonとexprespyで走っているPythonは別扱い？のため外部モジュール使う場合はモジュールのimportもコード内に記述必要であること。
（書かないとエラーが出る。スクリプトエディタ等で事前にMayaに読み込ませても駄目）
変数もMaya上で宣言済みのものにアクセス出来なかったりするためこの用途で使うのには向いていない。
（そもそもこういう用途のために作られているわけじゃないのでこんな変則的な使い方をしようとしてる事自体がダメな気がするが・・・・おそらくこれは、書かれたコードがコンパイルされてメモリに保持されるというGitの説明を鑑みるに回避不能。前述のimportもこれが原因か？）
なお余談ですが、exprespyの実行速度はめちゃ速だった。最初プロファイラからexprespyノードを探すのに手間取ってしまったくらいに表示上微細すぎて・・・・・（つまり処理時間が短い＝速い！！！）
諸々の事情を鑑みると別の手段をさらに模索する必要があると判断。（もちろん標準機能で。）
標準機能・・・ほか何かあったかなぁ・・・・・・BifrostGraphあたりになにかなかったっけ・・・うーむ・・・・と考えはじめた時に
再度天啓———————！圧倒的閃き！(ﾎﾟﾎﾟﾎﾟﾎﾟﾎﾟﾋﾟｭｰﾝ!!
MASHにPythonモジュールあるじゃん！
とりあえずdatetimeをprintするコマンドを打ち込んでぇ・・・
できたー！標準機能で出来たよーーーー！
あとはこれをPrintで毎フレーム書き出しだとちょっとI/Oの負荷が高いから配列変数にストックする仕様にしてcsvに書き出してぇ・・・ちょこっと使いやすいようにカンマ改行に整形してぇ・・・
CSVをエクセルに読み込んで・・・・（データ型検出をさせると勝手にコンマ以下のミリ秒を省いたりしたので検出なしにするのがミソ）
やったーエクセルに持ってこれたぞーこれでグラフを作れば負荷の推移を可視化出来ｒ・・・・・んん？？？？
なんかえらい数字がアップダウンアップダウンしてる・・・？
てか１２０フレームのはずが倍の２４０フレーム分のデータが生成されてる・・・？（正確には0フレームから120フレームで計測したので121Fのはずが242F
Mayaに戻ってテストしてみるとMASHはどうも1Fで2度評価が走っている・・・？ようで、ちょっと調べてみたものの理由がわからず・・・・・うーむ困ったな・・・・どうしよう・・・・
1行ごと間引けばいっか＾＾（妥協
あとはこのようにグラフ化すればどこで負荷が高まるか？がわかります。（今回は書き出しに使ったシーンが軽すぎて24fpsの1f実時間である0.041秒程度で最初のフレーム以外収まってしまっていますが・・・）
手元にあるデータがだいたいキレイに処理落ち殆ど無しで動いてしまったため、無理やりフレーム間の値をいじったグラフにはなりますが、フレームレートが安定しない場合このようなグラフになるのでどのフレームで負荷が上がっているか？というところからプロファイラ等を使って原因を探って見ると良いと思います。
一応これで目的は達成しましたが、そもそもMASH自体がこういうことのための物ではないのでやはりコレ自体の処理負荷がちょっと重いのが気になるところ
現状標準機能で他にどうしようも無さそうなので今回はこれで一旦手順としては完成かなぁ・・・・
と思いながら帰宅中重大なことを忘れているのを思い出しました。
はい。とっくにお気づきの方いらっしゃると思いますが、MELのpythonコマンドの存在を完全に忘れていました。（いやー普段MELからPython叩くことが稀過ぎて完全に存在が忘却の彼方でしたよﾌﾌﾌ….）
https://help.autodesk.com/cloudhelp/2023/JPN/Maya-Tech-Docs/Commands/python.html
普通にデータ返ってくるーーーーー！（当たり前だけど・・・・）
ううーむ・・・・今までの苦労が・・・・ｗ
そしてさらにダブルパンチ！
この記事を書きはじめたとき、コマンドを調べていて自分で発見（というか今まで見落とし・・・）しました
playbackOptionsコマンドにfpsクエリ出来るやつあるやん・・・・コレExpressionで発動させればええやん・・・実時間計算せんでもFPSで返ってくるやん・・・・
https://help.autodesk.com/cloudhelp/2023/JPN/Maya-Tech-Docs/Commands/playbackOptions.html
しかも小数点以下8位まで返ってくるー・・・！（そこまでは流石に要らない・・・！
いやぁ・・・・小難しい方法色々考える前に本当にコマンドに該当するものがないか調査しないとだめですねぇ・・・・
今回はいろんな知見発見に繋がったので全然OKですが、これが仕事の修羅場中の1分でも惜しい場合、ただの遠回りとなってしまうので普段からもっと簡単かつ最善手を打てるようにもっと知識を貯めなければと改めて思いました。
さてさて、いろんな方法が出てきましたが、今回の場合リグの負荷計測目的なので計測部分が重かったら意味がないのでここまで出た方法の中で一番軽い方法を採択スべきだな ということになるので処理負荷を比較してみました。
重い順に
getDate_py：expressionからpythonコマンドでdateTimeモジュールから現在時刻を生成したパターン
MASH1_Python+その他MASHノード：MASHのPythonノードでdateTimeモジュールから現在時刻を生成したパターン
※：MASH_Pythonノードは単体では評価が走らないのでMASH関連ノード連合として合算
exprespy1：exprespyノードでdateTimeモジュールから現在時刻を生成したパターン
getDate_mel：expressionからplaybackOptionsコマンドでFPSを取得したパターン
となり。ダントツでPythonコマンドからdateTimeモジュールを呼んだ場合が重く、文字通り桁違いでMELコマンドをそのまま使用したものが軽かったです。
ただ、今回の場合はDGモードかつ、パラレル評価等の考慮や安定性等は一切考慮していない検証なので、似たパターンでなんらかの仕組みを実装する場合も同じ結果になるか？というとそういうことは無いはずなのであくまで今回はこうなりましたよ。という参考程度にとどめてください。
1つの得たい結果に対して色々なアプローチでの解決法をプランニングするのもTAの仕事なので、MASHのように普段使わない方法も知っておくと色々あの手この手と考える源泉となるので専門外だと思ってる機能も触ってみると後々の武器になるかもしれません。（そして基本中の基本のコマンドリファレンスは定期的に色々見直してみましょう！反省！）
ではまた。
COYOTE 3DCG STUDIO
公式HP：https://3d.crdg.jp/
COYOTE 3DCG STUDIOはクリーク･アンド･リバー社が運営するゲーム専門3DCG制作集団です。
キャラモデル、背景モデル、3Dアニメーション、テクニカルアーティストによるツール開発などを得意としています。
新規立ち上げにおけるコンサルティングから量産制作まで幅広く対応可能な体制を保有しており、出向にも柔軟に対応しております。
