スクリーンキャスト機能を復活

時間が空いたが動画を取得したので貼ってみる。動かしてるのはwOCE用のサンプルアプリで画像ビューア。無難なの...と選んだ結果「オフィスに貼ってあるアレ」的なフォルダの中身を表示させてみた。

また動画の終わりのあたりでマウスカーソルを動かして奥行きをデモしたりしてる。

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

なんて思ってたんだが実はテクスチャの更新が遅いのは更新回数が原因だった。

どうやらテクスチャの更新は思ってた以上に回数依存ぽくて、一度に更新するサイズを拡大したらメインスレッドでの更新でPBOも使ってないにもかかわらず一発で十分なほど改善された。

これだとスレッド化してPBOで更新するようにすれば大きめのテクスチャをまるごとでも更新できそうなんだけど、それをすると通信路が詰まりそうなので今の方法で問題が出るまで放置することにする。てかおそらく今でもリモートで動かすと詰まりそうだし。

スクリーンキャスト機能を復活

「キャスト」というのは違うかも知れん。画面を動画でキャプチャする機能を復活した。

今回はPBOを大量に用意してフルフレームで「ぬるんぬるん」キャプチャできる上に通常動作への影響が感じられないくらいの低負荷にできた。

最初はPBOではなくテクスチャに格納するようにしていたのだが、テクスチャからメインメモリに読めるはずのglGetTextureが全く機能せず画像が真っ黒になってしまうのでPBOを使ってみたのだが、画像の取り出しも高速化されているハズで満足な結果になった。

しかし、動作確認に使ったサンプル画像がアレなので動画の公開はまた今度〜(ぉ

Cairoが

透過画像が暗く表示されるので何事かと思ったが、Cairoが改版されて透過色の扱いが普通になったのが原因だった。

以前はCairoでは透過の場合RGBの各要素に不透過率が乗じられた状態で格納されてた。こうするとそのまま足せばいいのである意味簡単なのだがCairoを特別扱いする必要があった。

で、これがなくなって普通にRGBにはそのままの値が入るようになったので、普通に扱えば良くなった。というワケ。

概ね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も挿してるのがダメっぽい。