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

2008年3月

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)

2008年3月28日 (金)

ぬるぬるバージョンアップ。

                  
選択中のオブジェクトに null をぬるぬるするプラグイン、ぬるぬるが ver2.0 にバージョンアップ。
      

      
      ぬるぬる
      http://homepage3.nifty.com/jjj/XSIFiles/Plugin/JJJ_XSI_Plugins.html
      
      

V2_menu

      

V2_nullnulloprions


      
新機能
      
・ぬるぬるトライブ = 新規 null を取り出し、選択中のオブジェクトの子供にする
・カスタム初期設定で、null のアイコンや命名規則その他を決められる
      
      


今回の仕事でトライブを使いまくった、というかそのためにトライブを書いた。超単純な機能だけど・・・・。
カットの途中からコンストレインで他のものに拘束したいときの新規コンストレイン先にしたり、リグを作っていくうちに他のオブジェクトからのコンストレイ ン先にしたかったりとか、そういう感じ。
      
      
null のアイコンや大きさも常にいじっていてデフォルトのままということがほとんどなかったので、そのときの作業でもっとも都合の良い状態に近い値を保持してい たくなり、カスタム初期設定化した。
      
      
      

しかしまあ、機能とは関係ないけど、ほんとは1~2本のスクリプトにまとめたかったんですよね。でも、1コマンドの中で機能ごとに function に分けて書くと、アンドゥしたときに、1アンドゥにつきスクリプトの1行1行を戻っていく感じで、とても不便になっちゃってね。 でも別コマンドに分かれ ていると1回のアンドゥで実行前の状態に戻ってくれるので、あきらかにこっちの方が便利なので、しかたなく機能ごとにコマンドを分けたという感じ。1つの ファイルの中で複数コマンドを定義することはできるのかしら。それは試してない。
      
いずれにせよこれは SDK の不具合ですよ。いちおうサポートに報告はしてあるけど、ちょっとまだ自分でも挙動がつかめていない所もあるので、引き続き研究課題にします。ああ、まだ やることいっぱいあるなあ。もうちょっと素直に動けよ XSI の SDK。 ゴルァ。
      
      
それと、メニューがごちゃごちゃになりすぎたのでサブメニューにまとめたんだけど、自分で作ったサブメニューって標準のサブメニューと違ってティアオフ (切り離してフローティング化)ができないのですね。不便だよこれも。ゴルァ。
      
      
      

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

2008年3月26日 (水)

RA_MeasureTools 測量ツール。

                  
XSI Base で測量ツールが公開されていました。
      
RA_MeasureTools
http://www.xsibase.com/forum/index.php?board=14;action=display;threadid=35462

      
      
インストール:
.py フォルダをユーザもしくはワークグループのプラグインフォルダにコピー。
Python スクリプトなので Pythonをインストールしている必要あり。
      
使い方:
Get > Property > RA_MeasureTools > どれか で起動。
右クリックで終了するまで続く。
結果はスクリプトエディタの中にログされる。
最後の結果はクリップボードにコピーされている。
      
・角度の測量 → 3点クリック
・バウンダリボックスの大きさ(ブツのサイズ)測量 → オブジェクトをピック
・カーブの長さを測量 → カーブオブジェクトをピック
・距離の測量 → 2点クリック
・合計距離の測量 → 2点以上クリック
・オブジェクト間(センター間)の距離を測量 → 2オブジェクトピック
      
      
      
今まで似たようなプラグイン/スクリプトは色々あったような気がするけど、これが一番便利なのではなかろうか。 結果をクリップボードにコピーしておいて くれるのがスヴァらしい。前からこれをやりたかったんだよな。ソースをちらっと見てみたら、Python では簡単にこれができるみたい。
      
オブジェクト間の距離測量に関しては今まで自作スクリプトでやってきたが、別に便利でもなんでもなかったので、もう捨てよう。 これからは当分、これを使 おう。
      
作者は、おフランスのプロヴァンスに在住の Remy 様です。 少し要望を出したらすぐに対応してくれたのもありがたい。最初は JScript で書かれていたんだけど、上記のクリップボード機能を追加するためにわざわざ Python で書き直したようです。  Remy様、ワインばっかり呑んでないで日本のビールも呑んでください。中央線に乗って東京のはじっこまでお越し頂ければ、お ごります。
      
      
      
      

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

