<?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; Computer Graphics</title>
	<atom:link href="http://www.ousam.com/blog/category/computer-graphics/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>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>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>BAKERY RELIGHT™</title>
		<link>http://www.ousam.com/blog/2009/11/05/580</link>
		<comments>http://www.ousam.com/blog/2009/11/05/580#comments</comments>
		<pubDate>Fri, 06 Nov 2009 01:20:40 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=580</guid>
		<description><![CDATA[レンダラ込みのrelightingツールだそうです．
The Bakery
デモを見せてもらったのですが，まだリリース版ではないものの，とてもよく出来ていました．簡単に言ってしまえば，先日のKatana + renderer + relighting engineと言った趣きです．Katana同様，簡単なcompもできるようになっています．レンダラは専用で，外部の物（PRManとか）を使うことはできないそうですが，専用のレンダラを使うだけあって，ツールとrelightingエンジンとの連携は素晴らしく良かったです．
レンダラはREYES + レイトレで，必要そうな機能はほぼ実装済みな感じでした．curve primitiveやpoint primitiveも使えるそうです．relightingのシステムとしては，レンダラがREYESであることからも分かるように，初めにmicro polygonに分割し，その情報をキャッシュしておいて，シェーディングとサンプリングの再計算を高速にするタイプの物です．PRManのそれと基本的には同じですが，PRManよりもいろいろな事ができるようになっていました．（というかPRManのrelightingはまだオマケみたいなもん）
最初にカメラからmicro polygon化してしまうので，視点の変更が起こるともう一度bakeし直す必要がありますが，実際のshot workではあまり問題にはならないでしょう．カメラは動かせませんが，displacementシェーダの変更には対応しているそうです．shadowも変更できるようですが，shadow mapが基本なようで，レイトレを使うとさすがに多少スピードダウンしてました．他にも，SSSやGIの変更にも対応していますが，これらはpoint cloudを使っていて，それをon-the-flyで再生成するのですが，オブジェクト毎にうまくローカライズされており，非常に素早いフィードバックが得られるようになっていました．他にもspherical harmonicsを使ったlighting情報をpoint cloudに保存できるなど，なかなか使いでのありそうな機能が搭載されています．例えば，IBLとかblurry reflectionに使えますね．
拡張性もなかなか良さそうで，shading networkも組めるし，custom shaderもC++や独自のshading languageで書けるそうです．procedural geometryもサポート．bakeするデータもカスタマイズ可能で，好きなデータをプラグインできるらしい．
話を聞いていて，PDIのやつに良く似てるなーと思っていたのですが，どうやらCEOとCTOは元PDIの人らしい．デモをしてくれたのも彼らだったのですが，同僚に顔見知りがいました．特にCEOはeffects leadだったようで，現場で必要そうな物をきちんと揃えているのはそういうことみたいです．
ただし，全体的にやはり3DCG feature向けな印象が強く，shadow mapやpoint cloudを多用する辺り，photorealにするには一手間かかりそうな感じはします．あと，ツールとレンダラがほぼ一体化しているので，既存のパイプラインに組み込むのが簡単ではないかな．ほぼ構築し直しになりますね．
自前で作る時の良いお手本にはなりそうです．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/11/05/580/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>iray</title>
		<link>http://www.ousam.com/blog/2009/10/02/574</link>
		<comments>http://www.ousam.com/blog/2009/10/02/574#comments</comments>
		<pubDate>Fri, 02 Oct 2009 23:05:32 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=574</guid>
		<description><![CDATA[発表されましたね．
mental images: Integrated iray® rendering
少し前に会社でデモをしてもらったのですが，技術としてはなかなか興味深い物でした．特徴を挙げるとすれば：
- フルにGPUで動くpure raytracer
- レンダリングサーバと表示マシンはどこにあってもOK
- ウェブブラウザからも起動できる
- ほぼリニアにスケール
ただ，今のところかなりプリミティブな物のようで，製作に使えるような代物ではなさそうでした．例えば：
- カスタムシェーダーが使えない（付属の数種類のみ）
- テクスチャはすべてGPU側でon memoryでなければならない
- no motion blur
あと，要求されるレベルのグラフィクスカードがあればサーバなしでも動くそうですが，$2000クラスの物が必要なんだとか．作業マシン全部に入れるには厳しい値段だし，それなら同じ金額でマシンをもう一台買いたいところです．
まあ，mental imagesが管理しているmentalrayライセンスの中で，entertainment業界が占める割合はかなり低いようですから，irayが即戦力になる市場もそれなりにあるんだと思います．建築業界なんかモロですよね．
GPUレンダラ関連は，まだうちらには早いかなー．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/10/02/574/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>CinemaDNG</title>
		<link>http://www.ousam.com/blog/2009/09/16/572</link>
		<comments>http://www.ousam.com/blog/2009/09/16/572#comments</comments>
		<pubDate>Thu, 17 Sep 2009 02:09:39 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=572</guid>
		<description><![CDATA[CinemaDNGは，デジカメで使われるDNGフォーマットの動画版です．
アドビ、高画質RAWビデオ規格「CinemaDNG」のベータ版を公開 &#8211; builder by ZDNet Japan
これからデジタルにシフトして行くであろう映画産業においても，こういった規格の統一はなされた方がいいとは思いますが，Adobeって実はハイエンドだと出番少ないんですよね．最後の編集をPremiereでやった，ってのはあまり聞かないですし．
静止画向けのDNG形式も一般に普及しているとは言い難いし，これもどうかなあ．支持している企業のリストにSony，Panasonic，RED，Thomson等がありませんしねえ．ただ，今のデジカメ業界のように，新しい機種が出る度に個別対応しなければならないのは馬鹿げてると思うので，早いうちに統一されて欲しい．
AvidとかAutodeskも参加してくれば，もう少し動きが大きくなりそうです．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/09/16/572/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Maya Composite</title>
		<link>http://www.ousam.com/blog/2009/08/03/559</link>
		<comments>http://www.ousam.com/blog/2009/08/03/559#comments</comments>
		<pubDate>Mon, 03 Aug 2009 20:09:04 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=559</guid>
		<description><![CDATA[AfterEffectsの終焉か？
&#8230;まあそんな事はないと思いますけど．
Maya 2010が発表になり，以前&#8221;Toxik&#8221;として売られていたノードベースのcompositeツールが，Mayaにバンドルされることになったそうです．ついでにcamera trackerも．
fxguide quick takes » Toxik RIP (sort of) + New Maya 2010
Autodesk &#8211; Autodesk Maya 2010 &#8211; Features
個人的に，こういった2Dワークは日本で最も遅れている部分だと思うのですが，イチからパイプラインを構築するのは相当大変で，経験者も開発者も必要になります．そしてそういう人材は日本にはあまりいない．でも，ある程度ツールにインテグレートされていれば随分楽になるでしょう．
まだ最初の段階なので粗も多いでしょうけど，だんだんとmentalrayとの連携も強化されていくんじゃないかと思います．&#8221;all in one&#8221;としての強みを生かしきって，2Dと3Dを行き来できるような，上手いpackagingを期待したいですね．
更に，Maya 2010からはUnlimitedとCompleteの区別がなくなったみたい．つまり，アップグレードすればもれなく皆さんにTokix，という事に．これはスバラシイ！日本のプロダクションなんかでは重宝されるんじゃないかな．
是非，活用してもらいたいと思います．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/08/03/559/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>RSL 2.0</title>
		<link>http://www.ousam.com/blog/2008/09/02/524</link>
		<comments>http://www.ousam.com/blog/2008/09/02/524#comments</comments>
		<pubDate>Wed, 03 Sep 2008 01:30:17 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2008/09/02/524</guid>
		<description><![CDATA[久しぶりに技術系の話題を書きます．とは言え，かなり現場寄りな話ですが．
PixarのPhotorealistic RenderMan（PRMan）は，13.5からRenderMan Shading Language（RSL）が大改良され，後方互換性はあるものの，今までとはまるで違うshading systemが構築できるようになりました．以下ではこれをRSL 2.0と呼ぶ事にします．
ネットにはまだあまり情報がないようですが，以下で概要を知る事ができます．
RSL &#8211; Introduction to Shader Objects
最も大きな変更点は，シェーダをクラスとして記述できるようになった事です．クラスのメソッドとしてsurface()やdisplacement()などを実装してやると，マテリアルとして機能するようになります．pre-definedなメソッドは他にもいくつかあり，それぞれ適切なタイミングでレンダラから呼ばれます．つまり，カスタムシェーダを定義するには，これらのpre-definedなメソッドをoverrideすれば良い，と言うことになりますね．
また，シェーダクラスはメンバ変数を持つ事もできます．このメンバ変数は同じクラス内のメソッドからは等しくアクセスする事ができるので，シェーダ間での値の受け渡しが非常に楽になります．分かりやすい例としては，surfaceシェーダとdisplacementシェーダで同じノイズの値を使いたい場合，今まではmessage passingやoutput変数でやりとりしていましたが，これを単純なメンバ変数へのアクセスで行えます．
クラスですから，もちろん独自のメソッドも定義できます．ただし，これらのメソッドはレンダラから自動的には呼ばれず，明示的に呼んでやる必要があります．これだと今までの関数とあまり変わりなさそうに思えますが，これは次に紹介する新機能で生きてきます．
クラスとして記述されたシェーダは，.rib内で&#8221;Shader&#8221;という新しいstatementでインスタンスされます．C++で言う所のオブジェクトですね．シェーダオブジェクトです．RSL 2.0では，新しく&#8221;shader&#8221;という型と，shader型の値を返すgetshader()関数が導入されました．これは.rib内でインスタンスされた任意のシェーダオブジェクトに，別のシェーダ内からアクセスするための仕組みで，更に&#8221;-&#62;&#8221;演算子を使う事でそのシェーダオブジェクトのメソッドを呼ぶ事ができます．アクセス権が許せば，メンバ変数へのアクセスも可能です．
RSLをガッツリ書いた事のある人ならもう気づいたでしょう．これらの仕組みを使うと，簡易的なshading networkを組むことができるのです！Yay！
今までmonolithicなシェーダしか書くことができず，ルーチンの関数化はできても，テクスチャ一枚，ノイズ一つ足すのにコードから変更しなければならなかったRSL 1.0に比べると，これは革命です．dynamic arrayと合わせれば，任意の数のマテリアルをレイヤーすることもできます．
他の大きな利点としては，これらの仕組みによってarealightを楽に記述できるようになりました．PRManはarealightをサポートしておらず，illuminance()ループ内では一つの光源につき一つの(L，Cl)しか返ってこないので，RSL 1.0では全てのlight sampleをmessage passingで無理矢理渡し，自前のlight loopを書く必要があったのですが，RSL 2.0では全てを素直に実装する事ができます．
PixarのプレスリリースでILMのChristophe Heryがこんな事言ってますが，もうまさにその通り！です．
But for us, the most important feature is the modernization of the shading language, allowing us to produce cleaner, yet more efficient shader code, in particular, area light shaders and the layering of complex [...]]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2008/09/02/524/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SIGGRAPH 2008</title>
		<link>http://www.ousam.com/blog/2008/08/23/521</link>
		<comments>http://www.ousam.com/blog/2008/08/23/521#comments</comments>
		<pubDate>Sun, 24 Aug 2008 01:05:48 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2008/08/23/521</guid>
		<description><![CDATA[遅くなりましたが，SIGGRAPH 2008の感想など書いてみます．
今年は仕事の都合上二日しか参加できず，見たかった物もほとんど見られなかったのが残念．人にもあまり会えなかったし．以下，少ない中でも印象に残った物を．
[ Technical Papers ]
&#8220;Real-Time Rendering&#8221;のセクションで，オフラインレンダリングにも応用できそうなアイディアがいくつかありました．&#8221;Hair and Realistic Rendering&#8221;はbeeさんの発表もあって是非見たかったのですが，スケジュールが合わず．見た人の話では，かなり良かったそうです．これとか凄かったらしい．
[ Talk ]
&#8220;To Trace or Not To Trace&#8221;が面白かったです．これも色々なヒントが発見できました．
[ Classes ]
&#8220;A Gentle Introduction to Bilateral Filtering and its Applications&#8221;が興味深い内容でした．Bilateral filterは，単純応用としてはノイズ除去などに使われるようですが，その他の応用例がバラエティに富んでいて面白かったです．あと，これも自分は見損ねたのですが，&#8221;Advanced Global Illumination Using Photon Mapping&#8221;の後半で発表された，volume renderingでのlightingを高速化する手法が凄かったそうです（元ネタはこれみたいですね）．
こんなもんですかねえ．やっぱりちょっと物足りなかったな．
今年は色々と再編されて何だか逆に分かり辛くなったような気がするし，Electric Theaterも分割されてしまっていたし，なんだかなあという感じでした．
来年はNew Orleansですが，自分はあまり好きな場所じゃないんですよねえ&#8230;
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2008/08/23/521/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IBL再び &#8211; 2</title>
		<link>http://www.ousam.com/blog/2006/12/17/465</link>
		<comments>http://www.ousam.com/blog/2006/12/17/465#comments</comments>
		<pubDate>Mon, 18 Dec 2006 06:54:42 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[Computer Graphics]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2006/12/17/465</guid>
		<description><![CDATA[必要な物を一通り作り終わって，基本的な部分は動きました．
予想よりも速度低下が防げて，light shader一つで完結できるような形が作れたのでそれは良かったのですが，PRManのシェーダを書いている時に大きな問題が判明．
PRManはシェーダレベルでarea lightをサポートしていない！
surface shaderから呼ばれたlight shaderは光源毎に一度しか呼ばれず，light shader内でいくら複数サンプルを取っても，各サンプル毎にはsurface shaderに返らないのです．これは即ち，surface shader内でサンプル毎のlight vectorとlight color(RSLでは&#8221;L&#8221;と&#8221;Cl&#8221;)が取得できない訳で，BRDFが正しく評価できません．
いくつか回避策があるにはあるんですが，shading systemとしてはどれも気持ちが悪いし，既にあるsurface shader全てを修正しなければなりません．いずれにせよ，パイプライン的に深い部分での変更になるので，少し話し合いが必要そうです．
うーん，やっぱりPRManはhackに弱い．できない事が多いです．その分敷居を下げているのは分かりますが，もう少しlow levelへのフックも用意してくれると嬉しいんですけどね．
この辺の仕組みはmental rayに分があります．
]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2006/12/17/465/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
