« 起動画面。 | トップページ | Making of 花火。 c02。 Comp。 »

2011年10月20日 (木)

Making of 花火。 c02。 ICE / RenderTree。

先日のパーティキュラー花火大会へ出した作品の、技術解説を書きたいと思ったんですよ。

いや、別に誰かにリクエストされたわけでもなんでもないんですけどね。
俺が勝手にやりたいだけ。



でも書き出してみたら、なんだかすんげえ大変で。
どこまで続くかわかんないけど、ひとまず気分で、書けた部分から出して行きましょう。



あ、言っておきますが、すごく高等なことをやっているわけでも、画期的なことをやっているわけでもないですよ。なんせ ICE の練習くらいのつもりで始めましたから。 しかも最後には練習という意図もどこへやら、もはやただ完成させることしか考えていませんでした。 誰にも頼まれていないのに、勝手に自分でやると決めて作り始めたんだから、完成してコンテストに出さなきゃもったいねえ! って、ほんと、最後はそれだけを考えてました。 

マトモにやったら間に合わなくなることがわかったので、完成させるためならということで、ICE の練習や研究になっていようがいまいが、ともかく誤魔化してデッチ上げるという感じになってしまったので、以下の技術解説も 「結果的に俺はこんなことをしていたようです」 という色が強いものになっているかもしれません。

まあいいや。 ともかく今回の花火作品の、ICE 関連や AE 関連について、書けるだけ書いてみます。










まずは、カット2の話を。これが一番最初に作ったカットでした。 
あ。そういう言い方は微妙だな。

「一番最初に作った素材が、結果的に c02 になりました」という方が正確です。 


このカットのビューポートキャプチャはこれです。


そしてこのシーンはこんなにシンプルです。
Xsiscreen

クリックで、でかい画像が別ウインドウに出ます。

エミッタになるヌルがひとつ、Point Cloud がひとつ、あとはカメラだけ。 ほんと、それだけのシーンです。ライトすらない。




### ICE編



ICEツリーはこのようになっています。
Ice_all

クリックで、でかい画像が別ウインドウに出ます。



上のICEツリー画像で、1の部分がエミッション関係ですね。

2が最初に発射されるパーティクルです。つまり、放射状に広がっているメインの玉です。このメインの玉が、Spawn Trails でトレイルになる小さい玉を産み続けます。

3が、そのトレイルですね。

1のエミッションによって2のメイン玉が発射され、そして2のメイン玉は寿命が尽きるまで3のトレイルを発射し続けているという構造になっています。 まあ、普通の構造だと思います。たぶん。




ではひとつずつ。

●エミッション部分

なんてことはない、ヌルをエミッタにした、普通のセットアップだと思います。Emit From Null コンパウンドを利用しています。
Ice1

エミッションシステム、つまりパーティクルの誕生ルールのシステムを、ゼロから自作するのはまだ俺にはできません。でもきっと、いずれやらねばなりません。標準のエミッション系コンパウンドに縛られていると未来はない、と感じています。 発生の場所、タイミング、その他、このコンパウンドに各種コンパウンドを突っ込んだだけだと、100%思い通りにはなりません。

例えば、どの位置で、何フレーム目に、いくつパーティクルが発生して欲しいか、あなた100%正確にコントロールできますか? このグリッドの表面において、、ぴったり1ユニットずつ間隔をあけた位置で、12フレ目に、それぞれの位置から1個だけパーティクルを発生させる、とか、できますか? 少なくとも標準コンパウンドじゃできない気がするのですが、どうでしょうかね? だから自作するしかないのかなと思っているのですが、エキスパートの方、どうでしょうかね?


まあともかく、順に見て行きましょう。 あ、大したことやってないので期待しないで下さいほんとに。 大したことを見たい方は、恋タローじゃない鯉タローじゃない、ええと、リタローさんのところへ行って下さい。

まずは Emit From Null コンパウンドの PPG を見てみます。
Ice1_em

ここが全ての始まりですね。


・発射頻度/数

