リニアワークフローのリンク集など

■テラオカさん
http://tiraoka.blogspot.jp/2011/10/blog-post.html
■ヤマギシさん
http://yamagishi-2bit.blogspot.jp/2012/05/aecg.html
■イナガキさん
http://ingk-tr.blogspot.jp/2012/04/ae01.html
■Area
http://area.autodesk.jp/column/tutorial/designviz_essence/4_about_linearworkflow_4/
■3DTotal
http://www.3dtotal.com/index_tutorial_detailed.php?id=1531&catDisplay=1&roPos=1&page=1#.T742i8VKT4Q
■seazo
http://www.seazo.no/linear-workflow
■hiroshisaito
http://hiroshisaito.net/blog/2011/05/after-effects-1.html
■CGやり直し
http://mj31000.blog13.fc2.com/blog-entry-76.html
■color is power(合成の式の説明)
http://elephantplus.blogspot.jp/2011/05/nuke-tutorial-over.html

//個人メモ
いつかまとめたい

・vrayの場合、設定でよく見るのがこちらのCバージョンなのだけど、Ａとの違いがわからない。。
違いはＣがレンダリング過程で2.2にしてリニアで返すって事なんだろうけど。。レンダリング過程で2.2にする理由って？？ノイズが出にくいとか？

・普段は整数型（tga,png）で画像処理してたけど、float型（OpenEXRなど）で画像を処理すると、色が破綻するのを防ぎ階調を保てる。環境による費用対効果にもよるけど、どんどん取り入れていきたい。


・３ＤＣＧでレンダリングする場合は,srgbのテクスチャはリニア化して読み込まないと、色が正しく再現されない。

・画像保存時に2.2をかけて保存すると、アンチに影響が出る。

・vrayのレンダリング過程で2.2をかけて1.0で保存すれば、アンチは大丈夫らしい。だけど、リニアのカラー確認ができない。

・ガンマ2.2の環境にする理由。
テクスチャをリニアに変換して読み込みレンダリングするため。
よって正しいテクスチャを元にＧＩも計算されるから、ＧＩもリアルになる。

TPのTimeBaseHelperのリファレンス意訳

TimeBase Helperは、付属のコンディションおよびオペレーターのアニメーションを処理するために、どのタイミングを使用すべきかをコントロールさせます。
ノンリニアアニメーションの背後にある基本的なアイデアのひとつは、
アーティストが固定フレームまたは時間値とは関係なくオブジェクトをアニメーション化することができるということです。
一旦アニメーションが作成されれば、後から全体のアニメーションのスケーリングやモーションのブレンドを調整することができます。
これの良い例は、鳥の群れです。
鳥の翼は、彼らの相対速度によって動きます。
標準的な翼のモーションサイクルが30フレームといいます。
しかし、パニックな鳥をアニメーションさせる必要がある場合はどうしますか？
翼のモーションサイクルは高速になり、多かれ少なかれ移動する必要があります。
低速で移動する群れにも当てはまります 。翼のモーションは遅くなります。
これは完璧な NLA 状況？？（←意味わかりません）
- thinkingParticles とタイムベース ヘルパーを使用して、
自動的にアクションのニーズを満たすためにこの翼移動サイクルのタイミングをスケールすることができます。

TPのTips的メモ

●パーティクルに毎フレーム、ポジションを与えて動かしているときのベロシティのとり方について

O memoryを使用し、前フレームのポジション（depth1）、現在のポジション（depth0）をC distanceノードへ流し、Directionをとってやる。

●O pathfollowはリニアなアニメーションしかできない！？

なので、H Path Positionを使用する。
パスの先端から終端が0-1となるので、時間毎に任意のポジションを与えてやることでカーブアニメーションができる。
問題として、H Path Positionではパスからの距離が取れない。
パスからの距離をとりたい場合は、こちらの⑤より。


●randomにサイズを与えるとき、大きいサイズの割合を多めにしたいとき

TimeToValueを使用し、グラフで割合を決める。

「TPでＩｔｅｒａｔｏｒ,Memory,Psearch周りを探ってみた」のちょっとした概要+α

やりたい表現もなく、TPチュートリアルやって、気になったところ調べてたら、気になったところがどんどん出てきて収集できなくなったパターンです。まあ、なんとか収まりましたが{%トホホwebry%}


とりあえず、その収まった動画です↓





一見、まあなんともない動画ですが学べるものが多くありました。


まず、以前の動画では、核となる黄色の玉が直線的な動きだったので、曲線的な動きにしました。そうした理由はなく、思い付きです{%笑いwebry%}


この、直線的動きを曲線にする手法はこちらから学びました。詳細はそちらをご覧ください。
又、深く（式など）で表現したいならば、こちらのSquirlArt_Crowdsを見るのが良いと思われます。
虫などの群集が障害物を避ける表現ができます！
ですが、今の私には難しく理解不能でした。パーティクル扱うには、やりたい表現なのでいつかリベンジしたいと思います。
よって、今回は前者の手法をとっています。


■では、まず核(nuclear)の動きからです。

