siGroupType の感激。

                      

先日、Todd Akita さまのエキスパートセミナーに参加しまして。
      
内容はさすがに PYSOP のＴＤだけあって、濃い～ものでしたが、ちょっと半端に濃かった気もしました。あの濃さでやるなら、３時間ちょいじゃあまりにも短い。　丸１日のコース か、もしくは超少人数で対話形式とかでやれるとベストじゃないですかね（難しそうだけど）。　Todd さんは人の良さと熱心さが顔に現れているような人で、より多くのことをひとつひとつ丁寧にやろうとしたあまり密度が少し薄くなってしまったような印象を受 けました。（あと何分ある？　とか常に時間を気にしていた）。　　せめて５時間くらいあると、１万５千円にふさわしくなりそう・・・。
      
      
もらったＤＶＤにはお宝がいっぱい。しかし諸般の事情があり、まだちょっとしか見れていない。
あと２週間くらい見れなさそう・・・。　研究は熱いうちにやらないといけないんだけどなあ・・・。
あ、再配布禁止ですね。ネットはおろか、個人間の手渡しも再配布になりますわね。
金払って参加した人だけの特典ですわね。けけけけけ。研究しよう。
研究成果を配布するのは禁止されてないですね。当たり前か。
      
      
      
      
セミナーの後は、自然の猛威で壊滅したあの街で出会ったあの方と、８年ぶりに再会。その方も含め、その方が勤める会社に在籍するとてつもなく才能のある人 たちとも、久しぶりに／もしくはお初で会うことができて、大いに刺激になった夜でした。　大いに呑み大いに語らい朝まで４軒ハシゴして早朝の電車で覚醒し てみれば自宅をはるかに通り過ぎた駅であわてて反対のホームの電車に飛び乗ったらさらにどんどん自宅から遠くなり実は終点まで行って折り返している途中に 覚醒したのだと気づいた時にはすでに遅くまた逆向きの電車に乗り換えてやっと最寄り駅に着いたのは朝の８時でその日は仕事だったのでしかたなく職場に泊 まってみたが起きても二日酔いで仕事にならなかったというのは誰にも言えない秘密です。
      
      
      
      
      
その日の呑み会で、スクリプトから　Group/Partition/Layer を見分ける方法の話が出て。　出て、ってよりも自分が出したんですが。
過去に Partition がらみのスクリプトを作っていて、ユーザが変なものを選択していたらはじくようにしたくて格闘していたんですが、結果的には思い通りに出来たのですが、な んともスマートじゃない方法で、なんとかスマートにしたかったのです。
      
スマートじゃない方法＝ selection(0).parent.parent みたいに親を２つ以上さかのぼってその差を調べたり、ごちゃごちゃやって消去法で特定する感じ。
      
      
普通に考えれば、type プロパティでものを見分けますね。シンプルかつ確実です。
      
しかし。
      
Group/Partition/Layer　この３つは、type プロパティを表示してみると、どれも "#Group"なんですよね。
この３つのうちどれでも１つを選択して以下のスクリプトを実行すると    
                                                      

logmessage (Selection(0).type)            

      
結果はどれを選択していても、      
                                                              

// INFO : #Group            

      
と出るはずです。　つまり全部 #Group (siGroupType) といいう type が返ってくる。　つまり type じゃ見分けがつかねぇぞｺﾞﾙｧ　ということになりますね。　エクスプローラでも、この３つは色は違うけどアイコンは同じ、マルが３つのやつですね。持っ ているプロパティも一緒ですね。　XSI にとって同じ扱いなんでしょうね。
      
      
      
      
しかしその呑み会で、Model プロパティである程度振り分けられないか、という話が出て。
なるほど、考えてもみなかった。
      
ってことでやってみると。      
                                                              

logmessage (Selection(0).Model)

      
返ってきた結果は、
      
