<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>* little things of mine * &#187; ますお</title>
	<atom:link href="http://www.ousam.com/blog/author/masuo/feed" rel="self" type="application/rss+xml" />
	<link>http://www.ousam.com/blog</link>
	<description>色々書けたらイイと思う</description>
	<lastBuildDate>Wed, 28 Jul 2010 03:19:43 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Alembic</title>
		<link>http://www.ousam.com/blog/2010/07/27/627</link>
		<comments>http://www.ousam.com/blog/2010/07/27/627#comments</comments>
		<pubDate>Wed, 28 Jul 2010 03:19:43 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=627</guid>
		<description><![CDATA[SIGGRAPH2010開催中のホットニュース．
Alembic
こちらでtaikomatsuさんが和訳されています．
Alembic &#8211; memlog
AlembicはILMとSPIが共同で開発及び公開した，アニメーションをシーケンシャルジオメトリにbakeするためのC++ライブラリです．&#8221;alembic&#8221;という単語には浄化器，蒸留器という意味があるそうで，必要な物だけを抽出する，というようなニュアンスですね．
ライティングやエフェクトはアニメーションされたシーンを元にして作業するのが普通なのですが，アニメーターがアニメートしたままの状態だと，リグやその他たくさんのアニメーション以外には必要のないデータも含んでいるし，何しろリグを毎回プロセスするのは色んな作業の邪魔になります．エフェクトなんかはそうでなくても重い作業が多いですからね．シーンも不安定になります．そもそもツールが別でリグが渡らない事も多い．そのため，ある程度の規模のスタジオでは，内部で特定のデータフォーマットを使ってbakeしたアニメーションをやり取りする事が多いのですが，Alembicはそのデータフォーマットとして使う事ができます．
シーケンシャルジオメトリのデータフォーマットは，今までこれといった決めてがなくて各スタジオがそれぞれ試行錯誤していると思います．GTOもかなり良さそうに思っていたのですが，AlembicはILMが絡んでいる事からして，GTOを更に改良した物（GTOは元々ILMで使われていた）と考えていいのかも？だとするとこれは良い候補になりそう．
ただ，こう言ったプロセスは，ある程度のパイプラインがあって，開発サポートが期待でき，大きなシーンやショット数をこなす必要がある場合に必要になる事だと思うので，規模の小さな場合は逆に手間になってしまう可能性もあると思います．あと，日本の某社の方に教えられたのですが，小さい所ではストレージとネットワークがネックになってしまうとも言っておられました．
今の所，ライブラリの使用例としてMayaのimporter/exporterプラグイン，PRManのprocedural primitive DSO，GTOからのコマンドラインコンバータ，その他ユーティリティがライブラリと一緒に公開されているようです．Pythonバインディングも一応あるようですが，これはまだまだこれからという雰囲気．
Houdiniのプラグインもないが，これは自前でやれという事か．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/07/27/627/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>IRON MAN 2</title>
		<link>http://www.ousam.com/blog/2010/06/22/624</link>
		<comments>http://www.ousam.com/blog/2010/06/22/624#comments</comments>
		<pubDate>Wed, 23 Jun 2010 07:17:52 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[映像作品]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=624</guid>
		<description><![CDATA[&#8220;IRON MAN 2&#8243;を観てきました．
Iron Man 2 &#124; Trailer &#038; Official Movie Site &#124; Now Playing
んー．なんと言いましょうか．正直に言いましょうか．
「つまんなかった」
映像は良かったのですが，ストーリーのダルさが映像を楽しむのを邪魔してる感じ，と言えばいいかな．普通，逆な事が多いと思うんですけど．1の方がキレがあって断然良かったと思います．
VFXはメインがILMとDouble Negative．その他に結構な数のスタジオが参加していました．そのせいかも知れませんが，出来に少々バラツキがあったように感じました．コンプの甘いショットも結構あった．バトルシーンは物量増えたにも関わらず，流石にクオリティ高かったです．恐らくはメインの二社によるものでしょう．
最後の終わり方からすると，3もありそうですね．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/06/22/624/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>PRManとmentalrayのマイクロポリゴン</title>
		<link>http://www.ousam.com/blog/2010/05/03/617</link>
		<comments>http://www.ousam.com/blog/2010/05/03/617#comments</comments>
		<pubDate>Mon, 03 May 2010 09:07:08 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=617</guid>
		<description><![CDATA[twitterで話題になっていたので，まとめようと思います．
この話は突き詰めると，Reyesとレイトレという根本的なレンダリングアルゴリズムの違いに帰着するのですが，まあここではPRManとmentalrayという事にしておきます．あと，最初に言っておくとV-Rayやその他最近のレイトレレンダラは色々と進歩していて，ここで書いている事は必ずしも正しくない場合もあると思いますが，基礎してとらえて下さい．
マイクロポリゴンというのは，何か特別なポリゴンを指す訳ではなく，そのサイズが大まかにピクセルと同じかそれよりも小さいサイズの物をそう呼ぶ事が多いようです．そういう意味では，PRManとmentalrayのそれは違いがありません．強いて言えば，PRManのマイクロポリゴンはquad，mentalrayのはtriangleという事くらいです．
さて，ではどこに大きな違いがあるのかというと，まずその生成のされ方に違いがあります．
PRManはbucket毎に処理を行い，NURBSでもポリゴンでも，全ての種類のジオメトリをbucketのサイズに近いサイズまで一度分割します．これをsplit processと呼びます．その後，スクリーンに入っているかどうかの判定をして，もし入っているようなら，今度はsplitされたジオメトリを更にマイクロポリゴンまで分割します．これをdice processと呼びます．
この時点ではまだ各マイクロポリゴンはバラバラではなく，メッシュ状態を保っていて，マイクログリッドと呼ばれる事もあります．なぜメッシュである必要があるのかというと，PRManではこの後にDisplacement shaderが実行され，各マイクロポリゴンの頂点が移動する可能性があるからです．メッシュでなければ，動かした所が割れてしまいます．
次に各マイクロポリゴン毎にSurface shaderを実行し，シェーディングします．PRManのマイクロポリゴンはシェーディングされるジオメトリの最小単位です．一つのマイクロポリゴンは一色にflat shadingされます．この後にメッシュはバラバラにされ，各マイクロポリゴンの前後判定と，どのピクセルに含まれるかを調べます．これが1 bucket毎に起こる処理の（大まかな）内容です．
一方，mentalrayは（scanlineモードもあったりしますが）基本レイトレーサですから，ポリゴン分割はレイとの交差判定が起こる前に終わっている必要があります．そして，その分割処理はオブジェクト単位で行われます．PRManのようにbucket毎に分割はしません．しかし，最近のmentalrayには分割処理の方法にfine approximationというモードがあり，PRMan「みたいな」処理をします．つまり，元のジオメトリをある程度の大きさに分割（PRManでいうsplit）し，更にそのサブジオメトリを再分割します（同 dicing）．この場合，サブジオメトリは個別のbounding boxを持つので，レイが交差判定しようと試みたサブジオメトリだけを再分割すればよく，オブジェクト全体を割るよりは効率的になります．結果，分割数を上げる事ができるので，fineなディティールも出せるというわけですね．
分割の後，Displacement shaderが実行されるのはPRManと同じですが，Surface shaderは各ポリゴン毎に実行されるわけではなく，純粋にカメラレイが当たった交点で実行されます（実はこの違いはReyesとレイトレのそれぞれを象徴する重要な要素なのですが，その話はそれだけで長くなりそうなので，またいずれ）．
余談ですが，mentalrayには他にも，面のcurvatureを基準にしたり，視線との角度を基準にしたりと様々な分割モードがあって，ユーザがその場に応じて使い分けられるようになっています．設定次第ではピクセルサイズまで分割する事もできます．ただ，adaptiveな分割はうまく動かないケースが結構あったりして頻繁に変更しなければならないし，一番の問題はアニメーションの途中で分割のされ方が変わってしまうため，フレーム毎にシェーディングの結果が違う場合があるのです．これが理由で自分はadaptiveな分割はほとんど使った事がありません．
さて，一次レイ（カメラレイ）に関してはこんな感じなのですが，二次レイ（反射や屈折，GIレイなど）になるとまた色々と面倒な話になります．
PRMan方式は基本的にレイトレと相性がよくありません．カメラからのレンダに関してはピクセルという明確な区分領域があるのでうまく動くのですが，レイは数学的に「線」ですから，領域がありません．つまり，ピクセルのサイズという大前提が崩れるのです．bucket毎に処理単位を分ける事もできません．今でこそPRManでも普通にレイトレが使えますが，マイクロポリゴンをそのままトレースする訳にもゆかず，様々なhackでどうにか形にしている感じです．
これは予想ですが，PRManでは二次レイが当たったジオメトリはピクセルサイズまでは分割していないと思います．もっと荒いはずです．これはテクスチャを張ったオブジェクトを鏡に映してみるとわかります．結構像がボケます．以前は二次レイから見たジオメトリの大きさを推量するためにconeを使っていると聞きましたが，今ならray differentials的な何かを使っているのではないでしょうか．
この点，mentalrayは基本がレイトレーサですから，別に二次レイが飛ぼうがなんだろうか，基本的には何も変わりありません．せいぜい，たくさんのレイがオブジェクトに当たりまくって，大量のポリゴンを保持するために多くのメモリを必要とするくらいです．メモリが必要なのはPRManも同じですからね．
と言うことで，一口にマイクロポリゴンと言ってもその使われ方には大きな違いがあります．displacementのディティールという意味ではあまり違いがないように感じるかもしれませんが，ディティールの善し悪しは分割数だけではなく，ジオメトリをどのようにサンプルするかが非常に重要なので，ポリゴンのサイズだけでは語れません．今のところ，displacementのディティールはmentalrayでピクセルサイズまで割っても，まだPRManに分があるように思います．
このテの話は色んな方面からツッコミが来そうで怖いのですが，とりあえずこれにて．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/05/03/617/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>DD Vancouver</title>
		<link>http://www.ousam.com/blog/2010/04/26/615</link>
		<comments>http://www.ousam.com/blog/2010/04/26/615#comments</comments>
		<pubDate>Mon, 26 Apr 2010 20:13:51 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[仕事]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=615</guid>
		<description><![CDATA[出張で一週間ほど行って来ました．
新しく準備したスタジオなだけあって，Venice本社よりも設備は良かったです．マシンもネットワークも速い．モニタもいい物使ってました．ビル自体は結構古い感じがしましたが，中はちゃんと作り直されていてきれいでした．
あと，まだ人が少ないせいもあると思いますが，一人分のスペースが広い．Veniceの倍くらいあるんじゃないかなあ．キューブとデスク自体が大きいんで，人が増えても狭くなる事はないんじゃないかと思います．Veniceで窮屈な思いをしている人は多いので，うらやましい．
それに一番いいのは，Vancouverという街が良い所って事でしょう．誰かに聞いた話ではどこぞの「世界の住みやすい街ランキング」でトップだったとか何とか．公共の交通手段がよく整備されているし，街も綺麗で自然も多い．道路もLAのようにデコボコじゃありません．あと，食事がなんでも美味しい！アジア人が多いので，食材なんかも楽に入手できます．
今，VancouverにはたくさんのCG/VFXスタジオがあります．DD，MPC，ImageEngine，Pixar，Imageworks，Rainmaker，EAなどなど．就労ビザや永住権もアメリカに比べると遥かに取りやすいそうですし，これから海外へ出ようと思っている方にはお勧めできると思います．
自分もちょっと考えよう．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/04/26/615/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>82th Academy Awards Winners</title>
		<link>http://www.ousam.com/blog/2010/03/09/611</link>
		<comments>http://www.ousam.com/blog/2010/03/09/611#comments</comments>
		<pubDate>Tue, 09 Mar 2010 10:12:12 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[時事]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=611</guid>
		<description><![CDATA[さて，今年の受賞作品は．
Nominees &#38; Winners for the 82nd Academy Awards &#124; Academy of Motion Picture Arts &#38; Sciences
AVATAR，Visual Effectsはガチでしたけど，他は思ったほど獲りませんでしたね．個人的には納得できますが，え？って思ってる人も多いかも？あと，Animated Feature FilmはCoralineに獲って欲しかった．District9が受賞無しなのもちょっと残念．
6部門を受賞したHurt Lockerという作品，自分は観てません．そんなのあったっけ？ってくらい記憶から消えてます．それもそのはず，boxoffice的には全然振るわなかったようですね&#8230;　今度観ておこう．
The Hurt Locker (2009) &#8211; Box Office Mojo
一方のAVATARは，Titanicが持っていた歴代一位の座を奪いました．James Cameronすごい！
All Time Worldwide Box Office Grosses
ただし，チケットの値上げ分を考慮するとまた違う結果になるそうです．
All Time Box Office Adjusted for Ticket Price Inflation
もう一つのAcademy，Sci-Tech Awardsの結果はこちら．
Scientific &#38; Technical Awards Winners &#124; Academy of Motion Picture Arts &#38; Sciences
今年はcolor management技術関連と，film [...]]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/03/09/611/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PRMan 15</title>
		<link>http://www.ousam.com/blog/2010/02/28/603</link>
		<comments>http://www.ousam.com/blog/2010/02/28/603#comments</comments>
		<pubDate>Sun, 28 Feb 2010 09:36:48 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=603</guid>
		<description><![CDATA[今更ながらPRMan15の話題など．
Pixar&apos;s RenderMan® / Press Releases
いろいろな追加機能があるのですが，目立った物だけ紹介します．
[ Volume Rendering ]
今回のバージョンで一番大きな追加機能はこれでしょう．PRManにモダンなボリュームレンダリングの仕組みが搭載されました．今までもボリュームをレンダリングする事は可能でしたが，「モダンな」と言うところが鍵です．
ボリュームレンダリングと言えば，視線（ray）に沿ってdensityを積分してゆくray marchingが一般的ですが，これはサンプル数が十分でないとノイズが出やすく，ディティールも再現できないので，サンプル数を上げざるを得なくなり，その結果時間がかかってしまうものでした．
PRMan15に搭載されたのは，frustum voxelを使った手法です．これは，通常のvoxel gridにperspectiveをつけたものと考えてもらえばいいかと思います．つまり，カメラに近い方が小さく狭く，遠くなるにつれて大きく広くなっているvoxel gridです．このようなvoxelを事前に生成し，次にそれぞれのvoxelにおいてシェーダを実行して各々のvoxel densityを計算，そのあと視線に沿ってdensityを足し算します．
イマイチわかりにくいと思いますので，ray marchingと処理手順を比べてみます．ray marchingは，「初期ポイント→次のシェーディング点を探す→シェーディング→足し算→初期ポイントを移動」という処理をボリューム内部において延々と繰り返す必要があったのですが，frustum voxelの場合，「voxel grid生成→一度に全部シェーディング→足し算」とシンプルになります．また，シェーディング結果がシェーディングポイントの決定に影響を与えないので，並列化もできます．サンプリングポイントをdynamicに決められない事が欠点のように思えますが，frustum voxelは近い所をより多くサンプルするようになるので（voxelが小さくて狭いから），効率の良いサンプルが可能なのです（もちろんパラメータでの調整もできる）．
軽くテストしてみましたが，レンダリングも高速で，非常に良い結果が得られました．point cloudと相性が良いのも実作業では大きな武器になるでしょう．scatteringとかやれますからね．
[ Struct Inheritance and Member Functions ]
RSLで，structがメンバ関数を持つ事ができ，さらに継承ができるようになりました．これはshader writerにとっては非常にうれしい事で，シェーダの機能をオブジェクト指向っぽくモジュール化する事ができます．今までは関数にするしかなかったので，これは大きな進化です．
実際にこれをフルに使ってshader libraryのプロトタイプを書いてみましたが，かなり奇麗に書く事ができました．一部制限があって（関数をインターフェイスにできない），小さなhackも必要でしたが，全体的に見通しも良くなりましたし，拡張も継承を使って楽にできるはずです．あとは使う人達がどう感じるか，かな．
[ Ray Differentials Shadeop ]
ようやくray differentialsがシェーダ側で取得できるようになりました．新しいRSL関数，raydifferentials()が追加になっています（ray differentialsについては以前の記事を参照してください）．恐らくこれに伴った機能追加だと思うのですが，filterregionという，pre-definedなstructが用意されました．これはあるシェーディングポイントにおいて，適切なfilter sizeを2D/3Dで計算して返してくれるクラスです．PRManは以前でもtexture filteringのクオリティは高い方でしたが，さらに良くなるようです．特に二次レイ以降の結果向上は顕著だろう思いますが，まだテストし切れていません．
[ Ptex ]
Ptexについては前回の記事を参照してください．
こんなもんでしょうか．他にも開発系の機能追加が多くあるのですが，今回も「使える」機能がたくさん追加されました．思わず「いいねえ」と言いたくなります．
さて，あとは実践投入だ．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/02/28/603/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ptex</title>
		<link>http://www.ousam.com/blog/2010/01/17/597</link>
		<comments>http://www.ousam.com/blog/2010/01/17/597#comments</comments>
		<pubDate>Mon, 18 Jan 2010 04:25:15 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=597</guid>
		<description><![CDATA[DisneyからPtexのコードがリリースされました．
Ptex Overview
PRMan 15.0でPtexがサポートされたので，その他の新機能を含めてまとめて書こうと思っていたのですが，思ったよりも早くDisneyからソースコードがリリースされたので個別に紹介したいと思います．
texture mappingは，現在広く使われているUVベースの物が開発されてから，恐らく40年以上，基本的なアイディアは変わらずに来ました．逆に言えばそれだけrobustなものであったとも言えるわけですが，実用レベルでの様々な問題を長年解決できていなかった事も事実です．それらはこのブログでも何度が取り上げた事がありますが，アンチエイリアス，UV空間と実モデルのボリュームの違い，どんなモデルでもUVをきちんと作らなければならない事，などです．
Ptexは，Disneyが2008年にEurographicsで発表した，新しいtexture mappingに関する手法およびデータフォーマットで，上記で挙げたような実作業上の問題をできるだけ解決すべく，Disney内部で開発された技術です．Ptexはper-face texture mappingの応用にあたる物と言えるので，細かい事を言えば「UVテクスチャ以来の新技術」というのは言い過ぎかも知れませんが，実用可能なレベルまで改良を施し，きちんと作品に還元できている点で，非常に評価できると思っています．元論文はこちらあります．
Ptex: Per-Face Texture Mapping for Production Rendering
特徴を挙げると：
- UVフリー
- seam問題の解決を含む高品質なアンチエリアス
- 部分ごとに解像度を調整可能
- 効率的なデータストレージ
詳しい仕組みは論文を読んでいただいた方が良いと思いますが，乱暴に言えば，ポリゴンフェイス毎に個別なUVを持ち，それぞれ違う解像度のテクスチャを充てている，と想像してもらえれば分りやすいと思います．全ポリゴンがそれぞれ個別なUVを持っているわけですから，テクスチャ座標を人間が作ってやる必要はありません．ポリゴンモデルができた時点で，全てtexture readyになるわけです．（それぞれのフェイスのUVは頂点ループの順番で固定できます）
Ptexではそれぞれのper-face textureを全て一つにファイルに保持し，加えてメッシュの繋がり情報を保存しておく事で，複数のフェイスに跨がったフィルタを解決しています．それぞれのフェイスが別の解像度を持つ事は，必要な部分だけ解像度を高くする事ができるわけで，ファイルサイズの節約になりますし，アンチエリアスもディティールを殺さずに済みます．
Disneyではprocedural patternもPtexに焼いているようです．個人的にこれはとてもいいアイディアだと思います．焼いてしまうとシェーダレベルで変更ができなくなるので逆行しているように見えますが，procedural patternは，voronoi diagramなど，物によって非常にアンチエリアスの難しい物があるので，むしろテクスチャに焼いてしまった方が問題が少なくなるケースも少なくないのです．
さて，とても良さそうなPtexですが，スタジオレベルでの大きな問題が一つあって，それは「Ptexをどうやって作るか」という事です．
Ptexの利点を最大限利用するには，フェイス毎にテクスチャをペイントする必要があります．Disneyでは自前の3D paintプログラムを開発してこれを解決したようですが，これはどこでもできる事ではありません．
しかし，個人的にはこれには楽観視していて，PRManがすでにPtexをサポートしている事と，今回DisneyがPtexのライブラリとそのソースコードを公開した事で，比較早い時期にZBrushやmodo，BodyPaintのようなツールがPtexをサポートするのではないかと思っています．そうなれば普及は早そうです．
最近のVFX業界は，技術がどんどん（有償無償問わず）オープンになってきていますね．技術の均一化によって値段が更に下がり，単純作業はコストの安い海外へアウトソースされて行きます．これからは単一の技術が生き残る要因にならず，パイプラインのコア技術や優秀な人材など，スタジオの地力みたいなものが効いてくる時代になって行くのでしょう．
なかなか厳しい時代になりそうです．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/01/17/597/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Open Shading Language</title>
		<link>http://www.ousam.com/blog/2010/01/14/595</link>
		<comments>http://www.ousam.com/blog/2010/01/14/595#comments</comments>
		<pubDate>Fri, 15 Jan 2010 04:16:27 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=595</guid>
		<description><![CDATA[OSLのソースと詳細がアップされたようです．
fxguide quick takes » Sony Releases Open Source Shading Language
openshadinglanguage &#8211; Project Hosting on Google Code
ドキュメントのみサラッと読んでみましたが，RSLとは見た目こそ似ているものの，設計は随分違いますねえ．このままPRManが今のまま同じ仕様をサポートするのは難しいでしょう．まあ，逆に言えば古いしがらみに捕らわれていない分，新しい事ができる土台になると思います．シェーダがclosureであるとか，light samplingはレンダラ側でやるとか，色々と興味深い．
ソースコードにはコンパイル済みシェーダの実行環境もライブラリとして含まれています．これを使って自分のレンダラにOSLを組み込む事ができますし，relightingツールなんかも作れそうですね．
今後の成長が楽しみであります．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/01/14/595/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>AVATAR</title>
		<link>http://www.ousam.com/blog/2010/01/08/593</link>
		<comments>http://www.ousam.com/blog/2010/01/08/593#comments</comments>
		<pubDate>Sat, 09 Jan 2010 04:51:33 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[映像作品]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=593</guid>
		<description><![CDATA[はい，観てきました．
Avatar Official Movie Website &#124; In Cinemas December 18
ストーリーに関しては，あまり意外性がなかったな，という印象．予想される展開がずーっと続いて，そのまま終わった感じでした．まあ，blockbuster映画のほとんどは同じなんですけど，前評判のせいで無意識のうちに期待してしまっていたのかもしれません．
映像は一言で言うと「前代未聞の密度」と言えると思います．正直言うと，巷で言われるほど革新的なものを感じたわけではありませんでしたが，物の量，動きの細かさ，視覚的な複雑さは物凄いものがありました．あのふざけた密度のジャングルとか，もうアリエナイ．今年のオスカーは決まりでしょう．
キャラクターもメチャメチャ良くできてましたね．合成もほぼ完璧．馴染ませるために実写の方をいじっているようなショットもありましたから，どこまで本物かもうわかりませんけどね．
今回はRealD方式の立体視で観たのですが，自分はやはり奥行き感がショット毎に変わりまくるのが苦手なようで，軽く酔ってしまいました．機会があれば通常版で観直してみたい感じ．IMAX3DとかDolby3Dだともっとマシなんでしょうかね？でも，焦点位置までの距離がスクリーンまでの距離に強制的に固定されるのは変わらないんじゃないかと思うんですが，どうなんでしょう．
以下ポインタです．
Weta Digital Avatar
ZBrushCentral &#8211; Avatar
Player CANAL+
YouTube &#8211; Avatar Human Hardware Featurette
映画「アバター」制作の舞台裏&#8211;リアルな視覚効果を生み出した2大スタジオの共同作業:スペシャルレポート &#8211; CNET Japan
boxofficeも快進撃中ですが，どこまで行くでしょうねー．James Cameronは自己記録を塗り替える事ができるでしょうか？
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/01/08/593/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>一年の計は元旦に在り – 6</title>
		<link>http://www.ousam.com/blog/2010/01/01/590</link>
		<comments>http://www.ousam.com/blog/2010/01/01/590#comments</comments>
		<pubDate>Fri, 01 Jan 2010 23:14:26 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[御挨拶]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=590</guid>
		<description><![CDATA[謹賀新年
もう六年目かあ&#8230;
昨年は，仕事の面ではあまり成長できなかった気がします．プロジェクトが不遇だったのもあり，新しい事をほとんどやれませんでした．
今年は何か違った事にチャレンジしたいと思っていますが，さて如何に．
本年もどうぞ宜しくお願い申し上げます．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/01/01/590/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
