たけなか制作日誌

メジャーなリアルタイム手法を自分なりにまとめてみました。
(ただし自分があまり詳しくないマイナーな手法等は除いています)

[Diffuse]
・Lambert
・Burley
・Ashikhmin-Shirley
・Oren-Nayar

[NDF]
・Blinn-Phong
・Beckmann
・GGX

[Anisotropic]
・Ward
・Ashikhmin-Shirley
・GGX Anisotropic
・Kajiya-Kay
・Merchner

[Frenel]
・Schlick Frenel
・CookTorrance　Frenel

[GI]
・SH2次orMore(頂点orテクスチャベイク)
・SH1次(ボクセル)
・AmbientCube
・HemiShpereLighting
・RadiosityNormalMap
・LightMap

[HDR]
・RGBE
・RGBD
・RGBM
・LogLUV

GeometricShadowingについては数が多い上にどれが普及しているのかよく分かって
いないので明記しませんでした。というより、多くのゲームではGeometricShadowing=1
で計算していると思われます。

ちなみに何故こんなまとめを行ったのかというと、自分が最近になってようやくこれらを
実装(というより勉強)したからなのですが。理論については半分も分かっていない
かもしれません苦笑。色々一度に調べすぎて、、頭がこんがらがりそうです。

1個使えば後は必要ないといわれそうですが、これらの知識が理解できることで
昔読んで理解できなかった記事等が理解できるようになったり、現在のシーンでの
最適な手法を選択できたりするので覚えておいて損は無いなと思いました。

前回のモデルのテクスチャまでがだいたい出来たところですが。今回は何となくですが、
チュートリアル的な画像を用意してみました。画像の左上から順に説明すると、

・作成したスカルプトモデルをリダクション
・リダクションモデルを手動で修正してローポリモデルを作成
・AOテクスチャとマテリアル色のテクスチャを作成
・マテリアルテクスチャの上にAOマップをオーバーレイ合成+レベル補正
・合成したカラーテクスチャの上にAOマップを乗算して遮蔽効果を強める
・出来上がったテクスチャモデルにマップして完成。

ここから更にテクスチャの色味修正やらディテールを描き足さなければならないですが、
スカルプトモデルが完成していれば、ここまでは結構すぐに出来るので、気が向いた方は
是非試してみて下さい。

最近は色々考察していたことが多かったので、おまけにもう一つ考察メモを書いて
おこうと思います。こちらはCPUによる3D計算の話。かなり憶測な部分が多いので
冗談半分程度に読んでもらえれば幸いです苦笑。

最近のCPUであるIntel Corei7はHDグラフィックスという機能を用いてDirectX10.1
相当をサポートし、処理速度でいえばGeforce7の上位版もしくはGeforce8の下位版に
相当している訳ですが。これは従来のIntel CPUのように内臓GPUを搭載しているわけ
ではなくCPUで全て計算しているので、そのことを考えると「何でCPUでこんなに処理
できんの？」と思ったりした訳です。

まずGPUはCPUと比べて何故早いのかということについて考えてみると、GPUは複数の
ユニットを持ちそれらのユニットで並列に処理させており、なおかつベクトル処理を
まとめて1命令で実行できるように設計されています。つまりこれをCPUに置き換えると
マルチコア+マルチスレッド+SIMDということになる訳です。
Intel Corei7のSIMD命令は従来のSSEだけではなくAVXという256bit単位の処理
も可能となり、SIMDだけでいえばGPUと同等のはずです。問題はマルチスレッド処理
ということになります。Intel Corei7のコア数は8もしくは16なので「それらのスレッド全て
を使って並列に動作させ且つSIMDを使用した場合、ユニット数が16程度のGPUと同等
程度ということになるのでは？」と仮定し、ネットで調べてみたところ、Geforce7の
ユニット数は12-20程度とかなり似通っていることが分かりました。ということで、HD
グラフィックスはコア数が同程度のGeforce7の上位版と同程度の性能ということに
なるのではないかと思いました(CPU-GPU間転送とか考慮していない上にCPUには
GPUに無い処理スキップ用の機能があるのでアレですが)。
ちなみに最新のGPUのコア数は千幾つとかなので、CPUとGPUの差は縮まるどころ
か広がってます(そう考えると昔のGPUってそれほど大したものでもなかったんだなあ)。

将来的にコア数が32,64のCPUが登場した場合を考えてみると、Geforce8の上位版と
同等の性能になるのではないかと予想されます。
画像処理以外の計算もコア数分のスレッド+SIMDでかなり高速化するはずですが…
そんな大規模な並列処理って画像処理くらいだからなあ。とりあえず自前のレイトレー
サーを機会があれば高速化しようかなと思います。

