メンタル霊のパラメータの名前。

よく Pass Override をやるんですがね。
例えばこの Pass だけリフレクションの反射回数を５０回に上げたい、とか。


昔はその Pass に Mental Ray Option のローカルコピーを作るしかなかったのに、今は Pass Override ができて便利ですね。



でもね。
オーバーライドを作るとき、
オーバーライドしたいパラメータの名前がわかんないんですよこのﾊｹﾞ。



例えば上に書いたリフレクションの回数などは、まだわかります。 TraceDepthReflection です。　オーバーライドするときドロップダウンする Explorer から探せます。


でもさっき、ある Pass で Primay Rays の Type を Scanline から Rasterizer に変えたかったんだけど、オーバーライドを作成する時に Primary Rays という名前のパラメータが見つからなくて苦労しました。


で、あれこれやってみたところ、Mental Ray の PPG上で Primary Ray の Type と表示されているパラメータは、実は Scanline という名前のパラメータでした。



ﾊｧ?



インターフェース上は Primary Rays という名前で、そのパラメータの「値」はデフォルトでは Scanline と表示されており、ドロップダウンリストから選べる他の「値」としては Rasterizer と Raytracing があるわけですが、「値」ではなく内部的なパラメータ名（スクリプトネーム）が Scaneline って、どういうこと？　　"Scanline" という名前を持つパラメータの値が "Scanline" だということですよ。　なんだそれは。

と思ってスクリプトエディタで履歴を見てみると、ドロップダウンから Scanline を選んだ時は、 Scanline というパラメータの値として 1 がセットされている。 Rasterizer を選ぶと 2  になっている。

つまり、「値」として Scaneline とか Rasterizer を選んでいるように見えて、実はそれはインターフェース上の見かけだけのことであり、実際には 1 とか 2 とかが「値」としてセットされてるということですね。　うーむ。

まあ、それは仕方ないかもしれない。俺も自分で書くツールでそうなってしまうこともある。　でもね、パラメータ名が Scanline ってなんなのよ。　UI 上は Primary Ray の Type って表示されてんだからさ。　おかしいでしょうそれ。　オーバーライドする時探せないじゃないですか。　いくらなんでもひどいでしょうこれは。　わざとやってんの嘔吐デスク様。　っていうかこれはアビッド様かなあ。　



これと同じようにね、オーバーライドしたい時って、いつも 「それ、なんていう名前のパラメータなんだろう？」　という所で困るのですよ。　だって UI 上と全然違う名前のものが多いんだもん。

あの変な Explorer からオーバーライドしたいパラメータを探して選ぶというインターフェースがまずいかんのですよね。そうではなく、例えばあらかじめオーバーライドしたいパラメータを PPG 上でマークしておき、Overdide の PPG の中に　「マーク中のパラメータに対してオーバーライドする」　とかいうボタンを作ればいいんじゃないでしょうかね。　自前でやろうかなあ。




非常にわかりにくいです。昔から。
嘔吐デスク様。
長年苦労してます。
悪意さえ感じます。
普通はスクリプトエディタなんて見ないんだから。
いいかげんどうにかして下さい。
いいですか。
頼みましたよ。
このﾊｹﾞ｡





.
.

お名前でイッキに選択。

シーンの中に複数の Model があり、同じ名前のオブジェクトがそれぞれの Model の中に存在している時とか、あるいはModel が複数かどうかに関係なく名前の一部が同じオブジェクトが多数存在している時とかに、そいつらをイッキに選択するスクリプトです。



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

//    結果を入れる器ﾖｰｲ
var oObjects = XSIFactory.CreateObject( "XSI.Collection" );
oObjects.Unique = true;

//    現在選択中のブツをループ
for ( var i=0; i<Selection.count; i++ )
{
    //    選択中のブツの Name を取得（ Fullnameではないことが重要 ）
    var SearchName = Selection(i).Name;
   
    //    シーンルート以下で、Model名に関係なく、その名前を含むオブジェクトを見つけて oObjects に格納
    oObjects.AddItems( ActiveSceneRoot.FindChildren( "*.*" + SearchName + "*" ) );
}

//    選択しておしまい
SelectObj( oObjects );

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

最初に選んだオブジェクトの名前を含む全ての 3D オブジェクトが選択されます。 3Dオブジェクトだけです。 Group とか Property とかそういうものは選択されません。

例えば、どの Model 以下にいるかは関係なく "Left_Arm" という名前のオブジェクトを選んで実行すると、シーンの中にある