Aは、Total Nuumber of Particles というモードになっています。いっぺんにこの数のパーティクルを出せというモードですね。 なので、Bで Rate を 3500 と指定しているので、シミュレーションの頭で 3500 のパーティクルを1回発射しておしまいです。

ここでいきなり質問ですが、このモードで、複数回発射することはできるのでしょうかね?  ぴったり1秒おきに、正確に100個ずつ発射、とかそういう風にコントロールしたいんですよね。でもこの Total Nuumber of Particles って、1回しか発射できませんよね? このコンパウンドの一番上、Enable のオンオフをアニメーションすることはできますが、オフにしておいてオンにすると、そのタイミングで1回、Rate で指定した数のパーティクルが発射されます。 その後オフにして、またオンにするキーを打っても、もうパーティクルは発射されません。 これ、2回目以降を発射させる方法を知っているお方がいたら、どうか教えて下さい。 まさにこういう制御のために、エミッションシステムを自作しないとダメかなあと思っているのです。



Mass はどっかで影響しているかもしれないけど、よくわからんのでデフォルトの 0.1 のまま放置しています。色も後でいじるのでここは放置でいい。




・形

次、Shape は Sphere にしています。これは後で書きますが、最終的にはボリュームシェーダではなく、普通のサーフェスシェーダを使ったマテリアルをくれてやります。Phong とかそういうやつのことです。なので Sphere にしました。

ちなみにまた質問ですが、 Point のままレンダリングってちゃんとできるんでしょうか? ここがわかっとらんのです俺。 ほんとは Point = つまりただの「点」あるいは「光点」としてレンダしたかったりするんですけどね。 しかし Shape が Point の状態で、パーティクルサイズを少しでかくしてレンダしてみると、下半分の半円みたいな形でレンダされますよね・・・・?  ここら辺研究せねば・・・レガシーパーティクルはこの辺楽だったなあ。 っていうか、最も基礎的な研究を怠ったまま花火などを作ろうとしている己の傲慢さに腹が立ちますええ立ちますとも。



・State

Dは State ですね。このエミッションで生まれるパーティクルの State ID は 0 ですと言っているだけです。が、この後 Spawn Trails とかやるので、今自分がいじくっているパーティクルの State ID はいくつだ、と意識しておかないわけにはいきません。っていうか今回の花火プロジェクトは、1つの State だけで作れる花火は少ないので、常にそれを意識しながらやっていました。



・方向

Eは発射方向ですか。 0 ~ 180 だから半球状に発射されるのかと思いきや、全球状に発射されます。 すいません、この辺の意味が実はよくわかってません。しくみが分からなくてもいじくってみて思った通りになればいいやということでスルーしてますが、こういう態度が ICE の理解を遅らせていることは言うまでもありません。 しくみというか、理屈を知っている方、どうか教えて下さい。



Emit From Null コンパウンドは以上。
次に、先ほどのエミッション関係全体のツリーをもう1回。

Ice1


・FCurve を使って異端児をちょっとだけ混ぜる

Size や Speed をランダマイズしてますが、画像のA、Bのように Fcurve ノードをかまして、数値に偏りを持たせています。 ランダマイズするときに、「平均的な値から極端に外れた "異端児" を、ちょっとだけ出したい。ちょっとだけでいい。ちょっとじゃないと異端児にならない」 とかいう時によく使ってます。 速度の分布はだいたいこれくらいだけど、ごくたまにすんげえ速いやつがいて欲しい、とかそういう時です。ごくたまに、という所が重要です。 画像のように、途中でポキっと折れ曲がったリニアなFカーブにすることが多いのですが、これについてはまた別の機会に書きます。



・サイコロ振ってトレイル出すやつかどうか決める

Cの部分はですね、後に出てくるトレイルのための「サイコロ」みたいなつもりでやってみました。

Dで self.SpawnFlag という値をセットしていますね。これは勝手に作ったカスタムアトリビュートです。値の種類はブーリアン=つまり true/false です。 Cでサイコロを振って、ある値が出たときだけ、この SpawnFlag を true にする、というつもりでこうしています。

