« 2011年10月 | トップページ | 2011年12月 »

2011年11月

2011年11月30日 (水)

PlaybackView。

緊急UI速報です。


XSI インターフェース中央下にある Playback メニューの中に、Playback View サブメニューがあることが判明しますた。

Pv1

強い画ブレに警戒して下さい。





再生ビューの切り替えが、こんな便利な場所で出来るんだったら、最初からそう言って下さいよ。 さっき初めて、偶然見つけましたよ。 とっくの昔から定説でしょうか? 全然知らなかったっスよ。 





七ちゃんからだと思うけど、ビューのミュートをしなくてもプレイバックされるビューが制限できるようになって便利だと思ってはいたんだけど、その切り替えはいちいち Preference に潜って行かなければいけないと思い込んでいました。 

Pv2

こんなめんどくさいことしなくても切り替えられるなら、早く言ってくださいよもう。 俺、いちいちこの Preference に潜って切り替えてましたよ。 

俺の場合は Active View が普段のモードですが、例えば何か問題があってその原因を探るための作業をしている時などは、何が起こっているのかを複数のビューで同時に見たいので、All View に切り替えたりしてました。そのたびに Preference に潜るのがめんどくさくて、なんか便利な UI でも作るかなあとか思っていたところでした。






ただ、気づいたんですが、Preference の方からいじった時はちゃんとスクリプトエディタにログが残るのに、Playback メニューの方からいじった時はログが残らないんですね。

Pv3

それもどうかな、と思うけどまあ、そんなに実害はないか。






現在どのモードになっているのか、パッと分かった方が便利なのではないか? と思って、Slate してみました。

Pv4

これ、2012 からの新機能だっけ? ビューポート上に任意の文字やらパラメータの値やらを表示できるみたいなので、どのビューが再生されるモードなのか表示しっぱなしにできたら便利かな? と思ってやってみただけです。



ビューの右下に、このように表示されました。

Pv5

うーむ。  そのマイナス1ってなんだよ。


そうか、UI 上では分かりやすく All View とか Active View とかコトバを表示させているけど、内部的には Integer か何かでパラメータを持っているんですね。 俺も自作のツールを作るとき、よくこういうことやります。数値の方が開発者側には便利な場合も多いのでね。  でもユーザにとってはわかりにくいですよね。 作っている自分でも意味不明になりそうなときはパラメータを String 型にして、ちゃんとわかりやすいコトバがパラメータの値になるようにしますが、めんどくさいと、ついつい数値にしちゃうんですよね。


まあともかく、All View とか Active View とかそういうコトバではなく、0 とか -1 とかそういう表示になるので、わかりにくかったです。

しかも、右下にしか表示できないし。 せめて文字の大きさくらい選べて欲しいですねえ。 # とかそういう記号もダメくさいし。 Slate って微妙だなあ。

それにそもそも、冒頭に書いた Playback メニューをクリックして現在のモードを確認する行為は、さほど苦痛ではないこともわかりました。


つまり、思いつきでこの Slate 表示をやってみたはいいけど、何も便利になりませんでした。 ありがとうございました。













仕事で苦しくなるとどうでもいいブログ記事を書いて現実逃避という、まあ、そんなアレですね。 すいませんすいません。まあ、いいじゃないですか。今は花火メイキングの続きとか書くほどの時間もないしね。ああ書きてえなあ。半端なものが残っていると気持ち悪いですね。 とか言って今まですんげえいっぱい半端記事が残ってますが。




曲行きましょう。

前にも登場したテイラーたん。 いやあ、良いなあ。

なんか、立ち姿が少し垢抜けないというか、キマり過ぎていないと思うんですよねこの子は。 顔もプロポーションもだいぶ良いと思うんだけど、ステージでの立ち姿に、どこか不十分さがある。 例えば素人が楽器を持った時の姿って、どことなくぎこちないじゃないですか。それにちょっと似ているような。 頑張ってカッコいい/美しいポーズをしようとしているんだけど、その頑張りがバレてしまっていて、ナチュラルにカッコいい状態にはなっていないとでも言うか。 そこが萌えるわけですよ。 ちょっとシロートくさく見える感じ。実にいいです。

| | コメント (3) | トラックバック (0)

2011年11月29日 (火)

You got wings。

Redbull1_0001

| | コメント (0) | トラックバック (0)

2011年11月22日 (火)

パーティクルの進行方向は変えないまま、速度だけいじくりたいの。

唐突ICE。

基礎パーツな ICEツリー記録。




パーティクルの進行方向は変えないまま、速度だけいじくりたいの。

Point Velocity, Length, Resize Vector

001

001_2

↑同じ画像を、別ウインドウで開く



Emitコンパウンドで初期状態を決めています。PPG の中ではPの大きさや形なども決めていますが、それらはこの話では重要ではない。 ここで重要なのは、SpeedDirection です。 Randomize Direction でPの方向を決定しています。そして Speed10 です。これで、向かうべき方向とその速度が決まりました。  西へ、時速300km で進む、みたいな。 東京から大阪行きの新幹線に乗った瞬間みたいなもんです。

このPを放置プレイすると、そのベクトルでその速度のまま、永遠に進み続けます。大阪を越えて福岡まで行ってしまうかもしれないということです。 なので、毎フレームちょっかい出すことにします。 方向と速度にちょっかいを出してあげるのですが、今回は方向にはちょっかい出さず、速度にだけちょっかいを出します。


まず Get Point Velocity でベロシティを取得してます。 ベロシティってのはベクタなわけですが、 「 方向 」 と 「 長さ(速度) 」 の両方の概念を含んでいると考えればいいんじゃないんですかね。 例えば 0,10,0 というベクタは、X や Z にはちっとも向かっておらず、Yプラス方向にのみ向かってまっせ、という方向情報を持っていますが、方向だけではなく、その長さ(速度)は 10 でっせ、という速度情報も持っています。 0,10,0 と書くだけで方向も長さ(速度)も表せてしまう、と考えるといいような気がします。


で、その速度の部分だけ取り出してちょっかい出します。Length というノードです。ベクタのインプットを食って、そのベクタの長さ(この場合の速度)だけを吐き出してくれるノードです。

