「やはり、どこの開発スタジオも気づき始めているようだ。今世代の3Dゲームグラフィックスのリアル志向を極めてしまうと、やや似た感じになってきてしまうということを。」
非リアル系の3DグラフィックスはNon Photo Realistic(NPR)系と言われたり、SIGGRAPHなどのCG系学会では「Stylized Rendering」(スタイライズド・レンダリング:ある法則に基づいたレンダリング手法)などとカテゴライズされることもある。
2011年5月19日木曜日
2011年5月4日水曜日
2011年4月7日木曜日
NVIDIA 3D VISION LRバッファ操作
公式ドキュメント
http://developer.download.nvidia.com/presentations/2009/GDC/GDC09-3DVision-The_In_and_Out.pdf #define NVSTEREO_IMAGE_SIGNATURE 0x4433564e
具体的なやりかた DirectX10/DirectX11でもできるという
http://www.klayge.org/2010/11/21/%E5%9C%A8%E7%A8%8B%E5%BA%8F%E4%B8%AD%E4%BD%BF%E7%94%A8nv-3d-vision/
DirectX9 ソースコード
2011年3月22日火曜日
似非SSS
http://marina.sys.wakayama-u.ac.jp/~tokoi/?date=20101203
SSAOをもとに作られている。（点の回りの体積をもとめる感じ）
アドホックな部分があるとかいてあるけど、おもしろいです。
参考
2011年3月16日水曜日
保守的な深度出力(Conservative depth output)
http://blog.gameenginejp.com/2010/12/d3d11.html#more
ピクセルシェーダで深度値を変更する場合、
その変更が前方向か、後方向かがあらかじめわかるなら、
（SV_DepthGreater や SV_DepthLessEqual）
高速化への指針になる。
ピクセルシェーダで深度値を変更する場合、
その変更が前方向か、後方向かがあらかじめわかるなら、
（SV_DepthGreater や SV_DepthLessEqual）
高速化への指針になる。
2011年3月14日月曜日
2011年3月3日木曜日
DICE 3Dエンジン Enlighten
http://publications.dice.se/publications.asp?show_category=yes&which_category=Rendering
- あらかじめ表示用の多ポリゴンのシーンと、対応した超低ポリゴンのシーンを作り込んでおき、そのシーンに対応したライトマップ生成と、あらかじめ設定しておいた複数の調査点(Lightprobes)における間接光量(環境光量)をGPUとは非同期にCPUで求めます。 Lightprobesは低解像度の3Dテクスチャに展開し、Deferred Renderingで、この3Dテクスチャをサンプルしてライティングを実行する…というシンプルな実装です。ポイントはLightprobesを3Dテクスチャに展開してしまい、大局照明的な環境光ライティングをDeferred Renderingに統合してしまっているところです。 PCないしはPS3では有効なテクニックとなるかも知れません。
 |