今回はHLSLでよく使用すると思われる(？)計算式をまとめてみることにしました。
一部以前紹介した式と同じものがありますが、まとめ編ということでご勘弁を苦笑。

・xを1.0以上の場合は0.0にループ丸めしたいとき
　x = frac(x);

・x(>0)のa以下の範囲をb倍する
　x *= b * step(a,x);
・x(>0)のa以下の範囲を滑らかにb倍する
　x *= b * saturate(a-x)/a;

・x(>0)のa以上の範囲をb倍する
　x *= b * step(x,a);
・x(>0)のa以上の範囲を滑らかにb倍する
　x *= b * saturate(x-a)/(1-a);

・ブールbによる値切り替えb ? z=c : z=dをしたいとき
　z = b*c + (1-b)*d;
・ブール演算(等価)a == b ? z=1 : z=0をしたいとき
　z = step(a,b) * step(-a,-b);

・x(RGBA)をモノクロにする
　x = dot(float4(0.299f,0.587f,0.114f,0.0f),x);
・xをaでスクリーン加算する
　x = x + a - x * a;
・xをaでオーバーレイ合成する
　float Switch = round(a);
　x = x * a*2 * (1-Switch)
　+ (1 - (1-x) * (1-a)*2 ) * Switch;

今日は少し画像を綺麗に縮小する方法について調べてみました。

実はなんだかんだで3Dでは、テクスチャをゲーム用に縮小したり、
アンチエイリアスやピクセルシェーダでの処理に画像縮小
アルゴリズムが必要になってくるんですよね。。
ネットで調べてみると色々な画像縮小のアルゴリズムがあるようで、
やはり試してみたソフトによって縮小時の綺麗さが結構違います。。

色々試してみた中で、一番綺麗に縮小できたのが、PhotoZoomという
画像リサイズの専門ソフトで、次に綺麗だったのがSmaheyと画像拡縮という
２つのソフトでした。これらはどれも独自の画像縮小アルゴリズムらしく、
その次にLanczos-4アルゴリズム、その次にバイキュービック等の
アルゴリズムが綺麗といった印象でした。ちなみにPhotoZoomという
ソフトは購入しようと思うと2万円します！お、お高い。。

ただ、どのアルゴリズムを使用しても「あ、この部分だけあの
アルゴリズムの方が綺麗だ！」なんてこともしばしばあったり。。
難しいものですね、画像縮小。今のところ、一番いいやり方は
とりあえず無難なアルゴリズムで縮小してアンシャープで
先鋭化した後、汚い部分をレタッチするのが無難なのかなと思いました。

トゥーンシェーダを試してみました！

今回はトゥーンシェーダと平行して、影の色処理にHSV-RGB変換を
やっていたんですが、中身がよく分からない状態で使用している上に
シェーダ命令が限界突破してしまったので、少し頭を冷やして
色空間の変換式をちょっくら研究してみることにしました。
さっそくですが、以下に色空間の変換式をメモしておきます。

RGB to YUV
Y = 0.299　* R + 0.587　* G + 0.114　* B
U = -0.169　* R - 0.331　* G + 0.500　* B
V = 0.500　* R - 0.419　* G - 0.081　* B

YUV to RGB
R = 1.000　* Y + 1.402　* V
G = 1.000　* Y - 0.344　* U - 0.714　* V
B = 1.000　* Y + 1.772　* U

RGB to YCbCr
Y = 0.29900 * R + 0.58700 * G + 0.11400 * B
Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B
Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B

YCbCr to RGB
R = Y + 1.40200 * Cr
G = Y - 0.34414 * Cb - 0.71414 * Cr
B = Y + 1.77200 * Cb

RGB to YIQ
Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
I = 0.5959 * R - 0.2750 * G + 0.3210 * B
Q = 0.2065 * R - 0.4969 * G - 0.2904 * B

YIQ to RGB
R = Y + 0.9489 * I + 0.6561 * Q
G = Y - 0.2645 * I - 0.6847 * Q
B = Y - 1.1270 * I + 1.8050 * Q

RGB to HSV
(H:0～360,S:0～1,V:0～1,R,G,B:0～1)
V = max( R, G, B )
diff = V - min( R, G, B )
S = diff / V
if(R == V): H = 60 * (B - G) / diff
if(G == V): H = 60 * (R - B) / diff + 120
if(B == V): H = 60 * (G - R) / diff + 240

