2012年1月12日木曜日

コンテナ概要

【コンテナ Container】

ver2010からの新機能
ver2011からもろもろ強化された

■ どんなもの?
オブジェクトのコレクションを作成し、制御するヘルパーオブジェクト

■ 何ができるか (マニュアルによれば…)
・シーンオブジェクトをグループ化して整理する
・オブジェクトやそれが所属するレイヤーの表示設定に関係なく、
コンテナ独自の表示方法を採用できる
(例えばレイヤーが非表示でも、コンテナで表示をOverrideすることで表示したり)
・コンテナの中身は外部参照であるため、
1.シーンのファイルサイズ軽減、結果的に、ファイルのロード/セーブが早くなる
2.一時的にアンロードすることでオペのパフォーマンスアップ
が可能
・プロキシモデルと本番モデルとの切り替えをすばやく行える
・データの変更を共有できるのでワークフローの後ろにすばやく伝達できる
・コンテナは参照している人のシーンの都合で変更を加えることもできるし、それを大元のデータに還元することも可能

■ 個人的な解釈
クラウドコンピューティングに近い感覚
ソースデータはみんなが共有できる形でサーバーに保存されていて、実際に作る人はコンテナの中で作業をする。
作業した結果は、みんなに共有されるので、再読み込みしなくても最新データでの作業が実現する。
後はパイプラインにどう組み込みか、という工夫だけど、、、、


・Lightwave のオブジェクトのような概念である。
・パイプラインで利用するというよりは、みんなで1つのものを作り上げる際に、パートごとにコンテナで作業を進めるような、並列作業に向いている。
・次々とデータを更新しながら次の工程に渡していくような直列の流れには対応できていない。
・XRef ともっとも違うところ
XRef はシーンに読み込むことしかできないが、
コンテナは今作業しているシーンのオブジェクトを外部参照に変換できる
(この仕様は Photoshop のスマートオブジェクトに近い)


■ 検証
・モデリングされたキャラクターをコンテナで参照して、セットアップをする
・セットアップされたキャラクターをコンテナで参照して、アニメーションを流し込む
---->NG

コンテナは外部シーンとして扱われるため、シーン内の他オブジェクトは干渉できない。
上記二つの場合、
1.モデルに skin モディファイヤを適用後、シーン内で作った(ローカルオブジェクト) bone がモデルに干渉するため NG
2.ボーンにアニメーションデータを流すには、キー情報を付与する必要があるためNG

いずれの場合も、同じコンテナの中に bone やアニメーション情報を含めれば機能するが、これはあまり有用な使い方ではない。

■ 使いどころ
・並列に作業を行う場合には強力(ロボットを複数人でモデリングしたり)
・データの量が大きいシーンで、各ブロックをコンテナで参照ファイル扱いすることで作業シーンそのもののファイルサイズは小さくてすむ。
 →後日検証結果11/01/20:大量にコンテナで参照させたシーンのロードセーブが異常に重たくなる。実用化不能なほど。この時点ではちょっと使い道が見いだせない。
・各パートで完成したものをコンテナで渡すことで、スムーズなデータの受け渡しが可能である(気がする)

■リニアワークフローと3DCGのガンマ補正のはなし

■リニアワークフローとか3DCGのガンマ補正の話 メモ


■理解する上で一番大切なことは
3DCGのソフトが、ライトなどの光を計算する場合、その計算式はリニアで行われているということ。それはつまり、いままでの方法でレンダリングした画像は、なんとリニアスペースで作られた画像そのものだった、ということ!

■問題は
自然界を見ている人の目も、写真も、リニアスペースで作られた画像(自然界の光)をそのまま見ているわけではないってところ。
感度が違う。

比較的暗いところの方が、網膜の神経は敏感。明るいところでは明るさの差をあまり感じ取れない。逆に暗すぎても分からなくなる。
懐中電灯を太陽の光の中で使っても明るくてらしたところが分からないのはそのせい。暗い中ではすぐ分かるのに。

■さらにややこしくなった原因 = テレビモニターのガンマ
人の目が自然界を見た時と同じようにテレビモニターを見たときも自然に感じるためには、テレビモニターも自然界と同様に、リニアスペースで色を発光させる必要がある。
しかし、モニターを作る時の技術的な問題から、モニターは光をリニアで表示できない特性を持って生れてしまった!

■撮影したリニアな画像をガンマ補正する
そこで、カメラで撮影した映像をテレビで見るときに自然に見えるようにするために、あらかじめ撮影した画像にテレビの発光特性と逆の特性を持たせて、テレビの特性をうち消すことにした。

