X-Particlesについて

[tofuji]

　X-Particles 2.0を使ってみました。以下に要点を書きます。

1.　X-Particlesのサイトは以下の通り。
http://www.x-particle.com

　私が翻訳した日本語リソースは以下の通り
http://www2.11moon.com/xparticles/062/strings_jp.zip


2.　X-ParticlesはThinkingParticlesより簡単か。
　「オブジェクトの表面からパーティクルを出す」といった、標準機能だけで表現できることなら確かに簡単にできます。

　しかし、「オブジェクトが衝突した位置からパーティクルを出す」といった、外部との連携が必要な表現になるとThinkingParticlesより難しくなります。
　理由は、TPが初めからそういう使い方を前提として「XPressoの中で一元的に組んでいく」のに対して、
X-Particlesでは、「外部からの情報を取得するXPresso」と「XPressoとの連携ができるように組んだX-Particles」を連動させる必要があり、
どこで何が行われているのかを把握するのが困難になるからです。

　X-Particlesの中にはPythonが組み込まれているので、XPressoの中でやっていることを全部Pythonで書けばX-Particlesの内部で作業を完結できます。
しかし、これはこれでThinkingParticlesより格段に難しい作業になります。


3.　X-Particlesの標準機能だけでどこまでできるか。
　X-Particlesには非常に多くの機能が入っているので、標準機能だけでいろんなことができるのは事実です。
　しかし、外部（つまり、普通のオブジェクトやMoGraphやTPなど）と連携させる場合には、上のような困難が発生します。

　そして、私の経験で言うと、仕事の種類にもよるでしょうが、外部との連携なしで表現できる仕事は一割以下です。


4.　X-ParticlesのThinkingParticlesに対するアドバンテージ。
　現在CINEMA 4Dに搭載されているThinkingParticlesは10年以上前に開発されたものです。XPressoも十年以上変わっていません。
　それに対してX-Particlesは新しいので、この十年間にでてきたいろんな機能や考え方や表現方法を取り込んでいる、というのが一つのアドバンテージです。

　もう一つ、標準機能に関してX-Particlesはエクスプレッションに依存していないので、ThinkingParticlesに比べて桁違いに速く動きます。
これは明確なアドバンテージなので、XPressoを連動させる場合でもパーティクルを一個一個XPressoに通すのではなく、
エミッタやモディファイアを通して間接的に連動させるのが正しい使い方だと思います。

　
5.　X-Particlesの流体に関して。
　X-Particlesに入っている「流体」は擬似的なもので、本質的にはソフトボディに近い働きをします。

　しかし、RealFlowのようにマジメにやれば簡単にリアルな流体が作れるという訳でもないので、
これはこれでいいと思います。

　むしろ、ThinkingParticlesに比べて多くのパーティクルを置けることと、優秀なメタボール機能が付いていることのほうが、
液体を表現する上では重要だと思いました。

　ただし、それでもRealFlowのような「きれいな水」を表現するのは無理です。
技術的には「表面張力」が考慮されていないからなのですが、サンプルにもあるように「お好み焼き」風の流体になります。


6.　X-Particlesで気体（炎）を作れるか。
　炎を表現するには、パーティクルよりシェーダのほうが重要なのですが、X-Particlesには炎を表現するためのシェーダは特に入っていないので、
PyroClusterやヘアに依存することになります。そのために、X-ParticlesにはThinkingParticlesを生成する機能があります。

　ここら辺もう少しがんばってほしかった。


7.　X-Particlesはどんな表現に向いているか。
　液体や炎を表現できないので、フォトリアルな方向では使えません。
　
　その代わり、内部にいろいろな機能がついているし、標準機能でもある程度は外部の機能やオブジェクトと連携できるので、
MoGraphと同様、CINEMA 4Dの標準機能を生かす方向で、モーショングラフィックに使うのが一番合っていると思います。

　実際、トレーサーのように軌跡をスイープNURBSに入れることができますし、X-ParticlesをCINEMA 4Dのダイナミクスで解析することもできます。
また、MoGraphのクローンからX-Particlesを出したり、X-Particlesをクローンに衝突させることもできます。

　また、X-Particlesの標準機能を使わず、ThinkingParticlesのようにほとんどをXPressoの中で組んでいくことも（おそらく）できます。


8.　X-Particlesを買うべきか。
　X-Particlesは現在35000円ぐらいです。

　R11まではBroadastでThinkingParticlesを使えたのですが、R12以降はStudioを買わないと使えません。
そういう意味で、Broadcastを使ってモーショングラフィックをやっている人は買うべきだと思います。

　X-Particlesはかなりの機能がMoGraphとかぶりますが、逆にMoGraphが解っていればX-Particlesを使うのも楽ですし、
組み合わせて使えるケースも多々あると思います。


　これに対して、Studioを使っていてかつTPを使えている人は、すぐにX-Particlesを買う必要はないと思います。
X-Particlesを購入したのにThinkingParticlesを止められない、とか余計面倒になった、というケースもあり得ると思います。
　しかし、物量的、機能的な理由で現在のTPに限界を感じているのなら、X-Particlesを使うことでかなり改善されるでしょう。


　また、Studioを使っていて、TPを使えていない人は、次の点を考慮した上でX-Particlesを買うようにしてください。