動画を見てもらうとわかりますが、全ての光球がトレイルを引いているわけではないですよね。全員にトレイルを引かせたら、もう画面がごちゃごちゃになってしまったわけです。美しくなかったわけですよ。 なのでトレイルを引かない光球も作りたかったというだけです。光球ごとにフラグをセットして、フラグが立っているの光球のみトレイルを発射させる、というしくみにしたかったのです。 

そしてこのサイコロ部分は Execute on Emit に刺しているので、光球が生まれた瞬間に1回だけサイコロが振られるはずです。 つまり、生まれた瞬間に1回振られたサイコロによってその光球はトレイル有りなのか無しなのかを運命付けられ、一度決まったらもう永遠に変わらないというしくみです。

サイコロはCです。1~20の乱数を発生させます。この時点ではスカラ値ですので Round を入れて整数にしてあげます。 そしてその値が 1 とイコールだった場合は、SpawnFlag に true をセットしています。それ以外の値だった場合は、false をセットしています。

つまり、1から20まで出る可能性があるサイコロを振って、1という数字が出たときのみ true にしているので、確立は20分の1ということになります。 結果、光球20個に1個の割合でトレイルを引くことになります。 あとで、実際にトレイルを発生させる仕込みをした後で、このサイコロがちゃんと機能しているか検証します。


ちなみに、こんなめんどくさいことするくらいならCloud を別にするというのが、正しいかも知れません。 トレイルを引くパーティクルを持つ Cloud と、トレイルを引かないパーティクルを持つ Cloud が別であってはいけない理由は、そんなにないのではないか。 レンダ時に何か問題あるかな。 まあ、少なくとも、このカットに限っては、1つの Cloud にこだわる意味はあまりありません。 にもかかわらずこうしているのは、やってみたかったというだけです。


・その他

あとは、Simulation Root にお約束の Simulate Particle が刺さっているのと、寿命が来たら死ぬように Delete Particle at Age Limit が刺さっているのと、State Machine が Execute に刺さっているだけですね。 State はメインの光球とトレイルの2種類あるので、この先の State Machine から2つに枝分かれします。




●光球State

次にメインの光球の挙動の制御部分です。
Ice2

・発射時からのツメっぽい動き

Aの FCurveノードとその前にある Get Particle Age Parcentage で、Drag の強さを調整していますね。 

これはどういうことかというと、Drag つまり減速というか、動きにブレーキをかけるフォースなわけですが、パーティクルが生まれてすぐ Drag の影響を受けるのではなく、生まれて少しの間は Drag の影響が少なく、しばらく経つと Drag の影響を大きく受ける、という感じにしたかったんです。 動きのスローダウンを、いわゆるツメの感じにしようとあがいた結果です。上手く行っているかどうかは微妙ですが・・・・。

仕組みを説明すると、まず、Get Particle Age Parcentage の挙動を理解せねばなりませんが、こいつはパーティクルの寿命に従って 0 から 1 の値を返します。つまり生まれたばかりのパーティクルは 0 で、死ぬときに 1 になります。 %なのに最大は 100 ではなく 1.0 なんですが、まあこれはこういうもんだと覚えると良いでしょう。この方が後で掛け算とかする場合に楽ですし。

それを Fcurve ノードに突っ込んで 0,0 から 1.0, 0.6 にマッピングしてますね。 ヨコが元のレンジ、タテが新しいレンジだと思えばいいと思います。 0, 0 で始まっているので Age% が 0 の時は結果の値も同じく 0 で、 1.0, 0.6 で終わっているから Age% が 1.0 になった時(つまり寿命を迎えた時)の結果の値は 0.6 になるようにリマップというかリスケールというか Change Range というか、しているわけです。

