署名500件達成AcombeeCom

英語のチュートリアルを日本語に訳すために立ち上げた会社「AcombeeCom」。
前年から、その実現に必要な署名を集めていたそうですが、締め切り4日前の今日、目標500件達成したそうです。
おめでとうございます。

締め切りまでは、署名集めは継続していくそうですので、まだの方は是非、がんばりましょう。

最初の日本語版が何になるか、楽しみですね。

　

メモ：mel link

http://edvardtoth.com/extras/mel-scripts/
http://mayasoup.blogspot.com/

パーティクル・エクスプレッションを作るときの思考手順（１）

エントリ「スクリプティング学習における第三の壁」で、プログラミング初学者の訓練で重要な事として「データ」に関する事を考えることが重要であることがわかりました。

（参照元：ブログ：毎日操縦不能「プログラミング初学者にはどうデータ化するかをしっかり訓練させる」）
初学者に教えるときには、
●最初と最後の状態
●各状態をどういうデータをもって表現するか
を大まかにつかませる、


この知識をベースに「個々のパーティクルの特性は何で決まるか？」で取り上げた内容「メモ：radiusPP = linstep(0,lifespanPP, age);」を再考してみます。


まず、「radiusPP = linstep(0,lifespanPP, age)」は個々のパーティクルのサイズを変えるためのものであることはわかります。


これを上記のルールに下がい「最初と最後の状態」を考えてみます。

パーティクル全体を一つと考えていては答えはみつからない。
「単体のパーティクルの最初と最後の状態」として考える必要がある。
「最初と最後」とはパーティクルにおいては「発生してから消えるまで」
その状態であるから、
（１）生まれたときの状態
（２）消滅するときの状態

今回の例ではサイズを変えているので以下のようになる。
●生まれたときは小さく
●消滅するときは大きく



ではつぎに、「各状態をどういうデータをもって表現するか」
これはすでに答えはでているが、radiusPPである。
しかしこれでは今ひとつ、納得いかない。

上記ブログ「毎日操縦不能」によれば、以下のように続いています。
それでも足りなければ一ステップの変化を追い、そこで必要な細かなパラメータやフラグを足す。

「1ステップの変化」とは「途中経過」であり、すなわち今回は
●徐々に値（サイズ）が増加する。
ということになる。

「必要な細かなパラメータやフラグ」というのは
●「変化率」の計算
●個々のパーティクルの特性を分ける値（「変化率」を変えるための値）
に関連している。

まず「変化率」を計算するには、
●徐々に変化していく値を算出する「linstep」

「個々のパーティクル特性を分ける」には
●存在時間をきめる「lifespanPP」


これらが徐々に変化するためにはステップ単位の時間が必要となる。
それを決めるのが
●時間上の現在地「age」
ということになる。



以上のことからパーティクルエクスプレッションを作るときの思考手順をまとめると
（１）パーティクル誕生時と消滅時の状態をどうしたいのかを決める。
（２）ここから操作すべきアトリビュートを特定できる。
（３）ステップ毎の変化を考える。
（４）それをどのように導くか考える（関数や計算方法）
（５）底に必要な値をどこから撮ってくるか考える。（アトリビュートなどの決定）


前よりはプロセスがはっきりしてきたように思いますが、まだ今ひとつな感じがします。


おまけ、
パーティクル単体に関連するアトリビュートを、大まかに分けて考えてみるといかの三つになる。

「位置」に関するもの：位置、方向、速度など、（position, velocity, accelerationなど）
「見た目」に関するもの：色、透明度、サイズなど（rgbPP, opacityPP, radiusPPなど）
「時間」に関するもの： 時間、寿命、発生時間など　（age, lifespanPP,birthTimeなど）
　　

Gradient EffectsのR&Dに見るMelのアイデア

VFXpro.comのJob掲示板で見つけたエフェクトハウス「Gradient Effects」。

この人材募集にきになる文がありました。
The Visual Effects business is dramatically changing. Smaller, experienced teams who can react quickly and communicate easily are becoming the norm.
（VFXのビジネスは劇的に変化しています。より小さい、素早い対応と容易なコミュニケーションができる経験を積んだチームであることがノルマになりつつあります）

最近、切実に思っていることでもあり、めずらしくポイントをついてくる会社だなと思い、どんなところかホームページをのぞいてみました。
http://www.gradientfx.com/