　Model1.LeftArm
　Model2.LeftArm_L
　Model2.LeftArm_R
　Model3.AAA_LeftArm_1

などが選択されます。　この子たちは最初に選んでたブツの名前　"Left_Arm" を自身の名前に含むからです。　ちなみに LeftArm_R ってなんですか。　ひどい名前ですね。　右か左かはっきりしなさい。

インターフェース右上のボックスに　 *.*お名前* 　と入力するのと全く同じことです。それが面倒だから、こうしただけです。　だってあそこって入力しにくいじゃないですか。　長い名前のオブジェクトだとタイプしてらんないし、コピペするのもめんどくさい。


このシーンにいる全キャラの目玉オブジェクト（名前は共通で Eye_Left とか）を選択してあのパーティションにブチ込みたい、とかなんとか、そういう風に使ってます。


そんだけ。
右クリックに入れるともっと便利かも知れない。





.

パーティションの掟。

うーむ。

Background_***_Partition は、特別なんですよ。


新規のオブジェクトとかが自動的に入る場所ですからね。　レンダの事故が起こらないためにも、Background Partition のレンダビジビリティは基本的に Hide にしておきべきだと思いますし、そもそも Background Partition の名前を完全に変えてしまって、どれが Background Partition なのか分からなくなっている状態なんて、言語道断です。

そういういけないデータを扱うときは、もう、スクリプト書いていけない子を発見するしかありません。



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

var oBackgroundPartitions = XSIFactory.CreateObject( "XSI.Collection" );//    全てのBGパーティションを格納する容器
var oPasses = ActiveProject.ActiveScene.Passes;//    全てのPass
for ( var i=0; i<oPasses.count; i++ )
{
    var oPartitions = oPasses(i).Partitions;    //    その Pass の全ての Partition
    for ( var j=0; j<oPartitions.count; j++ )
    {
        if ( oPartitions(j).Background ) oBackgroundPartitions.Add( oPartitions(j) );//    BGPartition なら格納
    }
}

//    ここまでで、まずは全Passの BGPartition が引っかき集められた

var oFuckinBackgroundPartitionsRenamedInVeeeeryBadWay = XSIFactory.CreateObject( "XSI.Collection" );//いけない名前のBGPartitionを格納する容器
for ( var i=0; i<oBackgroundPartitions.count; i++ )
{
    var oPart = oBackgroundPartitions(i);
    if ( oPart.PartitionType == siObjectPartition ) TheName = "Background_Objects_Partition";//あるべき名前（オブジェクト）
    else TheName = "Background_Lights_Partition";//    あるべき名前（ライト）

    if ( !oPart.Name.match( TheName ) ) oFuckinBackgroundPartitionsRenamedInVeeeeryBadWay.Add( oPart );//いけない名前のやつを格納
}

//結果報告　＆　いけないやつセレクト
Logmessage( "全てのバックグラウンドパーティション　: " + oBackgroundPartitions.count );
Logmessage( "Background_***_Partition を含まない名前にリネームされてしまっているバックグラウンドパーティション : " +  oFuckinBackgroundPartitionsRenamedInVeeeeryBadWay.count );
SelectObj( oFuckinBackgroundPartitionsRenamedInVeeeeryBadWay );

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

このスクリプトの場合は、Background_Objects_Partition （ライトの場合は Background_Lights_Partition）を含まない名前になってたら、悪い子だということにしてあります。　法則を変えたいなら TheName のところを変えれば良い。

幸い、スクリプトを書けば Background パーティションかどうかは見分けられるのですね。　Partition オブジェクトの Background プロパティです。 名前がどのように変えられていようとも、このプロパティで true が帰ってくるパーティションは、Background パーティションです。 手で削除してみて削除できないパーティションならそれは Background パーティションなんですが、見分けるために削除してみるとか馬鹿らしいですよね。　まあ、こんなスクリプトを書かなければいけないシーンデータを扱うのが一番馬鹿らしいのですが。とかなんとか。

結果的にスクリプトによって判別はできましたが、スクリプトでトラッキングできればそれで良いわけではありません。ちゃんと掟を守らなければなりません。



俺的掟：

●バックグラウンドパーティション判別可能にせよ

Background_***_Partition をリネームする場合は、せいぜいアンダーバーを付けるとか程度にしておいて、ひと目でそれが Background パーティションであるということが分かるようにせよ。



●バックグラウンドパーティションはハイドせよ