その値を、Drag の Strength(強さ)に突っ込んでいる。 つまり、誕生した時点では Drag の影響はゼロで、寿命が進むにつれ Drag の影響が大きくなって行き(つまり減速して行き)、最後には 0.6 という強さで Drag の影響を受けている状態で死ぬことになります。 ただし、FCurve の形を見ると最初の方でグイっと上がっていますので、Drag の影響をあまり受けないのは誕生後ほんのわずかな時間でしかなく、すぐに大きく(最大値である 0.6 に近い値の)Drag の影響を受け始めることになります。

こうして、誕生時だけクイックですぐにスローダウンするという、いわゆるツメっぽい挙動を、Drag の Strength にキーを打つなどパーティクル全体にグローバルな影響を与える荒業を使うことなく、パーティクル個々の寿命を基準にプロシージャルに作れないだろうか、という実験みたいなものです。 もっと研究が必要ですかね。 結果的には、いわゆるツメの動きにはなっていません。 調整していくうちにこれで落ち着いちゃったという。 まあいいや。


・重力の影響にバラつき

Bで -0.5 から -1 までの乱数を発生させ、それを Gravity の Y にぶち込んでますね。 光球が重力によって落ちていくその重力の強さにバラつきが欲しかったんだと思います。たぶん、トレイルの美しさのためだったのだと思います。

今見てみると、Min と Max が逆じゃねえか? -0.5 より -1 の方が小さいのに、なんで -1 の方が Max になってんだ? と思うんだがまあいいや。


・レンダのために独自透明度アトリビュート設定

Cの部分ですが、self.TranspFucker という独自アトリビュート(スカラ)をセットしています。 まず Age% を取得し、その値を FCurve でいじった結果が TranspFucker になってます。これは、後に RenderTree で取得して、Transparency つまり透明度にするためにやっています。

FCurve は 0, 0 から 1.0, 1.0 までになってますね。 Age% の値は 0~1.0 で、Transparency も 0~1.0 だから、レンジは変えてないことになります。 つまり、生まれたてのパーティクルは 0 という値が返るので、Transparency がゼロになり、つまり透明度ゼロ、イコール不透明度100というやつで、要は何も透けてない全部見えるパーティクルだということです。 寿命が尽きるときには 1.0 になるので、全透明になる=見えなくなるということです。 この辺の処理は RenderTree で値をどう扱うかの話なので、後でシェーダの話をする時にまた出します。 

で、FCurve を画像のような形にすることによって、生まれてしばらくは透明度があまり上がらない、寿命が尽きる直前になると急に透明度が上がる、という状態にしています。 リニアにしてしまうと生まれてすぐに半透明になってしまうのが嫌で、死ぬ直前までよく見えている、死ぬ直前から消え始める、という風にしたかったのです。



・色は3種類

Dでまたサイコロ振ってますね。 でもさっきは Round 使ってたのに、今度は最初から整数が出るサイコロになってるな。 Select Case につないだから整数型に変わったのかな。よくわからん。

まあいいや、進めましょう。 PPG を見るとわかるように、このサイコロは 0 から 2 の値を出します。 0, 1, 2 の3種類の値を採り得ると言うことです。そして Select CaseCondition に結果をぶち込んでいます。 Select Case は、Condition の値が 0 ならこれしろ、1 ならこれしろ、という条件分岐のノードですね。 JSctipt で言う switch みたいな。

で、サイコロの結果によって、3種類の Modify Particle Color を突っ込んでいます。PPG は表示していませんが、この3つの Modify Particle Color は、いずれも寿命に応じてパーティクルの色がグラデーションで変化するようにしてあります。そのグラデの色を3つで微妙に変えてあります。

つまり、サイコロ振って、0 だったらこの寿命に従ってこのグラデで色変われ、1 だったら同じく寿命に従って、でもこっちのグラデで色変われ、と指令していることになります。 色に少しバリエーションがあった方が良かろうと思っただけです。




・トレイル発射


次にEですが、さっきサイコロ振ってセットした SpawnFlag をまずはゲットしています。そして if ノードを使って、SpawnFlag が true だった場合のみ、Spawn Trails コンパウンドが実行されるようにしています。 独自に作ったアトリビュートである SpawnFlag をいよいよ使うときが来たということですね。