Length ノードによって長さ(速度)だけを分離できたので、それに 0.95 を掛けています。 x 0.95 なので、長さがちょっと短くなりました。つまりこの場合、速度がちょっとだけ落ちました。

いや、まだ速度落ちてません。机上の計算を行っただけです。Pにその速度をセットし直してやらねばなりません。 そこで Resize Vector コンパウンドです。 このコンパウンドは Vector と Length を別々にを食い、Length を掛け合わせて新しいベクタを生成します。 方向はいじってないのでそのまんまであり、Length だけ 0.95 かけて短くなった結果が、新しいベクタです。

最後にそれを Set Particle Velocity でセットし直してやります。これで終わり。



この1連の流れが、毎フレ起こります。 毎フレ起こるのは、ICETree が Simulation モード以下にあるからです。

毎フレ起こるということは、次のフレームで取得されるベロシティは、さっきの計算で速度だけが一度 0.95倍されたベロシティです。 次のフレームでも再び、 x 0.95 済みの値にさらに x 0.95 します。こうして1フレごとにどんどん速度が落ちます。 方向にはちょっかい出してないので、最初に与えられた進行方向は維持したまま、速度だけがどんどん落ちていくという状態です。



こうして大阪行きの新幹線は、だんだん速度を落とします。まだ名古屋あたりかもしれません。たこ焼きをあきらめて手羽先にしようかどうか迷います。落合さんお疲れ様でした。



以上。




ええとですね、Vector から Length を取り出してごにょごにょってのは何度かやったことあったのですが、今回、ごにょごにょした結果をどうやってパーティクルのベロシティに戻してあげるのか、ってのを知らないことに気づいたのです。 

って言うよりは、方向と長さに分離された2つの情報をどうやって1つのベクタに戻してあげるのか、を知らないことに気づいて焦ったんですね。 調べてたら Resize Vector にたどり着いたので、こうして記録しておきます。






ちなみに。

上記のツリーは、Get Data ノードで PointVelocity アトリビュートを取得し、そこから Length で長さを分離したわけですが、これを1つのノードで代替することもできました。

002

Get Data と Length を取っ払い、代わりに Get Particle Velocity コンパウンドにしました。このコンパウンドは、アウトプットに Velocity と Speed があるので、自分で Length ノードを足してやらなくても方向と長さ(速度)に分離できます。


ってよりも、このコンパウンドの中身を見てみればわかりますが、

003

そのまんま、Get Data で PointVelocity を取得し、Length ノードを使って長さ(速度)を取り出しているだけです。さっきやったのと全く同じじゃねえか。 ってことで、どっち使ってもいいです。 けど、このコンパウンド使えばノード数は減らせますね。


さらに。今回の用途であれば、Get Particle Velocity まで廃して、もっとシンプルにできます。

004

今回は「方向」にはちょっかい出さず、「速度」しかいじらないと決めています。ならば、Get Particle SpeedSet Particle Speed というコンパウンドがあるので、こいつらを使えば、最初から速度だけをいじっている状態になりますから、楽です。 ベクタを方向と速度に分解し → 速度だけいじくり → またひとつのベクタに合体し直す なんてことはしなくて済みます。

でもまあ、この2つのコンパウンドの中身を見ればわかりますが、やはり同じく Get Data で PointVelocity を取得して、かつ Length ノードで長さ(速度)を取り出しているんですよ。ただしこちらは、Speed しか関知しないという名目なので、アウトプットに Vector はなく、Speed だけになっています。 この違いだけです。 つまり表面に見えているパラメータを限定し、わかりやすくしているというだけで、処理的には、Length ノードつないでやったのと全く同じことをコンパウンドの中でやっていることになります。





このシーンのダウンロード(XSI 2012)
JJJ_ResizeVector.zip (246.1K)








とかなんとか。
ではごきげんよう。




---------------------------------------------
以下追記。

コメント欄参照。

mskさんが指摘してくれてますが、素直に Velocity を Multiply by Scalar で小さくしてやるのが最もシンプルなやり方だと思われます。 イエス、その通り!

005


.

| | コメント (3) | トラックバック (0)

2011年11月19日 (土)

XSI男忘年会あり〼。

今年で4回目になる XSI男忘年会 です。
ただの呑み会です。
参加者募集中です。
どうぞお気軽にご参加下さい。



2011年12月23日(金)

18:00くらいから
新宿で

http://tweetvite.com/event/XSIManParty2011


上記のページで参加の意思を表明してくれてもいいんですが、俺に直接なんらかの形で伝えてくれてもかまいません。

集合方法、場所、時間などは詳細が決まり次第、またアナウンスします。

当日、XSI男Tシャツの即売が行われる可能性があります。 でも、現在も受付中ですので、ご希望の方は呑み会を待たずに先に注文していただけると助かります。


参加受付は、遅くとも10日前くらいには締め切ります。2週前くらいになる可能性の方が高いかな。 店のキャパによってはさらに早く締め切る可能性があるので、お早めにどうぞ。









この呑み会、俺にとってはすっかり恒例になりつつあり、この呑み会が1年の終わりという、なんつうか、季節を感じさせてくれるイベントになってきました。 ああ、今年も終わるなあ、1年間これで良かったんかなあ、とか考えてね。  シオン風に言えば、何かやり残したような、柔らかな後悔をする、そういう季節です。






過去の様子:

第1回:2008年
http://junkithejunkie.cocolog-nifty.com/blog/2008/12/xsi-2008-d0c5.html

第2回:2009年
http://junkithejunkie.cocolog-nifty.com/blog/2009/12/xsi-2009-0a51.html

第3回:2010年
http://junkithejunkie.cocolog-nifty.com/blog/2010/12/xsi-2010-af9d.html



まあ、今まだ11月なんで、年末気分になっていられません。まだ紅葉すら見ていない。 仕事というかCG的にやるべきこともいっぱい残ってます。 店を早めに確保したいというだけで、早めに募集を始めたというだけです。




2011年を吞み飛ばしましょう (゚∀゚)






.

| | コメント (0) | トラックバック (0)

2011年11月11日 (金)

Making of 花火。 c05。 ICE / RenderTree。

c05 です。





OGLビューポートキャプチャ動画。