2008年3月24日 (月)

imf_disp。

                  
世の中に画像ビューアソフトはいっぱいあるが、なかなか決定版がないと いう感じ。
しかたなく、そのときの状況や気分に応じて複数を使い分けているわけですが。
      
Vix
XnView
      
連番をずらずらっと見るときは Vix か XnView を使っている。
Vix は起動や動作全体が軽いのが良い。しかしホイールでズームできないのがちょっと不便に感じることもあるし、アルファチャネルの表示ができないのが痛い。
XnView はまさにそこを補ってくれるのだけど、起動でちょっともたつくことが多い。リスト表示された連番をカーソルキーでととととと・・・と次々に選んで行ったと きの画像表示速度も、Vix の方が軽快で、XnView はもたつく。 それと XnView は豪華すぎてうるさく感じる。必要最小限の機能だけのライト版でもあればいいのだが。それと、XnView の全画面表示は手軽で良いんだが、全画面表示状態でカーソルキーの左右とかを押しても、となりのフレームに行ってくれない。いちいち右クリックのメニュー を出すのはやってられない。スペースバーを押すと次のフレームに進むので順方向はまあこれでいいんだけど、逆方向に戻れねえぞゴルァ。
      
      
ということでCG屋向けの良いビューアソフトないですか。教えてください。あるいは作ってください。
スヴァらしいやつ作ってくれたら、生ビール2杯(約1000ml)おごります。 ビールウェアとして公開して下さい。
      
・起動が超軽快
・連番を次々に選択しても超軽快
・ズームイン/アウト も超軽快
・対応フォーマット: Softimage PIC/Targa/SGI/OpenEXR/Jpeg/Windows BMP  とりあえずこんだけでいい。
・ショートカット一発でアルファチャネル表示
・ショートカット一発で全画面表示切替え
・最低限の情報表示(解像度・色深度など)
・ファイルの表示・操作はウインドウズのエクスプローラと完全に同一の扱い
・余計なものいっさいつけない
      
以上が ver1.0 の要求仕様書となります。
      
      
で、連番を見るためには使えないけど、1枚の画像をパッと見たいときに最もよく使っているのが、XSI に付いて来るスタンドアロンの imf_disp.exe なのです。
      
・起動が超軽快
・Ctrl + A でアルファチャネル一発表示
・レンダリング中の画像も見れる
      
