カテゴリー「XSI Animation」の6件の記事

2014年2月11日 (火)

Fカーブエディタで選択ツールに戻れず激怒。

Fカーブエディタで、選択ツールに戻れずに困ったこと、ありませんか? 俺はしょっちゅうなんです。激怒します。


ちなみに、0 を押して出現するフローティングのエディタではなく、ドックされたエディタ上での話です。フローティングのエディタの中でもこの問題が起きるのかは、わかりません。





Fカーブエディタ上では、デフォルトでは選択ツールですよね。

Fc1

上の画像にある、矢の先っちょのようなアイコンですよね。 これでFカーブもキーフレームも選択できる。



で、Fカーブエディタ上でパンとかズームとかの操作をします。 S キーだったり、Z キーとかですかね。
Fc2
すると、上の画像のようなアイコンに変わります。


で、その後、また選択ツールに戻りたい。 だから Space キーを押します。 Space キーを押すと、「選択ツール」 と 「Fカーブ選択ツール」 のトグルに入るはずです。 でも、なぜかそうならない。 選択ツールに戻れない。 なんで? 何度押しても、力いっぱい押しても、なでるように押しても、選択ツールには戻れません。 いったいどういう押し方をしろと言うのでしょうか。 激怒します。

選択ツール独自のショートカットは Y キーらしいのですが、Y を押してみても戻りません。 激怒します。



この現象、ないですか? 俺はいつもこうなります。 激怒です。



他のキーを適当にがちゃがちゃいじくっていると、急に選択ツールに戻れたりします。 いつの間にか直っちゃった感じ。 でも、どーしても戻れないこともあります。そういう時は仕方なく、XSI を再起動します。 再起動さえすれば必ず戻るのでいいのですが、超面倒です。激怒。


これ、ずっと昔からあったんだよなあ。 回避方法が分からず、何年も放置して来ました。 ビデオカードの問題かなあ、とか思ったり。






しかし、最近その回避策というか、この現象が起こったときに100%確実に選択ツールに戻れる方法を発見したような気がするのです。 サッキーたんと話をしているうちに、偶然見つけた気がします。


実にシンプルな方法なのですが、この症状が出たら、0 キーを押す。 以上。
Fc3

0 キーは、フローティングのアニメーションエディタを開くショートカットです(Fカーブエディタはアニメーションエディタの中の1つのモードですね)。 テンキーの方じゃないですよ。フルキーの 0 です。

このフローティングのエディタの中では、ちゃんと選択ツールに戻れるんですよね。 なぜかは知りません。 Space 押したり Y キー押したりしてみます。ちゃんと選択ツールに戻れることがわかります。

そのままフローティングのエディタは閉じちゃって、元のドックされたエディタに戻ります。 すると、Space キーとかでちゃんと戻れるようになっているのです。



ということで、この現象が起きたら フローティングのエディタを出して何か操作をし、閉じて、元のエディタに戻る。 をやればよいらしいとわかりました。 今のところ100%これで行けてます。



正確には、0 を押すことが重要なのではなく、フローティングのエディタを出現させることが重要なのだと思います。たぶん。

あれ? フローティングのエディタ上で、なにかしらの操作は要るのかな? もしかして、エディタを出して何も操作せずすぐ閉じてもいいのかな? ちょっとわかりません。 この現象は、しょっちゅう出るくせに、意図的に再現しようとするとできないんですよねー。 いったい何をきっかけにこの 「戻れない状態」 に突入するのか、いまだにその法則性がわからないです。 右クリックが関係してそうな気もしているんだけど、定かではありません。

あと、最初からフローティングのエディタでやっていた場合も、どうなるかわかりません。 もうひとつフローティングのエディタを出せばいいのかな?  そもそもフローティングのエディタでもこの現象は起こるのかな? 俺、普段はドックされたエディタでしか作業しないので、わかりません。




どうですか。やってみてもらえますか。なんか気づくことがあれば、どうか教えてくださいませ。どなたでも。







