概ねVBOは制覇した

敵は己自身(のミス)だけだったわけだけどorz

インデックスの値とか調べたところで三倍三倍繰り返してたのが原因で、インデックス数の三倍をglDrawElementsに投げててsegfaultで落ちるとか悩んでた。インデックス数はポリゴン数の三倍なので元々三倍されているというマヌケだ。

VBO使えないとキャラ出せないのでどうしようかとも思ったが、このあたりはこれで大丈夫そう。

VBOに着手

窓の描画ではほぼメリットのなかったVBOだが、背景画像や部屋、キャラを含むオブジェクトの描画では必要になるのでとりあえずエクイレクタングラーな背景画像もサポートするために着手してみた。流石に球の頂点を毎回プロセッサから送りつけるのは無駄が許容範囲を超えるしついでにスカイボックスもVBO化しときたい。毎回同じ頂点なんだし。

終了時に画面OFF

終了時に画面をOFFするようには組んであったが終了する方法がなかったので追加して画面がちゃんとOFFされることを確認できた。んしんし。

他に参照と(後)constポインタとポインタの原則を守ってない部分があったので修正。この原則は...

• 参照ならdeleteしない(実体か呼び出し側が管理してる)
• ポインタならdeleteする必要がある
• (後)constなポインタ、つまりポインタ自体がconstならNull安全(最低でもassertされてる)

...というもの。本来ならこのあたりは言語が強制すべき部分だけどなー。

キャラメイク

キャラメイクについて考えてみたのだが、MMOだとそこにいるキャラ全部のデータをグラボに読ませなきゃならない関係上、好きなように-例えばFBX読ませたりとかみたいな-キャラ作らせるわけには行かなくて、その上wOCEはコミュニケーションツールに重点を置くのでゲームと違って「なうろーでぃんぐ」が許されない。なのでデータはなるべく小さくなるべく使い回さなきゃならん。

今のは知らないけどDC版のPSOがああいう、種族、身長、太さ、色みたいな限られたキャラメイクになってたのはそういう理由からだと推測していて、今だともうちょっとリソース使えるにしても似たようなものになりそう。そのへんの研究のためにやってみるかな...。

スレッドでテクスチャをアップデートするのはダメポ(2)

テクスチャのアップデートがクッソ遅いのできっちりコントロール下に置かないとフレームレートを維持できないのが理由で処理を再び集中化した...のだが、わかっているつもりではあったがここまで遅いとは思わなかった。フレームあたり8x8のタイルでせいぜい200枚くらいしか更新できない。

というところで今のところテクスチャサイズが二冪ではないのを思い出した。どのみちグラボで完結する処理に比べたらクッソ遅いんだろうけど二冪にしたら多少は高速化できるかも知れぬ。

--

二冪テクスチャを作ってやってみたが大して変わらなかった。転送サイズ拡大のほうが効くかも。

XRandRで画面を自動設定

VRHMDのプロファイルから画面名を読んで、XRandRで読んだEDIDに書いてある名前と一致してる画面が見つかったらONにして所定位置へ配置するようにした。これで一応画面配置に関する問題は解決。

いちいちXRandRを起動してるのでlibXRR使いたいところだけど手間なので後回しにしてこの件はひとまず終了っと。

スレッドでテクスチャ更新するのはダメポ

テクスチャ更新はかなり重い処理なのでフレーム更新に影響が出ないようにコントロールする必要があるのだが、別スレッドでこの処理をするとまったくコントロールできなくなってテクスチャ更新がまとまって入ってくるとフレームレートどころの話ではなくなる。RiftCV1なんかはフレームレートが乱れるとブラックアウトして回復しないようだし、ダメダメだ。

困ったことにフレームバッファのスワップはVSYNCに近い場合でもなければVSYNC待ちをしないので、メインスレッドでメッセージ処理をしようとすると無駄に描画するばかりでほとんど処理が進まなくなる。これがスレッド化した理由なのだが。

どうやらフレームバッファをスワップした後にglFinishを呼んでおくとVSYNCを待ってくれるようなので、結構苦労してマルチスレッド化したのだが元に戻すかあるいはテクスチャ更新だけメインスレッドですることになりそう。

--

RiftCV1がブラックアウトするのはUSB3の電源が原因のようだ。追加電源使うボード使ってるのだが、DK2も挿してるのがダメっぽい。

libXRandRの資料がろくでもない

接続されてる端子がわかってれば何も考えずにXRandRをspawnすればいいのだが、その端子を探すためにはEDIDを読まなければならないので調べてみた(get-edidはうちの環境では画面ひとつ分しか読んでくれなかった)。

libxrandrのmanページがメモ同然なのでXRandRのソースを読んだらstaticおじさん感が溢れ出してくる上に処理自体が結構めんどくさい。libXRandRが低レベルすぎる感。これは将来的には自前で書くとしても今は自前で書かずにXRandRをspawnして結果をパースするほうが良さそうだ。

「xrandr --prop」とかでEDIDを取得できたらEDIDのオフセット54からの長さ18bytesの４つのブロックのうち、先頭が00 00 00 fc 00になっているブロックに画面の名前が入ってるので、それが検出されたVRHMDと一致してたらその端子名を使って、画面有効化なら「xrandr --output 端子名 --auto -pos 場所」、画面無効化なら「xrandr --output 端子名 --off」をspawnすればいいようだ。

XRandRしなきゃならんかもだ

OpenHMDからRiftCV1の歪み補正情報を得たので試してみた。

のだけれど、RiftCV1は設定しないと画面として認識してくれないのでDK1/2のように一度画面を設定すれば繋がってる限り画面の設定が保存されるってわけには行かない。

KDEは接続のパターンごとに設定を覚えているけれど(そしてよくデスクトップと画面の対応を滅茶苦茶にしてくれて腹立たしいけれど)XFce4は全く覚えてくれない(が、変更してもデスクトップと画面の対応は安定している)...という感じに環境によって追加された画面の扱いがまちまちなのでここいらでXRandR使って自前で設定すべきなのかもと。どのみち他所の環境で動かすようになったら必要になるし。