特にミュージックビデオ「Who's Gonna Save My Soul?」意外には、それほど有名な作品を手がけているようには見えませんが、（2012には関連しているようですが、ショット内容は不明）どちらかと中小プロダクションによくありがちな仕事内容ではないかと思います。


しかし、プロダクションのサイトにはめずらしく「Reserch And Development」というページがあり、しかもビデオでそれを解説しています。

それもとても興味を惹かれたのですが、特に「RigidBody System- Rigidbody Reserch」には、自分がやりたいと思っていたことが、ほとんどあります。しかも見た感じMaya上でやっているように見えます。
しかもJob掲示板で書かれていた考えを反映しており、企業自体の先見性や素早い行動力を感じさせ、経営者の考えがしっかりしているのではないかと思いました。

fxBulletSolver
*リアルタイム・リジッドボディー・ソルバー
*ユーザー定義のルールでアニメーションからシミュレーションベースへの切り替え
*安定しており、大量のリジッドボディーを操作可能
*サブレベルのリジッドボディーシステム
*クライアントの必要に応じたが調整可能（CとC++のソースコード）
*パーティクルとcfd（omputational Fluid Dynamics：計算流体力学）に作用
*GPL Bulletソルバー・ベース
*シンプルなMayaインターフェイス


ILM、ソニーやDDなどでは、もっと凄いシステムを作り出しますが、あまりにも自分のリアリティーとかけ離れています。

この会社のシステムは、それにくらべると見劣りするかもしれませんが、まだ理解しやすく、リアリティーがもてます。
とくに、サブレベルリジッド・ボディーは、自分でももう少し頑張ればできそうな気がします。
（気がするだけです）
アニメーションとシミュレーションの切り替えが簡単にできるのもいいですね。
もちろん、MelではなくAPIレベルでの開発ですが、処理速度は別としても、Melでも工夫すれば似たような機能を持たせることができるのではないかと思いました。

ベースとなっている物理シミュレーション・エンジン「Bullet」は映画「2012」でも使われましたね。


５～６年前は、PCのスペックと数が、生み出されるCGの成功に大きな役割をしていたように思いますが、これからは、リアルタイム性をもたせたシステム（最新ハードとソフトの連携）が必須ですね。

実際、BlastcodeはPhysx対応してますし、3dsMaxのreactorはHavok3.2ソルバ対応、RayFireToolsもPhysx対応。


まだそれほど踏み込まれていないのは、レンダリングとフルイドのエリアでしょうか。


次期バージョンのMayaは、是非Physx対応、DirectX対応でリアルタイム・レンダービューを実現してほしいです。
もしくはどこかRayfireのようなプラグインを開発して欲しい。
個人的にはRealFlowが対応してくれるとかなり嬉しいです。

特にスピードが必要とされるTV系には必須でしょう。
実際、ゲームなどのリアルタイムレンダリングもかなり質が向上しており、TVでモーションブラーかけまくりのシーンなどはプレイブラストでOKではないかと思うほどですｗ


それでも、ZoicやImageEngineでのNukeの使われ方を見ると、3Dの出番は少なくなっていくような気もします。
Nukeも3Dの需要があるならますますその部分の機能を強化するでしょうしね。
そのうち、3D側ではライティングとレンダリングはほとんど不要になるかもしれませんね。

しかしながらソフト更新もできない、先見性のあるプロデューサーがいない、体力（財力）のない弱小プロダクション（うちのことですが）では、そういったシステムを使えるプロジェクトがあり、かつコストの採算がとれなければ導入することはありません。
このような状況では、無料のシステムもしくはお試しで一度か二度つかえるものがないと検証も出来ません。
検証ができないと、そのシステムのノウハウもたまらないわけで、そうなるとますますR&Dなどに財力を避ける会社に置いて行かれるような気がします。
（そう考えると、うちは本気で危ないな・・・。）



VFX系で生き残るには、時間削減してコストを削減していくしかないようで、そうなるとアーティスト側の仕事は減っていくのは確実なように思います。

今回の不況もすぐには解消しそうにもないので、こういったシステムが一般化するまで十分時間はありそうです。
一度、一般化すると、不況が改善しても後戻りはしないでしょうから、プロデューサー以上の経営者サイドは得をすることはあっても使い捨てのアーティスト・サイドは不況が改善しても何も、状況は変わらないと言うことになるのではないかと思います。

