日々適当

昨夜のTwitterのTLが興味深かったので、ちょっと考えてみました。
で、出来たのがとあるコンパウンド。あんましスマートじゃないように思えるけど。そして欠点も多いだろうけど。



こんなふうにねじれたオブジェクトがあります。面がゆがんでいるわけです。このゆがんだ面を平面にしたいというのがコンパウンドの目的。

まずは参照とする平面を作ります。この場合、とりあえず、ゆがんだ面を取り出して、



ポリゴンのローカルのY方向に0倍してやって平面にします。



そいつをポリゴンのローカルのxz方向に拡大し、メッシュの分割も細かくしました。



で、変形させたいオブジェクトを選択して、以下のようなICE Treeを組みます。



Get Dataで取得しているpolymsh_extractedは先に加工した平面の板です。
この結果、



参照先の平面にぴたりと張り付きました。



参照先の板を前後に動かすとこんな感じで変形します。

選択したポリゴンにのみ影響を及ぼすという方法が分からないもので、通常はCut off distanceで、参照先の板からポイントまでの距離で板にくっつくか否かを判断し、それで余計なポイントが動いてしまうなら、ウェイトマップで動くもの動かないものを指定する、という形にしています。

そんなコンパウンドとなっております。

<追記>
非平面を平面に [__kissiylog__()]

そんなTLから素敵スクリプトも生まれているようです。
</追記>

Kratos & Momentum 破壊表現の基礎 on Vimeo

こちらのチュートリアルビデオを見て、試していたんですけど、いざ画面をキャプチャしようとしたりレンダリングしようとしたりするとシミュレートされないんですよ。で、どうしたもんかなぁ、と。

で、Kratosで分解されたオブジェクトそれぞれにICE Treeを作成し、Cache on Fileでキャッシュで出力。それを読込む事で対処できるようでした。
Momentum 2.0はいつ出るのかなぁ。





<追記>
Twitterで教えてもらいましたば、ビューポートキャプチャが出来ない問題は開発元に認識されていたらしく、現在のバージョンではfixされているそうです。でもまぁ、キャッシュとる事は必ず必要になる事なので、まぁよしとします。
</追記>

Side Books [iTunes Store]

PDFのビュアーです。
これ、結構いいかも。



開発元が日本らしく、マニュアルが分かりやすいのはありがたい。
PDFファイルを管理するにあたって、フォルダにまとめられるのもいいですね。



んで、見開きで本を見るにあたって、左右のページのペアを、表紙の有無で設定することができます。閲覧方向も、3パターンから選べます。つまり、漫画を見るのに結構よさそうな内容です。



個人的にi文庫HDより良いと感じた部分は、やっぱりこのアプリも見ていたら落ちちゃうことがあるんですけど、そんな時の次に起動し直した際の挙動ですね。起動すると開いていたPDFファイルの入っているフォルダが開いた状態になっており、そこから見ていたPDFファイルを選ぶと、落ちたタイミングで開いていたページを開いてくれます。i文庫HDですと、以前、正常にアプリを落としたタイミングのページが保持されているため、落ちてしまった時には、そのタイミングのページを探さねばならない、という作業が必要になるのですけど、それが無いのが素晴らしいと思いました。

もちろん、落ちないことが一番良いのですけど、見ようとしているPDFファイルが重い部類の物であろうと思うのでそこは仕方ないと割り切り、そうするとイカにストレスなく続きを読むことができる状態に持っていくことができるのかという部分に着目するなら、このアプリ、かなり良いなと感じました。

ってことで、i文庫HDにPDFビュアーとしての役割を持たせるのは、とりあえずやめることにします。

上方にエミットさせる実験の最中、キャッシュにしたパーティクルデータをロードしたものをメッシュ化しようとしたのですよ。





そしたらメッシュ化されない。あれれ？、SIが機嫌を損ねたか？とかなんとか思い、polygonizerを再適用してみたり、SIを再起動してみたり、マシンを再起動してみたりしたのですけど、原因は、パーティクルのサイズがあまりに小さすぎた、でした。





これがあって初めて意識したんですけど、キャッシュをとり出すPointCloudに対してICE Treeを構築し、キャッシュのポイントに対して効果を適用する事が出来るんですね。そこで、サイズをいじってみました。