あれ? なんかアスペクト比間違えてる? まあいいや。




・・・・しかしなんというか、なんでこうなっちゃったんでしょうねえ・・・。

このカイワレ大根みたいな花火、別に美しいとは思えんわ俺は orz
花火というより、なんかの胞子を出す植物みたいですよね。 汚れているのは水なんです、みたいな。


いや、こうしたかったわけではないんですよ、最初は。 
おそらく、よくある、こういうやつ、



この画像の下の方にあるやつ、こんなのが頭にあったと思うんですよね。




でも、実在の花火に見えるもの、つまり一定以上のリアリティがあるやつってのは、それなりに時間がかかるものです。 このショットを作り始めた時点で締め切りまでおそらくあと2日か3日という状況だし、これまでのショットでもリアルさを完全に捨ててCG臭いというかエフェクト臭い感じに走ってきたこともあるので、むしろ意図的にリアルから遠ざけようとする言い訳がましくみっともない意思が働いて、だんだんパラメータをヘンな方向にいじり、カイワレになって行ったような気がします。

タービュランスとか強めに入れると、いかにもCG臭い、あり得ない挙動になって行きますよね。なので、「 現実にはあり得ない、CGならではの、ちょっと面白い花火でしょ 」 などという言い訳がしやすい絵になって行きますよね。 目の利く人が見れば、必ずしも狙ってそうしたわけではなく、単に能力不足でリアルを作れないだけだとか、手抜きしてるだけだとか、一発でバレますけどね orz




まあともかくも XSI の作業画面です。

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

エミッタはポリゴングリッドです。 1発ごとにエミッタも PointCloud も分けています。 全部別レンダしてますね。 後で色を1発ごとに転がそうとか思っていたんだと思います。 床にもポリゴングリッドがあって、こいつにヒットしたパーティクルは死ぬようにしてますね。 余計なパーティクルは殺して軽くするため&要らん挙動のパーティクルがカメラに入ってくるのを未然に防ぐためですかね。 カメラは固定ですね。 背景は、グリッドをラティスで変形させて、好みの状態になるようにいじったようです。



### ICE編



これが ICETree 全体図です。

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




花火1発につき、これです。 全員がこのツリーを持っていて、多少パラメータを変えているだけのはずです。

A付近が、エミッションや、床に当たったら死ぬ処理です。

Bが、先頭弾ですね。

Cが、Bが出すトレイルです。




まずAから見て行きましょう。

Icetree_a

うん、見事に特筆すべきことがない orz


エミッションスピードをランダマイズしてるのと、発射方向をランダマイズしてます。発射方向は、今回は全方位の球状ではなく、コーン状に発射させてますね。 Randomize Direction の中の数値は今見たら -45 ~ 45 でした。

後は、Test Collision With Surface で、床に当たったら即死するようにしているだけですね。 俺、同じ目的で Delete Particles by Volume もよく使います。







次、Bです。 先頭弾です。

Icetree_b

うーぬ、これも特段の工夫をしたようには見えないなあ。 まあそんなもんです。


発射後の挙動は、フォースまかせですね。 GravityDrag のいつものパターンに、タービュランスを加えるという、これまた更にいつものパターンです。


タービュランスのツリーですが、Turbulize とか Randomize を by Range でやりたい場合、かつ 0 を中心にプラスマイナスを同じ幅でやりたい場合に、俺はこういうツリーを組むことが多いです。 なんのことはない、Min Value Max Value にプラマイ違いの同じ数値を2回打つのがめんどくさいというだけです。 パーティクルの挙動に関わる話ではなく、2回の数値入力を1回で済ませたいという、ほんとそれだけです。


なのであまり調整の必要がない場合はこのツリーも組みません。 っていうか、最初はこのツリーを組まないまま調整を始めて、Min Value と Max Value を数回打ち直すハメになった時点で超めんどくさがりの俺はキレ始めて、このツリーを組んでしまいます。 そして組んだ後に最初に入力した数値がいい具合だったのでそれで確定してしまい、何度も数値を打ち直すのを便利にするためにわざわざ組んだこのツリーが、たった1回の入力でその役目終了という結果になることが多いです orz



ちなみにプラマイの中心がゼロではなく、例えば 3 にしたいなら、このツリーの結果に Add ノードで 3 を足してやればいいだけですね。 ゼロを中心とした -1.25 ~ 1.25 に 3 がプラスされるので、結果的に 2.75 ~ 3.25 の値が出てくることになります。





あとは、パーティクルのサイズをランダマイズしてチカチカ感を出すというのもワンパターンですいません。 ただし今回は、前回までのように前のフレームのサイズをベースにしてランダマイズするのではなく、毎フレ脈略のないランダム値が入るようにしてますね。こっちの方が良かったです。前のやり方だと敏感すぎて、ランダム値の出方によってはあっという間に超巨大パーティクルが生まれたりしてましたから。



あとは色のランダマイズか。ありものの Randomize Color コンパウンドを使って、Lightness に多少バラつきをもたせているだけです。 ほんの少し明るい黄色、暗い黄色があるのがわかると思います。 以上。



Spawn Trails
でトレイルを発射し続けます。 

あっ Spawn で少し工夫しているのを忘れていた。 ええと、何やったんだっけ。 これ書きながら今あわてて調べ始めた。



・・・わかった。トレイルのパーティクルが発射される空間範囲にバラつきを持たせる、つまり空間の中の1点から生まれるのではなく、その1点からプラスマイナス XX の範囲の空間から生まれて下さい、ということをやったんだった。 それが、上の画像の Spawn Trails の一番下にある FuckinEmissionSpaceRange ですね。


これ、Spawn Trails コンパウンドの中身を開いて、ちっとだけ改造したんですよ。 これがその中身です。

B_spawn

もともとは、Aのアウトプットは、Bに入っていました。 A以下のツリーが何をしているのかと言うと、どうやらパーティクルが発射される空間をジッタリングしているようですね。グループコメントに Softimage の人が書いた説明がありますが、動きの速いパーティクルから生まれるトレイルは空間上で飛び飛びの位置に現れてしまうから、それを避けるために、元のパーティクルの位置からちょっとずらした場所に発生させることによって、飛び飛びの空間の隙間を埋めるということをやっているようです。