しかも、海外の税優遇措置で仕事をとられ、さらに状況は切迫してきているように思います。
　　

スクリプティング学習における第三の壁

第一の壁：なにもできない状態。
これを突破して初めて、スクリプトを使って何が可能なのか、わずかながら見えてきたように思う。
この壁を越える前までは、何をやりたいのかも漠然としてわからなかったが、壁を越えた後は、
仕事をしていても、それをスクリプトを使ってやるにはどうすればよいかと考えられるようになった。
（もしかしたら第一の壁以前に、もうひとつ壁「スクリプトの学習に抵抗がある」があったかもしれない。）

第二の壁：なにを勉強して良いかわからない
ここでは、なにを目的にして勉強すればよいのかが、みえなかった。
何を勉強しても良いのだが、興味が無いことを勉強するのは苦痛であり、興味があるところをさがそうにも、まだ問題意識が薄く、具体的な何かに興味を特定することもできないでいた。
自分の場合は、仕事で、あるスクリプトを書いたことがきっかけで、GUIの必要正を認識したことが興味を駆り立てることにつながり、それを勉強したことが突破口になった。
また、若干の経験がたまってきたので、ヘルプファイルを理解することができるようになってきた。
そのため、曖昧だった知識を整理し、明確にすることが出来るようになった。
また、情報の調べ方にもなれてきた。
そのためコマンドを知らなくても、調べればなんとかなるのではないかと楽観視できるようになってきた。




----------------------------------------
ここまでで、基本的なスクリプト作業ができるようになった。
まだコマンドのボキャブラリは少ないが、
●ヘルプファイルの活用方法
●スクリプトの検証方法
がわかりはじめたので、知らないコマンドでもある程度の時間をかければ使えるようになるという感じを持っている。


では、この次に待ち構える第三の壁は何かを考えてみた。


第三の壁：実際に活用したり、完結したスクリプトができない。
ここまででスクリプトの基本、そしてパーツとなるいくつかのコマンドは理解できた。
どんなスクリプトを作りたいのか、基本的なアイデアはなんとかもてるようになってきたので、そのアイデアを実際にスクリプトにしてしまう過程を習得する必要がある。
しかしながらパーツを組み合わせて何かを構築していくという技術はまだまだ未熟であり、
ちゃんと動く物をつくるのにも時間がかかるし、挫折することも多い。
しかしこの壁をクリアするのはさほど難しくないと思う。
まず「やりたいこと」を見つけ、
それを「スクリプト」にする。
これを２～３回行うことで自信につなげることが出来ると思う。
ここまでできれば自分は、「スクリプトをやる」とResumeに書いても後ろめたさは感じなく低良いだろうｗ。



----------------------------------------
前回のエントリ「個々のパーティクルの特性は何で決まるか？」では、個々のコマンドや関数、そしてその使い方を暗記するのではなく、それを使う根底にある考えをさぐり、普遍的な要素を抽出することを試みた。
そうすることによって、スクリプトにおける考え方をみにつけようとした。

スクリプトを構築していくときに「時間」、「サイクル」と言ったキーワードをコマンドや関数の代わりに用いることで、考えを整理する。
そして、スクリプトの考えがまとまったところで、そのキーワードに沿ったコマンドや関数と入れ替えていくという方法をとってみてはどうかと考えた。
ようするに考える段階では具体的なコマンドや関数を出来るだけ用いないで自然言語で考える方法である。

これは、自分でもまだあいまいなところがあるのだが、あるブログでこれに似た興味深いエントリを見つけたので引用したい。


ブログ：毎日操縦不能「プログラミング初学者にはどうデータ化するかをしっかり訓練させる」
アルゴリズム以前に、考えているものがどういうデータでできるか、という部品のところを考えること。
初学者には、アルゴリズムの問題よりも、どういうデータが必要かということは結構考えつかない。

（略）・・・必要なデータが何かを書き留めて整理しながら書くと楽になる。

初学者に教えるときには、
●最初と最後の状態
●各状態をどういうデータをもって表現するか

を大まかにつかませる、