■逆ガンマ
リニアカラースペースのものをガンマ2.2の特性をもつモニタで自然のままの色で表示するためには、モニタに送る信号に0.45の逆ガンマをかける。するとモニターはガンマ2.2の特性を持つので、強制的に発光する光には2.2のガンマがかかり、元のリニアスペースの色と同じになって自然に写る、という寸法。

■ノンリニアスペースとリニアスペース
  • ノンリニアのもの
    • 人の目
    • アナログフィルム(銀塩フィルム)
    • テレビやPCモニター(最近のものはsRGBを採用していて、これはガンマ2.2)
    • プリンター
  • リニアのもの
    • デジタルカメラのRAWデータ形式
    • HDR画像フォーマット(32bitの浮動小数点系のものはそう)

■3DCGソフトでは光をリニアスペースで扱う
何も設定していなければ、3DCGソフトでは光をリニアスペースでレンダリングする。
これが落とし穴。CGのライティングでできる陰影は、人が普段感じている自然な光よりも中間色が落ち込み、コントラストが高くなる。
ソフトウェアのガンマの扱いはそれぞれ違うので、何をしているのかを理解しなければいけない。実はリニアワークフローそのものを理解するよりもこれが難しい気がする。

■ガンマ補正?
ガンマ補正を行うと、最も明るい色と最も暗い色はそのままで、中間色が変更される。Photoshopのトーンカーブと同じ原理。2.2などの数値はガンマ曲線にかかる係数のことで、曲線のゆがみを規定する。
フィルムや人の目のガンマ係数はだいたい2.2らしい。これは暗い光に対して敏感で、明るくなるにつれて感度が鈍くなるような曲線だ。


■導入してみたい理由

1.フォトリアルな絵を作るためには光を正確に再現するべきで、そのためには現実に即したワークフローを採用すべきだから
1.ライティングに対して人間が感じる自然なコントラストはガンマ2.2であるから
1.ガンマ2.2で作業をするとガンマ1.0での作業より中間色の明るさが増すのでライティングの手数を減らせるのではないかと期待するから
1.今後のスタンダードになりうるから
1.上記理由から、より柔らかい光の演出を作りやすく、空間を感じさせるような絵作りに向くと思うから
1.後処理でレベル補正をする際に、中間色がしっかり出ているので劣化を押さえながら色を転ばせることができそうだから

これは実際の世界をカメラで撮影する作業工程と同じ。写真のフィルムや人間の目などのアナログ媒体は、光を非線形で捉えている。例えば、写真に映っている色で明るさが2倍違う領域同士は、本来の撮影場所では数字的には2倍以上の差がある。「露出量(EV)」は数字が2倍になれば明るさも2倍になるが、これは2倍に明るくなる露出量を2倍に表記しているにすぎず、本来の光の強さが2倍の強さとは限らない。つまり、光そのものは線形で表されるが、目や写真に写る色は非線形に補正されているということだ。銀塩フィルムや人間の目は光に対してほぼ同様の感度を持つ。デジタルカメラは、センサーが捉えるリニアな色をガンマ補正して従来のフィルムや人が感知している色に合わせているのだ。
CGソフトで作成している絵は実際の世界と同じで、光の強さをそのまま格納しているリニアスペースである。リニアワークフローではこれを撮影(レンダリング)するときにガンマ補正をかけて、本来人間が知覚している色で出力する。

■デジタル画像とガンマ補正
普段取り扱っている画像はすべてガンマ補正が画像の色に焼き込まれている状態である。デジタルカメラで撮影した画像はほとんどがsRGB空間で補正されており、これはガンマ2.2に相当する。パソコンで描いた絵もそのモニターのガンマで最適化されている。例外なのは写真の生データであるRAWとHDR画像で、これらはガンマが1.0となっている。RAWの場合は編集ソフト側で撮影時のデータからガンマ補正がされるが、データそのものはリニアで保存されている。

■3DCGソフトで扱うテクスチャの問題
このようにすでに補正されているテクスチャを貼付けている場合(ほぼすべてがそうなんだけど)、ライトによる陰影はガンマ補正がされていないために問題となる。リニアワークフローを採用しようと思ってソフト環境をガンマ2.2にすると、ライティングは正しくガンマ1.0 -> 2.2 となるのに対し、テクスチャなどの既に補正されているものはさらにガンマ補正をすることになってしまうからだ。

