【ViveProEye】時間遅れの話とRuntime (ver 1.1.2.0)で報告された不具合の話

ランタイムのバージョンが更新されたと聞いて、自分もアップデートを…('ω')

f:id:umehashi:20190731151010p:plain ←コレ

とか思ってたらフォーラムで、不具合を訴えるコメントが複数見つかったので慎重にまだ様子見ようと思ってます。（まだ自分はver 1.1.0.1と1.0.3.0だったりするんですが）

ランタイムの不具合について、そして視線の時間遅れについてフォーラムが動いてたので、書き留めたいと思います(/・ω・)/

フォーラムでは「ver1.1.0.1と入れ替えたらうまく動かなくなった」という方が「高い金払ってんだから対応しろ？」とお怒りのスレッドを立てていたり

「まぶたが完全に閉じなくなったぞ」とゴリラのアバターの動作を、動画にして投稿されてる方がいらっしゃったり…(。-`ω-)

確かに動画を見ると、目が閉じ切ってないですね。

そもそも、今回のランタイムのバージョンの更新内容は、このスレッドにもあった『経過時間の単位の誤植』の修正なはずなので、余計おかしいですね(´・ω・)

⇓ver1.1.2.0で修正された（らしい）更新内容と注意

ver1.1.0.1では、経過時間（ミリ秒）と言いながら（マイクロ秒）を返してくる不具合を修正。プログラムでEyeData.timestampを使っている人は、更新時に注意しましょう。

個人的には目の開き具合の方が大事ですし、経過時間はC#で取得しているのでバージョンアップはしばらく見送ろうかなと考えています('ω')

【2019/11/05追記】ゴリラの人はプログラムに追記忘れてたわﾃﾍﾍﾟﾛで解決したようです(笑)

これは研究者(もしくは中心窩レンダリングを正確に行いたい人)が使用するときくらいにしか気にしないような内容です。

ViveProEyeを使って時間遅れがどれくらいか試した大学？の方が、スレッドにおられまして計測結果をグラフ化してくださっています。

そもそも22~33msの遅れが起きるHMDに加えて、アイトラッカーが83ms更に遅れるとのこと。

これは市販のアイトラッカーとは遜色ないが、中心窩レンダリングとしてはどうなんだろうか？とのことのようです。（読み違えてなければ）

※中心窩レンダリング…注視点だけ解像度高めて周辺視野は落とす。

議論として

中心窩レンダリングするには遅れがデカすぎる

⇒最適は20~40ms遅れ程度だが、許容できる遅れの範囲にはいる(50~70ms)し、ポスト解析には問題ないのでは？

⇒レイテンシは裏の中心窩計算の負荷次第で変動している可能性がある、どれくらい安定するかは分からない。

⇒中心窩をレンダリングせず計算もせず、記録だけして後で注視点を解析することだけにすれば安定して研究に用いることが出来るかもしれない。

自分は注視点計算をリアルタイムで計算してるソフトにする予定なので、中心窩レンダリングなしにしてGPU負荷を落としてみようかな…(´・ω・)

Vive公式からの『時間遅れを誰もが減らせる方法を検討してる』との返事が見受けられたので、今後のアップデートに期待するとしましょう。

どうぞよしなに

うめ研究生のVR開発記