日々適当

リリースを知らせるメールが届いたので入れてみました。

emTools [Mootzoid]

メールによると Get Position on Curve コンパウンドと emTool_Volumeシェーダが追加され、Generate Position Set コンパウンドが強化されたそうです。
このうち Get Position on Curve はカーブ上に等間隔にポイントを高速に配置するというのが実現されています。




Closet Location を利用してカーブのU値からカーブ上の位置を得ると、カーブを構成するポイントが等間隔になっていない限り、等間隔には取得できません。それと同様の結果を得るモードも持っていました。



追加されたシェーダーはmetalrayのボリュームシェーダ。Windowsオンリーだそうですが、かなり高速な印象です。




このノードの各パラメータは外に対して公開されていないので、RenderTree内でカスタマイズ出来ないのですが、あるいはemFluidの次期バージョンに付属してくるかもしれないボリュームシェーダが、これをベースにして拡張したものだったりと妄想が膨らみます。

なお、こいつのサンプルシーンを開いたところ、emRPC5が入ってないよ、ってエラーが出たので、emRPCのアップデートも近いかもしれませんな。

サンプルシーンには先日の素晴らしいデモムービー（上のリンクのページに貼り付けられているムービー）のシーンが含まれています。これはとても参考になるかもですよ。

3delight for Softimage がバージョン4に上がりました。for Softimageのツールがでてくれるだけどありがたい。んで、サイト1つにつきQuad Coreまでのを1ライセンスがフリーってものを入れてみました。従来2コアだったのが4コア対応になったのは素晴らしい事だと思います。しかも、商業用途でも利用可なのがうれしいですね（パワーが足りなすぎて実用性が無いでしょうが。実用上はもっと多くのコアを使えるバージョンやバッチレンダリングで回すためのバージョンが必用でしょう）。

で、グリッドにこんなツリーのマテリアルを適用してレンダリング。



結果はこんな感じ。