光球1個生まれるごとにサイコロを振って、その結果でトレイルの有無を決めるというこのシステム、ちゃんと正しく動いているかどうか一応確認してみました。サイコロが出した値を round した後の整数と、結果である true/false を Show Value で表示させ、見やすくするためにエミッションの数を減らしました。
Saikoroshowvalue1

緑がサイコロが出した値、ピンクが結果である true/false です。 これを見ると、サイコロの値=緑が 11 とか 13 とか 18 とかの場合、結果=ピンクは 0 になってますよね。そしてトレイルを引いていません。

トレイルになっている部分の先端にズームしてみると、
Saikoroshowvalue2

ど頭のパーティクル、つまり最初のエミッションで生まれたメインの光球は緑もピンクも1です。つまり、サイコロ(緑)で1が出たので、結果は true になり(= true は数字で言うと1)、そして結果が true だからトレイルを引いているという状態ですね。 なんか上手く機能しているように見えます。

ちなみにこの画像を見ると、どうやら、メイン光玉だけではなくトレイルの方のパーティクルに対してもこの SpawnFlag の評価がされているように見えますね。0,0 と表示されているから。 たぶん無駄だと思います。メインの光玉に対してトレイルを持たせるかどうかのフラグなんだから、結果として出てきたトレイルのパーティクルがこのフラグを持つ意味はありません。この計算をさせなくすることができればシミュレーションが速くなる気がするのですが、どうでしょう。あるいは Show Value のために出てきただけであって、実際は計算されてないなんてことはあり得るかしら。




・ちかちか

花火っぽさの重要な要素として、玉の「チカチカ感」って言うんですか、明滅というか、そういうものがあると思うんですが、それをやろうとしたのがFですね。メイン光球のサイズをチカチカと大きくしたり小さくしたりすることで、そんな感じにしようとしています。

やっていることは、現在のパーティクルサイズをゲットして、そこにランダム値を掛けて、セットし直してますが、正直これ、失敗でした。どんどんでかくなって収拾が付かなくなるやつとかが出てきたので。 なので現在のパーティクルサイズなどゲットせずに、普通にレンジを決めてランダムしてやる方が良い気がしています。他のカットではそんな風にしていたかも知れません。




●トレイル State

次に、さっきのメイン光球から発射されたトレイルの挙動です。
Ice3

・寿命の進行に合わせてタービュランス

Aの部分なんですが、さっき出てきた寿命が進むに連れて Drag の影響を強く受けるというしくみと同じようなものですね。 今回の場合は、Turbulize ですが。

画像のように、Turbulize Aroud Value を使っていて、Base Value は 0, 0, 0 です。Variance にAからのツリーをつないでいます。 またもや Age% ですね。 つまり、基本的にトレイルのパーティクルはタービュランスの影響を与えたい。基点はゼロで、タービュランスのプラスマイナスの差を1つの固定値ではなく寿命が影響したものにしたい。 ということです。

具体的には、生まれてすぐはタービュランスの影響をあまり受けたくない、寿命が進むにつれてタービュランスの影響を強く受けるようにしたい、ということです。 なぜかと言うと、トレイルがすぐにタービュランスでかき乱されてしまったのでは、やはり画面がゴチャゴチャになって美しくなかったからです。 生まれてしばらくの間はメインの光球の軌跡に見えるようにその場にとどまり、だんだんと気流に乱されて崩れていくという風にしたかったわけですよ。

てことで、Bを見てみると 0.1 です。 基本的に、タービュランスは 0, 0, 0 に対してプラスマイナス 0.1 にしたい(プラマイ0.1が最大値)という意味です。ただし、上に書いたようにいきなり最大値になるのではなく、寿命が尽きたときに最大値になっていて欲しいわけであり、生まれてからしばらくの間は弱い方が良い。

