« 2012年2月 | トップページ | 2012年4月 »

2012年3月

2012年3月31日 (土)

ICE の PC にラティスでポン。

ICE の PointCloud をラティスで変形できないかなー、と思って、
やってみたらできなくて。効かない。変形してくれない。


昔のパーティクルはできたんだけどなー


とか文句言ってたら、アサクラさんというお方が教えてくれまして。

Lattice オペレータがモデリングスタックではいかんばい。Post Simulation スタックなど、ICE のオペレータよりも上ば持って行かなあかん という話でした。
彼の口調を最大限真似してみたつもりですが、ムズかしいです。



やってみたら、できました。
ありがとうございました。




留意点は、PointCloud が最大の大きさに成長しきったところでラティスを与えるのが良さそうだ、ということでしょうかね。

ラティスは、ブツのバウンディングボックスの大きさで出てきますよね。 PointCloud は、バウンディングボックスの大きさが刻々と変わるから、一番でかいところでラティスを与えないと、ボックスに入らないパーティクルが出てきた時に、効かなくなってしまう。 ように見える。


そして、パーティクルの各種パラメータをいじったら、再び、一番大きくなるフレームを見つけてそのフレームでラティスを与え直すといいように見えます。 パラメータいじると、パーティクルの挙動が変わって、バウンディングボックスの大きさが変わるからです。 色などバウンディングボックスの大きさに影響がないパラメータでは、ラティスを与え直さなくても大丈夫でした。


まあ、ラティスのことを考慮に入れながらパラメータをいじってその後いちいちラティス与え直すって手順は面倒ですよねえ。 なので、補助的に、ほんのちょっと PointCloud 全体の大きさや広がりを調整したい、みたいな時に有効かも知れません。どうですかね。



レンダの実験もしてないし、思わぬ落とし穴があるかも知れません。
どなたか実験して新たにわかったことがあったら、是非教えて下さいませ。







以下に、一応手順の画像を載せておきます。



真横にパーティクルが飛ぶだけの PointCloud。

L1






一番成長しきったフレームで、ラティスを与える

L2





ラティスオペレータの位置を変える。

L3






ラティスを変形すると、PointCloud が追従。

L4
ダウンロード LatticeOnICEPointCloud.zip (246.1K)

(XSI 2012 シーンファイル)





チュロス食べたいなあ。

プレッツエルも大好き。

あ、パーティクルの色は茶色系にしとけばよかったな。






.

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

2012年3月21日 (水)

親だけ残ってくれ。

複数のオブジェクトを選択している時、その中で、最も親になるオブジェクトだけに何か処理を施したいということがありましてね。



 A - B - C


という親子関係があったとして、A が一番親なんですが、 この3つを選択していたとしたら、一番親である A だけが残って欲しい。

B と C の2つを選択していた場合、その中で一番親になるのは B ですから、B だけが残って欲しい。

A と C の2つを選択していた場合、同じ理由で A だけ残って欲しい。

B のみを選択していたら当然 B が残って欲しいし、C のみなら C が残って欲しい



これを、上の例の A-B-C のような1つの階層だけでなく、任意の数の階層でやりたい。 つまり、シーンの中で任意に選択している複数のオブジェクトのうち、同じ階層にいる場合は親だけが代表で残って、最終的に親だけの集団が欲しいのです。


ということをやるスクリプトをババっとやってみたらこうなったんですが、どうでしょうか。

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

//    選択中のブツを、oSelectedObjects に退避
var oSelectedObjects = XSIFactory.CreateObject( "XSI.Collection" );
oSelectedObjects.items = Selection;
OriginalCount = oSelectedObjects.count;

//    ガキどもを入れる箱
var oChildren = XSIFactory.CreateObject( "XSI.Collection" );

//    選択中のブツのガキどもを全部ひっかき集める
for ( var i=0; i<oSelectedObjects.count; i++ )
{
 
//    FildChildren = ガキどもをコレクションとして取得
    oChildren.AddItems( oSelectedObjects(i).FindChildren() );   
}


