キャラメイクについて考えてみたのだが、MMOだとそこにいるキャラ全部のデータをグラボに読ませなきゃならない関係上、好きなように-例えばFBX読ませたりとかみたいな-キャラ作らせるわけには行かなくて、その上wOCEはコミュニケーションツールに重点を置くのでゲームと違って「なうろーでぃんぐ」が許されない。なのでデータはなるべく小さくなるべく使い回さなきゃならん。
今のは知らないけどDC版のPSOがああいう、種族、身長、太さ、色みたいな限られたキャラメイクになってたのはそういう理由からだと推測していて、今だともうちょっとリソース使えるにしても似たようなものになりそう。そのへんの研究のためにやってみるかな...。
テクスチャのアップデートがクッソ遅いのできっちりコントロール下に置かないとフレームレートを維持できないのが理由で処理を再び集中化した...のだが、わかっているつもりではあったがここまで遅いとは思わなかった。フレームあたり8x8のタイルでせいぜい200枚くらいしか更新できない。
というところで今のところテクスチャサイズが二冪ではないのを思い出した。どのみちグラボで完結する処理に比べたらクッソ遅いんだろうけど二冪にしたら多少は高速化できるかも知れぬ。
--二冪テクスチャを作ってやってみたが大して変わらなかった。転送サイズ拡大のほうが効くかも。
VRHMDのプロファイルから画面名を読んで、XRandRで読んだEDIDに書いてある名前と一致してる画面が見つかったらONにして所定位置へ配置するようにした。これで一応画面配置に関する問題は解決。
いちいちXRandRを起動してるのでlibXRR使いたいところだけど手間なので後回しにしてこの件はひとまず終了っと。
テクスチャ更新はかなり重い処理なのでフレーム更新に影響が出ないようにコントロールする必要があるのだが、別スレッドでこの処理をするとまったくコントロールできなくなってテクスチャ更新がまとまって入ってくるとフレームレートどころの話ではなくなる。RiftCV1なんかはフレームレートが乱れるとブラックアウトして回復しないようだし、ダメダメだ。
困ったことにフレームバッファのスワップはVSYNCに近い場合でもなければVSYNC待ちをしないので、メインスレッドでメッセージ処理をしようとすると無駄に描画するばかりでほとんど処理が進まなくなる。これがスレッド化した理由なのだが。
どうやらフレームバッファをスワップした後にglFinishを呼んでおくとVSYNCを待ってくれるようなので、結構苦労してマルチスレッド化したのだが元に戻すかあるいはテクスチャ更新だけメインスレッドですることになりそう。
--RiftCV1がブラックアウトするのはUSB3の電源が原因のようだ。追加電源使うボード使ってるのだが、DK2も挿してるのがダメっぽい。
接続されてる端子がわかってれば何も考えずに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すればいいようだ。
OpenHMDからRiftCV1の歪み補正情報を得たので試してみた。
のだけれど、RiftCV1は設定しないと画面として認識してくれないのでDK1/2のように一度画面を設定すれば繋がってる限り画面の設定が保存されるってわけには行かない。
KDEは接続のパターンごとに設定を覚えているけれど(そしてよくデスクトップと画面の対応を滅茶苦茶にしてくれて腹立たしいけれど)XFce4は全く覚えてくれない(が、変更してもデスクトップと画面の対応は安定している)...という感じに環境によって追加された画面の扱いがまちまちなのでここいらでXRandR使って自前で設定すべきなのかもと。どのみち他所の環境で動かすようになったら必要になるし。
シェルからのリクエストで子プロセスへの通信路を確保して起動できるようにした...んだけどメニューとか出すためにはレイアウタを完成させないとならん。とりあえず描画内容を反映できるからとメニューとか先に「てやーっ！」て作っても結局「リストコントロールを使ったメニューコントロール」を作るのだから二度手間だ...てわけでレイアウタでやることを書いてみる。
レイアウタはサイズを持つWidgetのサイズを決めるもので、レイアウタを使うことでユーザプログラムは配置計算から解放される。要するに項目を追加してったり、予めサイズが決まってるところを分活したりする時に確保する幅や割合だけで宜しくやってくれるってわけ。
しかし、追加したり割り当てたりするのはいいんだけど、どういうインターフェイスにするべきか悩むところ。縦用とか横用とか用意するのかとか。
Rift他大抵のVRHMDは光学系の歪みを描画内容を歪ませることで補正しているが、この副作用として実際のフレームバッファより大きな領域を必要とする。この関係で描画領域が実画面サイズと一致している場合フレームバッファ外から画素を拾う必要がある。
となるとテクスチャとして確保されたフレームバッファオブジェクトの外側をアクセスするわけで、デフォルトの設定では左右の外側が繰り返しになってしまって見苦しい、
というワケでフレームバッファオブジェクトの設定をGL_CLAMPへ変更。この設定だと外側へのアクセスは外周の半分の値を得られるのでちょうどいい塩梅にぼやけた感じになってくれる。最初歪み補正テクスチャの属性をいじって変わらんなーと悩んでたのはナイショだ。
TB::Threadではスレッド本体を自動で起動しているのだが、これがタイミングが悪いと継承する前のスレッド本体(純粋仮想関数)を呼び出してしまう可能性がある。
実際にはスレッドの起動は最低優先度スレッドで行われるのでまず起きないことではあるし今のところ問題は起きていないのだが、起動準備ができていないのに起動する可能性は依然残っているので明示的にRaiseThreadを呼び出して起動するようにした。
明示的に呼び出さないと動かないとか仕様として気持ち悪いのだが全ての継承先クラスのコンストラクタの処理が完了した事を確認する方法がないので仕方がない。
地磁気センサを扱うには地磁気より強い機器自体の磁化成分を除去する必要がある。旧来は「機器を8の字に回して」キャリブレーションしてみたり、あるいは旭化成が特許を持ってるDOEみたいな方法もあったのだが、VRHMDをぐるぐる回してキャリブレーションするのはかなり面倒だしDOEは知的財産権的に微妙だし四点のサンプルを必要とする。
考案自体はだいぶ前にしていたのだが式が解けなかったのだが、先ほど式ではないが図で解けた。しかもDOEが四点のサンプルを必要とするのに対して新方式は二点でキャリブレーションを進められる。
開発環境にはXfce4を使っているのだが、この環境でGLXでキャプチャするとXfce4をコンポジット処理の「全画面オーバーレイウィンドウを直接表示する」を設定しておかないとキャプチャできず真っ黒になり、指定しておくと画面の更新が止まり、コンポジットを使わないとゴミが読み出される...という状況になっている。
まぁ要するにこの方法では無理って事だ。
KDEとかだとまた違う可能性もあるのでそのうち試すとしても、GLXによるキャプチャが使えないとするとあのスットロイX標準の方法でキャプチャするしかないのか...orz
--Xephryを取り込んだりして子コンテキストに描画させることはできるので不可能じゃないんだけど、手間かかりそうなので将来の課題だなー。本筋じゃないし。
引っ越し先。 見えるかな。