« 頂点上にパーティクルを発生させる。 その3。 | トップページ | 取得 その1001。 全ICETree/RenderTreeビューの取得。 »

2012年6月 8日 (金)

頂点上にパーティクルを発生させる。 その4。

さらに続き。


m4g さんにはいつもお世話になっております。


パーティクルをブツの頂点上に発生させて、そして法線方向に向ける、というものですが、m4g さんに御教示頂いたツリーを載せておきます。 この方法の方が良い気がする。


この記事では、法線方向に向けるということのみに注目していますので、それ以外の要素のことは敢えて省いてあります。

Pointatnormal_m4g

クリックするとでかい画像。


このツリーで、パーティクルの Orientation を決定する(法線方向に向ける)ために使っているのは、Increment Rotation with 2 Vectors という標準コンパウンドです。 画像の中のEです。 (ちなみに、俺が前回使ったのは Rotate Vector でした)

この Increment Rotation with 2 Vectors ってのは、ある回転値(Rotation)をベースにして、ローカルのこのベクタ(Local Vector)を、ワールド座標のこの位置(To Vector)に向けるために必要なだけの回転値をベース回転値に加算するぜ、というコンパウンドだと思います。マニュアルにそう書いてあるように見えます。 しかし、例によってマニュアルの表現って不思議ちゃんな感じですね。


今は cone をパーティクルの形状に使っていて、とんがった方向をパーティクル発生源メッシュの法線ベクタに向けたいので、これはパーティクルのローカルY方向ですね。

ということで、Increment Rotation with 2 Vectors に食わせる情報は、以下のようになります。

  Rotation = パーティクル自分自身の元の回転値(現時点でゼロですが)。

  Local Vector = 0, 1, 0 (パーティクルのY方向)

  To Vector = パーティクルを発生させたメッシュの法線ベクタ



Rotation は、自分自身のローテーションですから、self.Orientation をゲットすればいいだけなので問題なし。今回は Get Particle Orientation コンパウンドを使っています。


Local Vector はそのまんま、0, 1, 0 を入力します。



問題は To Vector です。 というのは、こいつは発生源メッシュから法線情報をもわらねばなりません。 

俺ごときは画像内のDのように普通に発生源メッシュの PointNormal を突っ込めばいいやと考えてしまいがちなのですが、これはコンテクスト違いでつながってくれません。
 
Pointatnormal_m4g_unabletoconnect

なぜつながってくれないのか。 

それは、Increment Rotation with 2 Vectors は自分自身(PointCloud)の情報を欲しがっているのに、他人(発生源メッシュ)の情報を突っ込もうとしているから、だと解釈しましたが、合ってますかね。



つまりですね、そもそもこの ICETree が与えられているオブジェクトは発生源メッシュではなく PointCloud なのであり、その PointCloud に属するパーティクルの向きを決めるために Increment Rotation with 2 Vectors を使っているんだから、こいつは自分自身の情報(PointCloud が所有する情報)しか食ってくれない、という意味だと思うんですよね。


そこで、発生源メッシュが持っている情報を PointCloud 自身の情報にコンバートしてやらねばならない。 そのために、Get Closest Location ノードを使っていると考えられます。 画像内のBです。

Pointatnormal_m4g_2
クリックするとでかい画像。

発生源メッシュから Geometry ポートに情報を渡してます。 次にAではパーティクル自身のポイント位置を拾ってきています。 そして先ほどの Geometry とAを比較して一番近い場所(Location)を吐き出しています。 「A(自分自身の情報)のうち、メッシュに最も近いところを吐き出す」ですから、吐き出すものは自分自身の情報であるという部分が重要です。 そしてこのとき、パーティクルはもともと発生源メッシュの頂点位置に発生させているわけですから、「一番近い位置」 は頂点とズバリ 「同じ位置」 であると保証されています。 

そしてその位置を、Cの Get .PointNormal に食わせているので、CはBからもらった位置における法線方向を吐き出すということになります。 Bからもらった位置とは、自分自身の情報であるという部分が重要です。 

結果、パーティクルが発生しているズバリ同じ位置における、発生源メッシュの法線方向(他人様の情報)を、自分自身(PointCloud自身)の情報としてゲット出来たのがCだということになります。 よね? 合ってますよね?  で、もう自分自身の情報なんだから、自分自身のローテーションを決めるためのEに食わせることが可能になった、という解釈です。 