この3点において、他のどのビューワより勝っております、たぶん。  特にレンダリング中の画像を見れるのが重要で、GUI からのレンダリングはインターフェース上に画像が表示されるけどコマンドラインからではそれがないわけで、imf_disp を使う以外に方法はないわけです、たぶん。 あと、Always On Top オプションで常に他のアプリケーションよりも上に表示することができるので、時としてこれがとても便利なこともあります。
(GUI からのレンダリングも、画像の表示の有無を選べればいいのにな。 しかも AfterEffects のようにレンダリング中でもアプリケーションを最小化できればいいのにな。不親切だな XSI は。メンタルレイのせいのなのかな。だいたいそもそも・・・・ d●&@%#$  罵倒モードに入りそうなので以下自粛)。
      
      
imf_disp は XSI のインストールフォルダの、Application/bin の中に、様々なスタンドアロンと共に埋もれています。是非発掘して日の目を見させてあげましょう。

Imf_disp1_2


      
で、いつでもドラッグ&ドロップできるように imf_disp のショートカットをデスクトップに作っておくのはもちろんのこと、Softimage PIC に関してはもうファイルの関連付けを変えてしまい、ダブルクリックで img_disp で開くようにしてあります。アイコンは XSI.exe ファイルからテキトーに見やすいやつを貼っつけただけ。

Imf_disp2



ちなみに Flipbook も動画再生ソフトウェアという意味では最強だと思っていますが、起動が遅くてダメっすね。あと、連番フォルダをドラッグ&ドロップすると再生してくれれば いいんだけど、そんな便利なことはできません。連番の1枚だけドロップしてそのパスにたどり着く手間だけを省略し、後は Ctrl + O で開き直してやらねばなりません。 ちなみにこれを便利にするためには、金アルディスおじさんの Flipper を使いましょう。
      
Flipbook がこの辺を整備してくれたら、もはや imf_disp も要らないかもしれない。Ctrl + A どころか A だけでアルファも見れるし。でもズームの段階が大雑把すぎるな。無段階もしくはもう少し細かい段階のズームにしてくれれば、もう完璧なんだが。
      
      
      

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

2008年3月20日 (木)

未来はない。

                  
最近レンダリングが速くて、まったく休めない。
      
約50カット、モーションが完成・確定し、あとはひたすらレンダリングという状況。出てくるキャラクタが固定ならいいのだが、カットによって結構違う。ま た、カットごとに特定のマスクを出さなくてはならないことが多い。つまりシーンレベルであらかじめ完成形に近い Pass 分けをしておくことが難しく、結局どれかのキャラクタのPass分け済みシーンをベースにそれ以外は Model でインポートして、Pass 分け作業はその都度やるという、まったくもっていつものことながら、まったくもって非効率なワークフローになる。
      
K1 しかも今回は準備が非常にまずく、レンダリングに関する検証が不十分なまま見切りでモーション作成作業に入ってしまっているため、レンダリングする段階で やれこのマテリアルはまずいだのやれUVを差し替えなきゃいけないだのやれライトを Assosiate しておくの忘れただのやれXSI様が瞑想に入ってしまわれただの、いっぱい問題が出てきてしまった。結果、各シーンでレンダリングの仕込みをするのに、意 外と時間がかかるのである。
      
      
      
キャラクタのリグが固定なら話は比較的簡単で、Passやらマテリアルやらライトやら、レンダリング用に正しく設定されたシーンを1つだけ用意しておき、 モーション済みのシーンからモーションだけを移植してきて、ライティングをいじったらあとはせいぜい解像度やフレーム数やファイル名などの設定をしてレン ダリングを回すだけで良い。
      
K2 しかし今回はここでも準備が悪く、途中何回かセットアップを更新せざるを得ない事態になってしまい、もはやモーションを移植できなくなってしまった。ま た、これは最初からわかっていたのだが、カットごとに必要となる特定のモーションを付けやすくするために、ベースとなるセットアップは同じままでもリグの 一番表層にあるコントローラ達を大幅に組み替えながらモーション作成してしまったので(いつものことだが)、やはりアニメーションの移植は難しくなってし まっていた。
リグのどこかの階層で Plot かますことも考えたが、めんどくさいのも大いにあるし、危険も感じたのでやめた。すでに手描き用素材作成用にアタリとなるモーション=つまり動きとしては 完成されたもの、を出してしまっていたので、手でマスクを切る(組み)ことになっている部分では少しでも違うモーションになってしまっては困るのである。 時間がないこの段階で、Plot その他でモーションが寸分違わず移植できるかどうかの検証をしている場合でもなかった。そもそもリグの最下層部分すら更新されているものも多いのだから、 こうなるとジオメトリレベルでの移植、つまりポイントキャッシュ的なことでもしない限りモーションの移植は無理そうに思えた。んでもってそんなこと、過去 にまだやったことないのである。時間がないから実験が必要なことは避ける。避ける避ける。リファレンスモデルだかデルタだかも、全く研究していないため見向きもせず。これもいかんな。
      
      
      
      
ということで、結局はシーンごとにフツーに手作業することになる。
      
マテリアルを差し替えるものは、全部のシーンでマテリアルの Preset を読み込んできて差し替える。テクスチャがあるものはいちいちレンダーツリーの中でUVを選択し直してやる必要があったりもする。UVを差し替えるものは 全部のシーンでマスターとなる Model を読み込んできてUVのコピペをやる。K3 エンベロープされたオブジェクトそのものを差し替える場合には、一度モーションとポーズを Action として保存しておいた上でデフォルトポーズに戻り、差し替えるオブジェクトを削除なりミュートなりして、Model で読み込んだオブジェクトをエンベロープして、あらかじめ保存しておいたウェイトのPreset を適用した後 Action からモーションを戻すとかやってるうちにエンベロープがぐちゃっと壊れてこれはきっとこのデフォーマは他のエンベロープのデフォーマにもなっていたんだな などと思っても後の祭りでもう一度やり直すことになりしかたなく該当するデフォーマは複製+コンストレインによって新しいエンベロープのみを変形するデ フォーマにしてやったりとかしているうちにめんどくさくなってマシンを破壊する。
ライトとオブジェクトの関連付けも、マスク用の Pass 作りも、フツーに同じ作業を各シーンで繰り返す。多少はスクリプトを書いて自動化したが焼け石に水で、破壊されたマシンの山ができあがる。
      
      
      
      
      
とかいう作業をやっと終えて、レンダリングを回す。レンダリング専用としては6~8台というごく小規模なレンダーファーム。レンダーファームなんて呼んだ ら本物のレンダーファームが裸足で逃げそうな、レンダリングマネジメントシステムのようなものはなーんも入っていない、ただ単にネットワークでつながって いてXSI がインストールされているだけのマシンたち。K4 バッチィなど自作のツールで吐き出したバッチレンダリングのリストを食わせるだけ。マシンの前に行くのはめん どくさいので VNC でリモート操作。レンダリング専用ではなくとも空いているマシンがあれば、参加させる。
      
      
ふう。やっとレンダリングできた。休憩する。少ししてから、次のカットに取り掛かる前にレンダリングが落ちていないか念のため確認してみる。するとマシン は働いていない。なにっ、また XSI様が瞑想に入られたかっ、と思いきや、もはやレンダリングが終わっているのである。
      
一番重いシーンの一番重いPassで、1枚8分くらい。72枚レンダリングするカットだと576分かかることになるが、10台で回すと10分の1、つまり 約1時間で終わることになる。しかしこれは最も重い場合であって、それなりにオプティマイズした甲斐があったのか今回は1枚2分程度のものが多かった。そ うなると15分で終わってしまうのである。
      
げげっ。マシンを遊ばせてはもったいない。ただでさえ時間がないのだ。焦って次のカットに取り掛かる。仕込み終える。レンダリングを回す。そのまま更に次 のカットに突入する。作業途中、さっきレンダリングを開始したシーンの Render_Pictures をそーーーーっとのぞいてみる。げげっ。もう終わりそう。仕込みを急ぐ。レンダリングを回す。次のカットに行く。そーーーーっとのぞく。げげっ。以下永久 ループ。
      
K5 迫り来る納期よりも、迫り来るレンダリングが恐ろしくてたまらない。タスクマネージャのメータが俺をあざ笑う。機械ごときに早く次のカット仕込めよゴルァと責め立てられる。これは精神衛生上 良くない。非常に焦る。焦るので操作も間違える。操作も間違えるのでなおさら仕込みが遅れる。仕込が遅れるのでなおさらレンダリングに追いつかれる。追いつかれるのでなおさら焦る。以下永久ループ。
      
この様子を、なんとなくテキトーに JScript で書いてみると、
var CutNum = 現在のカット;
for (i=0; i<カット数.count; i++){
    for (j=0; j<パス.count; j++){
        Partition分け(j);
        もろもろ作業(j);
        var Yavai = CheckRender(CutNum -1);
        if (Yavai == true)
        {
            作業スピード++;
            休憩時間 = 休憩時間 * 0.8;
        }
        else{
            一服();
        }
    }
    if (レンダリング時間すげー長い == true)
    {
        帰宅();
    }
    else
    {
        作業スピード++;
        睡眠時間 = 睡眠時間 * 0.5;
        泊まり();
    }
}
function CheckRender(in_CutNum){
    var RenderStats = カットのレンダー状況(in_CutNum);
    if (RenderStats == '終わりそう')
    {
        var Yavai = true;
    }
    else
    {
        var Yavai = false;
    }
    return Yavai;

}


こうして疲弊していくのです。CG屋に安息はありません。安息のない職業に未来はありません。
      
      
      
そもそもの問題は、
      
・レンダリングの仕込みに時間がかかるような、手作業が多いワークフローはよくない
      
これに尽きる。準備不足。検証不足。後からやることが多くなりすぎている。
大規模スタジオのようにレンダリング用のTDの人とか、レンダリングアーティストなどと呼ばれる人がいると助かるのだが、そんなもんは夢のまた夢であり、 全ては自分でやらねばならない。
      
と反省しつつも、最終的には、
      
・最近はマシンが速くてよくない
・デュアルコアとかクアッドコアとか、最もよくない
・メンタルレイもバージョンが上がって速くなったようだから、よくない
・レンダリングに使えるマシンが潤沢にあるのもよくない
・6.5 から Adv のライセンスでバッチレンダリングが合計6本も走ってしまうのがよくない
・仕込み途中に瞑想に入られる XSI様が一番よくない
      
      
これらが我々CG屋を蝕んでいるのだという結論に達しました。
CG屋に未来はありません。



これからはスローライフで行きましょう。
      
      
      
      
      

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

2008年3月16日 (日)

咲き乱れる。

レンダリングの仕込み。

Pass を分ける。
レンダーリジョンを描く。
ライトをいじる。
アンチエイリアスをいじる。
レンダーオプション全般にいじる。
何度もレンダーリジョンをリフレッシュする。
やっと仕込みが終わる。
バッチリストに書き出す。
次のシーンに取り掛かる。
シーンのロードを開始する。

ロードが始まってまもなく、XSI 様はクラッシュの花を咲かせる。
美しい花。
世界にひとつだけの花。
いや、ひとつではないな。いくつもの、満開の花。

Crash13

  XSI様、きれいなお花ですね
  でも、もう納期はすぐそこなのです
  今の私には、花を愛でている時間がないのです


色んな作業、特にレンダーリジョンを描いて作業をしていると、メモリにごミでも
溜まっていくのだろうか。次のシーンのロード中に花が咲くことが多い。
GUI からレンダリングしたときも、次のシーンのロード中によく花が咲く。
おかげさまでバッチィの G-Batchie は、役立たずと化す。

また、普通に XSI 様を終了させても、花が咲くことが多い。
ただ終了させただけなのに、そこで花を咲かせる XSI様のお気持ちを、
凡人の私はまだ理解できずにいる。

GUI からのレンダリング中にタスクマネージャをながめていると、
XSI 様がどんどんとメモリを召し上がっていく様子を見ることができる。
そしてタスクマネージャの数値の推移を見る限り、
レンダリングが終わってもそのメモリを解放なさってくれないようだ。 
おそらくはこれが、花の肥やしになっているのだろう。

春が来ている。
今日も花が咲き乱れる。
私はただ、花を見つめるしかない。
今はそんな気持ちになれないのに。
途方にくれる私を置き去りに、
XSI 様はまた花を咲かせ続ける。





今年のモントリオールGPは無事開催されるのでしょうか。
中島悟の息子さんと琢磨くんは、こっそり避難しておいて下さいね。

けけけけけけけけ。




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

2008年3月 9日 (日)

またやられてる。

再びアフォが占拠しています。

Xsibasehacked2


こういうことをするアフォの方には、是非 Softimage の開発チームに入って頂いて、
あり余るエネルギーとそのプログラミング技術を以って XSI の不具合解消
貢献して頂きましょう。

あれぇ、モントリオールはもう廃墟かなあ。
貢献したくてもできないかなあ。
でも Softimage|NET は活発になってきているしなあ。
ここのサーバはモントリオールじゃないところにあるのかなあ。

けけけけけけけけ。




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

2008年3月 8日 (土)

説明ビデオ復活

自作プラグインページに置いてあった説明用のビデオファイルが全滅。
無料の WEBスペースに置いておいたら、ファイル置き場として使っていると見なされて、規約違反で削除されたのだと思います。超規約違反なので異存はありません。ありませんが、けちくせぞゴルァ。



ということで、HDDを捜索していくつかサルベージしました。リンク復活しています。
いちおう、ここにも直リンクしておきます。

G-Batchie パート1
G-Batchie パート2
ボンデージ
親子マッチョ
ひろびろXSI

全て Xvid コーデックの AVI ファイルです。

で、C-Batchie の説明ビデオだけが、削除してしまったのか、見つけられませんでした。
どなたか、もしお持ちの方がいらっしゃいましたら、ここにコメントして下さい。可能なら、提供してください。 自分で作ったファイルの提供をお願いするなどアフォですが、無くしちまったもんはしようがありません。

ということではまぐちさま、C-Batchie 以外は復活できました。よろしければどうぞ。




また鬼のようにスクリプトがたまってきたが、まとめている時間がない。そのときに必要だったことしかさせていない超ラフなスクリプト達なので、オブジェクト名は限定されるわ UI はないわデフォルト値は他のシーンで使えないようなあり得ない数値になっているわソースは読みにくいわXSIは落ちるわモントリオールは爆撃されるわで、自分でも使いにくくて嫌になってくる。この仕事が終わったらまとめよう・・・。早く整理したいけど今は我慢我慢・・・・。





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

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