それでも足りなければ一ステップの変化を追い、そこで必要な細かなパラメータやフラグを足す。
さらに方向を変えて、人がそれを実行する場合にはどうするか、自然言語でアルゴリズムを伝え、どういうデータをいじるかをこれもまた自然言語で伝える。
あとはコードの書き方のコツなどを加え、そこで必要なデータや、うまくコードを回すためのデータとその使い方に触れる。
ここまでやると大抵の場合は、もうほとんど答えとなる。

これを読むと、前回の、着眼点は間違いではなかったように思う。
特に上記で箇条書きにした部分は、現段階では重要に思う。

「最初の状態」とはスクリプトを適用する前の段階で、
「最後の状態」とはスクリプトが実行された後の段階
のことをさしていると思う。
ようするに「何がやりたいかということを明確にする」ということとイコールだと思う。
そして「それぞれの状態」を実現するために必要な「データ」が何かを明確にするということは、「スクリプトで操作する対象をつきとめる」こととイコールだと思う。



また以下のページはプログラミングの流れについて、重要なステップを書いているが、これも上記のアイデアに似ている。

情報通信ベンチャー支援センターの「ソフトウェア著作権関連判例集」ページにある
「■技術的な背景」
プログラムというものは，何か特定の仕事をするために作られるものである
プログラム製作の第１段階は，プログラマーが解決すべき問題は何かということを見つけだすこと

プログラマーが問題をよく判るようになるにつれて，段々に解決法をおおまかに描けるようになってくる。

プログラムの構造が洗練されてくるに従い，プログラマーが決定しなければならないものとしては
●どういうデータが必要か
●プログラムの操作手順のどこでデータが入れられるべきか
●データはどのようにインプットされるべきか
●それが他のデータとどう一緒にされるべきか
といったことなどがある。

コンピュータ・プログラムを作るに際して，もっと費用と困難さを要する部分は，プログラムの構造と論理を開発する部分であり・・・（以下略）


どちらにしても先が少し見えてきた気がする。
　　

ジェームスキャメロンの言葉

やっと昨日アバター（IMAX）を見に行った。
平日の昼間、しかもバケーション空けなのでそれほどいないかと思ったが、ほぼ満席状態。

しかしながら購入したミネラルウォータが合わなかったのか、始まって10分ほどで猛烈な腹痛におそわれ、映画どころではなくなった。
体温が急激に下がり、自分でも顔が白くなって冷や汗がでてるのがわかるぐらい。
とりあえず、貧血を起こさない程度まで復活するのを待ってトイレ直行。
復活できたが、ジェイク（アバター姿）が最初にネイティリの部族と接触したシーンからはじめてネイティリが乗るバンシーに出会うところまでは、見逃してしまった。

やっぱり３Dでみると見え方が気になって、ストーリーに集中できない部分があった。
なんとか集中できても、スピードが早い動きが、フリッカして見えて、注意が取られてしまう。
それに2時間をすぎると鼻のあたりが痛くなってきて、眼鏡をかけているの苦痛になる。
自分には眼鏡式の３Dは長時間はむずかしいと感じた。
今、コンタクトレンズを使っているのも眼鏡を使うと耳や鼻が痛くなってくるからだ。
同じ理由でヘッドフォン、イヤフォンもだめ、従ってiPodももってない。

ストーリーはともかくCGは、すばらしかった。
未だCGの領域を脱し切れていないという批判も見たことがあるが、それでもいままでのCG作品に較べたら時代をひとつ先へ進んでいるように感じた。
モーションキャプチャもすばらしく違和感をあまり感じなかった。
ジェームスキャメロンがクローズアップの質感を出すのにこだわったというだけあってフェイシャルキャプチャーもすばらしい。
ただ、どこかでそのままのデータを使うだけでなく調整は当然必要、手付けによるアニメーションの調整も行われたということは読んだことがある。
（ジェームスキャメロンはすべてのデータをキャプチャーしたといっているが、アニメーターは手付けでやっていると言っているどちらが正しいのか？　答え：どちらも正しい　といった内容だった）
本当にすべてCGで作られているのか？特殊メイクを使っているのではないかと疑問に思うほどだった。
すべてがCGだとすれば、皮膚の質感、目の表情、細かな皮膚の動き、表情筋の動きどれをとってもここまでのものは無かったと思う。