あ、明けましておめでとうございました。






.

| | コメント (2) | トラックバック (0)

2012年5月 9日 (水)

嘔吐 Actions。

Action の Export って、複数をイッキにできないですよね。


XSI のモーションモジュールで、 Tools > Import/Export > Export Action ってのがあって俺はよく使うのですが、一度にひとつの Action Source しか吐き出せません。 複数の Action Source をイッキに吐き出してはくれないわけです。 それどころか、複数の Action を選んだ状態で ExportAction を実行すると、意味不明のエラーを吐きます。


ほら。

Exportmultipleactions

「すいませんが、アクションは、ひとつだけ選んでおいてもらえますかね」 とかエラーを出すならまだしも、Unexpected failure ですからね。 予期せぬ失敗だそうです。 いわゆるソーテーガイってやつですね。 複数選んでいる状態はソーテーできなかったということでしょうか。 
それくらいソーテーしろよ( ^∀^)ゲラゲラ




ほんと XSI って、値段高いくせに、こういう細かいところで不親切ですよね。不親切というより、なんつうか、頭弱いですよね。 アクションの吐き出し機能を付けるなら、普通、複数いっぺんに出来るようにするでしょう? 俺でも気付くよそんなこと。 まあ、そこは置いといたとしても、このエラーメッセージは無いでしょう。ちゃんとエラー処理しなさいよもう。


まあ、XSI は Maya 様や Max 様のプラグインなのだから、仕方ないとは思いますけどね。



別にバグとかそういうわけではないでしょうね。一度に1つしか書き出せない仕様なわけですよ。  「マニュアルにもいっぺんに複数吐き出せるとは書いてないので、マニュアルに反してないという意味で、不具合ではありません」  とか、 「メニューの表記も Export Action であって Export Actions ではないから、これでいいのです」 とか言うのかな嘔吐デスク様は。 まあ、いいです。 普通に仕様です。 何もおかしくはありません。 実に興味深い仕様ですけどね。



ちなみにアクションのインポートも、ファイルダイアログを通すと一度に1つしか実行できないという謎仕様です。 これって、もしかして XSI のダイアログの設計上の制限かな? XSI 作業の他の場面でも、複数のファイルをいっぺんに選択できるってのは無いですよね? あの XSI 専用入出力ダイアログが、ファイルの複数選択に対応してないということなんでしょうか? どうなのでしょう。

ま、アクションのインポートは Windows の Explorer から複数をいっぺんにドラッグ&ドロップできるので、そんなには困りませんけどね。




ともかくだ、複数の Action Source をいっぺんに吐き出すスクリプトは、過去に数回書きました。 昨日またそれが必要になって、いつものクセでスクリプトエディタを開いて書き始めたら、過去に何回か書いたことをふと思い出してHDD をひっくり返してみたら出てきたので、今回は無駄なコード書きを避けられました。  あ、これ、タコ親父のアクションを吐き出す時に書いたやつだな。 リグの都合上、触手1本ごとに違う Model だったので、アクションのストアもいっぺんにできないし、書き出しもいっぺんにできない。しかたないから色々ツールを書いたんだった。 龍司、今日もちゃんとタコ焼いてるか。 目と目の間をひと突きだぞ。



ま、ともかくそのスクリプトにちょっと改良を加えたので、一応載せておきます。


JScript
------------------------------------------------------------------
//    嘔吐 Actions

//    デフォルト値取得
DefRemove = GetGlobal( "bOutoActions_RemoveEani" );
if ( DefRemove == null ) DefRemove = true;

DefModelName = GetGlobal( "bOutoActions_ModelName" );
if ( DefRemove == null ) DefRemove = true;

DefPath = GetGlobal( "sOutoActions_Path" );
if ( DefPath == null ) DefPath = Application.ActiveProject2.path + "\\Actions\\";