別の言い方で言うと、Get Closest Location の Position ポートに入っているのはAで取得した自分自身のパーティクル位置ですから、Bが吐き出すのはあくまでも自分自身が持つ情報だということです。

その自分自身が持つ位置情報のうち、発生源メッシュに一番近い場所=実はズバリ同じ場所をBは吐き出しているわけで、実質的には発生源メッシュの情報を100%コピーしたことになりますね。 コピー元は他人様で、コピー先は自分自身。 以降はコピー先(自分自身の情報)を利用する。 という感じ。 




ということだと思っています。
冗長ですみません。
しっかり説明できるくらい理解したい。
ちゃんと理解できたら、もっと簡潔に書けるかな。。。。
間違いあればどうか指摘お願いします。


ええと、前回までのツリーでは Build Array from Set を使っていたのですが、なぜアレイが必要なのかよくわかってませんでした。 他人様から情報を頂く時はアレイが必要なのかな? なぜ? みたいに思っていました。

でも、もし今回と同じ考え方ができるとすれば、アレイを介すことによって他人様の情報が自分の情報になる、と解釈できる気がしました。 アレイの入力は他人様からもらってるけど、アレイそのものはPointCloud 自身の ICETree 内に発生させているものなので、アレイが吐き出す結果はもう自分自身が所有する情報である。自分自身の情報になったのであれば、自分自身の情報を要求する下流ノードにそのまま接続することができる。 ということなのではないか。

どうですか。間違ってますか。どうか指摘して下さい。







もうひとつ重要な発見、というか新たな謎が・・・。


前々回の記事の後半で、ベースメッシュを変形させると、ビューポートが表示する法線=青い線と ICETree が返す法線が一致しないと書きました(GIFアニメーションになってます)。

しかし、今回 m4g さんに教えてもらった Get Closest Location 方式で取得した法線は、変形後も、ビューポートが表示する青い法線と完璧に一致するのです。

Pointatnormal_m4g_matchnormal

前回のツリー、Rotate Vector 方式では一致せず、今回の方式で一致するのは、うーむ、なぜなのでしょう。


一致したからどうだというものでもないのですが、その仕組みを説明できるほどは、俺はまだ理解できていません。 どなたか説明してくれませんか。 そこらへんが解ると、さらに理解が進みそうな悪寒がします。







.

|

« 頂点上にパーティクルを発生させる。 その3。 | トップページ | 取得 その1001。 全ICETree/RenderTreeビューの取得。 »

コメント

スクリプト他でこちらのページでは大変お世話になってるもので、少しでもお役に立てればとでしゃばっております(^^)

Twitterでも書いたかもですけど、他のオブジェクトの情報を参照する時、他のオブジェクトの何処を参照するかを明示しないといけないわけで、他のオブジェクトの情報をBuild Array from Setで配列に入れて、それの何番目の要素を取得するっていう風にしたり、Closest Locationを使って、自分自身が、参照したオブジェクトの近傍の値を取得する、というような事を常套手段としてやるのだと思っています。

んで、この例の場合、Closest Locationを使うより、junkiさんがやられているように、メッシュの位置や法線を配列に入れて、self.IDの値で取得する方が合理的だと思います。なんとなく、配列にどんな順番で入っているのか直感で分からないもんで、Closest Locationを使って都度取得するって事をやりがちな私です(^^;

法線については、ちょっとにわかには分からないので宿題にします(^^;

投稿: m4g | 2012年6月 9日 (土) 01時35分

>他のオブジェクトの情報を参照する時、他のオブジェクトの何処を参照するかを明示しないといけないわけで、
>他のオブジェクトの情報をBuild Array from Setで配列に入れて、それの何番目の要素を取得するっていう風にしたり、
>Closest Locationを使って、自分自身が、参照したオブジェクトの近傍の値を取得する、
>というような事を常套手段としてやるのだと思っています。

この感じというか、流れが体に染み付かないんですよ。なかなか。

いつも本当にお世話になります。ありがとうございます。足を向けて寝られません。

投稿: 潤樹 | 2012年6月 9日 (土) 22時56分

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 頂点上にパーティクルを発生させる。 その4。:

« 頂点上にパーティクルを発生させる。 その3。 | トップページ | 取得 その1001。 全ICETree/RenderTreeビューの取得。 »