画像で痛ポリ。

モデリングする時とか、板ポリにテクスチャ貼って下絵にしたりしますよね。
その時、画像のタテヨコ比を調べて、その比率のポリゴングリッド出したりするじゃないですか。　これ、めんどくさいですよね。　だから無駄な空白があるのを承知で 1 : 1 の比率になるようにあらかじめ画像を加工したりとか。

だから、最初から画像の比率で板ポリが出てくればいいかなあ、と思っただけなんですがね。


画像で痛ポリ。
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html




っていうか、UV を設定するときに、画像の比率の UV にしてくれればそれでもいいんですよね。　XSI って、オブジェクトの大きさの比率で UV が作られるじゃないですか。　これを変えるには UV を与えた後に手動でいじるしかないというのが、まあ不満ですよね。　たしか Max はこの機能がありましたよね。 XSI にも実に欲しい。





あー、そう言えば、実に久しぶりにモーダルPPGを使った気がする。　ウインドウの大きさとかが指定できないのでモーダルはだんだん使わないようになってたんだけど、やはり時にはモーダルの方が良いと思える時もあるわけでね。　モーダルはユーザから操作を奪ってしまうわけですが、それゆえにユーザが下手なことが出来ないというのが最大の利点だと思うんですよね。非モーダルだと、何か矛盾が生じる状態になってないかなど、いろいろエラー処理を書かなければいけなくなるので、これがめんどくさいんですよね。　モーダルの場合は起動時に１回くらい状態をフィルタリングしちゃえば、あとはユーザが変なものを選択し直してしまうとかそういう事態が起こらないから、以降ノーチェックで処理が実行できてラクなんですね。

あとは、ＯＫボタンを押すのに Enter キーを叩けば良いというのも、利点と言えば利点か。非モーダルだと、何かを実行させるためのボタンを付けたりするわけですが、このボタンを押すという操作はショートカットにできないですからね。たぶん。


でもいつも、モーダルか非モーダルかで一瞬ｳｯと悩んじまうんだよなあ。
臨機応変にやるしかないですね。



.

AddMaterial。

スクリプトを書いていてですね、オブジェクトにマテリアルを割り当てるために、AddMaterial メソッドを使ったんですね。


そしたらですね、異様に遅いんですよ。実行が。
マテリアル１つ与えるのに、２秒か３秒くらい待たされるんですね。

ほら。

コンスタントシェーダ１個くれてやるのに、1.828秒もかかっています。


１０回ループさせると、

やっぱり１８秒とかかかりますね。


遅い。これでは困る。


普通にインターフェース上から Get > Material > Constant を実行したときは、一瞬で終わります。またもやオブジェクトモデルにすると遅くなるパターンなのだろうか・・・と思ったんですが、ApplyShader コマンドを使っても同じく遅かったんですよ。UI から実行すると速くてスクリプトから実行すると遅くなる？　そんなのアリですか。



しかし、 Get > Material > Constant を実行したときのログを見て気が付いたんですが、

ApplyShader コマンドの引数で指定している Constant ですが、ディスク上の Preset ファイルを

　"$XSI_DSPRESETS\\Shaders\\Material\\Constant.Preset"　

という風にフルパスで記述してますね。

シェーダを与える時にディスク上の Preset ファイルにアクセスするらしいというのは前から知っていたのですが、今回の処理の遅さはこのアクセスに時間がかかっているのかも？　と思いました。


そこで、これを真似して記述してみると、

0.188秒　(ﾟ∀ﾟ)

１０回ループで 0.188秒ですからね。さっきのは同じ１０回ループで１８秒かかってますから、ちょうど１００倍速くなったことになります。ひゃくばいですよ。


結果的に速くなったのでまあいいんですが、何故なんだろうと腑に落ちないので、空調屋さんに聞いてみたんですよ。　そしたら、Workgroup が設定してあると遅いという事例があったとのことなんですね。　もちろん、うちの XSI 環境も Workgroup に依存してます。ないとプラグインの管理とかが大変ですからね。　

なので試しに Workgroup との接続を切ってみたら、わっ、速い。劇的に速くなりました。