HSV to RGB
H(i) = (H/60)mod6
f = H / 60 - H(i)
p = V * (1 - S)
q = V * (1 - f * S)
t = V * (1 - (1 - f) * S)
if(H(i) == 0): R = V, G = t, B = p
if(H(i) == 1): R = q, G = V, B = p
if(H(i) == 2): R = p, G = V, B = t
if(H(i) == 3): R = p, G = q, B = V
if(H(i) == 4): R = t, G = p, B = V
if(H(i) == 5): R = V, G = p, B = q

それにしても、HSVだけ変換が面倒くさいですね。。
シェーダでHSV-RGB変換をやってしまうとif文判定がかなりかさばって
しまうので、正直やめたほうがいいなと思いました(スキップ自体は
いいことなんですが、命令レジスタ自体が圧迫されるので)。
それと研究してみて、ふとHSV-RGB変換をやらなくても影の色処理が
できる方法を思いついたので、今度はそちらを試してみようかと思います。

ようやくある程度背景が修復できてきました。

そういえば、最近は少しばかりUDKやUnityに興味があったのですが、
どうやら非公式ですがUnityのドキュメント日本語化が進められてるようです。
個人的にはUnityはPCゲームとしてというよりWeb3DやiPhoneのような
ポータブルゲーム制作の主流になりそうかもと、少し期待してたりします。

それで、以下少しWeb3Dについての考察語り。

Web3Dは過去１０数年間構想されてきたそうですが、転送速度や
スペックの都合もあって今まで全く普及までに至らなかったらしいんですよね。。
今ではようやく3Dビュワーとしてぼちぼち使われてますけど。
Flashのようにゲーム感覚で扱いたい場合どうしてもGPUに
データを転送することが不可欠になってくるんです。

最近ようやく3DビュワーとしてFlashベースのPV3DやAway3Dが
注目されはじめて、PV3Dの書籍もようやく1冊出始めましたが。
現状Flashはどんな環境にも対応できるようにGPUに
データ転送できないようになっていて、O3DやUnityと比べて
かなり処理が重いんですよ。。これが。
しかもビュワーとしても問題があって、バッファを使用していないため
Zバッファ描画ではなくZソート描画なので、ポリゴンのちらつきが
発生してしまうんです。これはCGのポリゴン投稿で問題になってるやつです。

じゃあ何でO3DやUnityが普及しないんだろと、今日は少し
考えてみたところ。。結局のところ現状、Flashとの連携が如何に
とれているかがWeb3Dの鍵なのではないかなと思いました。

ほとんどの大手サイトは環境に依存しないWebデザインにするように
Flashでデザインすることが多いですが、O3DやUnityは
OSやブラウザ・GPUの環境によっては導入できなかったりする訳です。
プラグインの導入が面倒臭いってデメリットもあります。
なので、FlashがGPUを扱えるようになってWeb3DがFlashと連携を
とる事ができるようになれば、Web3Dが普及するんじゃないかと。
実際、PhotoshopなんかのAdobe製品は最新のWindowsに
合わせてDirectXを使用して描画するようになっているそうですが。
Flashもそうなってくる日が近いんじゃないかなと、そう思ってます。

個人的にはO3Dが普及してほしいけど。全く普及する見込みないなあ苦笑。

色々なテクスチャを描き描き。少しずつ調整中です。
更新するほど進展してないですね苦笑。

3Dで背景を制作するための資料を集めたりしていく内に、
ふと思ったことがあったのですが。ファンタジー・幻想的な
風景っていうものを、今まで漠然としか捉えていなかったけど、
例えばヨーロッパのとある民族の村であったりしても、色々と
違う特徴が多い中で、何か懐かしさや親近感を感じるようなものがある。
そういった部分を取り上げていくことで、世界中の誰がみても
同じようにファンタジー・幻想的といった感情を風景から
思い浮かべることが出来るのではないのかなと思いました。

何気なしに気がついたことなので、結構おかしなことをいっているのかも
しれませんが。。別の例でいうと、FF12のデザイナーの人の話で、
風景をただ現実そっくりのもので作っていくとファンタジーな風景に
ならないので、現実にない部分を取り入れていくという話が
本に書いてありましたが。これはただ現実ばなれしたものを
作ってしまうと、何だかおどろおどろしいものになるのではないか
という気がします。つまり、ファンタジー・幻想的というのは
ただ非現実的なのでなくて、どの部分を見ても「ああ、何となく
見覚えがあるな」っていう部分が必要なのではないかと、そう思いました。

そう考えると、ファンタジー系(？)のイラストやゲームに
厚塗り風のフラットなタッチで描かれることが多いのも合点がいきます。
つまりディテールをしっかり描いてしまうと、特定の地域限定の
種類のものになってしまうのです。
いうまでもなく、決して手抜きなのではない！笑。