//    PPG
var oP = XSIFactory.CreateObject( "CustomProperty" );
oP.name = "嘔吐Actions";
oP.AddParameter2( "bRemoveEani", siBool, DefRemove );
oP.AddParameter2( "bAddModelName", siBool, DefModelName );
oP.AddParameter2( "sPath", siString, DefPath );

var oL, oItem;
oL = oP.PPGLayout;
oL.AddGroup();
    oL.AddRow();
        oL.AddGroup( "", false, 55 );
            oItem = oL.AddItem( "bRemoveEani", "Remove " + '"' + "eani" + '"' + " from Name" );
        oL.EndGroup();
        oL.AddGroup( "", false, 45 );
            oItem = oL.AddItem( "bAddModelName", "Add Model Name");
        oL.EndGroup();
    oL.EndRow();
    oL.AddRow();
    oItem = oL.AddItem( "sPath", "Path", siControlFolder );
    oItem.SetAttribute( siUINoLabel, true );
    oItem = oL.AddButton( "OpenExplorer", "Explorer" )
    oL.EndRow();
oL.EndGroup();

oL.AddSpacer( 0, 10 );
oItem = oL.AddButton( "Export", "げろっ" );
oItem.SetAttribute( siUICX, 0 );

oL.Language = "JScript";
oL.Logic =    Export_OnClicked.toString( ) +
            OpenExplorer_OnClicked.toString( ) +
            FilterAction.toString( ) +
            DoTheFuckExport.toString( );

function OpenExplorer_OnClicked()
{
    var oFSO = new ActiveXObject( 'Scripting.FileSystemObject' );
    FolderPath = PPG.sPath.value;
    if ( oFSO.FolderExists( FolderPath ) )
//    フォルダ存在
    {
        XSIUtils.LaunchProcess ( "explorer /e," + FolderPath);
    }
    else
    {
        Logmessage( "そんなフォルダは無いので帰って下さい。", siError );
    }
}

function Export_OnClicked( )
{
    var oFSO = new ActiveXObject( 'Scripting.FileSystemObject' );
    FolderPath = PPG.sPath.value;
    if ( oFSO.FolderExists( FolderPath ) )
//    フォルダ存在
    {
        var oExportingActions = FilterAction( Selection );
//ActionSource収集
        if ( oExportingActions.count == 0 )
        {
            Logmessage( "Action Source が選択されてなかったので帰って下さい。", siError );
        }
        else
        {
            for ( i=0; i<oExportingActions.count; i++ )
            {
                DoTheFuckExport( oExportingActions(i) );
//Action嘔吐実行
            }

            SelectObj( oExportingActions );
            //    デフォルト値上書き
            SetGlobal( "bOutoActions_RemoveEani", PPG.bRemoveEani.value );
            SetGlobal( "bOutoActions_ModelName", PPG.bAddModelName.value );
            SetGlobal( "sOutoActions_Path", PPG.sPath.value );
        }
    }
    else
    {
        Logmessage( "そんなフォルダは無いので帰って下さい。", siError );
    }   
}


//    嘔吐実行ファンクション
function DoTheFuckExport( oAction )
{
    ActionName = oAction.name;
    if ( PPG.bRemoveEani.value )   
//    名前から _eani 削除
    {
        ActionName = ActionName.replace( "_eani", "" );
    }
    if ( PPG.bAddModelName.value )   
//    名前に Model名を付加
    {
        ActionName = oAction.Model.name + "_" + ActionName;
    }
    Path = FolderPath + "\\" + ActionName + ".eani";
    ExportAction( oAction, Path );
    Logmessage( "Action ゲロ完了す。 --> " + Path );
}


//    Action のみを返すファンクション
function FilterAction( in_Objs ){
    var oCol = XSIFactory.CreateObject( "XSI.Collection" );
    for ( var i=0; i<in_Objs.count; i++ ){
        if ( in_Objs(i).type == "Action" ){
            oCol.Add( in_Objs(i) );
        }
    }
    return oCol;
}