mentalrayの設定を詰めていないけど、それは3delightも同様ってことで許してもらって(^^; ディスプレイスメントマッピング時のレンダリング品質の信頼性が雲泥の差かなという感じがしています。
ちなみに、同じツリーなのに計算結果が違う（Cell_Scalarによる模様が違う）のは、シェーダーをRendermanのものに変換する過程で数値の解釈なのかアルゴリズムなのかが違うからなのでしょう。この辺は仕方がないけど、実際に作業をする時は最初から3delightでレンダリングすることを想定して制作を始めるだろうから問題ないでしょうな。

対mentalrayにおいて、3delightを導入する価値はもちろんこのテストだけでは何とも言えませんけど、このテストの結果だけを見るとあるように感じます。ただ、mentalray向けに組んだレンダーツリーをある程度解釈してレンダリングしてくれるとはいえ、全てのノードに対応しているわけではないし、対応しているものも全てのパラメータに反応するわけでもないわけで、そんな意味で3delight独自のレンダーツリーで使えるシェーダーのプリセットを増やしてもらうと嬉しいかなと思ったりしますな。もっとも、シェーダーを書けってのが本当の所かもしれないっすねw
それでも、ある程度の解釈をしてくれる幅は意外と広いので、mentalrayの低レベルなノードを繋いだりしなければ大抵大丈夫なんじゃないかって感触は持っており、ライトな用途（複雑なツリーを組まない）なら十分使えるんじゃないかって思えました。

商用レンダラーのfor Softimageでは 3delight、v-ray、arnold あたりが選択肢として真っ先に上がってくるものだと思います。今だと入れられるならarnoldという感じなのでしょうか。ちなみに個人で1台でしか利用しない（持っているマシンも4コアのものだ）なら、無料で利用できる3delightが一番コストが低くてすみますな。複数台で動かそうとすると、とたんに不利になりそうだけど（v-rayなら15万弱のお値段でレンダーノードが5ライセンス付いてくるから、一人で作業するにしてもこっちの方が価格は有利。なんでfor maxはネットレンダーでライセンス数無制限なの？。arnoldってお幾らなんざんしょ。）

for SoftimageってSoftimageのGUIをあげずにレンダリング回るのかな？ for Mayaはそれが出来ないらしくて、だから全部入りのStudioを入れないといけないらしいって話を聞いたけど…

今さらながら、emToolsをちょっと触ってみました。きっかけは2週間ほど前にEric Mootzによりアップロードされたムービー emTools v.1.81 - "Tools in the House" です。

emTools v.1.84 - "Toolz in the House" [Vimeo]

emToolsは emPolygonizerやemFluid等の比較的リーズナブルなSoftimageの有償ツールを提供するMootzoidから、おそらくそれらツールを開発する過程ででき上がったシンプルなコンパウンドやノードのパッケージです。

emTools [Mootzoid]

だから一番上に張ったvimeoへのリンクにあるようなムービーは、emToolsに含まれるコンパウンドをつないだだけで完成する、というような物ではなく、その他、ICE標準ノードやその他emTools等のサードパーティーノードと組み合わせて表現していく事になるわけですが、標準ICEノード・コンパウンドのみで作るにはつらい、重くなる、困難というような物が含まれているので非常に有用であるし、面白い物も沢山あります。
このツール郡が無償で配布されているのはとてもありがたいことですね。

もっとも、その使い方がよくわからない物も大量に含まれていて、一部はチュートリアルビデオを見て、多くはオンラインドキュメントを読んで理解することになります。けど、使いこなせれば非常に強力に制作をサポートしてくれるんじゃないかって思います。

ちなみに、すぐに試せて面白い効果の物としては Melt Particles ってのがあります。



パーティクルとパーティクルがぶつかると、互いが融合し大きなパーティクルができ上がるって効果を期待できて、がんばれば emNewton2を買わなくてもemNewton2 v.2.0 (beta) [Vimeo] みたいなのを作れるかもしれませんよ。
あるいは、Liquid Filaments Strands 。ポイントとポイントの間をストランドで結ぶコンパウンドはTim Borgmannの得意とする表現（vfx/design reel 2012 on Vimeo）の一部を簡易に実現させてくれます（ごく一部だけど(^^;）。

それ以外にも工夫次第で表現の幅が広がるこのツール郡。使わない手はないでしょう（チュートリアルを見ても、すぐに試せそうなものを把握できます）。
というわけで、以下は波はxOcean。その上にStrandを先のLiquid Filaments Strands で生やしてみたものを適当に質感設定して回したもの。適当だけど、作っている間は楽しかったw

過去書いた Point Cloud Lookup に関するエントリ全部に追記したけど、注意点というか大前提をメモしておきます。

PointCloudとそれを参照するオブジェクトは同じマテリアルを持っていなければならない。

この前提を忘れていて難儀しました。この条件を満たしていれば、PointCloudLookupで参照しているPointCloud内のベクトル値の属性がリストアップされてくるわけですが、満たしてなければ出てきません。出てこないということは正常に動作しないというわけで。

さて、After Effects CC になり、CINEMA 4D Lite が付属するようになりました。これにより、C4Dのシーンの情報をAE内に持ち込めるようになったわけで、ですから、SI→C4D→AEというフローを実現できるようになりました。具体的にはSIのカメラやSIシーン内のオブジェクトの位置情報をNullの形でC4Dに持ち込めるはずです。

ということで試してみました。



こーいうグリッドをグニャグニャさせたシーンを用意し、それはSIでレンダリングします。
こいつの下に置く地面をAE CC上で作ってみる、という想定です。

まずは普通にSIのカメラをFBXで書き出しませう。



AEにSI上でレンダリングした画像を読み込んでおきます。C4DのファイルはAEの ファイル→新規→MAXON Cinema 4D ファイルで作成します。そうするとCinema 4D ファイルがAEのプロジェクトに追加された上で Cinema 4D Liteで開かれます。



C4D Lite のFile→MergeでSIで書き出したfbxファイルを読み込みます。
それでシーンを保存してやればいいのですけど、カメラをAEに持ち込むためにもう一手間かけてやらないとダメでした。

SI上のカメラは通常、Camea_RootというNullの子供にカメラの本体とカメラの注視点である Camera_Interest というNullがついています。このCamera_InterestをAE上のNullとして読み込まれるように設定しておきます。具体的には、Camera_Interestの上で右クリックし Cinema 4D Tags → external compositing を選んでやるわけですけど、外部合成タグをオブジェクトに付けてやっているわけですね。



これがついたオブジェクトはAE内で読み込み可能なものなら読み込んでくれるようです。Camera_Interestの場合、AEのNullとして読み込まれます。

C4D Lite 上でシーンを保存し、AEに戻ると、AE上でその更新が反映された状態にあるので、そのまま c4dファイル をコンポジションに入れちゃいまする。



んで、そのc4dファイルのレイヤーにあるエフェクト、CINEWAREの中の Commands で Extranct を実行するとカメラやライト、外部合成タグを付けた連中がAEのレイヤーに展開されます。




たぶん普通ならこのままでもあうんですが、ずれるんですね。その原因が、カメラが注視点を見て制御するタイプだからみたいで、AEのカメラの目標点の位置が Camera_Interest とは違っちゃっていわけです。だから、カメラの注視点を Camera_Interest に一致するように設定してやります。

こうして、晴れてAEのカメラとSIのカメラ（C4Dのカメラ）が一致した、という状態になりました。



たぶん、従来のスクリプトを介してSIとAEの間でカメラをやり取りするってのより楽なんじゃないかと思うんですけどどんなもんでしょ。
なお、AEからSIにデータを持ち出す事については、CInema 4D Lite では対応できないようなので、CInema 4D Prime以上を買いなさいってことなんでしょうな。まぁそこはアエとXSIで…。

めりこみ上等w

以前こんな感じで某サイトを参考にICEでポリゴンアイランドを取得する方法を実践しそのコンパウンドを組んだんですけど、素敵ICEノードが出ていました。って出ているのは知っていたけど試してみたら驚いたというか。

Faster Polygon Islands [Julian Johnson's Blog]

ここのjj_Island_Indexer と

emTools [Mootzoid]

のVertex Islands周りのツールです。



jj_Island_Indexer単体でも各バーテックスがどのポリゴンアイランドに付属するかを得られますが、



emToolsを併用すれば、ポリゴンアイランドのセンターを取得できたりと利便性が上がります。
っていうか、これを適用したら20秒ほどかかっていた処理が一瞬になるのだからC++で書かれたノードは強力ですね。

目的とした物を完成するレベルには達せなかったのだけど、その途中段階の物が一応形になったのでメモ。
Photoshopにおける自由変形的な物。AfterEffectsにおけるコーナーピンみたいなもの。Softimage的には分割数が最低なラティスかな、ってもの。

この場合の考え方は、図形上の点からバウンディングボックスの縦横に平行な線をバウンディングボックスの境界線に交わるところまで延ばしたとき、その線はその点に分割された直線になるけど、その点が直線を分割する割合は、図形がいくら変形しても一定ということらしい。



分かりにくいので上図を見ます。図形内のある点PはABとCDの交点と考えることが出来ます。
んで、図形の四隅の点を移動させた移動後のA'B'とC'D'の交点がPnという事になります。
この時、

|AP|:|PB|=|A'Pn|:|PnB'|、|CP|:|PD|=|C'Pn|:|PnD'|

が常に成り立つ、という事みたいです。
そうすると、必用な情報であるPn0A' + A'Pnを求めるには、Pの位置における分割の割合（sy = |P0A|/|AP2|、sx = |P0C|/|CP1|）を記録しておいて、 Pn0A'はsy ×(Pn0Pn1)だし、A'Pnは sx × (A'B')となります。A'B'はPn0A'とPn1B'から求められますわな。

ってことで出来たのが以下のICE Tree。



XZ平面に限定した2Dの変形ってことなんですけど、厚みは保持されるようにしてみました。



しかし目的の物を作れず、ちょっと落ち込んでいます…

世のいろんな人が良いツールを出していますけど、自分でもやってみたのです。正確ではなく、何となく等間隔になるって雰囲気のものですけどね。



とはいえ、考え方としてはとってもシンプルです。シンプルなんですけど、これ、どーにかならないかなって処理がありまして…

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

という配列があったとして、これから

[1, 3, 6, 10, 15, 21, 28, 36, 45, 55]

という配列を得たい時、どうしたらいいんだろう、ってわけでしてね。自分自身のより前の要素を全部足し合わせた値になる、というもの。
仕方がないので、上図の等間隔っぽく並べるための以下のICE Tree内の

Make RefLength コンパウンドの中で以下のようにループ処理をして対処しています。

ここが明らかに速度低下の原因となっているんで、何とかならんもんかねぇ、と思う今日この頃なのでした。



だれかプラグイン書きませんか？

ちなみに、ポイントクラウドのポイントに対して直接処理を行う場合は、その方法がネット上に書かれておりました。eX-SIかsi-communityかメーリングリストだったと思う…(^^;




<追記>
Using Generate Sample Set to avoid the Repeat node [eX-SI]

感動しました。こんな方法があったんですね。ループ処理をさせずに配列を作成する手法です。確認のために自分でやってみました。

Element Indexを使うのかぁ。頭いいですなぁ。
というわけで、上の等間隔っぽく並べるICE Treeの中の Make RefLength コンパウンドの中身を以下のように変更しました。

この結果パフォーマンスが以下のように改善。素晴らしいですね。


</追記>

とりあえず、Mac Lookup Settings の Method が Linear Distance の時のお話です。



こんなシーンを用意しました。グリッドとポイントクラウドが存在し、ポイントクラウドには以下のような ICE Tree がセットされています。



グリッドにあるX軸上に均等に5個のポイントをおいてXの小さい値から緑、赤、青、緑、赤という色をつけている形になります。
この色はベクトル値に変換してカスタムアトリビュート ColorValue に記録しています。

でもって、グリッドとポイントクラウドが共有するマテリアルに以下の RenderTree を設定しています。マテリアルを共有していることが大切



Point_Cloud_Lookupから出力されてくるベクトル値をカラー値に変形しています。



さて。

Point_Cloud_Lookup の Max.Distance に入る値の意味ですけど、印象通り述べるなら、レンダリングされるピクセル部分に対応するポリゴンの表面の位置から、この値で指定された範囲を検索して、ポイントクラウドのポイントを見つけるというものだと、たぶん、思うと思います。でも、なんか違うのですよね。値を変えてその結果を並べてみましょう。



お分かりでしょうか。入れた数値の平方根な距離で評価されているように見えます。

1= 1
2 = 1.41459...
3 = 1.73205...
4 = 2
5 = 2.23606...

という感じですな。

続いて、 Max. Points です。そこの値を変えたときの色の変化は以下の通り。



そこの数値を増やすほど、暗くなっていっています。左上の赤い部分のRの値をみてもそれは明らかです（R = という形で数値を書いています）。どうやら Max. Points の値で割られているようなんですね。

256 / 2 = 128
256/3 = 85.333
256/4 = 64

出力されてくる値はベクトル値です。
平均ってことすかね。距離に応じて評価の重みを変えるということはせず、見つかったやつの平均を出している。
重みを考慮するためのパラメータがfalloffってことでしょか。

というわけで、今回のこのシーンの目的（色を足し合わせたい）としては、以下のようなRenderTree にしてやれば良さそうですかね。
Max. Points に入力する値と同じ値を、Point_Cloud_Lookupから出てくるベクトル値にかけてやってます。



ちなみに、これは前述した通り、MethodがLinear Distanceの場合の結果です。そうじゃないときは結果が変わる可能性がありますが検証していません。

以上、メモでした。

と思ったのです。
たとえば、PointCloudの球を取り出して、以下のようなICE Treeを設定します。

んで、Polygonizerでメッシュを作成するわけですが、そのメッシュの色を近接するパーティクルの色にしてやりたいって時に、PointCloud Lookupが使えるんじゃないか、むしろ使うべきなんじゃないかと思ったわけで…。

ICE Treeでカラー値を3D Vector値に変換してカスタムアトリビュートとして保持させています。
それで、メッシュのRenderTreeにて以下のように設定してやります。このマテリアルはPointCloudにも適用します。



すると、下図のようにパーティクルカラーを反映した形でレンダリングされてきました。



で、どうやら、PointCloud LookupのMax.Pointsの値に大きめの値を入れると出力されてくるベクトルは、設定した数だけ取得したベクトルを平均したものなのか、何となく混ぜられた値が出てくるんですよ。



そのルールが分からないので正確な値が必要なときには（僕には）まだ利用できませんけど、何となくでいいなら、これでいいんじゃね？って思いつつあります。

実際、どうなんだろうなぁ。