スポンサーサイト

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

単なる敗北

敗北である。
GPUでパーティクルして当たり判定もする、つーのが、結局のところ、それでもまだ重い。
重すぎる。
という結論に。シェーダをできる限り最適化したっつーのに。FPSに影響が出る。

なのでその処理はオクライリ。

ひょっとしたらジオメトリシェーダからStructuredBufferにアクセスすること自体もオーバーヘッドになってるかもわからんけど、そんな感じのプロファイルはどうとればいいのかわからなかったし。
取れたところで重いのは変わらない。それに対して対策が思いつかない。
しぬ

それでもまだCPUでじりじりやるのに比べればまだFPS影響はないレベルではあるんだけどももも。


数日いろいろ悩んでいろいろ試して、一つの結論は出た。当たり判定の原点に立ち返るのだ。
そう、みんな大好きバウンディングスフィア。
バウンディングスフィアさえあれば何でもできる。

。。。

キャラクターとの詳細な当たり判定を取りたくて取りたくて、スカートやツインテールに使用してる当たり判定もキャラクタモデルから作った超ローポリを使っていたけれど、やっぱりそれでもなお重いという事実。
ここが地獄か
っていうほどに方式検討して実装して最適化して歯が痛くなってしまったというのに。
バウンディングスフィアか!
っていう。(わからない)

というか
実際のところスカートについてはクロスシミュレーションできるくらいCPUは余ってそうだったので考えた。けど規則に従ってメッシュを作るのではなくてメッシュ読み込んで頂点を関連付けるにはどうしたら・・という点で躓いてしまったのでこれもナシ。ボーンをぶらぶらさせる方向でやってた。
このボーンの当たり判定も最初は頂点単位でやってた。ボーンが動いて面にあたる、というよりは面が動いてボーンにあたる→ボーンが押し出されるっていう処理にしていたせいで実際は面での処理がうまくいかず、頂点単位で処理っつーことをしていた。なので、あたり判定モデルが荒いとボーンがすり抜けてしまい非常に悲しい目にあっていた。ポリゴンモデルなので内外判定ができないので、あたってないならあたってないつーことで処理しきれなかった。
非常にダサい。

なのでちょっと前に思いついてボーンからバウンディングスフィアを作ってそれとの当たり判定をとってみると、処理は軽いは内外の判定ができるのでめり込むことはないわでえらいことです。


という経緯があった。

あとポリゴン単位での当たり判定を最適化するのには空間分割するしかない。これは作ってしまえば楽なんだろうけどGPUでそれやるにはちょっと気が遠くなる。CPUでもちょっと苦労した。どれだけはやくなるかの予測も全くつかない。これに手を出していたら死ぬ。それに衝突判定するポリゴンを減らすことができたとしても、判定のためには内積4回外積4回計算する必要がある。それ以外にもめんどくせーベクトル計算がいっぱいある。おそらく、パーティクルがモデルに密着している場合が多い今回の状況だと思ったほど効率は上がらないと予測される。

なので、次に検討するアプローチとしては原点であるバウンディングスフィアではないか、という結論に至ったのだ(エッヘン)

ついついとキャラクターのボーンからのこのあたり判定用のバウンディング作成定義ファイルを作って、そのデータからボーン位置にバウンディングスフィアをつくる処理を実装して動かしてみると。

StructuredBufferにぶち込むデータも小さく、ジオメトリシェーダ内処理ループ回数はローポリモデルよりもはるかに小さく、なんていうか真面目にやるのはバカじゃね
という結果に。
なんていうか分割とかして効率化を図らなくてもいいレベルで動いたのでぼくはなんかもういいやこれで。と思いました。

バウンディングスフィアで困るのはそれがスフィアであること。腕なんかはOBBでやるべきだろうか・・と思ったけどこれもコスト高そうだし衝突したところの法線をどう取得したもんか悩んだのでボーンの始点と接続している次のボーンまでの位置にバウンディングスフィアを並べることに。これも原点だね!


つかなんで現在最適化に心血を注いでいるのか。。と振り返るとすべてはOculusRiftの登場によるものだった。
75FPSの壁は厚い。
だけどこれである程度はカタが付いたので次の作業をしよう・・・

ネットでRiftに関する最適化の情報を探すと、ほぼUnreal EngineかUnityのみだ。自分でプログラムしてる人はいない。
南無南無。

このブログでは非常に珍しい有益な情報を残すとすると、Riftのプログラミングにおいては、
①パフォーマンスに関してはフィルレートが問題になる場合が多い。頂点シェーダは意外と頑張る印象。
②ポストプロセス系の、レンダーターゲット全体に処理するものについてはViewportを正しく設定しているか確認する。(左右の画像を一枚にレンダリングする場合)

①のフィルレートについてはとくにピクセルシェーダでのガウシアンブラーとか2回描画しないといけない場合、意外とシェーダ負荷が高い。ぼかし処理をするなら、使用するターゲットの解像度は見た目がおかしくならないレベルまで下げるといい。
それにkernelの回数も見直す必要があるかもしれない。
これはほかの環境(UEやUnity)でも言えることだと思うけど。最終的に出力する以外のバッファ(加工するバッファ)はサイズを下げてからどうこうするのは定石ですな・・・。
Riftから取得するレンダーターゲットサイズについては等倍で取得するとかなりでかいサイズが返ってくるのでビビるけど。画面作りを工夫して、例えば画面の色づくりそのものがすこしぼかしたような、あんまりソリッドでない画面作りだと出力解像度を減らしても見た目にそんなに影響は感じない。
解像度下げる場合は文字とかつぶれるからUIのサイズについてはいろいろ考える必要はあるけどね。

②については、XNAから始まった不幸なプロジェクトなので移植にはSharpDX toolkitをつかってるわけなんだけども、toolkitではレンダーターゲットを変更したときにデバイスのビューポートを勝手にそのターゲットにサイズに設定してくれる超便利機能がある。Riftでのレンダリングでは邪魔になるのでデバイスのAutoViewportFromRenderTargetsをfalseにしておくのをオススメ。


3Dのお勉強的側面が強いのでいろんなことは無駄にならない。方式検討し、実装し、結果の数字を見ることも目的の一つなのだから。無駄なことなど何もない!ないのだ!


(冬眠しよう・・)
スポンサーサイト

コメントの投稿

非公開コメント

プロフィール

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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。