InspectObj( oP, null, null, siLock );


------------------------------------------------------------------




Outoactions

Explorer から、ActionSource を選びます。もちろん複数可能。 っていうか複数じゃないときはこのツールを使う意味は全くないと思います。

で、スクリプトエディタにこのコードをペーストして起動し、PPG の中で嘔吐先の Path を入力してゲロボタンを押すと、そのフォルダに Action を全部ゲロします。




Explorer ボタンを押すと、嘔吐先の Path を Windows の Explorer で開きます。

Remove "eani" from Name をチェックしておくと、もともとのアクション名に "_eani" が含まれていた場合、それを削除した名前にします。 インポートによって作られた Action Source って、その名前にファイルの拡張子が付いちゃうんですよね。 eani ファイルをよくインポートするので、xxxx_eani という名前のアクションになることが多いです。 普段は放置したりもするけど、改めて書き出すときは削除したいので、この機能を付けました。

Add Model Name
をチェックしておくと、ゲロするファイルの名前の冒頭に "Model名_" が付加されます。 これは、複数 Model 以下で同じ名前の Action Source を書き出そうとした場合、このスクリプトは次々に上書きして行ってしまうため、ゲロしたはずのファイルが見当たらない、という事態になります。単に同じ名前で上書きされていただけなんですがね。 これを避けるために、 Model 名を付加する機能を付けました。







スクリプティング的に特筆するべきことは、まあ、ないですかね。

Get / SetGlobal を使ってその XSI セッション中は PPG に入力した値を覚えていて、次に起動したときに前回の設定がデフォルト値として入っているようにしています。 最近の自分の中での流行りですね。 Preference に残すほどでもないけど、起動するたびに設定がスクリプトにハードコーディングされた固定値に戻ってしまうのは嫌だ、という場合にこうしています。







しかし、もともとはすごく小さいスクリプトだったのに、ちょっとした機能を付けようとしただけで、なんか長くなっちゃいますねえ。


アクションがらみの細かいスクリプトも溜まってきているので、そのうちまとめたツールセットにしたいんだけど、今のところとっ散らかってます。






それではごきげんよう。




.

| | コメント (0) | トラックバック (0)

2012年1月18日 (水)

キーフレーム殲滅でポン。

昼間っから唐突に降ってくるスクリプト。

実は昨日の深夜に1時間くらいで書いて、さっき30分くらい手直し。 きっと俺の作業にも役立つ。



すいません、まだ解説無し。
いずれ。

動きますかね初夏さん。



JScript
-------------------------------------------------------

var oPC = Dictionary.GetObject( "PlayControl" );

DefMode = GetGlobal( "KeyFrameFucker_Mode" );
DefStart = GetGlobal( "KeyFrameFucker_StartFrame" );
DefEnd = GetGlobal( "KeyFrameFucker_EndFrame" );
DefLock = GetGlobal( "KeyFrameFucker_Lock" );

if ( DefMode == null )
{
    DefMode = 0;
    DefStart = oPC.In.value;
    DefEnd = oPC.Out.value;
    DefLock = false;
}

var oP = XSIFactory.CreateObject( "CustomProperty" );
oP.name = "キーフレーム殲滅でポン。";
oP.AddParameter2( "iMode", siInt4, DefMode );
oP.AddParameter2( "iStartFrame", siInt4, DefStart );
oP.AddParameter2( "iEndFrame", siInt4, DefEnd );
oP.AddParameter2( "bOverrideLock", siBool, DefLock );