どうやら、XSI はシェーダの Preset ファイルなどを読みに行くときに、先に Workgroup を探しに行くらしいんですね。　今回のように "Constant" と指定した場合、Constant.Preset ファイルを Workgroup フォルダ以下で探してしまう。　Workgroup はプラグインなど後から追加したものを入れる場所だから、当然ファクトリーシェーダである Constant.Preset ファイルは存在しないわけですよ。そして Workgroup フォルダは複数マシンで共有するという性質上、当然のようにネットワークの先のサーバに置いてあるわけで、なおさらアクセスが遅いのでしょう。　ひと通り Workgroup フォルダを探して見つからなかったら、ローカルにあるインストールフォルダ以下を探して、やっと Constant.Preset にたどり着いたけど何秒もかかっちゃったよ、ということなのでしょう。フルパスで指定すれば、ファイルの場所を明示しているということなので、すぐに Preset ファイルにたどり着けて遅延が発生しないということなのでしょう。たぶん。

ということは多分、Workgroup を設定していたとしても、その Workgroup フォルダがローカルディスク上にある場合は、ここまで処理が遅くなることはないんじゃないのかな。　ま、Workgroup がローカルにあったんじゃそもそも Workgroup の意味があまりないとは思うけど。


ということで、どうやら原因は Workgroup らしいということはわかったんだけど、Workgroup 無しに生きていけるはずもありません。なので、今後は基本的にフルパス表記で行くことにします。　幸いにも　$XSI_DSPRESETS などという表記が可能なので（環境変数？って言うのかな？）、XSI のバージョンなどインストール環境に左右されない書き方が可能です。



あと、AddMaterial メソッドでもうひとつ気づいたんですが・・・・。

マニュアルを見ると、

　　　SceneItem.AddMaterila( [Preset] , [BranchFlag], [Name] )

とあります。第３引数は　Represents the name of the new Material object　つまり、「マテリアルオブジェクトの名前」　とあります。RenderTree のノードで言うこところの、一番右側、シェーダではなくマテリアルそのもののことですね。



しかし RenderTree を見てみると、

マテリアルだけでなく、コンスタントシェーダ（左）の名前まで変更されています。


これはおかしいんじゃない？
と、空調屋さんに聞いてみたら、どうやらバグ、という話でした。

なんでもこの AddMaterial メソッドには、本来はマテリアルの名前を変えるはずなのに、シェーダの名前の方を変えてしまうというバグが昔あったんですって。　そのバグは前に直されたんだけど、どうやらマテリアルの名前にちゃんと反映させる部分だけを修正して、シェーダの名前を変えてしまうという部分は修正されずに放置されたように見える、との話でした。嘔吐デスクに確認を取ったわけではないので、空調屋さんの見解ですけどね。

ま、ほら、なんとも Softimage らしいバグの残し方じゃないですか。
これでいいんですこのソフトウェアは。

なので名前は AddMaterial メソッドで指定しない方がいいですね。上の例なら、

var oMat = Selection(0).AddMaterial("$XSI_DSPRESETS\\Shaders\\Material\\Constant.Preset",false);
oMat.name = "FuckMyMaterial";

こうやって２行で書いちゃえばちゃんとマテリアルオブジェクトの方だけ名前を変更できますね。ちょっとめんどくさいけど、これで行きましょう。



ｺﾞﾙｧ



.

撲殺アンコネクト。

まあ、またどうでもいいツールなんですけどね。


RenderTree の UserTools メニューの中に Delete Unconnected Nodes ってあるじゃないですか。

RenderTree の中で、接続されていない、浮遊ノードを削除する機能ですね。便利な機能なんだけど、その RenderTree のみにしか効かないじゃないですか。　だから複数オブジェクトにイッキに適用する機能が欲しかったという、それだけなんですがね。




撲殺アンコネクト。
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html



何も選ばずに実行すればシーン全体で浮遊ノードを撲殺。
何か選んでおけば、そいつだけを対象に撲殺。
そんだけです。




もともとは、先日書いた無限LensShaderの脅威に対抗すべく書いたんじゃなかったかな。　レンズシェーダが鬼のように溜まったカメラが複数あって、イッキに削除しようとしたんだった気がする。　それ以外にも、開発段階のシーンとかで、つないだり引っこ抜いたりしたノードの残骸がたっぷり残っている散らかりまくりの RenderTree を整理するときにも使ったりしています。


