日々適当

Softimage ICE - Tree building step by step [Chris Marshall]

こちらを参考にツリーを組んでみました。
互いにめり込まないようにしたり、それよりも継ぎ目をどうにかするにはどうしたらいいのだろう、という感じですね。

もっとも、これは単純にあるパラメータを0から1に変化させることで伸びていくような作りであり、実際はシミュレートすることで動くようにしたいという希望があったりします。だからたぶんこのアプローチの仕方じゃ駄目なんでしょうね。

追記
おまけ。
Vue xStreamをSoftimage 2010上で動かした時のVueの地面とICE Particleとのインタラクションのテスト。Vueは7.4（だって職場の奴、アップデートしてないんですもん）。
当然ながら、エコシステムの岩とは反応していないけど、地面とは普通のSoftimageオブジェクトと同様の反応をしてくれる。

FlexScan S2242Wを使っているんで買うことはあり得ないのだけど（壊れても5年保証なので修理しちゃうだろうし）、後継っぽいFlexScan SX2262Wが出たようです。

パネル品質自体に（スペック上は）変化ないようですけど、DisplayPort1系統とDVI2系統というのはいいですね。
ほぉ、DisplayPortって10bit入力が出来るんですか。
Macの出力は10bit対応しているのかなぁ？（ナナオのページからリンクされているページにある情報ではFireGLしか対応していないような雰囲気だけど）

総じて全うに進歩している感じで喜ばしい限りですな。

Snow LeopardではNTFSをサポート--その源流を訪ねる（1） [builder by ZDNet Japan]
Snow LeopardではNTFSをサポート--その源流を訪ねる（2） [builder by ZDNet Japan]
Snow LeopardではNTFSをサポート--その源流を訪ねる（3） [builder by ZDNet Japan]

上記ページが消えてしまったときのためのメモ。/etc/fstab に

LABEL=NTFS none ntfs rw

と書いておいて再起動するとNTFSのリード・ライトのモジュールがロードされるらしい。
で、筆者曰く、特に問題は起こっていないそうで。
ただし暗号化されたファイルには対応しないのは注意が必要。
それ以外は日本語も問題ないそうだし、BootCampでのWindows起動時とMac OS X起動時のそれぞれの間でのファイルのやり取りのためにFAT 32ボリュームを用意しているって人は、NTFSにするという選択肢もあるいは出てきたかもしれませんね。

追記
【コラム】OS X ハッキング! (342) 知られざるSnow Leopard(NTFS編) [マイコミジャーナル]