すると、こんな感じでサイズをある程度大きくするとメッシュ化が効いてくる事が分かります。

今後は、出力されるパーティクルのサイズを考えて、シーンスケールを考えないといけないなと、当たり前の事なんだけど、思いました。

ちなみに、この動画のセットアップはあまりよろしくありません。
パーティクルの速度を落とすとか、サブステップの値を上げるかしないと駄目だろうなぁ。マテリアルもいじった方がいいのかな？

いや、知らんけど。

for Softimageがねぇから追いかけてないレンダラー、V-rayってのがありますけど、これのバージョン2.0が昨年登場しておりました。で、そこにGPUレンダラのV-Ray RTってのが内包されているわけですけど、どうせCUDAなんでしょ、と思っていたんですよね。
そしたら、OpenCLベースというじゃないですか。CG屋さん利用のGPUはNVIDAかATI（AMD）の2択なわけですけど、前者が優勢という印象で、CUDAベースってのが多いイメージがあったところに、CG屋さん方面で超メジャーなレンダラに採用された事になります。
残念ながら現状for 3ds maxなツールなのでWindowsオンリーなんですけど、for Mayaが登場してくれば、Macででも動作しましょう（Linuxでも）。

GPUを選べないMacユーザとして、CUDAよりもOpenCLで実装してくれた方がありがたいわけで、今後も採用が増えていけばいいなぁ、って思います。mental rayの会社はNVIDAの子会社になっちゃってるから、OpenCL化は無理かね。PhysX なんかも…

GoogleがChromeのH.264サポート終了を説明、SafariとIE9向けにプラグインも [INTERNET Watch]

Flashを経由して見せているH.264は問題ないとおっしゃってる。

気になるのは、YouTubeで将来どうするか、かな。これがWebMのみになってきた場合、Appleはどうするだろうか。現状、iOS系のツールにはYouTubeに特化したアプリを標準で乗せているわけですけど、当然、Flashに頼った表示はしていないはず。だから、WebMのみになったら、さくっとYouTubeにさよなら告げそうに思うのだけど、どうなんだろ。

まぁ、一利用者としては、すぐにどうこうという事もないし、なるようになるさ、って感じだけどねー。

前試したのは下方向だったので、上方向に出してみました。
Initial Forceとして50を入れていあります。

ちなみに、イメージとしてこのシーンは1unitを1cmとして考えてあります。時速1.8km。たいしたこと無い速度に見えますね。





わりかし「パターン」って感じになっているし、低めのSubsteps（といっても十分に大きい値に思えるけど）では出口付近にすき間が生じており、このすき間はすべてのフレームで生じています。Substepを30とかにしてやるとそれも治まるのですけど、放出された粒子の起動がよろしくありません。

という事で、整流ということを考えます。

まずは単純に、直線部分を長くしてみました。



この場合、傾斜が強くなりすぎているためか、流れにまとまりがなくなってしまっています。でも、出口付近のすき間はありません。
ということで、傾斜を緩くしてみたのが下。



だいぶきれいになりました。
んで、気になるパターン感を無くすために、substeps値を大きく上げてみたのが下。



結構いいと思うんですけど、さすがに現実的じゃないよなぁ。

このあたり、どう整合性をとったもんか、というところですね。



あ、書いてから気付いた。
重力加速度の大きさが1cm/unitの値じゃねーぞ。

漫画誌をpdfファイルにした後、それを読むのに適したリーダーってなんだろう。
とりあえず、僕が知っている範囲ではi文庫HDなんだけど、その理由は、見開きのページを見開きとして見る事が出来る、って事なんですね。そして、単純にそれを実現するなら、pdfファイルの1ページ目と2ページ目、3ページ目と4ページ目、すなわちnページとn+1ページが左右に並ぶんでしょうけど、表紙を1ページ目とするなら、ペアになって欲しいのは、n+1ページとn+2ページなのです。その設定をi文庫HDではする事が出来る。



だから、機能は非常に気に入っているのですけど、落ちるんですよね。

幸い、i文庫HDは読み進んだところでいったんアプリを終了させれば、その時点で開いているページが記憶されるので、時々、落ちる前に自分で終了させてすかさず開いてやる事で、いざ落ちた時も、読んでいるところの側で再び開く事が出来るのですけど、それでもその作業はストレスだし、落ちるのも当然ストレスだし。