ICETree 用のも作りたいんだけど、RenderTree とは仕組みが違うようで、もうちょっと調べてみないとわかりません。



まだいっぱい野良スクリプトが転がっているんだが、まとめるのがめんどくせえなあ。




.

無限LensShader解消。しかし。

XSI 2011 SP1 が出ましたよね。
んで、バグ修正のリストを見ていたら・・・・

こんなことが書かれていたもんだから、つい実験。

どうやら昔ここに書いた、無限LensShaderの脅威から解放されるように見えますね！


自分の場合、2010 も 2010 SP1 もスルーだったんですよ。7.01 / 7.5 をずっと使っていて最近いきなり 2011 をいじり出してたんで、2010 でこの問題はどうだったかは知りません。 2010 はインストールすらしていません。


2011 SP1 の前に、まずは最初の 2011 でどういう挙動になるのか見てみました。

ということでカメラにレンズシェーダを与えようとしたんですが、あれ？　LensShader のタブがこんな風に変わっていたんですね？　Preset ファイルを選ぶのではなく、Add ボタンからドロップダウンメニューになっている。ほう、なかなか便利じゃないですかこれ。 2010 ですでにこうなっていたんですかね？


で、なんでもいいからレンズシェーダを与えればいいんですが、いつものクセでまずは Toon_Ink_Lens を探してしまいます。　すると、あれ？　ドロップダウンのリストに Toon_Ink_Lens がないよ？　うーむ、なぜでしょう？　

あれこれ探して、ようやく Insert > More に行けば昔どおりのファイルを選ぶやり方で Toon_Ink_Lens も適用することができましたが、なぜ他のレンズシェーダと同列にリストに入れないんでしょうか。Toon は軽視されているんでしょうか。どうなんですか嘔吐デスクさん。マイケルアリアスさんが怒りますよ。


ま、実験にはなんでもいいので、とりあえず mia_レンズヴォケを選んでおきましたがね。

この状態です。 SP1 じゃない方の初代 2011 です。

で、この状態でカメラをテキトーに操作し、Alt + Z でカメラアンドゥをしてみます。


すると・・・・、

あっ、7.01 / 7.5 と違って、レンズシェーダが増殖していません！
なんだ、SP1 が出る以前からもう直っていたんじゃないの？

・・・・でも、よく見ると、カメラPPG 内のレンズシェーダのリストに、さっきまで無かった Nothing という項目が増えている。なにこれ？

確かに、Add ボタンを押した瞬間に Nothing という項目が追加され、レンズシェーダを選ぶとこの Nothing が実際のレンズシェーダに置き換わるようですが、今は Add ボタンを押したわけではありません。カメラアンドゥをしただけです。


試しに、続けてカメラアンドゥをしてみます。
すると・・・・、

あっ


さらに続けてカメラアンドゥ。

(・∀・)ﾆﾔﾆﾔ

うーむ、どうやらカメラアンドゥでシェーダノードが無限増殖することはなくなったようですが、この Nothing という項目が無限増殖するようであります。　いやあ、なんて XSI らしい。

これ、実害はあるんですかね？　重くなったりするのかな。　前の無限 LensShader 状態の時は操作が重くなったので困りましたけどね。　今回は実害がないなら、まあ許せますけどね。


試しにですね、レンズシェーダが２個付いた状態でもやってみました。

こういう状態ね。


で、カメラアンドゥしてみると・・・・、

あっ


続けてもう１回カメラアンドゥ。

スヴァらしい

どうやら、シェーダが２個あったら Nothing も２個ずつ増えるみたいですよ！ ３個でやったら３個ずつ増えました。　ｹﾞﾗｹﾞﾗ
可愛いソフトウェアですねほんと。



で、ようやっと SP1 での実験です。

同じようにレンズシェーダを与えました。

で、カメラアンドゥしてみると・・・・、

だからなんで切れるのよ　カメラアンドゥだって言ってんだろ　誰が接続切れって言ったよｺﾞﾙｧ

はい、確かにレンズシェーダの無限増殖もないし、Nothing の無限増殖もなくなりました。
でもなんで接続切れるのよ？　意味わかりませんよ嘔吐デスクさん。