ハイクオリティテキスト。 [Junki The Junkie's Junkyard]

こーいうこと↓みたいです。



オプションを用意してまでやることか？とか思った。

メモ。

submit to backburnerを使います。
たぶん、Softimageにはまだbackburner自体は付属してきていないと思うので、maxやmayaを入れることで入るものだと思います。

で、それが入っているなら、通常は

C:\Program Files (x86)\Autodesk\Backburner

に一式入っていることでしょう。

でまぁ、それらが入っているとして、その上にWindowsのOS側の下準備が必要です。

まず、通常は

C:\Softimage\Softimage_2010_SP1_x64\Application\bin

に入っているXSIBatch.batを

C:\

にコピーします。バックスラッシュがこのページだとなぜか消えちゃうんで全角ので描いてあるけど、本来は半角バックスラッシュです。

それから、システム環境変数を追加します。

マイコンピュータ→プロパティ→詳細設定→環境変数

のパネル内のシステム環境変数にある「新規」ボタンを押し、

変数名：backburner
変数値："C:\Program Files (x86)\Autodesk\Backburner\cmdjob.exe"

とします。

でもって、いったんマシンを再起動させて環境変数を読み込んでから、submit to backburnerのAddonをインストールします。まぁ別に、インストール後に上記設定をしてもいいですけどね。

でもって、レンダリングするシーンを開いたらSubmit to backburnerを呼び出します。



ちなみに開くシーンのプロジェクトやその中に含まれる素材のパスはUNC表記になるようにしておくとたぶんスムーズです（素材についてはプロジェクトからの相対パスになっててもOK）。
UNC表記とは\\Machine Name\Shared Folder Nameというようなパスですね。



それで、Chunksって値ごとにシーンのフレームレンジが区切られて各サーバーにジョブが送られることになるので、必要に応じてそのあたりの値もいじってやるといいでしょう。
で、Submitボタンを押すとタスクリストのテキストファイルをセーブする画面が開きます。適当な場所に保存してやります。デスクトップは駄目みたいですねがね。



同時にbackburner.batってファイルがC:にでき上がっているので、そいつをコマンドプロンプトに放り込んでやればBackburnerのジョブにそのシーンが放り込まれました。
後はbackburnerがxsibatch -r コマンドを各マシンで呼び出してレンダリングを開始する、って感じです。

もちろん、backburnerのサーバー、モニタ、マネージャは必要に応じて立ち上げておく必要があるのは言うまでもありません。



Linuxで回すには、maya 2010あたりをLinuxマシンに入れたらbackburnerも入るのかね？
でも、その場合はLinuxのパスに書き換える必要がありますな。その場合はNFSなんかでネットワークのどのマシンから見てもパスはおんなじみたいな環境構築が必要そうですね。

追記
gooの投稿画面を開いたときに入力してあったが消えちゃうみたい。むぅ。

現実逃避でこんなグラフをネットからデータをかき集めて作って見たり。
Cinebench R10の結果です。

こうして見るとiMac Late 2009のCore i5、i7モデルのパフォーマンスの高さがとてもすてきなのだけど、一方で、それでもMac ProはCPUをきっちり使ってくる処理なら強いわけっすね。ってか、Mac Proのハイエンドの強さは圧倒的なわけで。

ただ、CPUの世代が変わっているためか、Single CPU（うわっ、図のスペル、間違えてる(^^;）のスコアがクロックが低いはずのCore i7 iMacの方が、Mac Pro Early 2009の2.93GHzより勝っているのが気になります。
これがハードウェアの進歩によるものなのか、ソフトウェアに起因することなのか、このグラフからは分かりませんけど、仮に前者とするなら次の世代のMac Proが仮にまだCore i7の系列を積んでくるとしても、楽しみと言うものですね。
2.26GHzのSingle CPUのスコアが低すぎるような気がするのだけど、今度、職場ではかってみようかな

まぁ、後者の可能性もありますが。Mac Proは10.5.x、iMacは10.6.2での結果ですから。

追記
納得いかなかった、Mac Pro 2.26GHz Octa Coreのスコア。職場のMacで出してみました。
Mac OS X 10.6.2環境下の値です。

Single CPU: 3139
Multiple CPU: 20576

おおっと、なんか大幅に数字が伸びていますね。
比較的納得できる数字が出たんじゃないかって気がします。
ちなみに、このMac Proは10.6がプレインストールされているモデルなので、新しめの筐体といっていいと思います。ですから、CPU自体がグラフにした物とは違っている可能性もありますけど（世代が進んでいるとか）、んー、でもどっちかというとソフトウェアの問題なんだろうなぁ、このスコアの違いってのは。

追記
ということで、上記結果およびコメントでいただいた結果を反映したグラフが下。



これ見ると、少ないスレッド数でビュンビュンさせたいという人以外のOcta Core持ちの人は、iMacにパフォーマンス方面で目移りする必要は無いですな。

カスタムアイコンがついたファイルって、Finder上でアイコンプレビューで表示する際、そのアイコン情報が邪魔なんですよね。だから削除したい。
で、以前、Automatorでアイコンプレビューを削除する方法を模索したわけですが、それだとそれを可能とするアクションを必要で、そのアクションはシステムには付属しません。
そのため、Snow Leopard にあげて後、そのワークフローが使えなくなっておりました。

ただ、古からのMac上でのカスタムアイコンの削除方法は有効であり、こちらのエントリ [向かい風でも軽やかに] で書かれている通り、Mac OS Xで拡張された複数選択してのインスペクタによる情報から削除可能だったりします。



こんな感じでね。88項目で7MB弱もの容量をアイコン情報が占有していたわけですが、それはともかく、この方法だと選択した中にカスタムアイコンが存在していなファイルが存在している場合、アイコンは削除されないのですよ。

さて、どうしたもんか。
xattrってコマンドでできるみたいなのだけど、ちょいとこれはいじりたくない。

できればサービスに登録する形でいけないかって思っているのですけどねぇ。

追記
ということで、さらに調べて見ると、
SetFile [Hiro's Personal Pages]によい情報がありました。

Xcodeをインストールすると入る/Developer/Toolsにあるコマンドラインのツール。
この中のSetFileを使うとよさそうです。

たとえば、あるJPGファイルを /Developer/Tools/GetFileInfo を実行してみると

file: "file path"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstClinmedz
created: 02/09/2008 12:10:25
modified: 02/09/2008 12:10:25

というような情報が表示されます。この中で大切なのが、attributesというパラメータ。ここのavbstClinmedzという部分の内、大文字のCがカスタムアイコンが存在していることを示しています。これが小文字のcであればカスタムアイコンを使わないという設定になるようです。
ってことで、上記ファイルに対して

SetFile -a c [そのファイルのパス]

を実行してやるといい感じなわけですね。
試しに実行後、GetFileInfoをみて見ると

file: "file path"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 02/09/2008 12:10:25
modified: 02/09/2008 12:10:25

というように大文字のCは小文字になっており、Finderでみても、アイコンプレビューによる白枠のついたアイコン表示になっています。

こうなれば後はワークフローを組んでやればいいだけです。



もっとも、この手法で難があるのは、あくまでも「カスタムアイコンを使わない」という設定をするだけなので、ファイルサイズは減らないというところですね。まぁ、いいか。

InterBEE 2009：Autodesk「Autodesk Smoke 2010 for Mac OS X」を世界初披露 [MACお宝鑑定団 blog（羅針盤）]

というわけで、そのデモンストレーションを見てきました。
InterBEEのAutodeskブースです。

上記リンクでそのデモの様子が動画で見ることができちゃうので、行かなくてもよかったかなって感じではありますけど(^^)、デモンストレーションが始まったばかりのころは画面がSmokeのそれで覆われていた状態でしばらく行われたために、これは本当にMac上で動いているのか、と疑問を持つぐらい見事にAutodesk（ディスクリート）な画面でありました。
んが、その後、他のアプリケーションとの連繋を示すときにMacのデスクトップやFCP、Photoshopの画面に切り替えたり、たしかにDockからSmokeが起動していたりと、間違いなくMac上で動作しているのがわかります。

Smoke自体の真価を語る能力は僕にはありませんけど、まぁ、実にうらやましい印象を持つ部分がいっぱいありましたね。

あと、実にさりげなく過ぎていきましたけど、データの変換作業のところでbackburnerという単語が出てきました。これ、3DCG屋的には3ds maxに付属するネットレンダーのツールという感じなのですけど、最近ではmayaにもついてきているものだったり、Softimage向けのbackbrunerと連携するツールが出てきたり、とか何とか、Autodeskのそんなツールとして認識されています。
んで、これ。Mac版がなかったりするんですよ、たぶん。Mac版maya 2010にも付属してきていません（たしか）。

しかしてsmoke上でそれが動いているっぽい。これはあれかな。近い将来Mac版mayaにも提供されるかもしれませんな。

お値段は上記ページによると140万円程度ということです。この値段なら飛びつくプロダクションもありそうですね。
成功することを祈っております。

ちなみに、このデモの前に2つほどのユーザデモを見ました。
そのうち一つがILMのChad Taylorさんによるインフェルノを使った映画（ターミネーターとトランスフォーマー）の合成のデモでした。個人的に非常に興味深かったのが、想像以上に実写素材を多用していることでした。煙やマズルフラッシュ、炎、破片。それら要素がCGでつくられている量が、見せてもらったカットでは非常に少なかったような気がします。そのかわり、合成は恐ろしく面倒なことになってそうなんですけど、素材としての現実感は、やはり実写の方が上ってことなんでしょうかね。

追記
ちなみに、InterBEEで面白かった展示物が↓

シンプルアイデアだと思うのだけど、しばらく立ち止まって見入っておりました。



追記
Smoke for Macのお値段。[InterBEE2009]オートデスク株式会社ブースレポート [PRONEWS]こちらによると、249万2千円だそうです。

症状はことえり時代から出ていたのですけどね。

iTunes 9にあげた頃より、曲を選択してCommand + i で開くウィンドウにおいて、「情報」タブと「よみがな」タブに移動するときにすごく時間がかかっていたのです。あるいは、それらタブを選択した状態で次の曲に「前へ」や「次へ」ボタンで移動したときもそうでした。

それはiTunes 9の不都合だと思っていたのですけど、どうも、IMとの相性というか、そんなところの問題だったみたいです（iTunesが悪いってこともありうると思いますけどね）。

かわせみが1.0から1.0.1にアップデートし、その結果、iTunesのレスポンスがよくなったという書き込みをネットで見かけた為に期待してアップデートをかけたら、確かに雲泥の差ってくらいレスポンスがよくなってくれました。



実にうれしいアップデートとなりました。

CGTalk - Smoke for Mac OS Xに興味深いことが書かれていました。

SoftiamgeはかなーりWindowsに依存する仕組みになっているみたいですね。
まぁ、スクリプトを書く時とかにうっすらとは感じていたことですけど。実際、XSIのベース部分はマイクロソフト時代に書かれたものでしょうし。

それが何でLinux版があるのかというと（そして過去SGI版があったかというと）、Mainwinっていう（その投稿の説明によると）Wineのようなものに乗せられて動いているから、って事みたいです。それゆえに、Mac版が実現するには、Softimageがプラットホームレスな環境に移行するか、Mainwinって物がMac上で動作するようになるかって感じになるんでしょうか。

個人的にはぜひ移植はやって欲しいわけですけど（でも、mayaのような感じになるのは勘弁っす(^^;）、難しいかなぁ…