　Group を選んでいた場合　　　 --> その Group が所属する Model
　Partition を選んでいた場合    -->  エラー終了(型が一致しません)
　Layer を選んでいた場合　　　 -->  エラー終了(型が一致しません)
      
うーむ、惜しい。Partition と Layer で違う挙動を見せてくれれば消去法を使わずに振り分けられるのに・・・。
      
      
ってことでごくあっさりとあきらめたのですが、無理やり Model プロパティをからめた見分け方をやると、
                                                              

//選択 している最初のものを取得
var oSel = Selection(0);
            
// type プロパティ　が、そもそも #Group じゃなければはじく
if (oSel.type != siGroupType)
{
    Logmessage ('師ねやｺﾞﾙｧ');
}
            
// Model プロパティが取得できれば、それは Group
else if (oSel.Model != null)
{
    Logmessage ( oSel + ' は Group です。ｺﾞﾙｧ');
}
            
//　じゃなければ、parent が Scene.Layers なら Layer
else if (oSel.parent == 'Scene.Layers')
{
    Logmessage ( oSel + ' は Layer です。ｺﾞﾙｧ');
}
            
//　そのどれでもなければ、そりゃPartition しか残ってねぇよｺﾞﾙｧ
else
{
    Logmessage ( oSel + ' は Partition です。たぶん。ｺﾞﾙｧ');
}

      
こんな感じですか。結局最後は消去法。 Orz
      
      
しかし、今までやっていた方法では Group が消去法の最後に来ていたので、Group かどうかをチェックするだけでも消去法ルーチンを最後まで実行せねばならなかったわけです。この方法であれば、Group かどうかだけを（＝Partition と Layer 以外かどうかを）知りたい！　のであれば model プロパティのエラーさえチェックすればいいことになるので、これだけでも収穫ですわ。
って、落とし穴ありますか。そうですか。指摘してください。
っていうかあなた、もっといい方法知ってるんでしょ。教えて下さい。生ビール（ヱビス500ml）おごります。
      
      
      
      
独学で黙々とやっていても限界がありますわね。
でも人と話すと、思ってもみなかった発見がありますわね。
ＣＧって特にそういうことが多そうですわね。
こんなどうでもいい小さいことでも、人間ひとりって、いかに無力かって思い知りますわね。
      
      
僕と酒を呑みながら色んな話を聞かせてくれた方々に、最大級の感謝と賛辞を。
呑みすぎて半分以上覚えていないことに、海より深い反省を。
昔と何ひとつ変わらず走り続けているあなたたちに、深く厚い敬意を。
昔と何ひとつ変わらず僕と呑んでくれるその事実に、はちきれるほどの感激を。
再び幸せをつかんだ君に、泣きそうなくらい心からの祝福を。
若すぎることに、逮捕状を。
モントリオールに爆弾を。
      
      
      

XSI男のムービーサルベージ。

まったくどうでもいいムービーだが、愛する XSI 男をリンク切れのまま
放置しているのが忍びなく、HDDをほじくり返してみたらサルベージできた。

http://junkithejunkie.cocolog-nifty.com/blog/2007/12/xsi_53b9.html
http://junkithejunkie.cocolog-nifty.com/blog/2007/12/xsi_4856.html

test1_proj などという、いかにもどうでもよさそうな名前のXSIプロジェクトの
Render_Pictures 以下に、彼は居た。

ごめんな XSI男。淋しかったよな。
こんなしょぼくれたマシンの、古い HDD の奥底にある、test1_proj なんていう
辺境の地に置き去りにされて、今まで待ってたんだよな。
せめて、インターネットの海に置かれていたかったよな。ごめんな。
今日もエンベロープのテストで使わせてもらったよ。
お前、ほんとによく働くよな。

今日、ちょっとすごいＣＧ屋の人と会うんだ。
お前も来るかい。　彼もきっとお前を使っていると思うな。
一緒に生ビールでも飲もうよ。

名前。 バージョンアップ。

                  