でもね、RenderTree をアップデートしてみると、実際は接続が切れていなかったです。つまり、どうやらカメラアンドゥした瞬間は切れたように表示するけれど、実は内部データ的には切れていないということのようですね。　結果的には切れてないのでいいと言えばいいのですが・・・・。

・・・・うーーむ、わかりにくい。　ほんとにもういい加減にしなさいよ嘔吐デスクさん。




んでね、さらに色々いじくっているうちに気づいたのですが・・・・

レンズシェーダのリストに、この Nothing というものが存在していない状態で、RenderTree でレンズシェーダを接続しようとすると・・・・

つながんねえよﾄﾞﾙｧ

レンズシェーダの out のポートから矢印を引っ張って Camera ノードに突っ込もうとしても、接続すべきポートが現れて来ないんですね。

どうやら、Nothing がリストにある状態になって初めて、レンズシェーダを接続できるポートが用意されるようです。Nothing さえあれば、矢印がちゃんと接続できますから。

ということは、カメラのPPG を開かずにいきなり RenderTree 開いて接続することは出来ないという・・・。　試しに SP1 じゃなくて初代2011 で試してみたら、同様に Nothing が無いと接続できませんでした。　ええ～　7.5 の頃は出来たじゃないこれ。　なんで出来なくなってんの？　嘔吐デスクさん？　　そもそも、「Nothing ＝ 無い」　というものが「有る」状態にしないと接続できないなんて、なんですかこれ？　わざと分かりにくくしておちょくってんですか？



さらにもうひとつ気づいたんですが・・・・。
RenderTree 上に、接続されていないノードが存在している場合ですね。

こういう状態ね。
XSI が七ちゃんになって以来、RenderTree 上で接続されていないノードが保持できるようになりましたよね。邪魔な場合もたまにあるけど、色々試している最中など、ノードを消したくないこともよくあるので、これはなかなか便利です。


んで、この状態でカメラアンドゥをしてみると・・・・・

あっ、　レンズシェーダが消えたっ

もう～　また表示上の問題でしょ？　さっきと同じパターンで、本当は消えてないのにカメラアンドゥをした瞬間だけこういう表示をしちゃうんでしょ？　アップデートすればちゃんとそこにあるんでしょ？


と思って RenderTree をアップデートしてみると、

本当に消えたのかよっ　マジかよっ　


これも、2011SP1 だけでなく、2011 でも同じでした。

俺の環境だけですかね？　他でも再現しますかね？
ここは XP32bit SP3 です。関係あるかわかんないけどビデオカードは Quadro です。



なんだかもう、俺、XSI のベータテストをやってる気分ですわ。
これが高い金払って購入したソフトウェアですか。
車に例えるとですね、間違えてワイパーのスイッチを入れてしまったのでアンドゥしたら（ワイパーのスイッチを切ったら）、ワイパーそのものが消えてなくなって、新たに手で装着しない限りもうワイパーは使えない、みたいな。
トヨタがこんな車作ったら、米国議会で証人喚問どころじゃ済まないですよ。
でも嘔吐デスクさんの場合は、こんなくだらないブログに１回書かれるだけで済むんですよね。
もう、呆れてものも言えない、なんて今さらですね。とっくの昔から慣れっこですけどね。




さぁー　　これからもどんどん重箱の隅つっつくぞー　　おー




.

AddCamera と SIGetPrimCamera の対決。

うーむ、カメラなんですがね。


カメラに関係するスクリプトを書いていて、カメラを取り出すのに、当然のように X3DObject.AddCamera メソッドを使ったわけなんですが。


なんかね、動作がもっさりしているんですよ。遅いの。数秒待たされるような感じ。


こういうもんなのかなあ、と思っていたんですがね。
でも考えてみれば、普通にインターフェース上から Get > Primitive > Camera ってやれば、カメラなんて一瞬で出てくるじゃないですか。おかしいなあと思ってね。　そこでインターフェース上から操作したときにログされる GetPrimCamera コマンドをペーストして実行させてみたら、一瞬で終わりやがるんですね。