■逆補正を行ってテクスチャをガンマ1.0に補正する
そのために、リニアワークフローで作業する場合には作業環境をリニアスペースに保つために補正されているテクスチャに逆ガンマ補正を行う。ガンマ2.2の画像を1.0にするには単純に1/2.2 = 0.4545… を掛ければ良い。
こうすることですべてがリニアスペースのカラーとなり、ライトへの反応も正しくなる。注意すべき点は補正するべきテクスチャはカラーに関係のあるものだけだということ。diffuse、specularColor、reflectionMapなどで、bumpやdisplacementには逆ガンマは不要。そもそもそれらはリニアスペースだから、明るくなってしまう。

■補正なし=ガンマ1.0の作業環境から補正あり=ガンマ2.2の作業環境へ
「リニアワークフロー」という単語で初め勘違いしていたのは、私自身の認識としては作業はリニアではなく、ガンマ補正がされているガンマ2.2の状態で行うということだ。3DCGソフトにもいろいろあるので、扱い方はそれぞれだが、リニアなのは内部的な話であって、レンダリングされる画像はばっちしガンマ補正されてる。つまり、この言葉の意味するのは「レンダリングする直前までの行程をリニアスペースで行う」という意味での「リニアワークフロー」である。3DCGソフトでの作業環境で起こる大きな変化は、全体的にマテリアル等が白っぽくなるという点だが、これはライトの光量を考えるとむしろ正しい結果だといえる。
これまでのCG制作でガンマ補正をしていない状態というのは、デジタルカメラで撮影した画像をガンマ補正せずにリニアスペースで見ていたということと同じで、最終的に補正を行って光を正しく(人間の目と同等の感度で見るという意味で)再現しよう、というのがリニアワークフローの中核である。
ただし、従来通りの方法でもライトをうまく使って光量そのものをあげれば十分に美しい絵を作ることができるのでリニアワークフローを採用しなければならない、というほどのことでは無いかもしれない。
唯一気に留めておきたいのは、テクスチャなどの素材は補正されているが、ソフトでライティングされて生まれる陰影は補正されていないということだ。このギャップを良しとするか、違和感を覚えるかはこれまた人それぞれかもしれない。


■導入にあたってのあれこれ
モニターをガンマ2.2に設定する。最近のモニターは大抵がsRGBを採用しているので問題は無いはず。MacでもOS10.6以降はデフォルトでガンマが2.2になっている。
テクスチャ素材に逆ガンマを掛ける必要がある。これは自動化スクリプトを作る等すればさほど問題ではない。さらに、これまでの色を数字で再現できなくなる点での慣れが必要になる。
リニアワークフローではレンダリングするまで正確な色は表示できない。ただしこれに関しては今までとさほど変わらないと思う。
カラーピッカーで選ぶ色はライティングによって初めて正しい色を返すということ。
真っ白と真っ黒に近い色はこれまでとさほどかわらない。中間色が大きく持ち上がる。
なんだかんだ言ってもやることは意外と単純で、複雑なプロセスは無い。理解が大事。
Maya2011からはMentalRay限定でカラープロファイルを設定できるようになっている。これによってテクスチャに逆ガンマ補正を掛けたり、レンダラーの出力ガンマを設定しなくてもすむようになっている。レンダリングが重くなるそうだが、未検証。従来通りのsoftwareRendererは手動で行う必要があるが、swではそもそもリニアワークフローで制作しないだろうなぁ。そういう理由でswには未対応なのだろう。ただ、手動でリニアワークフローを構築した場合と、カラープロファイルを指定して補正をする場合とでは若干手動のほうが明るくなる理由が分からない。
MentalRayの場合はgamma設定をframeBufferで指定すると、自動的にカラーテクスチャにその値で補正を掛けてくれる。簡単に試した結果、bumpMapには補正が入っていなかった。
露出系のユーティリティと併用するのが一番良い結果を生むらしい。ただ、建築などのビジュアライズと違い、メディアアートはそこを省いても良さそうである。
主に、光の回り込みを柔らかく表現したい場合、自然に感じられるような光の挙動を作りたい、という場合に導入を検討すればよい。

Ruben Mayer

Ruben Mayer
VFX TD/Artist




MaxScript が数点
Tutorial も少々

FumeFX のシミュレーションを複数同時に行えるスクリプト:
http://www.aespid.com/aespid/scripts/3ds-max/86-fumefx-multirun.html

2012年1月2日月曜日

Apple製品の新製品発売周期

統計を取って、Apple製品の新製品発売次期を予測しているサイト
過去の販売次期からの予測値で今買うべきかどうかの判断材料にする

Apple製品発売時期予測:
http://appledays.santalab.me/

元ブログ:
http://tools4hack.santalab.me/appledays_01.html

2012年1月1日日曜日

資料サイト リンク

■資料サイトリンク

--- SMCARS.NET 車の素材CGIと設計図のサイト。飛行機やその他の車両も少し。