Get Perticle Age% は上で書いたように 0 から 1.0 の値を返しますから、それを最大値である 0.1 に掛け算するのが最も手っ取り早いですね。 生まれてすぐの頃は 0.1 x 0 や 0.1 x 0.02 などという計算になるので、結果は 0 や 0.002 ということになり、タービュランスの影響は皆無もしくはほとんど受けていないということになります。

寿命が尽きる頃には Get Perticle Age% の値は 0.9 や 1.0 を返すわけなので、0.1 x 0.9 = 0.09 や 0.1 x 1.0 = 0.1 という計算になり、自分で最大値と決めた 0.1 というタービュランスの値に近いもしくは同一の結果になります。

Fカーブはその中間をコントロールしているわけですが、見てみるとほとんどリニアと変わらない形になってますね。 今回の場合はたまたま、調整していたらリニアに近いくらいがちょうど良かったんでしょうね。

ってことで、動画を見てもらうとわかりますが、メインの光球が空間に残していったトレイルは、しばらくの間はあまり動かず、結果「軌跡」のように見えて、でも時間が経つにつれ段々とタービュランスで乱されていっているのがわかると思います。


・色

特筆すべきこともないですね。ご覧のように Modify Particle Color コンパウンドを Age% モードで使っているというだけです。 トレイルパーティクルの個々の寿命に応じて、このグラデで色が変化しますというだけです。





### RenderTree編


・Color Pass

上記のような Point Cloud に対して組んだ RenderTree はこれです。
Rendertree1

色は Color Attribute で取って来ているので、ICETree で決めた色が反映されています。

Mix2colors で同じ色を加算で混ぜてますね。Incidence を使って、中心部分に光の「芯」ができるようにしたのだと思います。

エッジはボケていたいので、やはり Incidence を使い、Transparency に突っ込んで半透明にしていますね。 で、寿命に従いだんだん透明になって行くために、上記の TranspFukcer をここでゲットして、Incidence の値に加算しています。TranspFukcer は上で書いた通り、FCurve でいじっていはいるものの、基本的には生まれてすぐは 0、死ぬときに 1.0 になる値です。つまり、最初は Incidence の値に 0 が加算されるので Incidence の値そのまんまが Transparency に入っていきます。 だんだん加算される数値が増え、最後には 1.0 が加算されるので、たとえ Incidence で 0 だった部分でさえも 1 になり、結果 Transparency = 1 つまり全透明、つまり見えない、つまり消えた、ということになっているはずです。

Particle Age% を Attribute の Scalar でゲットするのが最も素直かとは思いますが、これだと生まれた直後からもう透明に向かって消え始めてしまうわけで、それは嫌なので(しばらくは全く消えずにいたいので)、FCurve を挟んで TranspFucker というカスタムアトリビュートにし、そちらを参照してレンダ時の Transparency を決定しているということになります。


Constant シェーダ使ってますし、ライティングは関係ないツリーですね。なのでシーンにはライトが存在すらしていません。



・Depath Pass

上の RenderTree はメインの Pass( Color Pass )のマテリアルですが、もうひとつ、ポスト処理でのレンズボケ用に Depth Pass を用意しています。

その RenderTree。
Rendertree_depth_2

俺は大抵の場合、デプスは Scalar State の RayLength を白黒に変換してやっているのですが、このやり方だと Primary Ray の長さしか考慮されないわけで、今回のように Transparency を使っているとよろしくありません。 本当は透けて向こうが見えているのに、透けてないデプスの絵ができてしまうということです。おそらくはこれが原因で、ポスト処理でレンズボケをかました時に汚いエッジが出ました。これはまた別の記事で書きます。 他のショットではぶっちゃけ、汚いエッジのままでもバレなかったので放置していたりもするんですが、このショットだけはバレバレだったので、Transparency も考慮に入れたデプス素材を作らざるを得ませんでした。

ということで Depth Pass では、表面色を ICETree から取って来るのではなく白単色にして、 Transparency は Color Pass と同じ設定の Incidence を使い、Pass に Volume Fog を設定して黒を指定し、白いパーティクルがカメラから遠くに行くほど黒になるという状態にしています。