var oL, oItem;
oL = oP.PPGLayout;
oL.AddRow();
    oL.AddGroup( "", false, 23 );
        oItem = oL.AddButton( "DeleteKey", "∀゜)⊃" );
        oItem.SetAttribute( siUICX, 0 );
        oItem.SetAttribute( siUICY, 110 );
    oL.EndGroup();
    oL.AddGroup( "", true, 54);
        oItem = oL.AddEnumControl( "iMode", Array( "Keep this Range", 0, "Fuck this Range", 1 ), "Mode", siControlCombo);
        oItem.SetAttribute( siUINoLabel, true );
        oItem = oL.AddItem( "iStartFrame", "Start" );
        oItem = oL.AddItem( "iEndFrame", "End" );
        oItem = oL.AddItem( "bOverrideLock", "Fuck Key Lock" );
    oL.EndGroup();
    oL.AddGroup( "", false, 23 );
        oItem = oL.AddButton( "DeleteKey", "⊂(゜∀゜" );
        oItem.SetAttribute( siUICX, 0 );
        oItem.SetAttribute( siUICY, 110 );
    oL.EndGroup();
oL.EndRow();

oL.Language = "JScript";
oL.Logic = DeleteKey_OnClicked.toString();

function DeleteKey_OnClicked()
{
    var oCol = XSIFactory.CreateObject( 'XSI.Collection' );
    oCol.items = Selection;
    var oExpanded = oCol.expand( );

    var oAllFuckinAnimatedParametersGodDamnItYouMotherFuckerEatThisShitSonOfABitch = XSIFactory.CreateObject( 'XSI.Collection' );
    for ( var i=0; i<oExpanded.count; i++ )
    {
        oAllFuckinAnimatedParametersGodDamnItYouMotherFuckerEatThisShitSonOfABitch.AddItems( oExpanded(i).NodeAnimatedParameters( siFCurveSource ) );
    }

    Mode = PPG.iMode.value;
    FrameStart = PPG.iStartFrame.value;
    FrameEnd = PPG.iEndFrame.value;
    LockOverride = PPG.bOverrideLock.value;   

    for ( var i=0; i<oAllFuckinAnimatedParametersGodDamnItYouMotherFuckerEatThisShitSonOfABitch.count; i++ )
    {
        var oFcurve = oAllFuckinAnimatedParametersGodDamnItYouMotherFuckerEatThisShitSonOfABitch(i).Source;
        if ( Mode == 0 )
        {
            oFcurve.BeginEdit();
                oFcurve.RemoveKeys( FrameStart - 9999999, FrameStart - 0.01, LockOverride );
                oFcurve.RemoveKeys( FrameEnd + 0.01, FrameEnd + 9999999, LockOverride );       
            oFcurve.EndEdit();
        }
        else
        {
            oFcurve.BeginEdit();
                oFcurve.RemoveKeys( FrameStart - 0.01, FrameEnd + 0.01, LockOverride );
            oFcurve.EndEdit();
        }
    }

    SetGlobal( "KeyFrameFucker_Mode", Mode );
    SetGlobal( "KeyFrameFucker_StartFrame", FrameStart );
    SetGlobal( "KeyFrameFucker_EndFrame", FrameEnd );
    SetGlobal( "KeyFrameFucker_Lock", LockOverride );

    Logmessage( "|∀゜)⊃ 終わりますた ⊂(゜∀゜|" );


    // 以下の1行追記。表示を強制アップデート。 2011までは多分必要。Thanks to 網ー誤マーティン
    SelectObj( oCol );
}

InspectObj( oP, null, null, siLock );

-------------------------------------------------------



Keyframefucker


Keep モードで、そのフレーム範囲内にあるキーフレームを保持しそれ以外を殲滅。 つまり指定したフレーム範囲より前にあるキーフレームと後にあるキーフレームが殲滅されます。 頭とケツ削除。

Fuck モードで、そのフレーム範囲内にあるキーフレームを殲滅。

Fuck Key Lock は、ロックされてるキーフレームでも強引に犯っちまうかどうか。

ボタンは左右同じです。どっち押してもいいです。

複数オブジェクト可。 オブジェクトをブランチ選択してればその子供も含まれる。 Group を選択していればその Group 内の全てのオブジェクトが対称。 つまり Expand の魔法




解説はまた後ほど。たぶん。



ごきげんよう。


------------------------------------------
追記:

コメント欄にありますが、ヤラたんからのタレコミで、2011 まではどうやら表示のアップデートに問題があったようでした。 キーフレーム削除後、表示が更新されないという。 実際はちゃんと削除されているんだけど、画面上即座にそれが確認できないという状態ですね。

俺はもともと 2012 でこのスクリプトを書いたのですが、2012 ではその問題が出なかったんですよ。 でも 2011 SAP SP1 で試してみたら、まさに同じ問題に出くわしました。

他のお方はどうですか? 同じ問題が出るお方はいますか? バージョンは?

とりあえず、ヤラたんの実験結果に従い、上のコードの赤字の部分、1行追加しました。 おそらくこれで、キーフレーム削除後に表示が強制アップデートされると思います。 2012 よりも以前のバージョンでは必要と思われます。 2012 以降のバージョンでも、まあ害にはならないので、この1行があって良いでしょう。

マーティンヤラたんありがとう (゜∀゜

------------------------------------------

.

| | コメント (4) | トラックバック (0)

2011年3月 4日 (金)

Hierarchical Scaling。

Local Transform のプロパティの中にある Hierarchical Scaling って何に使うんだろうなーと思っていたんですがね。 あんまり使わないしまーいーや、とスルーしてたんですが。

どうやらスケーリングを親からどう引き継ぐかの挙動を決めているらしくて、他のソフトウェアからデータを持ってきた場合などで、その計算方式が違うと正しくスケーリングされない(シアーがかかってしまったり)するらしい。それを防ぐものらしい、としか思ってなかったんですが、今日その効能を実感しました。



Instance にマイナスのスケールを入れてシンメトリにしたかったのだが・・・・。

Hierarchicalscaling1

対称になってくれない・・・・(;Д;)

Model の下にキューブがあります。緑色のオブジェクトです。
その子供に、XSI男さんが二人います。 彼らは、それぞれ独自にローテーションされています。
この Model を Instance します。
左右対称にしたいので、Instance のスケールX を - 1 にします。

すると、左右対称になってくれるのは親であるキューブだけなんですね。子供である XSI男さんたちは、向きが対称状態になってくれません。

この時、二人の XSI男 の Hirerarchical Scaling はオンでした(デフォルトのまま)。



そこでこれをオフにすると、
Hierarchicalscaling2

ちゃんと対称状態になってくれますた。ヽ(・∀・ )ノ


子供が親からスケーリングを引き継ぐ時に、親の軸でスケールするのか自分の軸でスケールするのかを決めているようですね。 デフォルトのオンだと自分自身の軸でスケールされ、オフにすると親の軸でスケールされるようです。 今回のような Instance にまるごとスケールをかけて対称状態にしたい場合は、オフが望ましいということになりますね。 最初オンだった時は、XSI男さんたちは自分自身のローカルXでスケールされていたため、その場でXが反転していただけだったのですね。


ということを実証するために実験。
男さんたちのジオメトリをいじり、明白に左右対称を崩しておきます。

その上で、最初と同じく Hierarchical Scaling をオンにしてみると、
Hierarchicalscaling3

やっぱりね。 自分自身がその場でXスケール反転していただけでした。



今思えば過去に、Instance にマイナススケールを入れたら、元Model に含まれる子供のパーツの向きが  Instance 上でおかしくなってしまい、泣く泣く Instance をあきらめて普通に複製したことが何度かあります。 なんだあ、ここをいじれば良かったのかあ。 リグの都合とか無ければ、これで良さそうじゃないか。 早く言ってくださいよハゲ



いつからこのオプションが付いたのか知りませんが、ずっと昔から、ヘタすると ver1.0 からあったのかもしれません。 ノーマークでした Orz




.

| | コメント (2) | トラックバック (0)

2009年10月28日 (水)

Mixerとタイムレンジの軋轢。

かねがね思っていたんですがね。



Animation Editor 上で、タイムラインカーソルをドラッグして現在フレームを変更するってのはよくやりますよね。 アニメーション作業をしている時に、Fカーブに集中できるので便利ですよね。

Ae1上の画像では現在フレームは1です。 シーン全体のスタートフレームも1です。


で、Animation Editor 上で思わずカーソルをドラッグし過ぎて、マイナスフレームまで持って行ってしまうこともありますよね。Ae2上の画像では、Animation Editor 上では - 6 のフレームにカーソルがあります。
でも、シーンのスタートフレームは1のままですよね。そりゃそうですよね。シーンはフレーム1から始まれと指定してあるわけで、自分でマイナス6に変更しない限り、勝手に変えて欲しくないですよね。




Animation Mixer ではどうなのでしょう。

Am1同じように、Animation Mixer 上でフレーム1にいます。 シーンのスタートフレームも1です。



Mixer 上で、思わずタイムカーソルをマイナス領域にまでドラッグしてしまいました。

Am2
Animation Editor と挙動が違うじゃねえか  そもそもシーンのスタートフレーム変えろなんて言ってねえだろ  勝手なことすんなゴルァ

Mixer でドラッグしたらシーンのスタートフレームが変わってありがたい場面って、想像付かないんですけどね。 俺があんまり Mixer 使わないからそういう場面に出くわしてないだけ? ねえ? どんな場面でこれが便利になるんですか?  むしろ、毎回 Mixer 使うたびにスタートフレームやエンドフレームを手で修正しなければならなくって、ヒジョーにうざったい思いをしておりますよ俺は。 ねえ。これが便利な場合ってなんなの。誰か教えて下さい。

Mixer でどう動かそうがシーンのスタートフレームを絶対変えないオプションなんて、ないですよね? そうですよね? ね? ね? ないと言ってくれ。




思えばこの Mixerゴルァも、大昔から付き合ってきてしまったな・・・。

長いこと付き合ってると、どんなに悪いことでも慣れてしまって、
決してゴルァが消えるわけではないんだけど、
深いあきらめを抱きながら、
結局付き合ってしまうんだよな。

悪い女です。
こればっか。




.

| | コメント (0) | トラックバック (0)

2008年3月29日 (土)

this_model の恐怖。

                  
エクスプレッションで、thisthis_model というものがありますね。 「私」 もしくは 「私が所属する Model 」を表すものですね。 長ったらしいオブジェクトの名前や Model の名前を書かなくても済むので便利ですね。
      
      

 便利ですか。
 そうですか。
 ほんとにそうですか。
      
      


Hoge という名前の Model があります。 cube と cone がこの Hoge に所属しています。
PPG から Rot Z のアニメーションアイコンをドラッグ&ドロップして、普通にイコールの関係のエクスプレッションを作りました。

Tm01

画像の赤線のように、エクスプレッションの中には Model の名前である Hoge  が入っています。ここではひとまず this_model を使っていないということです。
      



この状態で、cube を Hoge から切り離してみます。

Tm02

cube はもはや Hoge の子供ではなくなったので、エクスプレッションも自動的に更新され、Hoge.cube.kine.local.rotz ではなく、cube.kine.local.rotz になっています。なんも問題ありません。スヴァらしいです。っていうか当然です。
      
      

      
今度は cube を、別の Model である PIYO に所属させてみます。

Tm03

同じようにエクスプレッションは正しく自動更新されています。 いい子だなあ XSI ちゃん。
      
      

      
ここで、便利な this_model が登場します。 親子関係は元の状態に戻しました。つまり cube は Hoge という Model の所属です。

Tm04

this_model に書き換えたので、Hoge だろうが PIYO だろうが名前は関係なくなり、自分が所属する Model を指し示すことになりました。 問題ありません。エクスプレッション通り、Rot Z がちゃんと連動して動いてくれています。 いい子です。
      
      


      
でも、シーンを作り進めていくうちに、cube は Hoge から切り離す必要が出てきたので、親子をカットしました。

Tm05

げげ。 今度は自動更新されない。 this_model のまま残っている。 cube は Hoge から切り離されたので、もはや this_model.cube というものは存在しないのに。

でも不思議なことに、エクスプレッションの関係は生きています。ちゃんと Rot Z が連動します。エクスプレッションの表記と実際の挙動が違ってしまっていることになります。 うーむ どうなのよこれ。
      
      



さらに、cube は別 Model に所属させる必要が出てきました。 すると、

Tm06

やはりダメー。 this_model は居座り続けます。 でも、やはりエクスプレッションの関係は生きています。
      
      


      
バグだそうです。 アフォか Softimage。
      


      
      
もっと最悪なのは、これに気づかず、エクスプレッションを Action 化してしまったときです。
上に書いたように、親子を切り離したり別 Model に所属させた場合、エクスプレッションの表記は更新されていなくても実際の挙動はちゃんとエクスプレッションが生きている状態になっているため、パッと見は正常なので気づきにく いわけです。この状態でエクスプレッションを持っている cone を選択し、Store メニューから Action 化します。

Tm07


すると、

Tm08

Action の中には、this_model が残ったまま格納されます。まあ、そりゃそうだわな、実際にエクスプレッションに this_model って書かれているんだからな。
で、Action 化するときのPPGでアニメーション(エクスプレッション)を削除したり、後で Apply Action するつもりで手動でエクスプレッションを削除したりとか、よくやります。そのための Action ですから。
      

ってことで、Apply Action を実行して格納したエクスプレッションを cone に戻してあげます。

Tm09


すると。
      

Tm10

Action の中には this_model という表記で格納されているにも関わらず、実際はもう cube が元の Model に所属していないわけで、つまり this_model.cube が指し示すオブジェクトが存在しないわけで、当然、エクスプレッションが元に戻せません。したがって Apply Action したあとも、エクスプレッションは空っぽのままです。
ふざけんな XSI。 悪い子です。
      


しかたなく、Action のPPGを開き、this_model と書かれている部分を、現在の所属モデルである PIYO に手で書き直してやります

Tm11

これでちゃんと Apply Action でエクスプレッションを戻せるようになります。 
ああめんどくせえ。ふざけんな XSI。
      
      

      
Apply Action でアニメーションが戻せないのは、this_model で参照しているオブジェクトが存在しないから当然なので、それ自体が問題なのではない。 問題は、this_model を使っていると親子を変えたときにエクスプレッションの表記が正しく更新されないことにある。 正しく更新されていないまま、でもエクスプレッションに書 かれた文字列をそのまま Action として格納するため、このようなことが起こるのである。
      
・this_model を使ってるときでも、親子変えたらちゃんとエクスプレッションを更新しろゴルァ
・さらに安全策として、Store で Action化するときに、参照先の存在をチェックしろ。存在してないなら警告出せゴルァ
      
ということになる。そしてこれは XSI側の不具合なので、次のバージョンとかで修正されるまでこちらとしては為す術が無い。そうなると結論は、
      
・this_model 使うな
      
ということになる。 Orz
      
      
      
最初これに気づかずガンガン this_model を使っていたため、後で大変なことになった。 気づいた後は、Action 化する前に全部 this_model を普通に model の名前に戻そうと手で打ち直していたが、やってらんなくなったのでスクリプトを書いた。ついでに検索と置換もできるようにしたらけっこう便利になった。ま だ散らかっている状態のスクリプトなので、そのうち整理できたらアップします。
      
      
XSI はこういう細かい不具合多いですねえ。細かいことだからまあいいでしょなんて思ったら大間違いですよ Softimageさん。 もし8本足の動物がいて、1本につき400個のエクスプレッションが入っていたりしたら、どうするんですか。実際にいるんです よ、8本足の動物は。10本のだっています。わかってますか。
      
今日もモントリオールに向かって怨嗟の炎を吐く。
      
      
      

| | コメント (0) | トラックバック (0)