複数オブジェクトをイッキにリネームするツール、名前。 ver3.0 にバージョンアップ。
      
      
      
名前。
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html

             
・大文字小文字区別機能やっと搭載
・アルファベット追加機能搭載（あんまり利口じゃないけど）
・グローバルマッチっていうの？　検索置換で、マッチした全箇所で置換が行われるように仕様変更
・モーダルPPG廃止　→　シーンに残らないタイプのカスタムプロパティに変更
・ファイルが複数に分かれたため　Add-on 形式に変更
・その他 PPG 整理など小改良

しばらく放置していた名前。をバージョンアップしてみました。先日の記事に書いたようにモーダルPPG をやめてみました。たぶんこっちの方がいいと思う。
      
前回のバージョンダウンの時に善さまに教えて頂いた方法で、グローバルマッチ？っていうんですか、検索でヒットした文字列全箇所を処理対象にすることがで きました。善さまには謹んでお礼申し上げます。約束の生ビール（約500ml）の進呈は遅れています。善さまには謹んでお詫び申し上げます。
      
実験的に付けてみたのがアルファベット機能。試行錯誤＆暗中模索＆手探りでやってみたが、使えないかも。バグあるかも。なんか本人もよくわかっていませ ん。Orz
      
      
後は、頭とかケツとかだけじゃなく、指定した部分の文字を削除したり追加したりする機能が必要かしら。　連番を２桁にリネームする機能とかもあると便利か しら。　そもそも正規表現がまんま使えるようにとか、できるんだろうか。　色々思うところはあるが、まあ仕事やってて必要だと感じたら改良することにしよ う。
      
      
      
      

さらばモーダル。

                  
 

　最近、GOTETZさまの書いた InteractiveThickness というプラグインを使ってみた。とても使い勝手が良いと思ったが、それは使った人ならわかるだろうからここでは触れない。それよか、PPG が表示されるにも関わらず、シーンのどこにもその PPG 自体が存在していないことに気が付いた。　あれえ？　どうなってるの？　PPG の実体がないのに PPGが表示されてるよ？
      
　ということで、恐れ多くもソースコードを拝見させていただくと、    
                                        

var oProp = XSIFactory.CreateObject( "CustomProperty" );
oProp.Name = "Interactive_Thickness";

この２行を発見した。ま、２行目は名前を付けているだけで重要ではない。着眼すべきは１行目である。　XSIFactoryオブジェクトの CreateObject メソッドは、XSICollection を作成する時にいつも使っている馴染み深いものである。しかし意味をわかって使っているのではなく、とにかく XSICollection が必要なときは

                                               

var コレクションの名前 = XSIFactory.CreateObject( 'XSI.Collection' );

と呪文を唱えればいい、くらいにしか思っていなかった。すいません、素人です。
      
　で、XSIFactory をマニュアルで調べてみたが、予想通り超簡潔な説明しか載っていなく、また日本語版のマニュアルは相変わらず無責任かつ超愚直 な直訳かつユーザ置いてけぼりな書き方しかされてないのでマシンを１台破壊して閉じてしまった。ただ、「シーングラフに残らない方法でオブジェクトを作る ときに云々」と書かれていたので気になった。
　次に CreateObject メソッドのページを見てみると、サンプルコードのコメントに、「この方法はカスタムプロパティの一時的なインスタンスを作るが、シーンに残らないので、 使った後にそのオブジェクトを削除する必要もない」という意味のことが書かれていた。　つまりこの方法でPPGを作った場合は、そのPPGはそもそもオブ ジェクトとしてシーンの中の階層に存在しない。InspectObjコマンドで開かれて、あとはウインドウを閉じられるまでの命である。ウインドウを閉じ たら永遠に消える。
      
　おおう、こんなことができたのですか。　なんとなく初めて読んだわけではないような、知っていたような、知らなかったような。　でもこの方法で使ったこ ともなければ深く考えたこともなかったので、まあ知らなかったと同じことだわな。これは便利かもしれない。
      