Background_***_Partition は、レンダしないパーティションにせよ。　つまりレンダビジビリティは Hide にせよ。　ビュービジビリティはまあ、レンダ的にはどうでもいいや。



●男らしくせよ

レンダすべきパーティションのレンダビジビリティは全て Show にせよ。　レンダしないパーティション（Background含む）は Hide にせよ。　つまりレンダ可否はオブジェクトレベルや Group や Layer に頼らず、一番強い存在である Partition でオンかオフにすることによって一元管理せよ。　No Effect 禁止。　男らしく白黒はっきりせよ。 女も男らしくせよ。

これがレンダ事故を避けるためには必須です。 異論を待つ。

.

V-Ray でピタゴラ装置。

XSI Maling list に載ってました。

https://groups.google.com/forum/?hl=ja&fromgroups=#!topic/xsi_list/pz8eUMl_JLo

XSI と V-Ray と Momentum だそうですよ。

ICAD AWARDS - Opening Sequence from Piranha Bar on Vimeo.

おおう、XSI V-Ray で、ちゃんと動いているものって、あんまり見たことがなかった気がする。

このレンダリングは全体的に若干ノイジーな気もするんですが、どうでしょうかね？　設定次第でもっと行けるのかな。　レンダリング時間はどうなんだろうな。　最後の風船人間は、頭部の風船の質感が良いですよね。胴体のファブリックな質感も良い。DOFも悪くないのではないかと思いました。　でもまあ、いまどきの水準で言うと、フォトリアルという意味ではびっくりするほど良くできたレンダというわけではなさそうな気がしました。普通にＣＧに見えるもんね。　とかなんとかまたビッグマウス。この辺のフォトリアルレンダに対する俺の目は節穴なのでシカトして下さいとかなんとか。

あと、レンダリングとは関係ないけど、やたら手の込んだピタゴラ装置を作った割には、ギミックがさっぱりわからないのが残念ですね。カット割や寄り引きなど、そもそもの構成の問題のように見えます。　とかなんとかまたもやビッグマウスすいません。


作ったのはピラニアバー？　っていうのかな。アイルランドの会社のようです。


みなさんは V-Ray 使ってますか？　どうですか？　日本で XSI V-Ray なことしてる人、色々情報教えてくださいよ。

淫婦裏嫉妬。

これもたった今気づいたんですがね。

インプリシットオブジェクトって、パーティションに参加できるんですか？

できてますよ？

インプリシットって、レンダできないオブジェクトじゃないですか。ヌルとかカーブとかレンダできない種類のオブジェクトは普通パーティションに入れないですよね。　でもどうやらインプリシットだけは入ることができる。　なんで？　昔からこうでしたっけ？　　他と違ってインプリシットだけ、レンダできない種類のオブジェクトであるにも関わらず、パーティションに入ることができる理由は、何でしょうかね？　それとも最近の XSI は、インプリシットをレンダする機能が付いたのでしょうか？

いやまあ、GUI 上で色んな操作をしている上では問題にならないんですけどね。　問題になるのはスクリプト書いている時でね。　こういうこと知らないと、ツールを開発するときにここがトラップになってつまづいたりするわけですよ。　処理対象外にしていたはずのものが対象になっていたりその逆だったり、まさかインプリシットがパーティションに入れるとは思ってなかったものでそこらへんはノーマークで、関係のない部分をいじくってスクリプトを壊してしまい動いていたものも動かなくなってモニタを青山通りに連続遠投するとか、よくやります。

スクリプトで、パーティションに入ることのできるオブジェクト（レンダ可能なオブジェクト）かどうかを一発で判別できる機能が欲しいと思いませんか。　昔から思っているんですけど。　パーティションに入れる種類のオブジェクトって、ポリゴンメッシュ、サーフェスメッシュ、ポイントクラウド、インスタンス、あとなんでしょうかね？　　その辺を一括で判別できるよう、siRenderableGeometryID とか X3DObject.IsRenderable とか、そういうの付けて欲しいんだよなあ。　スクリプト書きがすげえ楽になるはずです。嘔吐デスクさま。



っていうか、パーティションに参加可能・不可能（レンダ可能・不可能）を判別するもっといい方法、何かありますかね？

俺はいつも、愚直に Type とか調べて　「もしこいつがポリゴンかサーフェスかポイントクラウドかインスタンスだったら云々」　とか書いてます。　こういう書き方だと、見落としている Type があるといけないなあ、といつも思ってます。

.

.

カスタムプロパティのお名前。

今まであんまり意識したことなかったんですが、カスタムプロパティのネームスペースについてなんですがね。