8a.　総合的に、X-ParticlesはThinkingParticlesより難しく、当然MoGraphより格段に難しい。

8b.　したがって、ThinkingParticlesを使えない人がX-Particlesを購入しても使いこなせない可能性が高い。

[tofuji]

　X-Particlesのサンプルです。

http://www2.11moon.com/sample_files2013 ... 31/net.mp4
http://www2.11moon.com/sample_files2013 ... 31/net.zip


　X-ParticlesはMoGraphのクローンから簡単にパーティクルを出せますが、パーティクルであるが故に「出続けてしまう」ので、
クローンの位置にパーティクルを留めておこうとすると、結局XPressoを使って二つの操作を追加する必要があります。

1.　パーティクルの数をクローンの数に合わせる。

2.　パーティクルの位置をクローンの位置に合わせ続ける。


　しかし、MoGraphのトレーサーでは全てのポイントをつなぐことができません。
　また、ThinkingParticlesを使ってポイントをつないだとしても、こんなに速くは動きません（スプラインのポイント数は15500個もある）。

　というわけで、X-Particlesは強力だ。しかし、結局何をするのにもXPressoは付いて回る、ということでした。

[tofuji]

　
　X-Particlesについてさらにいじってみたところ、予想外に使えないことがわかりました。

　例えばThinkingParticlesを使うと次のようなシーンを20分程度で作ることができます。
http://www2.11moon.com/sample_files2013 ... ision3.mp4
http://www2.11moon.com/sample_files2013 ... ision3.zip

　典型的な「衝突した部分からパーティクルが出る」という表現です。


　しかし、X-Particlesでは以下のような理由からこれに相当するシーンを作ることができません。
回避策を探して2日間がんばりましたが、諦めました。

　X-Particlesは貧弱なコアの上に見かけ倒しの機能を乗せたものなので、標準機能以上のことはできません。
それに対して、ThinkingParticlesはコアがしっかりしているので、使う人間の腕次第でいくらでも拡張できます。

　今まで当たり前のようにThinkingParticlesを使ってきましたが、そのすごさを再認識しました。
これを作ったEdwin Brownは本当に天才だと思います。


　X-Particlesが使えない理由。

1.　理由は不明だが、リング状に拡がるパーティクルを作れない（標準パーティクルでさえできるのに）。
http://www2.11moon.com/sample_files2013 ... 4/ring.mp4

　リング状のオブジェクトの表面から発射すれば可能だが、パーティクルを分裂させる場合にはこの方法が使えない。
　

2.　パーティクルにマトリックスがない。
　つまり、パーティクルに縦横高さがあるオブジェクトを乗せた時、その向きを指定できない。球以外乗せるなと言うことか。
　おそらく処理を軽くするために省略したんだろうが、だったらオブジェクトを乗せる機能も省略すべきだ。

　このサンプルでは、パーティクルが拡がる方向を指定できない（ある程度の回避策は存在する）。


3.　パーティクルにユーザデータ（TPのデータチャンネル）がない。
　つまり、ある特定のパーティクルにオブジェクトを乗せることができない。
　インデックスを指定してオブジェクトを乗せた場合、同じグループのパーティクルが寿命等で消滅するとインデックスが変化し、
オブジェクトがジャンプして見える。


4.　エミッタが1フレームで一回しか働かない。
　ThinkingParticlesではエミッタがXPressoの中に入っているので、繰り返しノードを使えば1フレームで何回でもエミッタを働かせられる。
しかし、X-ParticlesではXPressoから出してオブジェクトにしてしまったため、一回しか働かない。
　つまり、そのままではパーティクルを分裂させることができない。

　この問題を解決するためにX-Particlesでは内部に分裂する機能を持っているが、当然その部分をXPressoで制御することはできないし、
標準で用意されているオプションも少ない。


5.　同じ理由から、X-Particlesでは「フレーム遅れ」や「エラー」が頻発する。
　例えばThinkingParticlesでは、次の全ての処理をXPressoの中で1フレームで実行できる。

　a.　衝突点の数を調べ、その数だけパーティクルを生成する。

　b.　生成したパーティクルの位置を衝突点に移動する。

　しかしX-Particlesでは、a.の後半の処理（生成）を、XPressoの処理が全て終わってからX-Particlesの中で実行する。
つまり、b.の処理が行われる時点ではパーティクルが生成されていないので、位置を変更できない。

　多くの場合は、次のフレームでb.の処理が行われ、これが「フレーム遅れ」となる。
また、次のフレームで衝突点の数が変わっていた場合、パーティクルの数と合わないので「エラー」となる。


　他の部分はまだ調べていませんが、これだけダメな部分があると、他の部分がいくら優れていても仕事には使えないと思います。

[tofuji]

　上記の点についてX-Particlesのメーカーに問い合わせてみましたが、基本的に「できない」ということでした。

　詳細は、X-Particlesのユーザーフォーラムに書いてあります。

http://www.x-particle.com/forum/viewtopic.php?f=4&t=159

[tofuji]

　X-Particleについてその後進展がありました。

　あるユーザによると、TPの「PBorn」等に相当するノードを「Python」ノードで書けば、XPでもTPと同じことができる、ということでした。

　そんな面倒なことをしてまでXPを使う理由はないので、私はやりませんが。