しかしながら、これを実際の人間に使っていたらやはり不気味の谷を出ることはないと思う。
ナヴィの異星人だからこそ、不気味の谷を感じにくかったのだろう。

また、バンシーをはじめとする数々の生き物もよく作り込まれており、本当に生きているような感じを出すための質感や、細かな肉の震えやめくれ上がりといった細かな演出がすばらしい。
もうどんなセットアップをしているのか想像もつかない。
生き物相互のインタラクション、水や細かな灰や砂粒とのインタラクションもすばらしいかったが、皮膚表面のパーティクルとのインタラクションに関しては、あともう一歩なにか欲しいという感じはした。
皮膚のテクスチャーもかなり良かったが、きれいすぎるのか若干CGっぽさを感じる事はあった。

どこまでがCGでどこまでがミニチュアかわからないが、ジャングルの描写はすばらしい。
細部まで気を遣って作られており、空気感を感じられるほどリアルだった。
巨大な木は、RPGのウォークラフトを思い出した。
コンセプトアートでよく異世界を描いた物はある。そしてそれを映像にした物もある。
しかしながら、コンセプトアートの領域をこえて空気感まで伝える物は記憶にない。
アバターはそれを達成していると思う。

難を言えば、アバター公開前の広報活動が、大げさすぎたと感じる。

----------------------------------------
さて、ジェームスキャメロンのアバターに関するインタビューは今やいろいろなところで目にするようになったので、いくつか気になったところをまとめておこうと思う。

（堀　公夫氏によるブログのエントリ「【NO.2832】３Ｄ映像がビジネスを変える」より）
「技術は、いくら新しかろうと、ユニークであろうと、それ自体は世の中において何の価値も存在意義も無い。
新しい、ユニークな技術が世の中において価値や存在意義を生み出すのは、該当技術の使い手（価値創造者）が、該当技術のみが醸成できる問題解決とその先にある感動を信じながら有形無形のモノづくりに命を賭けて打ち込んだ時である」 by ジェームスキャメロン

これが今Melを勉強している理由であり、CGの技術を苦しみながらも向上させていく理由なんだなと思いました。
しかし「タイタニック」作成後に公言したことを、実現するために着々と10年もの月日をかけて、開発をすすめていたんですね。
会社を持っているとはいえ、その間に作品を作っていないので、すべて自社からの出費だと思いますが、「タイタニック」で成功してなかったらあり得ませんね。
今思うと、「Ghost of Avys」などの3D作品は、アバターのための布石だったんですね。
しかし慣性までに12年とは．．．、信念と人間に対する深い造詣がないと続けられないですね。



（クローズアップ現代「3D映像がビジネスを変える」）
NHKのクローズアップ現代「3D映像がビジネスを変える」の全ダイアログです。


（「本誌特集でジェイムズ・キャメロンとの12年の空白、埋めてください」）
「ＳＦというのは、人間であるということがどういうことかを認識させるジャンルである」がキャメロンのＳＦのひとつの定義

ああ、なるほど、Alien2はそういうことかと納得出来ました。


（【映画業界研究】俳優は不要？ キャメロン監督新作『アバター』の全貌に迫る）
日本で今年9月に調査した結果、日本人は単なる戦闘シーンにはあまり感動せず、『よくあるCGの戦闘シーンでしょう』という反応を示すことがわかってきた。
日本人にとって大切なのは、戦闘ではなく、戦闘に至る理由。なぜ、主人公が戦い、なぜ悩んでいるのか？　そうした説明があると、すごく興味を持っていただけるんです。

中瀬氏が大切にしているのが、こうした物語を伝えることだ。「先ほどもお話しした調査の際に、映像を10代～50代に見せたんです。彼らの反応で共通していたのが、物語設定を説明したら、多くの方がものすごく見たいと仰ってくれたこと。

「アメリカ本社のインターナショナル部門も、他国とは異なる日本の特殊性を理解してくれている」


ジェームスキャメロンの言葉ではないですが、日本の特異性を語っています。
ジェームスキャメロンの「バトルエンジェル」をはじめ、多くの映画制作者が日本の漫画やアニメに注目しているのは、やはりこのストーリー性なのでしょうか。

幼少期から絵本に親しんだり、良質のTV番組も多かったこともあげられると思います。