一般的には、オブジェクトモデルで書いた方が実行速度が速い。はず。
でも今回の場合、コマンドモデルで書いた方が速いという結果になっている。
しかも、1000回ループさせてようやく体感できる程度の速度差が出たとかではなく、たった１個のカメラを取得するだけであからさまな差が出ている。


試しにに計測してみました。

AddCamera メソッド 2.453秒
SIGetPrimCamera コマンド 0.047秒

こんなに差があるっ (　Д)　ﾟ　ﾟ


カメラを取り出す以外のことも少し書かれていますが、速度への影響は完全に無視できる程度です。基本的に、両方ともカメラとインタレストをオブジェクトとして取得して名前を確定するという、処理の結果得られるものが同じになる条件にしているだけです。ちなみに上の画面は XSI 2011 ですが、XSI 7.01 で試しても結果は同じでした。


つうことで、理由はわからねど、カメラ取り出す時はコマンド使った方が速そうだということになりますた。今後そうしよう。


ちなみにオブジェクトモデルの AddCamera メソッドは戻り値がカメラそのものなので、

     var oCam = xxx.AddCamera("Camera","MyCamera")

などとやれば oCam にカメラがオブジェクトとして取得できますが、 SIGetPrimCamera コマンドは JScript で書く場合、そのまんまカメラを取得できません。JScript では Output Argument が使えないから？　なんですよね？　VBS では問題ないはず。　Output Argument　って日本語ではなんて言うんだろう？　出力引数？　　ま、ともかく、上の画面のように

    rtn = SIGetPrimCamera( "Camera", "CM_Cam", "CM_Int",ActiveSceneRoot );
    var oCam2 = rtn.Value("3DObjCamera" );
    var oInt2 = rtn.Value("3DObjCameraInterest" );

こんな風に書かないとカメラをオブジェクトとして取得できません。めんどくさい気もしますが、まあ、こういう風にやればよいと覚えてしまえばいいやと思っています。

これは ISIVTCollection　っていうんですね？　ISIVT ってなんやねん。　マニュアルには　「コマンドが Output Argument を持っているんだけど戻り値を明確に指定してない場合は、実は ISIVTCollection　という特別なコレクションを返しています」　という意味のことが書かれてますが、意味判りません。

判らなくてももなんとかなってるからまあいいけど、いつもこうしてスルーしているから根本的な部分での理解が進まず、下手な鉄砲を数撃ちながら当てるという、まさに場当たり的なスクリプターになっていくのであります。Orz





.

さよならロール。

テキトーなスクリプト達が眠る墓場 Graveyard に、さよならロールを埋葬しますた。
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html

カメラのロールを取っ払うスクリプトです。
Ｌキーとかでカメラをロールさせて、その後ゼロに戻したい時に、いちいち Explorer から Kinematics > Constraints > Direction Cns に潜っていくのがめんどくさかったという、そんだけです。
Interest 付きのカメラを１つだけ選んで実行です。
Interest が無いカメラは効きません。複数カメラも効きません（最初の１個だけ）。

１行スクリプトだし、わざわざ埋葬する意味は薄いんですが、供養のためです。



そのまんまコードを載せると、

　　　if(Selection.count!=0&&Selection(0).type=="camera"&&Selection(0).interest!=null){Selection(0).Kinematics.Constraints.Find('dircns').roll.value=0;}

これなんですけどね。

あと６文字、誰か削ってくれませんか。
そうすると、つぶやき対応のスクリプトになります。
意味ありませんが。

エラー回避を取っ払えば楽勝で短くなりますが、まあそこはね。こういうくだらないものだからこそ、意味のない潔癖さがあった方が良いわけでね。

VBScript や Python ならもっと短くなるのかな？


追記：
名も無き天才スクリプターの超絶コーディングにより、短縮できますた。
コメント欄参照であります。





.

キャプちゃん!! ３。

キャプちゃん!!が久しぶりにアップデートされますた。



キャプちゃん!! ver3.0
http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html

ずいぶん昔に書いたプラグインなんですがね。　XSI 標準の Start Capture が色々気に入らなくてね。