これにヒントを得て、細いトレイルを太くしたというのが、俺がやった改造ですね。 パーティクルが発生する座標にバラつきを持たせるツリーがもう出来上がっているなら、そこに更に任意の数値をプラスマイナスしてやれば、このツリーで決定された発射位置よりさらに広い範囲で発射されることになる = トレイルが太くなる  と考えたのです。 太くしたかったんですよ。なんとなく。


ってことで、Cの Add ノードを足しました。そしてD以下を足しました。D以下は、まさにたったさっき出てきた「ゼロを中心にプラマイ同じ数値でランダム」のツリーになってますね。

つまり、ゼロ中心にプラマイ XX の値を発生させ、それをCで Add しているので、結果は、Aまでの結果として出た数値にプラマイ XX していることになります。 Aまでの結果は、もともとこのコンパウンドで出した値ですから、もともとの数値にプラマイ XX した数値が最終結果になります。 バラつき幅は、Eの部分でエキスポーズして Spawn Trails の PPG からいじれるようにしました。



わかりにくいので、単体でやってみました。

B_fukcer
何もしないままの Spawn Trails が残すトレイルは細い。左側です。 それに対し、プラマイ 0.1 の範囲で出現位置をバラけさせたのが右側です。 太くなった。これがやりたかったんです。



ああ良かった。。。大したアレではないかもしれないけど、ひと工夫入ってた。。。。







次C。トレイルです。

Icetree_c

ううむ、今度こそ工夫無しか。

同じくタービュランスで乱していますが、プラマイ入力なツリーがまた登場。 今回はパーティクルの寿命を掛け合わせて後半ほど強く効くようにしてはありますが、これも前回まで出てきたネタで、新しくはありませんね。

後は色を寿命に合わせて変化させてるだけですね。









### RenderTree編


すすすすすいません、こちらも特に工夫無し。。。。

Color Pass の RenderTree。

Rendertree1

先頭弾もトレイルも一緒くたですね。StateID ごとにツリーを分岐させたりはしていません。 元になる色は Color_Attribute で ICETree から拾ってきているので、先頭弾とトレイルで色は差がありますが、、ADD で Mix して明るくしたり Incidence でエッジ部分を透明にしたりする処理は一緒です。


次、Depth Pass の RendrTree。

Rendertree2

これも前回まで出てきたのと同じ。Ray Length を使って、カメラから出たレイとパーティクルのサーフェスの交差した座標におけるカメラからの距離をゲットし、デプスの範囲を Change Range で決めて 0 ~ 1 の範囲にリマッピングし、それを色に変換するから白黒のグラデになる。というものです。


しかも、こともあろうに透明度を考慮していない。 パーティクルのエッジが透明であるにも関わらず、おかまいなしに Ray Length を使っている。 Ray Length はプライマリレイの長さですからね。 つまり透けたサーフェスを通過した時点でそこから先はセカンダリレイになるわけで、返してくる値はカメラのポジションからの距離ではなく、おそらくプライマリレイがヒットした座標(つまり透けたサーフェスの表面)から次のサーフェスの交点までの距離を返してくるはずだと思います。


結果、カメラからの距離ではなく、レイが最後に透明なサーフェスを通過した地点からの距離でレンダされるという不正確な Depth Pass 画像が出来上がり、最終的に AE で Lenscare に食わせた時におかしな Bokeh になります。 Y崎さんはこういうのを許せないそうで、どんなチートを使ってでもおかしな Bokeh を排除して美しくしようとするのですが、俺などは「おかしな Bokeh で何が悪い」と開き直り、文句を言わせなくしてしまうという方向のチートをします。 Bokeh が壊れるとわかっていながら敢えて「まあいいだろ」と楽な出し方の Depth Passを選んでいるんですからタチが悪いです。 まあ、世の中色んなチートの方法があり、良くないものを良いと言い張るのも立派なチートの方法だよという話です。 ただし彼のようなチートのやり方だとCG専門誌で連載を持つくらい賞賛され、俺のようなチートのやり方だといい歳こいていつまで経っても業界の片隅で小さく生存しているだけになり、Vimeoでガイジンにディスられ、下品なブログを書くことにひたすら精神力を費やすという、社会のゴミのような人間になりますのでご注意下さい。ええ、とってもご注意くださいね。



あれっ。 ここで唐突に思い出す。 昔からある、BA Shader CollectionBA Ray Length に、Total Ray Length というモードがあったよな?  今、マニュアルを調べてみると、
http://www.binaryalchemy.de/develop/shd_ess/description.htm


  total ray length from the camera to the surface, including reflections and refractions.

って書いてありますね。つまり、透けたサーフェスを通っても、プライマリレイの長さにどんどん加算していくということですよね? ってことは透けたサーフェス越しでも正しくデプスの距離が取れるということじゃないですかね?

あー 前からこの Total Ray Length って何に使うのかなと思っていたんですよ。こういうことに使うものなのかな。 んー これは実験が必要だ。 宿題増やすなよもう。










コンポジット編へ続く。

と思う。














あ。 この記事は、2011年11月11日午後11時11分に公開されるようにセットしますた。

isobeさん、超おめでとう。 心からお祝いするっス o(゚∀゚o)


Isobe_20111111

ふう~ 画像間に合った! 6分前だw

さて、お祝いの酒は何がいいかね。

| | コメント (0) | トラックバック (0)

2011年11月10日 (木)

整数乱数の激怒。

また ICEドリル的な・・・・ いや、ドリルじゃないなこれは。 ICE罵倒か。




まあともかくですね、Randomize な Integer ですよ。

Randomize Value by Range を使って、整数(Integer)な乱数を発生させた時のキョドり方について書きます。

実はだいぶ前に気づいてはいたんですが、今回改めて実験してみますた。







Randomize Value by Range は、デフォルトでは Scalar値 を吐き出しますよね。 Scalar は小数点も含む数値です。 でも、整数が欲しい時もあるわけですよね。 例えば ParticleID とかは整数です。1.572個目のパーティクル 」などというものはありません。必ず整数です。 このように、整数を扱うことは普通によくあるわけでして、それを Randomize するとどうなるかという話です。