ちなみに１。　ここでいうオブジェクトとは通常の 3DCG のオブジェクトではなくプログラミング的な意味も含む広義のオブジェクトです。

ちなみに２。　SDKガイド日本語版は、サンプルコードのコメントは翻訳されていません。ここも重要だっちゅうの。わかってますかあなた。 SDK ガイドを翻訳した人。あなたです。　しかもあなた、ＣＧのこともプログラミングのことも何も知らないでしょ。バレバレですよ。なんですかこのひどい翻訳 は。はい、そう、あなたのことです。
      
      
　で、たまたま GOTETZ さまとお話をさせて頂く機会に恵まれた。氏によると、シーンに余計なものを残さないためにこの方法を使っているとのことである。　しかも、PPG 内部のボタンを押すと自分自身を消去するようになっている。これも知らなかった。　試しに、シーンに実体が残るPPGにもこういうボタンを仕込んでみたと ころ、同じことができた。なるほど。やはりそういう使い方ですな。正しく使えばこれはとても handy ですな。目からウロコが落ちました。
      
　氏との話の中で、そしてその後の実験の中で、なんとなく俺的結論が出て来た気がする。
　これまでは、その場限りの使い捨て PPG を作るときは、シーンの中に実体があるオブジェクトとして PPG を作成し、それをモーダルモードで開き、モーダルウインドウをＯＫまたはキャンセルした後に消す、ということをやってきた。しかしモーダルPPG は処理を完全に奪ってしまうのがまず気に入らないし、使い捨てなので（１回使ったらもう要らない）、使用後に自動で消すルーチンを仕込まないとシーンにゴ ミが残ることにもなる。今ひとつスマートじゃないと思っていた。
      
　しかし、この XSIFactory.CreateObject で PPG を作り非モーダルモードで Inspect すれば、非モーダルゆえにPPG を開いたまま他の処理ができるし、手動で使用済みプロパティを削除する必要もない。　ひとつ手間が増えるとすればモーダルPPGと違ってＯＫ／キャンセル ボタンがないため、処理を明示的に実行させるボタン、またはパラメータが変化したときに処理を起動するための logic function を仕込むことくらいである。特に問題はない。
　またはシーンに実体が残る PPG を作成したとしても、基本的には非モーダルPPGとして開くことにし、PPG内に自殺ボタン（自分自身を消去）を作れば、少なくとも Explorer から手動消去の必要はなくなる。
      
　うーむ、これはもう、モーダルPPG の出番がなくなってしまった気がする。
      
      
      
--------
      
　一応、モーダルとか非モーダルとかについて書いておくと。
      
　
　プリミティブの sphere を選んで Enter を押すと、

　こういう PPG が出てきます。これが非モーダルPPGですね。　PPG を開いたまま他のオブジェクトを選ぶでも、シーンの何かのパラメータをいじるでも、メシを食うでも納期遅らせるでもモントリオールを爆撃するでも、何でも できますね。当たり前ですね。
      


　これと同じ PPG を、今度はモーダルモードで開くことにします。　スクリプトを書くことになります。                                                

InspectObj (null, siGeneralKeyword, null, siModal );            

sphere を選んだ状態で↑これを実行すると、

      

　↑これがモーダルPPG ですね。ＯＫ／キャンセルボタンが付いていて、これを押すまでは一切の処理を奪われます。 他のオブジェクトを選ぶことも、シーンの何かのパラメータをいじることも、メシを食うことも納期を遅らせることもモントリオールを爆撃することも、何もで きません。
      
　しかもモーダルPPG は、PPGが開く初期位置も、ウインドウの大きさも決められません。少し大きめの PPG になるとすぐスクロールバーが出てきて、とても見づらい状態になります。そうなるとスクロールさせる必要が出てこないよう、PPGLayout を駆使して少しでも小さい UI にしようと必死の開発になります。消耗します。
      
