昨日の続き

最適化実装は一応終了。
基本的に浮動少数点演算なSSE1はそんな複雑じゃないけど
SSE2となると整数演算が本格的にサポートされたせいか一気に命令増えて理解に時間かかった。
というかcvttps2dqとか命令語が長くて覚えるのが大変だ。2ってなんじゃい？と思ったらtoの意味だったり。
いちいちマニュアル見てたんじゃ時間かかってしょうがないしなあ。

と、ここまで書いておいて実は昨夜書いたアルゴリズムはSSE2の命令を使ってはいるものの
SSE1の命令だけで書き直せそうな気がしたり、しなかったり。
（個人的にはSSE1はpen3だから当然あるものとして遠慮なく使って構わないが
SSE2はpen4なのでどうかな～という認識）

それと前回の記事でライトマップ計算は「速度が重要じゃない部分」と書いたが。
テクセル1つにつき3回、下手したら1つのマップで何万回も呼ばれるルーチンなので
やっぱり最適化はデバッグ段階でも意味があると思った。
ちょっと強引な結論だけど、そういうことで。

パックされた値のブレンド

・・・・まじか・・・まじかよ
とりあえず明日からのニュースは要チェックかもなあ

まあそれはそれ。これはこれ。
ゲームの進捗。CPUによるバイリニアキューブマップ参照である。
実装して動作確認も一通り完了。
パックされたA8R8G8B8フォーマットのテクセルのブレンドをするルーチン、
現時点では速度はあまり重要じゃないんだけど
なんとなくSSEを使い始めて自称最適化してみたり。これがまたパズルみたいでハマる。
ハマッってる場合じゃないのは重々承知なんだが
今日だけは最適化したい気分なので、そうさせてもらう。

まだまだ

いよいよ明日選挙かー
どの党に票入れるか決めかねてるんだけど
なにはともあれ投票率が上がるのは良いことだ。70％いくんじゃないかって言われてますな。

で、キューブテクスチャの自力バイリニア補間だけど・・・ごめんまだ途中だ。
誰に謝ってるのか分からないが予想以上に処理が面倒で
中でも補完するテクセル群が面をまたぐときにやる事が多い。
周囲4平面をリスト化して参照できるようにしたり
その際にUV座標を2x2の行列変換したりとかして。

それとは別に3DベクトルからUV座標を計算する部分は
最初に書いた時は律儀にレイ判定してたけどちょっと検索したらもっと
効率のいいアルゴリズムがあったのでそっちに変更した。

明日中にはいい加減完成させたい

スミ

引き続きバイリニア補間の実装をば。
思ったんだけど隅っこのテクセルを参照する時は周囲の4テクセルじゃなくて
3テクセルになるんだなあと。
通常は4テクセル混合なんだが・・（球はUV座標を表すと思ってください)


角だと3テクセルになる

混合の割合はどうやって出すんだ？

造語

影の計算の過程でCPUで処理してるキューブマップのテクスチャ参照が
ニアレストネイバーだったのに気づいてバイリニアに直してる。
面倒＆処理が重いのは承知だ。でもこれで影の品質がもう少し向上すると思う。
でもまあ準前計算（自分用語：毎フレーム計算はしないけど事前に計算しておく物でもない）
だから多少重かろうが関係ないかと。

準前計算という造語はバックグラウンドで処理と表現してもいいが処理のタイミングを表す言葉が
前処理（ゲーム開始前）、準前処理（CPUやGPUが空いた時間）、リアルタイム処理（毎フレーム又は数フレームごと）
と3つレベルがあれば便利そうだなという思いつきである。
準リアルタイムという言葉は既にあるが、これは
本当はリアルタイムにしたいんだけど設備や精度の関係で
結果がちょっと後れて出力されるような場合な気がした。
「準リアルタイムモニタリング」、「静止気象衛星準リアルタイム画像」とか。

影を綺麗に。

なんとかできた。variance shadow mappingを応用した静的影のアンチエイリアス
適用前：

適用後：

どちらもライトマップの解像度は同じ。
基本的に影をぼかすと輪郭が綺麗になる、が
ぼかす度合いによっては細い影が薄くなりすぎたり
隙間から差し込む光が暗くなったりするんで
（上の画像だと左下のちょっとだけ光当たってる床がそれに該当）
一概にどっちが良いとも言い切れないが・・・

これよりもクオリティアップするにはラジオシティしか無さそうだ
しかし計算量が膨大になるので
上の画像のマップの計算時間は両方1秒位だがラジオシティやると
どんなに最適化しても1分とかになるんだろうなあ

と言うわけでライト関係は一旦中断して銃の処理に戻ろうかと思う

ライトマップ生成が速くなった

分散シャドウ無しでキューブマップを使ってライトマップ生成できた。
CPUだけで計算した場合の2倍速い。これはいい副次的効果だ。
だけどゲーム中にも次のフロアをバックグラウンドで計算させるつもりなので
プレイ画面描画する合間だと、どうなんだか。
一番いいのはCPUかGPUのどちらが余力があるか調べて空いてる方を使って計算する方法だが面倒そうだ。

ちなみにCPUと比べて速いというのは半分嘘です。
CPUは1テクセルずつ個別にで計算するがGPUだと一度に描画してテクスチャ参照してる関係上精度が違いますんで。
どのくらいかっていうと見た目じゃ良くわからんけど。

それはさておき分散シャドウしようと深度バッファをガウスフィルタでぼかしたら
キューブマップの継ぎ目が合ってない事が発覚。
調査したらガウスフィルタかけた時点で右下に数ドット画像がずれている。
直さなきゃいかんな。

身近な人が見てないから

このブログは直接の知り合いが見てないから良いんだな
twitterの方も同じく。
居たら気軽になんて書けやせん
一時期教えようかと思ったけど教えなくてよかった

撤回

つい昨日DualParaboloid駄目だとか書いておいて布団の中でよく考えたら
ライトマップはテクセル単位で座標計算するから使えるじゃんって気づいた。
使える使えないとかもうどっちやねん！て感じだ。
眠い頭で決断するなとあれほど(略

どうせ途中までやっちゃったから両方実装してみようと思います。
で、色々計算速度と影の精度をテストしてゲームに適した方にしよう。

やっぱキューブマップにします

更に昨日の続きでなんとなくファイルを同時に3つ程コピーしてみたが時間は同じだった
AHCI・・・よくわからん。まあいいか。

で、ゲームの方はライトから見た壁の距離をDualParapoloidで
テクスチャに格納してみようかと思った。
非線形な座標変換をする関係上ポリゴンが荒いと宜しくないので
なるべく歪みが小さくなるようにポリゴンをライトに近いほど細分化する
アルゴリズムを書いて、試したとこまでは良かったが。
それだと当然描画のときも細分化したポリゴンでやらないと
元のポリゴンを使おうとしてもテクスチャ座標が一致するわけないよな！ってことであえなく没。
名残惜しいからスクショ置いとこ。徹夜で作業したんだけどな～

よくよく考えたらDPの、全方位を2面でカバーするという利点は
準前計算である今回のケースだと恩恵が薄いわけで。
そしたら普通にキューブマップでいいじゃんと。