また、マンガ文化で、大量のマンガの中で生き残れるのは良質のストーリーを持つ物だけなので、作家側は良質のストーリーを作る事を心がけ、見る側も良質のもに触れる機会が多い。
そしてそれらが、Tvドラマの制作側や見る側にも影響しているとも言えるかもしれない。


絵本なども日本語に訳される物は、多く、種類も豊富に思います。
ちなみにこちらで日本だと普通に発売されている「イエラ・マリの絵本」も、こちらでは一部しか出版されておらず、見つけるのはかなり苦労しました。
また四季の差を感じる事から普段から感情を刺激される部分がおおく、わびさびといった微妙な変化を大切にする文化も影響しているのかもしれません。


これに関して、Wired Visionの「米国でも『少年ジャンプ』が人気」を書いた著者も同記事の中で、以下のようにのべている。
映画関係者ではなくてもストーリー性の差は、明確に感じ取っていることがわかる。
記事の内容からすると、子供も例外ではない。

筆者は、辛抱しながら数号を読んだところ、すぐにストーリーがかなり見事だということに気がついた。
友情や、悪役の複雑な性格描写などを楽しんだ。ところどころにはすばらしい絵が描かれている。ワイルドなコンセプトも気に入った。

　　

個々のパーティクルの特性は何で決まるか？

昨日のエントリ「radiusPP = linstep(0,lifespanPP, age)」は、今ひとつ要点を得なかった。
なぜ、パーティクルにスポットを当ててみようと思ったのかもう一度考えてみた。

１）パーティクルの動きを予測してエクスプレションを作れるようにする。
２）パーティクル・エクスプレションの汎用的なエクスプレッションを知る。

この二つができれば、いろいろなエクスプレッションを、文字通りメモしたり記憶するのではなく、「そのエクスプレッションを作るための考え方」を身につけることが出来る。


----------------------------------------
まずデフォルトのエミッタ１つ作り、フィールドを使用しないシーンで考えてみる。

パーティクル・エクスプレッションでは、リアリティーを追求するときは、パーティクル単位アトリビュートにエクスプレションを使う事が増える。

的確なエクスプレッションを作るには各パーティクルの動きがどうなるのかを予測する必要がある。
しかしながら実際のエミッタからは大量のパーティクルが様々な方向へ発生し続けているため、とらえどころのない感情におそわれ混乱してくる。


まずこの感情を克服するには、すべてをシンプルにしていく必要がある。
シンプルな物は理解しやすい。


エミッタからは次々と新しいパーティクルが生み出されており、シーン内では、それがすでに生み出されたパーティクルと混在している。

「このパーティクルが生まれて3秒でこうなって．．．。」「このパーティクルが生まれて1秒で」などと頭の中でトラッキングしていると考えることが多すぎてすぐに混乱する。

エクスプレッションを使ってやりたいことは「パーティクルをよりよくコントロールすること」である。


まず沢山のパーティクルがある状態では、各パーティクルの動きを完全には把握することができない。「把握できない」と感じるなら、「コントロールできない」と感じても当然である。
まずここをシンプルにすることが役に立つ。

一番簡単な方法は、シーンそのものをシンプルにする方法。
●パーティクルが放出される方向をDirectionalにして一方向にする。
●放出されるパーティクルを少なくする。「rate」にキーフレームを打つことで可能になる。
●それでも駄目なら放出されるパーティクルを１つに絞る。

慣れない内は上記の方法をとるのが良いだろう。


----------------------------------------
では、大量のパーティクルが存在し、それを上記のような状態に変えたくないときはどうすればよいか？
ひとつは上記の方法をとったR&D用のシーンファイルを作成する。
もう一つは、頭の中で整理する。


まず基本的なことから考えを整理してみる。
●まず自分がやりたいことは「パーティクルのコントロール」である。
●そしてそれは、「パーティクルが画面内に存在する」から、コントロールできるのである。


ここでカギとなるのは「パーティクルが画面内に存在している」ということだ。
いいかえれば発生してから消えるまでということになる。

「発生する」のは、タイムライン上のタイミングでみると個々のパーティクルによって様々である。
これを整理するために、
１）発生したフレームを「１」と考える。
２）発生フレームをタイムライン上の「１」にそろえて考える。

これに加えて、以下のように考える。
●すべてのパーティクルの移動方向を同一にする。
いいかえれば、「パーティクルの放出方向をDirectionalにして一方向にする」のと同じ事。