　モーダルダイアログの説明　（ IT用語辞典 e-words ）
　↑この説明によると、非モーダルPPG は「モードレスダイアログ」というものに含まれるんでしょうかね。
　ちなみにカスタムプロパティなどではなく XSI の標準操作でモーダルPPG が出てくるのは、パッと思いつくのは UV (Texture_Projection）の名前を変更する時でしょうかね。 Animation > Sequence All とかもそうですね。　ああ、あとは Immed ボタンがオンの状態で色んなことをすると、モーダルPPG が出てきますね。その場でパラメータを確定するために。
      

--------


　ともかくモーダルPPG はこのように使い勝手が良くない。　ユーザに他のことをさせずにこのパラメータをまず決めさせないといけない、という時以外には使わない方がよさそう。ま ずは使い捨て PPG にモーダル使うのはやめよう。　・・・という仮ルールを、今後のプラグイン開発で設定してみることにしよう。
      
      
　モーダルPPG よ、しばしの別れだ。
　いつかたくましくなって戻って来い。
　せめてウインドウの大きさと位置をユーザが決められるようになったら、
　何かの時に使ってやる。
      
      
      
      
参考にさせて頂いた GOTETZさまにこの場を借りてお礼を申し上げます。勉強になりました。
      
ちなみにですが、個人的な好みの問題もありますが、Interactive Thickness はやはり、PPG をシーンに実体として残す方が使いやすいと感じています。最初に厚みを仮に決めて、邪魔なのでPPGは閉じた状態で他のオブジェクトの具合などを調整し、 あとからもう一回 PPG を開いて厚みを再調整したいことが多い。しかし現在の仕様では、ウインドウを閉じると PPG は永遠に失われます。まあ weld と push は生きているわけで、そこを手でいじればいいと言えばいいのですが。
      
なので自分は勝手に、シーンに PPG が残るように改造して使わせて頂こうと思います。
もし次のプロジェクトでガンガン使うことになれば、どっちが自分のワークフローに合うか答えも出るでしょう。
      




そういえば、SI3D の頃って、PPGと言えばモーダルモードしかなかった気がする。ウインドウ開いたらＯＫするまでは何もできないという。　その場でパラメータ決めないといけないという。　おそらく当時の Power Animator など、ウインドウ開いたまま作業するスタイルの３Ｄソフトウェアを見ると、おおおー　なんかかっこいいーと思ったものでした。

果てしなきコンストレイン。果てしないプラグイン。

                  

コンストレインメニューから Constrain > Postion とかを実行すると、オブジェクトをピックしたあとすぐに PPG が立ち上がり、コンストレインのピックセッションは終了する。
      
続けて他のオブジェクトに同じ操作をしたいなら、XSI のスヴァらしき中クリックを使って、もう一度 Constrain > Position を実行する。さらに続けて同じ操作をしたいなら、XSI のスヴァらしき中クリックを使ってさらにもう一度 Constrain > Position を実行する。さらにさらに続けて同じ操作をしたいなら、XSI のスヴァらしき中クリックを使ってさらにさらに実行する。さらにさらにさらに続けて同じ操作をしたいなら、マシンを破壊する。
      


      
果てしなきコンストレイン
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html
      
      

拘束する人　→　拘束される人　→　拘束する人　→　拘束される人・・・・　の順番で、右クリックで終了するまで延々とオブジェクトをピックしていき、最 後にイッキにコンストレインをするツール。すでに大量のオブジェクトが存在していて、それぞれをそれぞれにコンストレインしなければいけない時に少し楽に なるかも知れない。
      
前プロジェクトで作業中、大量のオブジェクトに延々とコンストレインをかましているうちにブチ切れて、その場限りの使い捨て繰り返し処理のスクリプトを書 こうと思ったが、オブジェクトの名前が連番になっていなかったりしてダメで、さらにブチ切れて書いたプラグイン。　最初からオブジェクトの名前付けを戦略 的にやらないとマシンが何台も破壊されてもったいない。　しかしそのオブジェクトたちの役割上、連番の名前にしない方が都合が良いことも多いわけで。
      
      
XPOP がないと起動しません。
なぜ XPOP を使う仕様にしたかというと、先日のこの記事で書いたとおり、XSI インターフェース右側のメニューにサブメニューを登録すると、サブメニューから呼び出されたコマンドは全く実行されないというアフォな不具合があるためで す。　サブメニューを使わないと Constrain メニューの中にズラズラズラっと項目が増えてしまって嫌だし、このプラグインの機能上、左側のメニューや上のメニューに入れるのも違うなと思ったので、 Constrain メニューに入れつつも、サブメニュー的な使い方をしようとした苦肉の策です。この不具合がなければ XPOP は使わずに済むのに。　悪いのは Softimage さんです。
      
      
      
そういえば、ええと、ちょっと記憶が曖昧になってしまったが、昔、SI3D の頃って、こういう次々にピックしていくスタイルでコンストレインしてなかったっけ？　XSI に移行した頃にこの挙動が変わっていてあれっ？と思ったような気がするんだが、記憶違いだろうか。
      
      
      
      

サブちゃんの恐怖。

                  

自作プラグインを作っていると、XSI のインターフェース上のメニューに入れるか、ただのスクリプトコマンドにしておいてボタンから起動する仕様にするか、悩む。　しかし過去にボタンが増えす ぎてどれが何だかわからなくなっていた経験から、もう最近ではほぼ１００％メニューに入れることにしている。そもそもボタンを置いておくためにはツール バーが必要で、ツールバーが占有する面積が惜しい。


                                     

ということで片っ端からメニューに ぶち込んで来たわけなんだが、今度はメニューが長くなりすぎて困っている。インターフェース右側にある Transform タブなどは、もともとすげー長いメニューである。タテ1200ピクセルの画面の半分以上を占める。ここに、さらに自作プラグインの項目を足したらもう、そ れはそれは長いながーいメニューになってしまうわけで。
            
そうなるともう、サブメニューを使うしかなくなる。つまりメニューの階層化である。目的のコマンドにたどり着くまでのクリックが若干増えるが、長過ぎて目的のコ マンドが探しにくいよりはずいぶんマシである。自作プラグインでは、バッチィやぬるぬるでサブメニューを使っている。　サブメニュー、便利ですね。
            
            

      
  便利ですか。
　そうですか。
　ほんとに便利ですか。
　いや、便利ですよ、確かに。
　しかし。



      
      
XSI のスクリプティングに興味のある方は、このファイルをダウンロードして、プラグインフォルダにぶち込んでみて下さい。サブメニューのテスト用プラグインで す。　右側の Snap メニューに、SubMenuTest という項目と、SubSubSub というサブメニュー階層が現れます。

      
ソースを見てみます。

赤文字の　１　は、oMenu に直接コマンドを追加しているのでサブメニューではありません。そしてそのコマンドとはこのファイルで定義しているコマンド自身ですので、 function SubMenuTest_Execute(  )　が実行されます。 その中身は　２　の部分です。 Logmessage コマンドで "SubMenuTest -- サブメニューじゃないやつを実行。" とログするだけですね。試しに実行してみましょう。

するとスクリプトエディタに

このようにログされています。問題ありません。いい子です。


      
次にソースのサブメニュー部分を見てみます。上の画像の ３ で oSubLevel という名前でサブメニューを追加しています。以下に続く３行のうち、最初の２行は AddCallbackItem となっていて、このファイル内のファンクション　 ４ と ５ を呼び出しています。　最後の１行は AddCommandItem となっていて、NullNullEXE という外部コマンド（このコマンドにとっては外部のコマンド）を呼び出しています。これは自作プラグインぬるぬるに含まれる１コマンドです。
      
ではサブメニューの項目を実行してみましょう。

最初の２つは、ソースの ４ と ５ の部分を見ればわかるように、Logmessage コマンドが実行されて "SubMenuTest -- サブメニュー 1　を実行。" などと、スクリプトエディタ内にログされるはずです。

しかし。

何も起こりません。　なにっ。
      
３つ目の NullNullEXE は、当然プラグイン「ぬるぬる」をインストールしていなければ存在していないコマンドです。　でも、もちろんここの環境にはインストール済みです。ここで 作ったんですから。

しかし。

何も起こりません。　なんだとっ。　悪い子です。
      
      
・・・・。
      
      
ところで自作コマンドをXSI のインターフェース上のどのメニューに登録するのかは、ソースの前半、XSILoadPlugin ファンクション内で指定します。

この　in_reg.RegisterMenu(siMenuMCPSnapID,"SubMenuTest_Menu",false,false);　 ですね。SDK マニュアルを見ると、登録できる全てのメニューのリストが載っています。ここでは siMenuMCPSnapID としているので、XSI インターフェースの右側、Snap メニューのところに登録されたわけです。
      
しかし、サブメニューじゃないコマンドはちゃんと実行されるのに、サブメニューのコマンドは実行されない。そこでものは試し、他のメニューに登録してみます。 　ソースの siMenuMCPSnapID を、siMenuTbModelCreateModelID　に書き換えました。

なので、今度は Model メニューに現れます。

ってことで、実行します。

あらっ。　こんどはちゃんとコマンドが実行されました。　サブメニュー1も２も、NullNullEXE もちゃんと実行されました。
Model メニューからは動いているのに、なぜ Snap メニューからは動かなかったんだ？
      



結論を言うと、バグだそうです。アフォか Softimage。


      
      
全部のメニューを試したわけではないのですが、左側のメニューはどれも問題無いようです。上のメニューも問題ありませんでした。右クリックのコンテキスト メニューも大丈夫でした。しかし右側のメニューは全滅です。　下の Animation メニューもダメでした。　でもなぜか Playback メニューは問題なく実行されます。　メニューに登録できる場所はすげーいっぱいあるので、全部試すことはできませんが、どうもメニューの ID に MCP という名前が付くものは全滅のように見えます。しかし上に書いたように問題なく実行される Playback メニューは、MCP の分類に入っています。よくわかりません。アフォです。
      
自分が試した限りの実験結果。クリックで拡大。

      
      
これが XSI の不具合だと気づくまでにずいぶん時間がかかりました。なにせ素人スクリプター、絶対に自分がどこかを書き間違えているだけだ、とか、そもそもメニューの 概念をよく理解できてないからだ、などと謙虚な姿勢でさんざん調べまくっていたのです。　馬鹿でした。
      
ということで、サブメニューにしたくてもできない場合が多くて非常に困っております。しかたなくサブメニューをあきらめて第一階層にズラッと並べるか、メ ニュー項目を選んだら XPOP コマンドが立ち上がるようにして擬似的にサブメニューを作ったりしながら、なんとか運用しています。とても不便です。不便だよ Softimage さん。特に右側のメニューが使えないのがイタすぎだよ。そもそも、ユーザが好きな場所にメニューを仕込めるようにわざわざ SDK を改良したんでしょ？　そのときに、実験しなかったの？　全部のメニューでちゃんと動くかどうかテストしなかったってこと？　左側のメニューだけ実験して 上手く行ったから右は実験してないとか？　それじゃまるで素人スクリプターの俺みたいじゃないですか。あなた素人じゃないんだから。頼むよほんとに。次の バージョンで直してよ。いいですね。約束ですよ。



      
XPOP 起動による擬似サブメニュー以外に今のところ代替案無し。
次バージョンを待つ。
      
毎日ボヤいているうちに顔が野村克也に似てくる。
あなたのせいよ Softimage さん。