アラメダの海軍基地跡の滑走路って、バスターズが使ってたところ? 見たことあるような景色。な、気がする。
***
南側から眺めた図。1月初旬の頃。
白線が太陽の方向。南極付近が照らされてる。
アニメーションで地球が自転したり、公転したりするので、夏になれば北極側が照らされるようになる。はず。自転が見える程度の速度で半年分待つの大変。。。
***
試しに、地球と同じ径のチューブを表示してみた。
光線ベクトルと同じ向きに合わせてるので陰影が消えてる。
三角形ポリゴンの深度を、3頂点の平均で近似してるから、隣接するところでは奥行き計算が破綻してる。
目的は、適当に物体を配置して、この筒の中かどうかを判定する処理を実装すれば、地球の影を再現できる。そのための確認用のオブジェクト。計算処理には筒は不要だけど、動作確認時に目で見えると便利。
レンダリングは大部分をParallel.Forで回してるので、ポリ数が増えても25msecくらいで処理できるけど、CPU使用率がかなり高い。冷却ファンの回転数が高まるレベルで処理してる。タスクマネージャで見てると「このアプリめっちゃ電気食ってんぞ！！！」ってオレンジで表示されてる。
メモリアクセス(フレームバッファ、デプスバッファ)の排他処理は行っていないが、あんまり問題にはなっていないようだ。
そもそもポリが前後に並んでいる量があまり多くないし、前後の比較が必要としても、同一ピクセル位置の比較が同じタイミングで行われるのは確率の問題で、それもかなり低い確率だし、次のフレームでは別のタイミングになるから、フレームごとにランダムな位置にノイズピクセルが出る程度の問題にしかならないはず。
本物のレンダリングエンジンでは前後に重なるポリゴンが大量にあるから、同じタイミングで同じ位置を参照する確率も増えそうだけど、そういう用途の場合は空間周波数も高いから、ノイズピクセルもあまり目立たない気がする。もっとも、ちゃんと排他処理してるんだろうけど。
今の所、色は24bppRGBで管理しているので、透過処理はできない。今回みたいに、動作確認用の領域の表示だと、半透明の透過表示ができれば便利なんだけどね。
CoD4 MWのチェルノブイリで匍匐してる時とか、1bitαで敵が見えづらいの、「なんで8bitで透過しないんだよ！！」とか思いながらコンティニューしてたけど、エンジン作る側になると「んなめんどくせーことやってられっか！透過は1bitで処理してやる！！」みたいな気持ちになる(実装してないけど)。
透過が2bit以上だと、奥から順番に書き重ねる必要があるので、大量のフレームバッファが必要になる。例えば半透明のテクスチャを貼ったポリゴンが最大で5枚重なる可能性がある場合は、フレームバッファが6枚必要になり、更にフレームバッファの使用有無の管理も必要になる。4Kレンダリングの場合、32bppARGBと32bitDepthで、1枚あたり64MBのバッファが必要で、それが6枚なら、400M弱のメモリが必要になる。それらにアクセスするだけのメモリ帯域も必要になる。
そして、すべてのポリゴンのレンダリングが終わった段階で、すべてのフレームバッファから描画済みを取り出して、奥行きでソートしてから最終的なフレームバッファに描画する必要がある。凄まじく高コストになりそう。
αが1bitだと、「書くか」「書かないか」の判定しかないから、通常のレンダリングと同じパイプラインに通せる。もちろんフレームバッファは1枚でいいし、ポストエフェクトでゴリゴリやる必要もない。
もちろん、そのあたりを解決するための数々のアルゴリズムの研究もされているんだけどね。
***
レンダリングエンジンは色々あって、amazonで本探したりすると、それらの使い方の本とかはいろいろあるけど、エンジンの実装みたいな話は比較的少ない。
「ゲーム制作者になるための3Dグラフィックス技術」は、そのあたりの話が多い。概念的な部分が多いけど、「描画処理ってどういうことをやってるんだろう？」ということを知りたい人にはいい本だと思う。これを読んでからファンタジー系のMMORPGとかで街を歩くと、「ここはこうやって処理してるのかな」みたいなことを想像しがち。(現行は改定3版だけど、初版に比べてかなり分厚くなってて、届いてびっくりした。10年でこんなに増えるんだな)
公開情報を集めて使用例として紹介されていたりするので、丹念に集めていけば詳細な話も色々出てくるんだろうな。しかし、衛星でも資料集め沼に落ちてるし、他のジャンルにも手を出すと大変なので、遠慮したいところ。とはいえ、衛星より身近なことも確かなんだよなぁ。昔と比べれば最近はあまりゲームで遊ばなくなったけど、少なくとも人工衛星よりは身近なのは確か。
0 件のコメント:
コメントを投稿