以上、Color Pass と Depth Pass をレンダし、AE で合成しました。背景は2Dの静止画を AE上で合成したようです。 コンポジットはまた別記事で書きます。たぶん。

他のショットもまあ、似たような構造、というかほとんど同じ構造で成り立っています。あまり手広く実験できませんでしたね。


たぶん続く。



.

|

« 起動画面。 | トップページ | Making of 花火。 c02。 Comp。 »

コメント

まだ全部見てないですが、凄く参考になります
毎度スクリプト等の解説を書かれるたびに思うのですが
理解できない人間が何を分かっていないか、どこで躓いているのか
痒いところに手が届くという感じのポイントが書いてあって
ありがたいです。
印刷して参考書にでもしたい位です

お仕事に障らない程度に続けてもらえると嬉しいです

遅ればせながらコンテスト1等賞おめでとうございます!

投稿: すがら | 2011年10月20日 (木) 16時31分

すがらさん、ご丁寧にどうもありがとうございます(゚∀゚)

全然仕事に差し障ってないですよ!
ヒマですから!
仕事に差し障るくらい忙しい人間なら、メイキング記事はおろか、そもそもこんな花火映像作りませんって!
ヒマ人の成せる業です!


ほんとです orz

投稿: junki | 2011年10月21日 (金) 09時57分

めっちゃ参考にさせていただきました。
ぜひ参考書執筆していただきたいくらい。

1点、ずうずうしくもご質問させていただきたいんですが、
ICEツリー内、エミッション関係の
"true","false","1"ノードってどうやって、というかどこから取り出せばいいんでしょう?
ノード探しても見当たらなかったもので。。
そんなわけでぜひトライしたい「サイコロ振ってトレイル出すやつかどうか決める」が再現できません。
当方2011使用しております。


「ここでいきなり質問ですが、このモードで、複数回発射することはできるのでしょうかね?」

は、"emit from null"内の、seedに、コンスタントでキー振って値変えれば、キー振ったフレームで再度エミットされます。
偶然発見しました。
既出、もしくはもっとまともなやりかた既にご存知でしたらごめんなさい。

投稿: ミツモト | 2012年6月12日 (火) 19時46分

ミツモトさん、ご丁寧にありがとうございます。
こんな古い記事にコメントが付くとは。

 「このシリーズまだ完結してねえだろ。早く続き書けやオラ」

と仰りたいのですよね。よくわかります。 orz





で、true と false の出し方ですが、Preset Manager に true とか false とかタイプしてもヒットしません。 true や false というのは「値」です。ノードの種類ではありません。 そしてこの場合はブール値なので、ブーリアンノードを使います。boolean とタイプすれば出てきます。このノードのパラメータの値が、true か false なのです。

同じく、1というのもノードの種類ではなく、Scalar ノードあるいは Integer ノードのパラメータが持つ「値」です。 なので Scalar あるいは Integer とタイプすればゲットできます。





>は、"emit from null"内の、seedに、コンスタントでキー振って値変えれば、
>キー振ったフレームで再度エミットされます。

げげげげげ! ほんとだっ!今やってみました!

裏技的かも知れないけど、これ、すげえ良い tips じゃないですか。お手軽で良い。
近く本記事で書かせて頂きますね。

ありがとうございます。
感謝します。

投稿: 潤樹 | 2012年6月12日 (火) 20時23分

潤樹さま
わぁ早速の返信ありがとうございます。
ご回答に感謝です、なるほど!見事再現できました。

見ごたえ十分なラストカットらへんこそ解説読めると個人的には泣いて喜びます。

裏技、既出じゃなかったんですね。お役に立てて光栄です。
どもありがとうございました!

投稿: ミツモト | 2012年6月12日 (火) 21時02分

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: Making of 花火。 c02。 ICE / RenderTree。:

« 起動画面。 | トップページ | Making of 花火。 c02。 Comp。 »