こうすると、それぞれのパーティクルを比較検証できる。
Lifespanがコンスタントで、他がデフォルトであれば、すべてのパーティクルが同時に出現し、同じサイズで、同じ方向へ、同じ速度ですすみ、同じ時に消えるはずだ。
・・・・・・・●



----------------------------------------
さて、各パーティクルにユニークな特性を持たせるには、それぞれがユニークなアトリビュート値を持つ必要がある。

それを簡単に行えるようにしたのが「パーティクル単位アトリビュート」だと思うのだが、
例えば以下のような物がある。
position　：位置
velocity　：位置
acceleration：位置
rgbPP：見た目
opacityPP：見た目
radiusPP：見た目


右側に書いたのは、それぞれどのようなものに影響しているかということだが、大きく分けて
「位置」
「見た目」
に影響する物に、分けられる。

これらに手を加えれば、各パーティクルに動きや見た目の変化が生じるはずだ。

でも他に、各パーティクルのユニークな物と特徴付けるものはないか？
各パーティクルの特性を決めるが、使っても動きや見た目の変化を生じさせないで、基本的な要素として役に立つようなもの。

パーティクルIDは各パーティクルを示しているが特性をユニークにする物ではない。

ここで思い出したいのが「パーティクルの存在」とはなんであったかということである。
「発生してから消えるまで」
ようするに寿命である。
LifespanPPは、ランダムに設定すれば個々のパーティクルがそれぞれユニークな値を持つことになる。
これが各パーティクルの特性を決めることになる。
簡単に言えば「特性」は「寿命」によって分けられる。


これがLifespanPPがいろいろな面で使われる理由と思われる。
見た目や動きに変化を与えず、放出された時点で各パーティクルへユニークな特性を付与する。

これをベースにさまざまな、パーティクル単位アトリビュートをコントロールすれば、それぞれの特性にあった変化を持たせることも出来る。
そして同じLifespanPPの値を用いるので、ひとつのパーティクルにおける様々なパーティクル単位アトリビュートの変化を統一させることが出来る。


----------------------------------------
ここから導き出されるシンプルな考え方がある。
パーティクルが変化するエクスプレッションを作るとき、時間ではなく「放出されて消滅するまで」のサイクルで考える方法である。

個々のパーティクルはそれぞれ寿命は違うが、ライフサイクルとして考えた場合はどれも同じである。
birth(誕生）--- exist（存在） --- Die（死）
ここでは時間の単位は考慮する必要がない。


したがってそのサイクルの中の変化だけを考えそのエクスプレッションを作成し、
後で、各パーティクルの違いを生み出すためにlifespanPPを使うようにすると良い。

LifespanPPは
●値をランダムにすれば、各パーティクルの特性をユニークにする。
●「消滅」の時を、あらわす。



昨日の「radiusPP = linstep(0,lifespanPP, age)」の各要素を考えてみる。
１）時間が経つにつれて変化することに関係：　「linstep」 「age」
「linstep」だけでは機能しない「age（秒）」を使う事で時間という概念が取り込まれる。

２）個々のパーティクルにユニークな特性を持たせることに関係：　「lifespanPP」「rand」
「lifespanPP」だけではすべてのパーティクルは一様である。
「rand」を使ってその値を指定することで、各パーティクルがユニークな物になる。

すべてのパーティクルサイクルを同じと考える場合、lifespanは任意の物でよい（例えば「１」）
radiusPP = linstep(0,1, age）
これにより生じる変化で特徴をつかむことができる。

あとは、この時間が延ばされるか縮められるかのちがいだけとなる。
そしてそれは、この「１」を「lifespanPP」に置き換えるだけでよい。


lifespanPPの数値（秒数）は、
「パーティクル毎の特性を決めるための数値」
「消滅時の状態の数値」
として使う事が出来る。

また、あるパーティクルに対する様々なアトリビュートに対し、「同一の変化率を持たせたい」ときにも使える。（たとえばパーティクルID２４のパーティクルのサイズと透明度、加速度などに同じ変化率を適用する場合）


これはよりエクスプレッションに着目する場所がわかりやすくなるのではないかと思う。


※　経験が少なすぎで今ひとつ、まとまりきれません。
強引なところがあると思いますが、今回は、これでとりあえず終わりにします。