ひとまず、実験のためにダミーのタスクを設定します。 「ポリゴングリッドの、各頂点のYポジションを、整数でランダムする」 ということにします。 つまりグリッドを構成する頂点が上下方向にランダムに引っ張られるわけですが、ポジションが 1.2365 などではなく、1 の次は 2 しか無いという、つまりその中間にある小数点の値は出て来ない、ということです。


ってことで、Randomize Value by Range を取り出し、アウトプットのデータの型を整数にするため Integer to Scalar ノードを取り出し接続します。 これで Randomize Value by Range のアウトプットは整数型になりました。 1.2535 みたいな値は出てきません。 0 の次は 1 だし、その次は 2 です。





あとは図のようにツリーを組んでYポジションがランダム化されるようにしました。

Int1

むむむっ 

ちょっと見て下さいよ。 もともと 0 の高さにある頂点に対し、ランダム値 0 から 1 までを足せと言っているのに、実際には -1 から 1 までの値が出現してしまっています。


-1 ってなんですか?

0 に対して 0 を足したら 0 だし、1を足したら 1 じゃないですか。

なんで -1 が出てくるんですか。

おかしいですよね? 

Seed をいじくっても、どうしても -1 が混じってしまいます。


これ、最初気づくまで、けっこう時間かかったんだよなあ。意味分かりません。最小は 0 だと言っているのに、勝手に -1 を出すんじゃねえドルァ








他の数値も試してみます。 今度は 1 から 1 までにしました。それ以外 ICETree は全く同じです。

Int2

だーかーらー (メ゚皿゚) 

1 から 1 なら、 出てくる値は 1 しかねえだろうがー なんで -1 とか 0 が出現するんだよー 間違えるなよ ICE ちゃんー






今度は、 0 ~ 2 を試してみました。

Int3

あっ ( ゚∀゚)

出てきた値は 0, 1, 2 の3種類! 合ってる! 

ここは、Seed を引っ掻き回しても、必ず 0, 1, 2 の3種類しか出てきません。 うん、それでいいんだよ。 いい子だ。








ならば。 今度は 0 ~ 3 を試してみました。

Int4

ICE は今すぐ市んだ方がいいです
市ね市ねすぐ市ねこのICE野郎






結局ねえ、原因不明なんですよ。 なぜこうなるかもわからないし、このツリーのまま解決する方法は見つかってません。 0 ~ 2 の時だけ正しい値が出るのも、原因不明です。

これ不具合ですよね? 嘔吐デスクさま?




しかたないので、Randomize Value by Range を整数型で使わず、Scalar のまま Round に食わせて、四捨五入してやることにしました。

Int5

はい、これがやりたかったんです。




一応他の数値も確認しました。上記でおかしかった、1 ~ 1 の場合。

Int6

うん、いい子だ。それで良い。



0 ~ 3 の場合。

Int7

よしよしいい子だ。






結局ですね、原因も、根本的な解決方法も、わかりません。単に Round すれば結果が同じだからいいや、Round 使っても不具合が無いように見えるのでいいや、という所で止まっています。

おかしいですよね? 嘔吐デスクさま?

ひとまず仕事が進まないからこれでやりますけど、ちゃんと直すか、最低でも説明はして下さいよ嘔吐デスクさま。

Int8_2

| | コメント (2) | トラックバック (0)

2011年11月 9日 (水)

愛☆ちゅカーブレングス。

某所で ICEドリル というものが流行っています。


いや、まあ、単に俺的ブームというか、自分が今やっている作業に利用させてもらっているだけですがね。 ICE を使った特定のタスクで、みんなで知恵を出し合って解決法を教え合うような主旨かなと思っていたのですが、俺の場合、自分で解決できない問題を誰かに解決してもらうという、じつに厚顔無恥な使い方をさせてもらっております。 すいません orz  恩返しはいずれ俺が ICE的に成長してからってことでね。出世払いで許して。






で、カーブの長さの取得ですよ。


今まではスクリプトオペレータ(SCOP)でよくやってました。他人様の書いたプラグインとかスクリプトを利用させてもらってるんですがね。 過去にもこのブログに書いたことありますね。 これこれか。



これを、なんとか ICE 化できないものか、と。

ICEドリルな方々に教えてもらいながら、ひとまず ver1 です。 稚拙ですがスクリプト書きました。書きたてホヤホヤです。 熱いので冷ましてからどうぞ。





カーブを選んで(複数可)、以下のスクリプトを実行します。



---------------------------------------------------------------------------------

//    カスタムプロパティを入れる器ヨーイ

var oProps = XSIFactory.CreateObject( "XSI.Collection" );

//    選択中のブツをループして、カーブだった場合はファンクションに飛ばして処理実行
for ( var i=0; i<Selection.count; i++ )
{
    if ( Selection(i).type == siCrvListPrimType )
    oProps.Add( SetIchuCurveLength(  Selection(i) ) );
}

//    器がカラじゃなかったら(プロパティが存在したら = この場合、選択にカーブが含まれていたら)、PPG を表示しておしまい
if ( oProps.count != 0 )
{
    InspectObj( oProps );
}



//    以下、メインの処理をするファンクション

function SetIchuCurveLength( oCurve )
{

    //    カーブにカスタムプロパティを与え、カスタムプロパティに Length パラメータを与える
    var oProp = oCurve.AddProperty( "CustomProperty", false, "IchuCurveLength" );
    oProp.AddParameter3( "Length", siFloat, 0 );

    //    ShapeModelingモード以下に ICETree を作成。 名前も付ける
    //    ApplyOp のカッコ内最後の 1 を変えると、他のコンストラクションモード以下に作る

    var oICETree = ApplyOp( "ICETree", oCurve, siNode, null, null, 1 )(0);
    oICETree.name = "ICETree-IchuCuveLength";

    //    Set Data ノード召還。 カスタムプロパティの Length パラメータに接続
    var oSetDataNode = AddICECompoundNode("Set Data", oICETree );
    SetValue( oICETree.fullname + ".Set_Data.Reference", "this.IchuCurveLength.Length", null );
    ConnectICENodes( oICETree.fullname + ".port1", oSetDataNode.fullname + ".Execute");

    //    Get Data ノード召還。 this.CurveLength をセットし、上記 Set Data ノードの Value ポートに接続
    var oGetDataNode = AddICENode("$XSI_DSPRESETS\\ICENodes\\GetDataNode.Preset", oICETree );
    SetValue( oICETree.fullname + ".SceneReferenceNode.reference", "this.CurveLength", null);
    ConnectICENodes( oICETree + ".Set_Data.Value", oGetDataNode.fullname + ".value");
   

    //    プロパティを返す
    return oProp;
}