//    ##### ここまでで準備完了




//    今度は、FindChildren で引っかき集められたガキどもの方をループし、選択していたブツ(oSelectedObjects)全部と一致するかどうかを、総当りでチェック

for ( var i=0; i<oChildren.count; i++ )
{
    for ( var j=0; j<oSelectedObjects.count; j++ )
    {

 //    ↓ ガキが親と一致した = FindChildren によって取得できたガキは、実は最初に選ばれていたブツのひとつだった
        if ( oChildren(i).fullname == oSelectedObjects(j).fullname )
        {
            oSelectedObjects.Remove( oChildren(i) );   
//    ならば、 oSelectedObjects から追放
        }
    }
}
FinalCount = oSelectedObjects.count;

//    ##### 結果
Logmessage( "最初に選んでいたノード数 = " + OriginalCount );
Logmessage( "最終的に残ったノード数 = " + FinalCount );
for ( var i=0; i<FinalCount; i++ )
{
    Logmessage( "   残ったやつ -- " + oSelectedObjects(i) );
}

SelectObj( oSelectedObjects );

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



なんかこう、もっとスマートに、簡単にできないものでしょうか。
最も泥臭くやっている気がします。 総当りなので効率悪そうな。
まあ、これでちゃんと機能はしているように見えるのでいいのですが、
もっといい方法があれば、是非教えて欲しいのです。
お願いします。










こんなの書いている場合じゃないような。

こんなの書かないと手作業でやってられないような。

まったくもっていつも通りの状況です。



差し替えとかって、面倒ですね。
全てが理想通りに進めば、差し替えって発生しないんですよね。
最初から完成版モデルで、完成版マテリアルで、完成版のモーションを作り、そのままレンダする。
リニアですよ。
リニアワークフロー。
色の話じゃありませんこの場合。
一直線に、後戻りせず、順番に、進めるってことです。
昔は割とそうだったよね。

でも今どきそんな上手く行かない。
っていうか全然上手く行かず、ひどい状況になることの方が多い。
仮のモデルでモーション作業とか。
マテリアルは後で決まるとか。
このパーツだけ後でこうなるから、先にモーションはやっといて、あとで移植とか。


まあ、日常的ですよね。こっちの方が普通ですよね。
複数の作業を同時に進めている、とかいうキレイ事ではなく、
体制やスケジュールの状況が悪くてこうなることが実に多いというか、ほぼ100%。
もちろん自分の手が遅いためにそうなって行くのも、ほぼ100%。


XSI はそんなひどいCG業界の状況を念頭に置いたソフトウェアなので、非破壊だとか何だとか言って、後戻りしたりしやすいように出来ているように思えます。
つまり、ダミー作業、差し替え作業が多発するような、体制やスケジュールの状況が悪い仕事ほど、本領を発揮するソフトウェアなのかも知れません。

いいんだか悪いんだか。



で、差し替える段階になって、もうこういう風にシーンを整理しちゃったから、もう一度同じ整理するのは嫌だ、とか。

ここはモーション都合でアップデートしちゃったけど、マテリアルが最新になったモデルが来たら、そちらは当然モーション都合のアップデートはされてない。  さあ、どっちをどっちに移植する方が工数が少ない? とか。

Pass 分けもう一回やり直せっていうの? とか。



こうして、しかたなく、スクリプトを書き始めるという感じですね。 まさに。


より綺麗に表現するためにポリゴンが多くなり手作業でやってられないとか、ディテールアップしてリッチな絵にするために部品点数が多くなり手作業でやってられなくなってスクリプト書くとかなら、まあ前向きなんですがね。でもそんな場合は、少ないですよね。

ものごとが、予定通りに、スケジュール通りに進めば、きっと多くのスクリプトは不要になるだろうなあ。 スクリプトを書く頻度の高さは、状況の悪さに比例しています。







まあそんなことはどうでもいいや。

親だけ残す。

なんかいい方法ありますかね。





.

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

« 2012年2月 | トップページ | 2012年4月 »