スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

gugugu

じりじりと作りこみ
・GPUパーティクル
・Rift対応
・XInput対応

不幸にも今回は図版なしの時系列に沿ったクドい長文です。


○GPUパーティクル
GPUパーティクルにもいろいろ方法はあるみたいだけどStreamOutputをつかう方法で。
最初はまあよくわからなかったんだけども、実際のところやってみればCPUでは考えられない数のパーティクルを出せる。どばどばって。
GPUパーティクルで懸念してたのは当たり判定で、一体どうすればシェーダーにモデルのデータを渡すことができるんだろう・・と思ってげんなりしてたけど、GPGPUのことを調べていくうちにStructuredBufferがジオメトリシェーダで同じように使える様子。
で当たり判定をほぼそのままもりっとシェーダで実装してみるとこれが遅い。
残念なほど遅い。

そしてうつろな目をしながら次にやるのはシェーダの最適化。このままではまったく使い物にならないけど、最適化して使い物になるかどうかはわからないという暗闇に踏み込む。経験のなさが目にしみるわけだ。。

シェーダは演算機としてif文とかの分岐に弱いらしい。実際遅い。forも処理回数そのものが爆発的に増えるので遅い。ので制約も多い。(詳細は知らない
だからまずif文をなくす。極力減らす。とくにループ内部では本当にできるかぎり削る。

どうやってif文を削ってif文で分岐したかのような結果を出すかというと、if文で0を返す処理がある場合、そこで分岐するくらいなら処理を走らせて最後に0をかけて結果0にするとかそういう感じの手わざ的なゴリゴリ感あふれる最適化をすることになる。
普通の言語でよく使われる処理そのものを減らそうとするアーリーアウトって考えなんかはかえって遅い感じ。
あとfor文をキャンセルしたいときはなにかのフラグをビット演算でつくっておいて、ループの最大数にかけるとこれもif文でfor回避しなくてすむ。
bool flag = ビット演算式;
for(int i = 0 ; i < max * flag ; i++ ) { 処理; }
みたいな。

もうひとつハマったのはモデルはblenderのfbxで出力してるんだけど当たり判定がおかしなところで行われてて死ぬかとおもったという点。
当たり判定モデルのデバッグ描画は問題ないもんだからアレ。
頂点を調べてみるとblenderで編集している頂点数の数倍あることに気が付き(いまさら!)、さらに調べていくと法線の関係で頂点は同じ位置に複数出力されるっていうことがわかってドロリ。
描画時にはインデックスに沿って描画されるのでおかしなことにはならないわけだけども。ただそれだとインデックスにそって三角形との判定とってるのにおかしなことになるのもよくわからないのだけれども。わかんない。
なので同じ位置、同じUVを持つ頂点をブっ消してインデックスを作成しなおす処理をコンバータで作成して、データも少しダイエットできて、CPUスキニングする頂点数も減って処理負荷も減った。うむ。
インデックス数を見るとトライアングル数は変わらない。頂点シェーダを通る頂点はそもそもインデックスに沿って流れるはずだからふつうの描画の負荷も変わらないはず。
あとはバウンディングボックスでおおまかに当たり判定をするかどうかの判定もいれてごっそり高速化できた。

正直疲れた。


○Oculus Rift対応
バイナリ分けるのアレだし#ifでやるのも絶対アレなことになるので分岐で対応。それでも十分アレなことになってしまったのだけれどどうにか。
マウス操作で移動・回転させる視点とRift視点の兼ね合いもアレだったけども最大の問題はRiftでのUI。
Riftでは画面の端っこに固定でUIがあると見えない。見えないのだ。
なの考えた。見えるだけのUIではなくてボタン類が主なので、視認性がよくないといけない。画面中心付近にボタン類をスペースキーを押すたびに表示を切り替えて選択してもらう方法と、3D空間上にメニューそのものを配置する方法を考えた。
前者の問題は、操作しづらいのと間に合わせ感がダサい。
後者の問題は、あんまりない。うまくいけば最小のレイアウト変更でそのままメニュー処理が作れる。
なのでもともとメニューUIは別レンダーターゲットに書いてたので、それをそのまま3D空間上、カメラの視線の上のほうに配置。カメラ方向に追随して動いて、Riftで頭を上げるとすぐメニューが見れるという状態に。
クリックは単にスクリーン座標→メニュー表示ポリゴン内座標→メニュー空間内座標変換でそれ以降の処理はそのまま。

地味に苦労した。

あとRiftで忘れてはいけない要素としてフレームレートの維持。描画は二回するので単純に2倍コストがかかるかとおもったけど考えてみればピクセルシェーダーのほうはというと1フレームに描画する面積は半分(片目分)×2なのでたぶんそんなに変わらない。
そして頂点・ジオメトリシェーダとドローコールが問題になると思われる。こっちは単純に2倍。

思われる、って書いたのは、ドローコール回数を調べたら1フレーム400もあってぶったまげて、その勢いで再び地獄の最適化作業、160減らして240位にまで落としたんだけど思ったほどフレームレートは改善しなかったため。
なんでそんな回数ドローしてるのかというといろいろ変な描画ロジックのせい。あとポストプロセスありきの色づくりも影響してるけどここは容易に変更できない。
んで頭抱えてシェーダーデバッガでじりじりと見直していくとあるレンダーターゲットバッファのサイズがおかしいことに気が付けた。そこ直すともりもりフレームレート上がった。つまり、ピクセルシェーダー負荷だったのである。最初に可能性除外してんじゃねえかよ馬鹿>俺


○XInput対応
コーディングパワーがここに溜まってきた(ストレッチパワー的な)のを感じたので勢いでさくっと対応したけど、Xinputってあんまりキーコンフィグってしない慣例だし、キーコンフィグ対応しないし、デフォルト設定がよく考えられてないと地味にイライラしてしまう操作感を生み出してしまうのでよく考えねばなるまいと思って考えた。
基本的にOculusRiftでは箱コン使うほうが事実上のべすとえくすぺりえんす(棒)を生み出すし、ボクも箱コン大好きでふつーにPCでゲームするときもことごとく箱コンつかうし、ぜひ箱コンをオしていきたいです。

んで箱コンのキーバインド的に考えたコンセプトはシンプルで、「おおむね片手で操作可能で、両手でも可能」というもの。
左手で視点操作関連はすべてできるように。メニュー選択周りは箱コン左側にあるショルダー、トリガー、DPad、左スティックだけでは厳しかった。左スティックの挙動として移動関係が最も適当であると思っているのでその辺を割り当てたんだけども、もうちょっと詰めが必要かなあという段階。すべてを片方だけで、っていうバインドは無理かも。詰め込んだら逆になんだかよくわからない操作感になるよな、とは思う。

むずかしいのう。

でも なんか 妥協したくないので 進める。
スポンサーサイト

コメントの投稿

非公開コメント

プロフィール

zerobyteorbit

Author:zerobyteorbit
deathpiyoがgameをdevelopしたり、musicをcomposeしたり迷走したりする。

現在は迷走中。

under the lotusはリビルドのために考え中。

deathpiyo twitter

UnderTheLotus test3h(download)
I'm thinking about rebuilding UTL.


同人音楽アルバム
[Lovers Immortality]
-Japanease-
Lovers Immortality -works until worldend- DLsite.com直リンク
Melonbooks DL
-English-
Lovers Immortality -works until world end- Link to DLsite.com

18+
【東の森の魔女2 VS 魔王 -終宴する世界と肛虐(逆)の魔女たち-】
東の森の魔女2 VS 魔王 -終宴する世界と肛虐(逆)の魔女たち- DLsite.com直リンク
DMM.同人

紹介ページ


【地下迷宮の機械姦自壊オナニー生活。】
地下迷宮の機械姦自壊オナニー生活。 DLsite.com直リンク
DMM同人

紹介ページ




DLSite
Link to DLsite.com

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
FC2カウンター
検索フォーム
RSSリンクの表示
リンク
QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。