-------------------------------------------------------------------------------- 



すると、

Ichucurvelength1

カーブの下に、IchuCurveLength というカスタムプロパティが作られます。その下には Length というパラメータがあります。

カーブの Shape Modeling コンストラクションモード以下には、ICETree が作られます。

その ICETree の中で自身(カーブ)の CurveLength アトリビュートを取得しています。Get Data の部分です。 そしてその結果を、上記のカスタムプロパティの Length パラメータにブチ込んでいます。 Set Data の部分です。



結果、カーブをぐねぐねいじくると、Length パラメータはインタラクティブにアップデートされます。 これがやりたかったんです。 ICEで。




Shape Modeling コンストラクションモードに ICETree を置いたのは、Modeling よりも上ならまあいいだろうというだけのことで、あまり考えていません。 Modeling モードに置いてしまうと、カーブの形をいじくった履歴が ICETree の上に来てしまい、ICETree で結果の長さを正しく取得できません。 なので Shape Modeling モードに置いたのですが、考えてみれば、例えば Animation モード以下でカーブの長さが変わるようなことをやっていた場合、やはり正しく数値をゲットできませんね。 ってことは、Secondary Shape Modeling モードとかに置いた方がいいのかも知れません。




ちなみにカスタムパラメータを介さずに、元からある XSI の何かのパラメータに接続しようとすると、できる場合とできない場合がありました。 できない場合というのは、Set Data ノードでデータのセット先を決めるとき、Explore ボタンで出てくるミニExplorer の中に、目的のパラメータが見つからないという状態です。

例えば、ヌルの size パラメータに直接接続するのは、問題なくできました。 一方、グリッドの Geometry Op の中にあるパラメータ(グリッドの大きさや分割数)は、全滅でした。 そもそも Geometry Op が、Set Data のミニExplorer に出てこないもんだから、ピックしようがない。



今回のやり方では、カスタムプロパティの Length パラメータにセットするので、ここを中継すればどんなパラメータにも接続できると思います。 普通に Expression でつなぐだけ。 これはまあ、以前の SCOP 使ったやり方でも SCOP によってアップデートされるのはカスタムパラメータでしたからね、同じことですね。



ただし注意しなければいけないのは・・・・。 



SCOP の場合は、SCOPで制御されているパラメータのアニメーションアイコンは S に変わるじゃないですか。 ミキサーで駆動されているパラメータは、ミキサーで動かされてますアイコンに変わるじゃないですか。 よって、手ではキーを打てなくなりますよね しかし今回の ICE で駆動するやり方の場合、上記 Length パラメータのアニメーションアイコンは、変わらないのです。そのまんま、通常の緑色の四角のままです。 ってことは、ここに普通にキーを打てちゃうんです。


で、キーを打つと、カーブの長さが変わっても数値がアップデートされません。 キーがあった場合はそちらが優先されるのかなあ? あるいは GUI 上でアップデートされてないだけで、スクリプトで値を取得してみると内部的にはちゃんとアップデートされているとか? ← XSI様に実にありがち


ならばキーを打てないようにするために、このカスタムパラメータを作成する時点でアニメーション可能フラグをオフにしてしまうこともできるんですが、そうなるとあの緑色の四角が出てこなくなるので、他のパラメータに Expression でつなぐ時に困りますよね。



ってことで、キーを打たないよう注意して下さい。







っていうか、ICE から制御されている時には、アニメーションアイコンがそれ用のものに変化して、キーが打てなくなればいいんだよ。 SCOP でも Mixer でも Expression でも、皆そうなるじゃないか。 なぜ ICE だけそうならないんだ。 嘔吐デスク様?




それと、この Length を Show Value しても、ビューポート上に値は出ません。 おそらく、Show Value が効くのは ICETree の中で値をセットしている時だけなのでしょう。 今回はカスタムパラメータにセットしてますから、ICETree の外に向かってセットしているわけで、効かないように見えます。 ダミーのアトリビュートを作って同じ値をセットしてやれば、Show Value できると思います。 そうか、そうすりゃ良かったかな。








それと、挙動がどうもアヤシイので、さらに注意書きを書いておきます。




まず、こういうカーブに適用した場合。

Ichucurvelength2

なんてことないカーブですけどね。
のポイントを、Mキーを押してぐりぐりいじくったりしても全然平気なのですが、真ん中ののポイントをいじろうとすると、いじれないか、レスポンスがすごく遅くなります。


なんで? なぜこうなる。 さっぱりわからないけど、俺のところでは必ずこうなります。


しかもですね、Mキーでの移動、つまり Tweak ツールですね、Tweak ツールを使った時だけこのアヤシイ挙動になるのです。 Tキーを押してBのポイントをタグし、Vキーを押して移動させる時には、普通にスイスイ反応してくれます。 おかしいのは Tweak ツールの時だけです。


カスタムプロパティを削除したり ICETree を削除すると、つまり何もしていない元のカーブの状態に戻すと、普通にスイスイいじれます。 なので、俺のこの ICETree などが悪さをしていることは間違いないんだと思いますが、なぜなのか、どこがそうさせているのか、さっぱりわかりません。 よくわからないのでご注意下さい。










もうひとつ、ヘンなことに気づきました。

上記と同じ場合で、Length を他の何かのパラメータに接続した場合です。

Ichucurvelength3

この場合、Length をトーラスの Radius に Expression で接続しています。 つまり、カーブの長さが変わると、トーラスの大きさも同期して変わるという状態です。 実際の仕事では、カーブの Length は何かに接続してこそ意味がある場合が多いはずで、普通はこの状態で使うと思います。


で、このように何かのパラメータに接続されている状態にすると、上記の Tweak ツールの問題は起きないんですよ。 つまり、Tweakツール使ってもBのポイントもスイスイいじれる。 なんでだ?