元をたどれば、24fps のシーンで２コマ打ち（step2）とかのキャプチャをしたい時に、自動で起動される Flipbook の再生が２コマ打ちになってなくて、手動で step2 とか 12fps とかに設定し直していたのがめんどくさくて書いたんじゃなかったっけな。　そのうちキャプチャする時に要らないもの表示オフにする機能とか付けて、いつの間にやらこれがないと生きていけない体になって、でもすんげぇ昔に書いたものなので自分のワークフローも変わったために色々不満も出てきて、去年の末くらいにゼロから書き直し始めたんですよね。大まかにはとっくに完成していたんですが、仕事で使いながら少しずつ改良してました。


今回のバージョンアップの機能的な目玉としては、再生に Flipbook 以外のアプリケーションが使えるようになったことと、ムービーフォーマットも含めて対応ファイルフォーマットが増えたことでしょうかね。


ビューポートキャプチャする時はほとんど Softimage PIC や TARGA などの連番を使ってるんですが、XSI の中で mixer に音を置いて何らかの音合わせでアニメーションを作っている時なんかは音も一緒に出力したいじゃないですか。　でも以前のキャプちゃん!! では Softimage PIC しか使えなかったので当然音声を入れることはできず、そういう時は仕方なく標準の Start Capture を使っていたんですよね。　標準の Start Capture がほんとに嫌いなので、これをどうにかしたかった。

それとは別に、Flipbook 以外で再生する機能も前のキャプちゃん!!には無かったので、これもどうにかしたかった。Flipbook は実はすんげえ高機能な連番再生プログラムだと思っているんですが、フルスクリーン表示や無段階ズームができないことや、起動がちと遅いことなどが不満でしたかね。また、音声を再生する機能が付いてないみたいで、音付きの QuickTime なんかを食わせても無音で再生されやがります。　なのでQuickTime Player や VLC Player みたいなので再生したいこともよくあったんですよね。


最近は連番の再生に DJV Imaging をよく使ってます。これ、すんげぇスヴァらしいです。音は再生できないですが、Flipbook でできることはほぼ網羅しつつ、それ以上のこともできます。Windows の Explorer から連番の１枚をドロップするだけで再生を開始してくれるのがスヴァらしい。起動が軽いのもスヴァらしい。これがタダですよ奥さん。　キャプちゃん!! からこいつを起動するようにしておくのもアリです。

でもまあ俺の場合、キャプちゃん!!から起動するのは普段はやっぱり Flipbook ですかね。　IN / OUT の設定が簡単にできること、再生速度（fps）の変更が再生しながらその場ですぐできること、アルファチャネルが簡単に見れること、メモリにプリロードしてコマ落ち無しで再生できること、この辺がクリアされてれば、まあ基本的には何でもいいです。 Flipbook と DJV Imaging はクリアしてます。


PDPlayer は高いので持ってないのですが、k_isobeと愉快な仲間たち様がご親切にもテストして下さって、キャプちゃん!! から問題なく再生できているとのことです。　テスト有難う御座いました。


あーそうだ、QuickTime や AVI など、キャプちゃん!!からムービーフォーマットで書き出すにはちょっとめんどくさい準備が必要です。ムービーフォーマットには コーデックの指定が必須になってくるわけですが、スクリプティング的にこのコーデックの設定を保存しようとすると、ViewportCapture オブジェクトの PPG を Preset としてセーブしておくしか方法がないんですね。　これを手動でやってもいいんだけど、一応キャプちゃん!! のPPGからの操作でもできるようにしておきました。でもやっぱりこの方法は分かりづらいので、いつか廃止になるかも知れません。



しかし XSI のビューポートキャプチャ周りって、ずいぶん前からアップデートされてないですねえ。静止画ばっかり作っている人とかならともかく、アニメーションを作る人には必須の機能なわけで、もうちょっと色々便利になって欲しいなーと思うわけですが。　モニタの解像度以上のキャプチャはできないのか？　キャプチャ中に他のアプリに切り替えてウインドウが重なっちゃうとそっちをキャプチャしたり。　まあこの辺は、「表示させた絵のスクリーンダンプを取る」という仕組みっぽいから、この仕組みである以上は無理ですかね。　Maya とか Max はどうなんだろう。

まあ、操作まわりの不便さは俺様のために書いたこのプラグインでとりあえずどうにかなっていますけどね。　でもこのまま XSI が死ぬまで放置される機能になりそうな悪寒がしますね。





.