CPUで粗いジオメトリのシーンに対してのライトマップ生成とLightprobesにおける関節光量を計算(左） |
 |
ライトマップをシーンジオメトリへ適用した結果(左） http://d.hatena.ne.jp/yakiimo02/20110305 |
- EnlightenはReal-Time Global IlluminationのMiddleware。入力のDirect Lightingを元に２次反射バウンス光のIndirect Lightingを計算してくれる。
- PS3版のランタイムコードはSPUを活用。SPUのコードがCUDA実装のベースとなったそうです。
- ランタイムは速度重視。単純なメッシュに対してライティングを行い、結果を実メッシュに投影したり、変化のない場合はCache情報を再利用する(Temporal Coherence)などを行って高速化している。ストリームではそのような話はなかったですが、Siggraph 2010スライドではRadiosityの２次反射Bounceを複数フレームまたいで蓄積していると書かれています。
- 最初はGPU実装だったけど、現世代のゲームはGPUに余裕がある事が少ないので、現在はGPU処理の裏でCPU/SPUにIndirect Lighting処理の計算させている。
- Enlightenは完全動的ではなく、Lightingの複雑な演算部分をツールで前処理計算させて、ツール側で実機で高速に処理ができる構造体に落とし込んでいる。
- 完全動的ではないので背景が破壊されたりする場合は少し工夫が必要になる。セッション中のデモでは天井が破壊され、室内のIndirect Lightingが背景の変化に順応する様子がデモンストレーションされていました。
- 日本の会社を含めた15社が現在Enlightenを使用して開発を行っている。Eve Online、Battlefield 3などが初期使用タイトルとなる。
- 動的オブジェクトはGIの影響を受けるだけで、GIには影響を与えない。
後半はEnlightenのCUDAを使用した高速化の話でした。
- ツールによるプリプロセスとランタイムの両方がCUDAに対応している。
- プリプロセスのレイトレ処理は自前のGPGPUレイトレではなくOptiXを使用している。
- 最初はIntel TBBを使用したマルチスレッドCPU実装だった。
- CPUの場合は1M ray/sec per CPU Core（8コアで 8M ray/sec)がGeforce GTX 470、１個で20M ray/secに高速化された。
- CUDAレイトレ実装の処理時間の50%がCPU-GPU間の転送処理らしく、その部分がネックになっている。
- CUDAの使用でレイトレ処理が約５倍高速化され、Geometry Preprocessing処理全体が2倍程度、高速化された。
- CUDAランタイムだと通常のランタイムより複雑なライティング処理が可能。NVIDIAのセッションなので、そのような話題はなかったですが、CUDAでできるのならDirectComputeでも同様にランタイムの高速化ができるような気がします。
- ランタイム部分の説明ではDirectXとCUDAの切り替えはモード変換を伴うので、遅いから注意が必要だという話もありました。
2011年2月23日水曜日
2011年2月12日土曜日
物理計算はゲームを面白くするのか？
リンク禁止でした
-----引用-----これはいけないということで、『リトルビッグプラネット』をプレイしてみることにした。
すごく評判が良いそうじゃないか。
しかし実は、私はあんまりこのゲームの素晴らしさが判らなかった。
すごく評判が良いそうじゃないか。
しかし実は、私はあんまりこのゲームの素晴らしさが判らなかった。
(略）
創り手はこの位置でキャラが飛んで、どこに着地して、プレイヤーはこのぐらいのタイミングでボタンを押すだろう、ということを厳密に想定してマップメイキングをしていた。
制限があるからこそ、素晴らしいマッピングが生まれるのである。
良くできたアクションゲームやシューティングゲームをやっていると、ああ、そのためにこの障害物はここにあるのか！と稲妻にうたれるかのように理解できる瞬間ってあるでしょ？
あれですよ。
制限があるからこそ、素晴らしいマッピングが生まれるのである。
良くできたアクションゲームやシューティングゲームをやっていると、ああ、そのためにこの障害物はここにあるのか！と稲妻にうたれるかのように理解できる瞬間ってあるでしょ？
あれですよ。
（略）
ところが、『リトルビッグプラネット』をプレイしていると、なんだか各ギミックが適当に置いてあるように感じられるのである。
稲妻にうたれるどころか、蚊に刺されたほどにも創り手の意図を感じない。
稲妻にうたれるどころか、蚊に刺されたほどにも創り手の意図を感じない。
（略）
まじめに計算しているからプレイヤーをドット単位で把握しきれない上に、キャラの初速などで結果が変わってしまうから、厳密なマップメイクが出来ないのではないか、あるいはやっても意味がないのではないか、と思うのである。
想定するプレイヤー像がぶれると、どうしてもマージンを大きく取らないといけないからな。
想定するプレイヤー像がぶれると、どうしてもマージンを大きく取らないといけないからな。
（略）
創る側は楽しいのかもしれない。
しかし、それがホントにゲームを面白くしているのか？というと、私はあんまりよく判らなかった。
しかし、それがホントにゲームを面白くしているのか？というと、私はあんまりよく判らなかった。
---------------
すいません、ほとんどそのままです。
2011年1月27日木曜日
2011年1月26日水曜日
HLSL 擬似乱数
乱数マップを作りたくないときに便利
#define aSubtract 0.2727272727272727
float4 randGrieu(float2 coords : WPOS,
uniform samplerRECT ranTexture) : COLOR
{
float4 t = f4texRECT(ranTexture, coords);
float a = t.x + t.z*cMult + aSubtract - floor(t.x);
a *= a;
float b = t.y + a;
b -= floor(b);
float c = t.z + b;
c -= floor(c);
float d = c;
a += c*cMult + aSubtract - floor(a);
a *= a;
b += a;
b -= floor(b);
c += b;
c -= floor(c); return float4(a,b,c,d);
}
2011年1月18日火曜日
SSE Matrix Vector
Matrix Inverse Product, vector dot product
http://www.devmaster.net/forums/showthread.php?t=14569Maxtrix*Vector SSE4での考察
_mm_dp_ps (SSE4)
The 128-bit and 256-bit AOS to SOA shuffle
SSEをつかったMatrixライブラリ
Column-Major
2011年1月13日木曜日
DirectX マルチモニタ フルスクリーンまとめ
なぜフルスクリーンは高速か
フルスクリーン アプリケーションで Present を呼び出した場合、スワップ チェーンはバック バッファーのコンテンツをフロント バッファーに切り替えます (ビット ブロック転送するのではありません)。
マルチモニタ処理
- フルスクリーンのデバイスを作成した同じ Direct3D オブジェクトによって作成されている。
- フルスクリーンのデバイスと同じフォーカス ウィンドウを持つ。
- どのフルスクリーン デバイスとも異なるアダプタを表す。
フォーカスウィンドウ：DirectX9にしかない
HRESULT SetFullscreenState( BOOL Fullscreen, IDXGIOutput *pTarget );
これでOutputを直接指定することができる
処理に失敗した場合は、DXGI_ERROR_NOT_CURRENTLY_AVAILABLE を返します。全画面スワップ チェーンをウィンドウ モードに切り替えられない場合、さまざまな理由があります。次に例を示します。- アプリケーションがターミナル サーバー経由で実行されている。
- 出力ウィンドウが遮断されている。
- 出力ウィンドウにキーボード フォーカスがない。
- 他のアプリケーションが既に全画面モードになっている。
2011年1月11日火曜日
プレイヤーと同じ大きさのゲームキャラクターが画面に登場し，地上に投影された映像の中にすっぽりと入り込んで，自分自身が動いて遊ぶこと
http://www.4gamer.net/games/026/G002688/20101208090/
写真がいいんだよね
見せ方がうまい。 何年も前からあるとか、関係なくなる。
あとコンセプトとか
コンピュータースペースで繰り広げられる新しいスポーツのコンセプトを指す
メディアでたもん勝ち
2011年1月2日日曜日
High-Quality Global Illumination Rendering Using Rasterization
GPU Gem2の記事
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter38.html
これがゲームに応用されたとか
| 1576 | Reply | GPU Gems 2のアレ | Bee | 2010/06/19 03:30 | ||
| 何だか知らない間に某ゲームに使われていたようなので，ちょっと言っておくと， DX11に制限されてもよければ，今ならリストを使ったOITと同じ方法で かなり高速化できるはず．ソートすらいらないので，100Mrays/secぐらい出るかも．暇があれば自分で試してみたい． | ||||||
この方
緑の会社とはnVidia
登録:
投稿 (Atom)