--追記0513--
※画像下の入射角と反射角はイコールになる式ではございません。。イコールになるのは入射角が45度の時のみです。この式では入射角が大きいほど反射角は低くなり、入射角が低いほど反射角は大きくなるようです。
正解は米岡さんのこちらのムービーで使用されているようですね。
-------------

上の動画で、球に衝突している部分を、
衝突する前に、コリジョンを曲線的に躱すような表現にしています。

■次に、レーザーの表現についてです

↓↓laser_birthダイナミクスは説明が不十分すぎますね。理由は本人が理解不十分のためです{%トホホwebry%}
補足としてＩｔｅｒａｔｏｒはfor文みたいなもので繰り返し処理をするという認識です。ここでもそうですが、パーティクルの配置などでよく使われることがあるかと思います。

以上です。

TPでＩｔｅｒａｔｏｒ,Memory,Psearch周りを探ってみた #TPJP

MemoryのDepthってどういうときに使うのだろうという疑問から始まり、色々探っていたら、こちらにある表現ができそうになってきた{%笑いwebry%}

パーティクルでターゲット同士を結ぶライン表現をしたいときは、Iteratorを使った手法が良い模様です。
※参考としてBlackBox内にmakeLineというものがあります。
二つのターゲット間を結ぶのは上記のブラックボックスを使えばよいです。
ですが、あるパーティクルから複数のターゲットの場合は使えません。
これは、MemoryのDepthを使うことにより、解決することができました。
詳しくは、近いうち更新します。


とりあえず、できた動画（全てパーティクル、コンポなし）↓↓

TPパーティクルカラーメモ

ざっと、ＴＰでのカラー周りのまとめです。
早く次いきたい^^

以前記事で紹介してしまいましたが、ＶertexColorMapを使用しての、パーティクルのカラー調整は極力避けるようにしたいと思います。
なぜなら、TP Variation Texmapが使えなくなるためです。
使えなくなる理由としては、仕様によりTP Variation TexmapはparticleからInputにvertexColorを接続しなくてはならないからです。
というのは、既にカラー調整をＶertexColorでやっていた場合,Inputがすでに埋まってしまっている状態となりますので、どちらかを選択するしかなくなるのです。
色のバリエーションを出すTP Variation Texmapが使えなくなるのは惜しいです。
ここは、もう特別の理由がない限り、ＶertexColorMapを使用しての、パーティクルのカラー調整は避けます。


そこで、ＶertexColorMapを使用しない二つの方法を考えました。
※これらはパーティクルのある変化（age等）による色、透明度の変化を合わせて考えたものです。


①シェイプの形がStdShapeのものでよい場合。（Facing除く）
結論から言うと、色、透明度の変化を合わせて表現できるのですが、シェイプの形を変更することはできません。工夫次第かもですが。。
例えば、色と透明度（白黒）のグラデーションマップを2つ用意し、diffuseとopacityに割り当てます。
ＴＰ内の設定で、uvwの0～1のアニメーションをINputします。
これで、 色、透明度の変化を合わせて表現できます。
ですが、こちら のようにアルファを使ってシェイプの形をとることはできません。
なぜなら上記で、uvw値が決められているためです。
シェイプの形が、デフォルトで問題ないのであればこちらの手法で行くとよいと思います。


※注意点として、上記の方法だとfacingタイプは使えません。

又、この方法はStdShapeにしかできないようです。
Geom InstanceだとuvwのＩｎｐｕｔがないからです（泣）

②シェイプの形を自由に表現したい場合
こちらは好きなシェイプでも良いし、上のことは全てできると思います。
こちらの考え方としては、①のuvwを変化させるのと比べて、マテリアルのカラー自体を変化させ、それをパーティクルに割り当てるという考え方です。
ただ今のところ面倒くさい感があります。カラーアニメを用意しなくちゃならんのです。
完全なプロシージャルな手法ではなくなります。詳細はこちらをご覧ください。
これは良い手法があれば確立すれば、あまり問題ないでしょう。（例えば、下に書いてある問題など。。）

後、新しい発見としてmaterialTimeを使用した場合、トラックビュー（カーブエディタ）を開いてレンダリングするとmaxが落ちるというのを発見しました。

問題
3dsMaxのマップで三色カラーをフェードしながら変化させる良い方法ないですかね？
二色ならmixマップでよい感じにできるのですが。。
僕としては、カラーにキーを打つのが感覚的にわかりづらいので。。

TPでビューポート上のパーティクル表示量を制限する。 #TPJP

これで、ビューポート表示に関しては解決ですかな？
--追記　2012/04/19
グループの構造が逆でした。
渡されたグループが子になる設定です。

ビューポート表示↓↓

レンダリング表示↓↓

元ネタはCGTalkより
↓
Make your group not display anything in the viewport. Then make a child group that does display something, and make a dynamic set that sends a percentage of the original group to the visualization group. Since the child group gets all the behaviors of the parent group, this would work if the viewports are the only problem. If the calculation of the system is what's really the problem - try partitioning it.