　１．　カスタムプロパティは、別のオブジェクト以下なら、同一 Model 内でも、同じ名前のまま存在できる

　２．　カスタムプロパティは、別の Group 以下の場合、同一 Model 内だと、同じ名前で存在できない

１はいいとして、２に気づくのに手間取りまして、あるツール開発でこれのためにまる２日くらいトラブっていた気がします。　今わかりました。　くそ。　なんでそうなんだよ。カスタムプロパティがぶら下がっている場所は 違う Group なんだからさ、同じ名前で存在させてくれよ XSIさま。

同一 Model 以下で同一の名前のオブジェクト（３Ｄオブジェクト）は許されてませんよね。なので、複数の同じ名前のカスタムプロパティをいろんなオブジェクトにぶら下げてもカスタムプロパティ名のフルパスは同一にならず、だからこそカスタムプロパティは同じ名前のままでいられるのではないかとなんとなく思ってました。

Group も同じく同一 Model 以下で同じ名前が許されてません。なら同じ法則で、Group にぶら下げたカスタムプロパティも同じ名前で複数存在させられる気がしちゃうじゃないですか。ねえ。　俺なんか変なこと言ってますか。そうですか。すいません。

画像：

null も cube も arc も同一 Model 以下だが、カスタムプロパティ Hoge を同一の名前で保持している（赤）

Scene_Root 以下の Group1, Group2, Group3 が持つカスタムプロパティの名前は Hoge, Hoge1, Hoge2 となってしまい、同じ名前で存在できない（青）

Model である Fucker 以下の HageGroup1, HageGroup2 が持つカスタムプロパティの名前は Hoge, Hoge1 となってしまい、同じ名前で存在できない（黄）

損失。

なんだかニュースに乗り遅れている俺ですが、

http://xsisupport.com/2012/08/31/friday-flashback-85/

我らの Stephen Blair さん、リストラの対象になってしまったようで。

Guillaume Laｆorge さんもそうなんですね。彼の場合は Fabric Engine に行くことが既に決まっている、のかな。


大事な２人をクビにしてしまって、大丈夫ですか嘔吐デスクさま。
そこいらへんの仕事できない若僧とかじゃないんですよこのお二方は。
日本の嘔吐デスクでも同じようなことするつもりじゃないでしょうね。
やめてくださいよほんとに。
XSI はどうなってしまうのでしょうか。
まあ、XSI なんてただのプラグインですから、大した問題じゃないでしょうけどね。



彼らが去ることは、俺たちにとっては大きな損失ですが、嘔吐デスク様にとってはそうでもないのでしょうね。　いや、イヤミではなく真面目な話、嘔吐デスク様は大きい会社ですから、我々庶民が普段持っている感覚とは大いに違う視点での経営的判断とかなんとかがたくさんあるとは思います。　Softimage が嘔吐デスク様に売られた時も、俺も心情的には嫌だったけど、理解はできるし、そうでもしなきゃダメだったんだろうなと思います。　逆にネット上で 「Avid や嘔吐デスクはユーザのことを何も考えていない！　明らかに間違った経営判断だ！」　などと豪語している多くの毛唐を見て　「あ、ちなみにそのショボいＣＧ、あなたの作品ですね。あんた、そんなに正しい経営判断ができる人なんだったら、そんな９０年代後半みたいなＣＧ作ってるより、会社の経営者になったほうが儲かりますよ」　ってずっと思ってましたすいません。　今もまた、si-community でそんな話がファイアしているように見えました。　なぜあんな小さなコミュニティの、しかも一部のアクティブなユーザのみが、嘔吐デスク様にとってのマジョリティだと思えるのか。　どうして一介のＣＧ屋風情が巨大会社の経営判断を即座に間違いだと断言できるのか。　まあいいや。


とか言いつつも、あんだけ SI-Support ブログを書いてくれていた人だし、それ以外の場所でもユーザと直接対話してくれる貴重なお二方でしたからね。　我々ユーザにとってとてつもなく大きい損失であることは変わりがありません。　あのブログはどうなるんだ。なくなるのか。 AREA に同じ機能は期待できそうもないし、困ったなあ。　どうしてくれるんだ嘔吐デスクさま。




お二方、超お疲れ様でした。
今後のご活躍をマジで祈ります from bottom of my heart.
それしても、まさか、まさかリストラされるとは思っていなかったでしょう。
俺すんげえ分かりますよ Stephen さん Guillaume さん(；Д；)