A と C はもともと問題ないから、関係ありません。問題出ません。


この Expression の関係を絶つと、つまり Expression を削除すると、やはり Tweak ツールでいじりにくい問題が復活します。




さらに。

Tweak ツールの問題が出ている状態でしばらくいじくっていると、XSI 様が瞑想に入られます。

いやまあ、XSI様 の瞑想自体はね、別に珍しくもなんともないんだけど。でもまあ、再現率の高い瞑想です。






ってことで、謎も多く、爆弾も仕込まれてるスクリプトですが、よろしければ是非使って頂きたいです。 そして感想や注文を聞かせて頂きたいです。 特に上記不具合が再現するかどうか。  

そうやってフィードバックがあると、不具合を発見したり、そもそも論の根本的な問題が出てきそうな気がします。 それこそが、ICE 理解へのキーだと思います。 問題が出て、その回避方法が見つかれば、挙動の理解に役立つわけですね。 問題・不具合が出ないとなかなか理解って進まないものです。 俺の力では、不具合とか見つかっても修正できないかも知れないですが、それをきっかけに理解を進めよう・オベンキョしようという魂胆なわけですよ。 上手く行った事例からよりも、上手く行かない事例からの方が学ぶこと多いですよね。 






改造も大歓迎っス (゜∀゜)








.

| | コメント (0) | トラックバック (0)

2011年11月 6日 (日)

西からビールウェア。

西の国から、マルプラさんが東京へいらっしゃいました。 なので迎撃と称して、御茶ノ水で一緒に吞みました。


最近、マルプラさんのご要望に沿ってスクリプトを書いたことがあったのですが、なにやらそれが役に立ったようです。 また、彼曰く、以前から俺の書いたスクリプトなどをちょこちょこ使っていたそうです。




そしたら彼は、
この晩の吞み代を、
おごってくれました ヽ(゚∀゚ )ノ
わあい ヽ(゚∀゚ )ノ




ちなみにこの日同席してくれた狐森さんは、ビールウェアのシリアルナンバー 0012 を持っています。以前俺にビール券をくれたからです。 マルプラさんはその次のシリアルナンバー所有者になってくれたわけです。 



ってことで、はるばる西の国から来訪して下さったマルプラさんには、俺のスクリプト/プラグインの永久無料ライセンス Serial No. 0013 を、謹んで進呈いたします!!

超ありがとうございます ヽ(゚∀゚ )ノ







いやあ、楽しい吞みでした。
ウマが合うというか、ノリが合うというか。良いねこの3人。
互いに良いリスペクトがあるとでも言うか。
ちょっと時間短すぎたぐらいですか? もっと話をしたかったですね。
次は俺が西の国に行くしかないな。

迎撃たのむで。






さて、このブログでたまに出現する脈略のない曲紹介が好きだというマルプラさんのリクエストにお応えして、久しぶりに曲行きましょう。




The Band Perry
If I Die Young どうぞ。



俺は相変わらずカントリーっぽいのが好きです。 

このバンドは、アメリカのいかにもカントリー好きな野郎たちのツボを上手い具合に突きながら、でも全くカントリーなど聞かない層にもひっかかりを与えるかのような、そういう曲の妙があると思っているのですがどうですか。まだデビューして2年くらいしか経ってないみたいですが、いい曲いっぱいあります。



この3人、実の姉弟なんですよねえ。 いやあ、リアルな家族3人集まってバンドやるなんて、俺には考えられねえ。


ヴォーカルのキムさん、素敵です。 容姿も声も素敵です。 最初に聴いた時、一瞬で好きになりますた。 キムさんって言っても将軍様とかじゃないですよ。 このバンドで歌を歌っている、綺麗なパツキンの、キンバリー・ペリーさんのことです。


このPVの絵も美しいですよね。 この色とか好きです。 こういう感じにカラーグレーディングするのは、流行なんですかね。 絵の感じも、最近の動画撮れる一眼レフで撮ったみたいな雰囲気に見えるような気がしているんですが、そんなことないですか。デタラメですか。




同じ曲の、スタジオライブバージョン。



こちらも良い。 とても良い。

ハスキー気味の声が、高い音階を歌っている時に、かすれて千切れるかどうかのギリギリの感じが良いわけですよ。ツボにぐいぐい入ります。 イきそうです。 この手の声はこのスリリングさこそが良いわけで、何テイクも録って切り貼りとオーバーダブを繰り返したようなスタジオ版より、ライブ版の方がより味わい深いものになると思っているのですが、どうですか。


そしてさすが姉弟、ハモりが完璧ではないですか。 実に美しいハーモニーだと思います。 DNAレベルで協調するのだと思います。


絵も綺麗ですよねえ。Bokeh が綺麗だ。 まさかポスト処理じゃないよね? 手でマスク切って安易に Lenscare しましたとか言わないで下さいよ。俺じゃないんだから。




この曲の歌詞はあまり掘り下げて聴いていないのですが、


  If I die young bury me in satin
  Lay me down on a bed of roses
  Sink me in the river at dawn
  Send me away with the words of a love song



なんか、尋常じゃないですよね。



  もし俺が早死にしたらな、
  サテンに埋めてくれへんか。
  ほんでもって薔薇のベッドに寝かしてくれや。
  ほんだら夜明けに川に沈めてくれや。
  川藤が引退した時みたいにな、愛の歌の言葉と共に送り出してくれや。



とかなんとか言っているんでしょうかね。 縁起でもねえ歌なのか、害基地の歌なのかよくわかりません。 曲が良いのでどうでもいいです。






Youtube で探ると、ほとんどがシロートのようですがけっこう色んな人がカバーしているようで、比較的気に入ったやつをいくつか。



歌い方がけっこう好き。

なんつうか、歌い方というかフシ回しというか、そういうのが重要な気がするんですよこの曲は。 少なくとも、一定の感じで流れるように歌ってしまってはダメで、突っかかりやタメみたいなものが無いと台無しになってしまう曲だと思えるんですよね。 ただ歌唱力があるだけではダメ。泣きのフシ回しでいかにググっと引っ張れるか、みたいな。 何言ってるかわかりませんか。そうですか。 まあいいや。この人のフシ回しがいいなあと思ったんですよ。 まあ、オリジナルに近いのかな。