今日はネットでゲームのプレイ動画をみたりキャプチャしたりして
資料集めをしながら、制作用のラフを描いたりしてました。
キャラクターはデザインを決めるのがすごく難しいですね。

そういえば、息抜きに今までよく分からなかったCUDAについて
調べてみたのですが、実はこいつ、GPUとCPUを並列プログラミングさせる
言語だということが分かりました。おおー。

え？よく分からないって？

僕も今までよく理解していなかったので、あまり説明できないのですが。
以下、いつもより少し長めに説明します。

まずはじめに、DirectXやOPENGLのような3DグラフィックスAPIは通常、
座標変換やラスタライズといった処理はCPUだと重たいので
GPUによってそれらを処理させております。
GPUはCPUと違い頂点やピクセルの計算を１つづつではなく並列して
一気にまとめて計算できるように作られているので、CPUよりも
かなり高速に処理できるわけです。

が、しかし。このCPU-GPU転送間には問題もあるのです。
まず第一にCPUからGPUのデータにアクセスしたり、
メインメモリのデータをGPUに転送したりといった処理自体が
重いという問題があります。いままで何回かこの問題で四苦八苦したので
結構この辺は分かりやすいですね。

それ以外に今回発見した問題。それは…。
GPUにデータを転送した後は、実はCPU側では何も処理を
せずにじっとしていたということです！まあ考えたら、そりゃそうですよ。
あるオブジェクトをGPUが描画計算している最中に、
CPUから「これお願いしますねー」っていわれて、次から次へと
命令を送られても、どうしようもないので。

じゃあ別にCPU側で何もしてない方がいいじゃないかと思うかもしれないですが
案外そうでもないんです。例えば、ゲームでは当たり前のように
当たり判定処理を必要としますが、これを毎回描画計算の
前もしくは後に行っていると、それなりに処理が重いんですよ。
けど、当たり判定に必要なフレームの座標値はオフセット行列から
あらかじめ取得できるので、GPUに転送する前のデータだけで
当たり判定が出来ちゃうのです。つまり、この処理をCUDAを使って
GPU計算時にCPU側で処理させることで結構高速になると。そういうことです。

それじゃさっそくCUDAをインストールしてみようと思ったのですが…。
仕様書をみてみると、僕のビデオカードが対応していない！！
GeForce8000系以上にしか対応してないようです。ががーん。
さらに付け加えると、nVidiaの自社のビデオカードに
最適化するように設計されているので、他の会社のビデオカードだと
利用できないという苦笑。

けど、OPENCLというAPIならCUDAと違ってマルチな設計に
してあるみたいです。まあ最適化されていない分、若干遅いようですが、
これならいいなと思ってネットで調べてみても。
…ほとんど情報が無いじゃないか。。おまけにOPENGLには
標準対応させているにも関わらず、DirectXには対応していないという。
DirectXはMicrosoft側が自社で設計を考察してるようですが、うーん。

結局、CPU-GPU間の並列プログラミングはここ2～3年にようやく
普及しはじめた技術のようなので。まだまだ発展段階のようです。
なので、まだ今の制作に生かすには早いように感じましたが、
最新の３D事情が少し位は理解できるようになったかなと、そう思いました。

それでふと思ったんですが。
わざわざそんなAPIを使わなくても普通にマルチスレッドプログラムを組んで
GPU転送前にスレッドを分けることでそれなりに速度向上できるのかなと
思ったんですが。どうなんですかね。

てか、CPUで頂点計算させる分、GPUの負荷が軽くなるなんて
今までほざいとりましたが(僕の本にそう書いてあったんですけどね)、
実際のところCPUで頂点計算させるメリットが全く無いね笑。
とりあえずシェーダで頂点計算させてみようかな。

モデリング技術はようやく人並みに達したような気もしますが
テクスチャ技術はまだまだだなあと他所様のサイトをみて実感。

今日はテクスチャ画像を収集したり整理したりしてました。

テクスチャは、はじめは1024～2048以上のものを用意して
形状に沿って簡潔に描いて。うまくいってからエアブラシあたりで
よくなじませ、その後でフィルタやテクスチャ画像でダストを加える。
で、最後に後処理にリサイズしたりマスクして複数の
テクスチャを複合させたりしてまた少し描き直す。

この手順をはっきり区分して進めたほうが早そうです。
それに、分業させることでテクスチャをうまく使いまわしたりできるので便利です。
Photoshopのカスタムブラシなんかもそれにあわせて
新しく作ったりすると、なお良し。

ロジックは大切ですね。ほんと、今まで適当にやってました。。