iBooksもそんな感じで管理できるかな。

今度試してみるか？（iPadを買った当時、iBooksはPDFのブラウジングが出来なかったので、以降、試していないのです）。

樹を生成するアプリです。
Windowsでしか動きませんが、かなり良いです。ありがとう、TwitterのTLで情報流してくれた人。



葉っぱはテクスチャなので、そこのバリエーションを自力で増やしてやれば、作れる樹のバリエーションがさらに増えましょう。

objで出力できるので、modoにももっていけます。



リプリケータで増殖させて、森や林を作るのもいいでしょう。



無償で使えるっぽいのがうれしいですね（実際に使うなら、ライセンスは要確認）。

ちなみに樹木生成系で素敵なのはSpeedTreeでしょうか。有償のツールだけど、普通にお安く売っていたら手を出したくなる内容です。まぁMacで動かないし、自腹では買わないでしょうけど(^^;

まぁでも、単体で樹を作っていくぶんにはtree[d]でかなり十分な感じがします。
こんなツールのMac用は無いものか…。

ジャバジャバと蛇口から水を出しましょう、という時に、きれいに水が蛇口から出てくれるようにするにはどうしたもんか、という課題。
Lagoaの水をじゃーっと出すプリセットから始めます。



Nullをエミッタに、変形した円柱を障害物に設定してあります。で、下のツリーはプリセットのコンパウンドを展開したもの。



とりあえず、Lagoa Simulate Multiphysicsコンパウンド内のサブステップの値の影響を見てみました。
まずは、Lagoa Emit GridコンパウンドのResolution Per Unitの値が0.5の時。





Substepsの値を上げると、粒子や障害物の影響がより細かく判定されるためか、流れがよりランダムになっています。

続いて0.25の時。たぶん、Initial Forceの値を上げています（流速を上げている）。





Substepsが小さいと、衝突成分がきちんと反映されていません。
以上から、Substepsの値により、ずいぶんと結果が変わってくるという事と、粒子を小さくしたら、Substepsの値は大きく取らねばならない事が分かります。

で、この水を注ぐ時に問題になっているのは流量です。注ぎ込まれる水の量を増やしたいのだけど、Lagoaでは球の数を増やすという考え方が出来ない。増やそうと思うと、Resolution Per Unitの値を小さくしたり、エミッタのサイズを大きくしたりする事になるけど、それはアプローチとしてはどうなの？という感じだし。

Lagoaで扱われる流体は非圧縮であり、粒子であらわされるものは、流体の体積という事らしいです。水などの流体は、通常、空気などと比較して圧力や温度による密度の変化が無視できるぐらい小さいことから、非圧縮として扱われ、Lagoaもそんな感じで取り扱っている、らしい。故に、蛇口の大きさは変化しないのだから、一回に通過できる粒子の量は一定であり、だから、蛇口から出てくる水の量を増やそうと思ったら、蛇口を通過する粒子の速度を増やしてやる、という考え方になります。

そこで、Lagoa Emit GridコンパウンドのInitial Forceに値を入れてやります。
見ての通り、流速の速い方が早く溜まっていくのが分かります。



流速を変化させる手段として、流速を速める方向に力を加えてやったらどうかなぁ、って考えたりもしました。



こんな感じのベクトルをLagoa Add Forceコンパウンドにつなぎました。これは、下図のサークル側にいる粒子に、マイナスY方向へ力を加えるイメージのツリーです。



そうすると、確かに流速は上がるのですが、密度が下がってしまうようです。



放出される粒子の量も、変わりませんでした。



ということで、現実的にはInitial Forceの値を上げてやる、という事になりそうです。
だから、蛇口を捻って徐々に水量が増える、というような事をやろうと思ったら、Initial Forceの値をアニメーションさせてやればいいはず、なんですな。



ちなみに、上のムービー。DisplayInfoのInitial Forceの値が変化しておりませんが、流速を示す球の色の変化とパーティクルの溜まりかたの変化が一致している事か分かる通り、Initial Forceの値は変化しています。なんで値がDisplyaInfoに反映されないんだろ。

まぁ、だいたいこんな感じですかね。