これもいいなあ。



男二人。
1台のピアノを二人弾き。
素晴らしいハモり。

独特ですね。


なんとなくゲイっぽい。
アニキ、カッコいいぜ。
男にも勃つよ。







最後はこれ。



なんつうか・・・・w

いや、素敵ですよね。歌唱力も声量も抜群で、実に良いと思います。 でも、なんか笑ってしまうのは俺だけですかw

なんかサブちゃんっぽいな。 うん、これは、北島サブちゃんのガイジンバージョンだw


映像的には、リムライトが素敵ですね。 これ、狙ってライティングするの難しいですよね。










ということで、今日は If I Die Young 特集をお送りしました。

ごきげんよう。




.

| | コメント (4) | トラックバック (0)

2011年11月 1日 (火)

花火高画質バージョン。

先日から書いている、パーティキュラー花火大会に出品した映像の完成版を、Youtube にアップロードし直しました。 高画質で再生できるようになったみたいです。


720p とかで HD再生することができます。 明らかに画質というか、高精細感が上がった。


中身は変わらないので、高画質になって嬉しいのは作った本人である俺だけだということはよくわかってますが、まあいいじゃないですか。 階調とか色深度とか割と気にして作ったのに、ヴォロヴォロになってましたからね。残念だったのです。




マスターのムービーは、800 x 600 で、QuickTime アニメーション圧縮の品質 100% です。つまりロスレスです。 ファイルサイズは 2GB 強あるムービーです。 

これを 10Mbps 程度の H.264 にしてアップロードしたのが前回バージョンです。 H.264 ムービーになっても、そんなに劇的に画質は落ちてないんですが、Youtube にアップロードするともう1回なんらかのエンコードをかけるようなので、ここで劇的に画質が落ちますね。


で、ちょっと調べたら、そもそも 1280 x 720 以上のレゾにしないと Youtube 上で HD な再生モードが選べないのでダメよ、というのがわかってきて。 

しかし今回の花火大会は、規定のレゾが 800 x 600 だったのです。 作り始めたのが締め切り1週間前とかなのでレンダ時間も惜しいし、そのまんま 800 x 600 で作ってしまいました。 なのでマスターのレゾが 1280 x 720 相当に達していません。


しかたないので、AE で 1280 x 720 のコンポに完成済み 800 x 600 をブチ込んで、上下左右に余白がある状態にし、今度は 20Mbps 程度の H.264 でレンダし、 それを Youtube にアップロードしてみたら、明らかに高精細な再生になりました。 圧縮の品質の話ではなく、高解像度再生ができるようになったことによる恩恵が大きいように見えるのですが、どうなんでしょうかね。

ちなみに、同じく余白付き 1280 x 720 ではあるんですが H.264 エンコードなどはやらずアニメーション圧縮 100% のままというムービーも作ってみたのですが、これはファイルサイズがでかすぎるのか(元が 2GB強で、1280バージョンはそのプラスアルファくらい)、何度アップロードしても失敗でした。 アップロードは一旦成功し、「現在エンコード中」ですという旨の表示が出るのですが、数時間経つと「アップロードが中止されました」とかに変わってやがりましてね。中止してねえよ。 これを数回繰り返して、あきらめました。

そこで H.264 にしてみたら、一発でちゃんとアップできました。 ファイルサイズは 150MB弱ですね。 H.264 エンコードにしたことがポイントなのか、ファイルサイズが小さくなったことがポイントなのか。 よくわかりません。







それにしても、今どき、何でも 1280 x 720 以上にはしておいた方が良さそうですね。この花火も 960 x 720 でレンダしときゃよかったなあ。

でも嫌な時代ですね。フルHDとか平気でやってるし、しかもステレオ3Dとか。 4K TV とかマジでやめてください。 あなた、ほんとにそこまでして高精細で見たいですか。


4K が普通になったら、制作サイドにはどんだけでかいモニタが要るんだろう。やっぱ 1:1 の大きさで見れる環境無しには作れないじゃないですか。 机もでかいのが必要になり、オフィススペースは圧迫され、広いビルへの引越しを余儀なくされ、引越し貧乏で倒産していくCGプロダクション。ああ恐ろしい。

とか言って、現在既に 1:1 でちゃんと全域は見れない環境で作っちゃってますね。1920 x 1600 のモニタ1枚で、1280 x 720 の映像作ろうとすると、AE の画面はかなりキツい。どうしても縮小表示になってしまう。 あるいは 100% 表示で一部ウインドウに隠れているとか。 実はけっこうストレスです。 

今回の花火大会で 800 x 600 と聞いたとき、すげえ安心しましたもん。 ああ嬉しいな懐かしの SD だな。 AE 上でもほとんどの場合見切れずに 100% 表示でコンポできるな。嬉しいな。



この辺で高解像度化の流れは止めなければいけませんよ。 せめて 1280 x 720 までにしませんか。ねえ。 レンダ負荷もそうだけど、上記のように作り手側の表示環境の問題もあるし、ペンタブレットもでかいのが必要になり、ストレージは圧迫され、テクスチャ解像度だってそれに合わせて上がり、モデル解像度も当然上がり、納品データはネット越しに送れなくなり、パシリ君が 2TB の HDD を抱えて編集所に走るみたいな、まるで俺が駆け出しの頃にやっていたことがそのまんま繰り返される。 退行ですよこれは。


あと、関係ないけど「ハイビジョン」という言い方もいい加減やめませんか。それ日本以外で通用しないでしょう? たぶん。   まったく、日本放送協会様の野郎、ふざけた名前を普及させようとしやがって。MUSEを押したかっただけだろう? たぶん。    「CGデザイナー」みたいなもんですよ。やめましょうよ。












そういやメイキング記事まだ終わってませんね。
まあ、ネタとしてはもう切れかかっている気がします。
なら、全ショットやらなくてもいいわな。
どうしようかな。
ものすんごいエネルギー要るんだよな。
楽しいんですけどね。





.

| | コメント (5) | トラックバック (0)

« 2011年10月 | トップページ | 2011年12月 »