かのろぐ

日常と、なかよく。

VIVE Ultimate Tracker を買った (が、買うにはまだ早いと思う)

VIVE Ultimate Tracker

去年のブラックフライデーで Quest 3 を買って以来、 VRChat に魂を持って行かれました。Beat Saber したかっただけなのに。

mstdn.maud.io

そんなこんなで、足も動かしてえなあ~と思っていたら VIVE Ultimate Tracker を購入してしまったので、知見をまとめておきます。

VIVE Ultimate Tracker

ベースステーションの要らない VIVE トラッカー!! なんですが、現実はそう甘くはないです。

www.vive.com

よいところ

  • ベースステーション不要。トラッカー 3 個セット買えばフルトラ準備完了、さくっと高精度なフルトラマンに!
  • すぐ買えます。1~2週間ですぐ届きます。

よくないところ

  • 海外ガジェットを扱う基本的な知識が必要
  • まだまだ β版、こないだまで OS のロケールが en-US じゃないとトラブってたりした
  • マッピングが大変、覚えておけるのは 1 部屋だけ、広めの部屋が必要
  • ラッキングが飛びまくる、飛んだら中々戻ってこない
  • 高い。10万円です。高いね……

現時点での評価

現時点では お勧めしづらい です。

  • なんにせよ高い、転ぶと痛い価格。合わなくて売るとしても、メルカリでほぼ新品の中古は 85,000 円前後の相場感、送料手数料を引くと7万円くらいになるので 2万円くらい損すると思います。
  • 英語が読めて書けるくらいは必須です。トラブった時の相談先も Discord で英語です。
  • マッピングは時間かかるし今のところ頻繁に行う必要があり、どうせ 1 部屋しか覚えられないので、ベースステーション + トラッカーを買った方がマシそう。
  • トラッカーが飛ぶ頻度が高く、飛んだ後になかなか復帰しない

案の定ではありますが、高精度なトラッキングが必要であればベースステーション式、手軽な運用を求めるのであれば IMU 式 (ハリトラ、uni-motion、 mocopi あたり) がやっぱり手堅いかと思います。

とはいえ、VIVE トラッカーとベースステーションはず~っと品薄ですし、英語できる + PC に自信 + 金ならあるんやの人は買ったらそれなりに楽しめるとは思います。

買い方

公式サイトで買えます、買うのに苦労するのでコツを書いておきます。

クレカ決済が通りづらい

komoju payment というところで決済されるのですが、三井住友カードだとほぼ通りません。 一度決済を弾かれ (よくある)、手動で解除して再度決済してもまた弾かれたので (なんで?) 、三井住友カードはやめた方がよいでしょう。

ちなみに、楽天カードは通りました。

購入ステータスが分かりづらい

決済が通らなかった (?) からといって何度も決済はしないほうがよいでしょう。挙動的に何個も注文してしまうおそれがあるかもしれません。

いくつも注文してしまった恐れがありそう (あるいは、注文が通ってるかどうかわからなそう) であれば、問い合わせフォームに投げてみると状況を教えてもらえます。

(もしかしたら) ログインせずゲストで注文したほうが注文が通るかも

私の場合、VIVE アカウントにログインして行った注文はすべて決済が完了せず失敗しましたが、ログインせずゲストとして注文したものは通りました。

タイミングや試した順序もあるかもしれませんが、どうしても通らない!って方は参考にしてみてください。

(おそらく) 購入者住所氏名は英語で記入したほうがよいでしょう

購入フォームはすべて日本語化されていますので、日本語で住所を書きたいところですが、発送は台湾から UPS で送られてきますので、英語表記にしておくほうがよいでしょう。

正しく注文できていれば

正しく注文できていれば、メールで「注文確定のお知らせ」「VIVE_JP オーダーの請求書」「VIVE_JP オーダーの領収書」が注文から数時間以内に届くと思います。

届くまで

私の場合、買おうと思い立ったのが春節真っ最中の 2/13 だったので、注文が処理され始めるのは春節明けの 2/15 からでした。

  • 2/13 (火) 注文 (+オーダー問い合わせメール送信)
  • 2/15 (木) 春節明け、メール返信
  • 2/20 (火) 発送
  • 2/22 (木) 着

発送は台湾 桃園から、 UPS Express Saver で空輸されてきました。輸送経路は下記の通り、台湾 桃園 → 中国 深圳 → 日本 成田 でした。

2/21 の深圳 → 日本便が運休だったようで 2/22 での到着でしたが、もし 2/21 に飛んでいたらもう 1 日早く到着したかもしれません。

日本に届くまで

というわけで、注文から 3 営業日で発送、発送から2日で届きました。海外通販としては高速な部類かと思います。

届いてから

そんなこんなで高級なおまんじゅうを手に入れました。主な用途は VRChat で、しかも Quest 3 を使うので β版ファームウェアをセットアップする必要があります。

セットアップの手順は、天狼さんの下記の記事が詳しいです。

note.com

セットアップ時のあれこれ

  • 動画内では Quest Link での接続が推奨されていましたが、Virtual Desktop でも問題ないようでした。
  • OpenVR Space Calibrator では、キャリブレーションの開始時に明確な指示がなく、キャリブレーションが一生進行しないような気がしますが、気にせずにコントローラーとトラッカーを ∞ の字に動かすようにすればキャリブレーションが進行します。
  • ラッキングマップは 1 つのトラッカーで完了すれば OK です、残りのトラッカーには自動的に同期されます。うまくつながらない時はトラッカーを再起動してやるとよさそうでした。
  • トラッカーのファームウェアアップデートは動画内で説明されていましたが、ドングルのファームウェアアップデートもあります。VIVE ストリーミングハブの 設定 → バージョン情報 → トラッカードングルのファームウェア で更新できます。

ラッキング マップの品質

ラッキングマップのセットアップ後、 C:\ProgramData\HTC\ViveSoftware\ViveUltimateTracker\config\Calibration.json を開くと以下のような内容が保存されています。

{
   "map_setup" : {
      "last_map_creation_time" : 1708762609,
      "map_quality" : [ 85, 80, 80, 80, 70, 70, 85, 80 ]
   },
   "space_setup" : {
      "last_space_calibration_time" : 1708762662
   },
   "transform" : {
      "center_to_boundary1" : [ -1, 0, 1 ],
      "center_translation" : [ 0, 0, 0 ],
      "position" : [ -3.8824076652526855, 1.2561577558517456, -3.5396261215209961 ],
      "rotation" : [
         -0.0012621181085705757,
         0.41655132174491882,
         0.00036863924469798803,
         0.90911126136779785
      ],
      "universe_id" : 9277627169231678956
   }
}

上記の .map_setup.map_quality がマップの品質を示していて、0 ~ 100 の数値が入っています。

概ね 70 以上でマッピングに成功しており、80 以上が望ましいようです。

使ってみて

主に以下の点に課題を感じます。

  • マップの作成が大変すぎる + マップの使い回しが厳しい
  • トラッカーが飛ぶと戻ってこない

マップの作成が大変すぎる + マップの使い回しが厳しい

マッピングは概ね 10 分程度かかる感覚です。できる限りゆっくりトラッカーを動かしたほうがいいので、ささっと進めるわけにもいかないのがかなり難点。

さらに、一度マップを作成すれば使い回せるかというと、中々そういうわけにもいかなそうです。特に照明や太陽光の影響はかなりあるようで、照明を付けずにマッピングしたあと照明を付けるとトラッキングできなくなったり、夜に照明をつけてマッピングした後、翌朝使用しようとしたらトラッカーが飛んでしまったり、結局使用時にマップ作成するのが最も良さそうであり…

トラッカーが飛ぶと戻ってこない

VIVE トラッカーはベースステーションの影に入るなど、トラッカーが見えなくなるとトラッキングが「飛ぶ」と言われていますが、これは VIVE Ultimate Tracker も同じで、カメラが塞がれるとトラッカーが飛びます。

各種動画を見ていると、VIVE トラッカーはトラッキングが飛んだ後にベースステーションの視界に復帰すれば位置が戻っていますが、Ultimate Tracker は一旦トラッキングが飛ぶと回復まで時間がかかる というか、一旦胸元にトラッカーを持ってこないとトラッキングが復活しないように思われます。

おまけ

Quest を PC に繋いでいる人はみんな持っていると噂の Virtual Desktop のリファラルリンク置いておきます。25% オフで買えますし、私にキックバックが入ります。

Get 25% off Virtual Desktop | Meta Quest

Meta ストアの Virtual Desktop を持っている人なら誰でも発行できるので、私に小銭が入るのが気に食わない方はお知り合いの Quest ユーザーに聞いてみるといいかも。

Krile Advent Calendar 24日目

すっかり 百合 Advent Calendar の色を帯びている Krile Advent Calendar ですが、 ところで、 Krile Advent Calendar は今年が最後です。

Project Krile has been permanently frozen.

平たく言えば、Krile StarryEyes、Krile Altairを含む全てのKrileシリーズの開発を"永久凍結" (今流行のワード) します。

皆さんはもう御存知だとは思いますが、Twitterでは来年の6月より 新しいAPI体系を導入するようであり、また、クライアント デベロッパーは締め出されるという話もあります。

その環境下において、また、その環境下でなくても、私はどうやら Krileシリーズの開発継続が難しい状況下にあるようです。

長々とお付き合いさせてしまって申し訳ございませんでしたが、 Krileシリーズはここで一区切りとさせていただきたく、何卒よろしくお願い申し上げます。

バイナリの公開は来年春を目処に終了する予定ですが、ソースコードの公開停止等の予定はありませんので 皆様としては特段変わったことはないかと思います。また、メンテナンスについてはバイナリ公開終了までは 気まぐれ程度に実施するかもしれません。

これまでのご愛顧、ありがとうございました。また機会があれば。

Krile Advent Calendar 25日目: アトリエシリーズ

この記事は Krile Advent Calendar 2016 - Adventar 25日目の記事です。

www.adventar.org

アトリエシリーズ

さんざん百合の話が繰り広げられてきた Krile Advent Calendar ですが、最後に持ってくるとしたらこれということで、 今日はアトリエシリーズに関する記事とします。

続きを読む

二夜連続特集『うらら迷路帖』 その2

この記事は うらら迷路帖 Advent Calendar 2016 - Adventar 24日目の記事です。

www.adventar.org

昨日の記事もうらら迷路帖関連なのでよければご覧ください。

karnoroid.hatenablog.com

アニメ『うらら迷路帖

今日の内容は、「この冬最も熱いアニメ」「優勝しすぎて殿堂入りに最も近い」「どちや」の呼び声高い2017冬アニメ『うらら迷路帖』です。

www.tbs.co.jp

さて、このアニメ『うらら迷路帖』ですが、先日ようやく(!!)PVが公開されました。

www.youtube.com

うらら迷路帖アニメのキャストグループ「らびりんず」が歌う「夢路らびりんす」がBGMでかかっていますが、完全に頭に残るやつですね。 右クリックでループが選択できることにどれほど感謝したことか、もう何度見ているのか覚えていません。

さて、PV中ではいろいろなシーンが描かれていますね。そのほとんどが原作シーンの準拠となっていますが、 どれくらい準拠しているのか調べてみました。

ということで、この先はネタバレが含まれます。うらら迷路帖をまだ購入されていない方はもうさすがにいらっしゃらないと思いますが、 万が一未購入であれば今すぐ買いに行ってください。今すぐ。

続きを読む

二夜連続特集『うらら迷路帖』 その1

この記事は Krile Advent Calendar 2016 - Adventar 23日目の記事です。(うらら迷路帖 Advent Calendar の記事ではありません)

www.adventar.org

漫画『うらら迷路帖

おすすめのマンガ各種と『うらら迷路帖

最近、マンガを買いに買っている私です。メロンブックスのポイントが6000ポイントを超えていて自分でも若干引いています。 メロンブックスでは購入金額のおよそ5%分ポイントが付くのですが、怖くなるのでいくら使ったかは計算しないことにします。

さて、今まで買ったマンガの中には、たびたび読みかえすほど好きなもの、残念ながら続き買うのをやめてしまったもの、諸々あります。

好きな漫画を挙げるとしたら、Krile Advent Calendar においてもいくつか紹介されていますが、例えば「少女終末旅行」「わたしのカイロス」「ゆるキャン△」「紅殻のパンドラ」「やがて君になる」、そして先日アニメ化が突然発表されました「メイドインアビス」(http://miabyss.com/)などが好きです*1

さて、そんな大好きな漫画の中から、この場は百合アドベントカレンダーであることを鑑みて、私がこよなく愛してやまない、そして、この冬最も熱いアニメとなる予定であるうらら迷路帖について、僭越ながら、少々書かせていただきます。

うらら迷路帖 (1) (まんがタイムKRコミックス)

うらら迷路帖 (1) (まんがタイムKRコミックス)

*1:ここでは「ゆゆ式」「きんいろモザイク」「ご注文はうさぎですか?」は必修科目として挙げていません

続きを読む

私の推しマンガ5選

こんばんは。かーのです。Twitterではめっきりツイートしなくなってしまいました。

さて、

で発言した内容ですが(鍵アカウントなので以下に内容を添付しておきます)、ニーズがあったのでやってみます。

ここ1年以内に買ったマンガから面白かったものを5つ、苦渋の決断で選び出して紹介します。

f:id:karnoroid:20160107194915p:plain

なお、ツイートの通り、以下の内容において

f:id:karnoroid:20160107195045p:plain

f:id:karnoroid:20160107195119p:plain

は紹介いたしません。なぜなら必修科目ですので、当然みなさん既にお持ちでしょう。(あと、買ってから1年以上経ってるし)

続きを読む

邪道式 Windows Presentation Foundation

世間ではUWPだ、Electronだという声が大きくなっていますが、今更WPFの話をしようと思います。 というのも最近は、WPFのレイアウトに関する長年の悔恨をそろそろ晴らしておきたいと思いまして、とある難題を調べ漁る毎日を送っていたからです。 あと、最近ブログにプログラミングの話題を書いていなかった上に、そもそもブログに文章を書いていなかったので、長文記述力を取り戻すためにもここらで何か書いておくかという思惑もあります。

※この内容は続き物な気がしますが、次回投稿があるかどうかは主に気力がないので不明です。ということで、第n回みたいなタイトルは付けないでおこうと思います。

やっていること

拙作のTwitterクライアント「Krile StarryEyes」にはタイムラインのスクロール制御を組み込んでいるのですが、こいつが動いたり動かなかったりと 中々適当な挙動を見せてくれるうえに、ついに最近(.NET Framework 4.6以降?)は全く動かなくなったとの話も聞きます。

KrileのタイムラインはWPFのリスト、より詳しく言えばピクセルベースのスクロールとコンテナリサイクルを有効にしたVirtualizingStackPanelを レイアウトに使用するItemsControlで構成されています。こいつが思い通りに動いてくれないわけです。

これをなんとかするため、VirtualizingStackPanelとItemsControl、ScrollViewerの関係を探っています。主にReference Sourceを読み漁り、たまにMSDNを読んでいます。 各種クラスの関係とか内部の実装とかはほとんどドキュメント化されてないので、MSDNだけですべてを探るのはけっこう厳しいものがあります。 そういう意味ではReference Sourceはとても参考になりますが、やっぱり読みづらいです。。。

そもそも論:WPFレンダリングプロセス

昔々、WinFormsのコントロールは、最悪自前で全部描いてしまえばなんとかなる、みたいなことがありました。

しかしWPFXAMLに予め定義された要素を置いて、あとはスタイルなりビヘイビアなりで制御して、という形がほぼすべてです。 WinFormsではよく見た、完全にカスタムしたコントロールをコードで作るという例はWPFではあまり聞いたことがないです。

というのも、WPFXAMLでちょいちょいっと書くだけで、かなり複雑なカスタマイズにも対応可能だからです。 XAMLで見た目を定義するのはとても楽ちんですし、今更レイアウトを計算するコードを書くなんてダサいし非効率的だしバグの温床になるというわけで、 自分で何から何まで面倒を見るコントロールを作るという文化はWPFではほとんど廃れてしまったように感じています。

私はこれまで、WinFormsのコントロールとくらべてWPFのコントロールはカスタムできる範囲に限度があり、そしてそれは最悪自分で全部レンダリングできる WinFormsと、レンダリングの要素が予め用意されているものに限られるWPFの構造に起因している と思い込んでいました。そして、それは事実ではありませんでした。

つまり、やりようによってはWinFormsの流儀である DO IT YOURSELFWPFにおいても通じるようです!それができるなら、もう既存のコントロールの 不快な動作にやきもきする必要もなく、自分で全責任を持って楽しい毎日を過ごすことができそうです。

そんな楽しい毎日を過ごすために、ここでWPFがどうやってUIを組み上げているかの説明をしておきたいと思いますおきたいと思いましたが、中途半端に終わってしまいました。

反省の弁

そして、何より今まで私は、WPFがどうやって要素をレイアウトしているか、どうやって要素を描いているか、そんなことに気を配らずにアプリケーションを書いてきました。これは大変に恥ずべきことです。。。

どうやって動いているかが分かれば、あとはそれをなぞるなり逆手に取るなり無視するなりの対策が打てるようになるので、もっとマシなアプリケーションが書けそうな気がします。 反省も含めて、WPFのレイアウトシステムがどうなっているかを簡単になぞりたいと思います。

レイアウトとレンダリング

そもそも、WPFレンダリングは2つのツリーによって行われています。

ひとつは、「LogicalTree」。XAMLで記載する内容に近いデータが保持されています。たとえば、Windowの下にGridがあり、その中にListBoxがあり、その中にはさらにListBoxItemがぶら下がっている、そんな構造が そのまま現れます。

そしてもう一つが「VisualTree」。こちらは、画面に描画するコンポーネントが登録されます。ListBoxの中にはScrollViewerがあったり、さらにその中にVirtualizingStackPanelがあったり、…。

おおよそ見当が付く通り、WPFはこの「VisualTree」を使って描画します。そして、VisualTreeに参加する資格があるのは「System.Windows.Media.Visual」以下のクラスです。

そしてMSDNにはVisualについて「WPF でヒット テスト、座標変換、境界ボックス計算などの描画をサポートします。」との記載があります。 つまるところ、WPFで何かレンダリングするためには、以下の条件が達成できれば良いわけです。

  • ヒットテスト - 指定した座標がVisual内にあるか判定
  • 座標変換 - 指定したVisualに含まれる子Visualの相対座標の制御
  • 境界ボックス - bounding box、指定したVisualが画面中で占める領域を計算

ところで、Visualではヒットテストや座標変換を制御できるvirtualメソッドはありますが、Bounding Boxの言葉は一言も出てきません。

それもそのはず、Bounding Box周りのvirtualメソッドはすべてinternalになっています: Visual.cs - Microsoft Reference Source

ではどうするかというと、その一層下の UIElement を見なければなりません。

UIElementは「MeasureCore」「ArrangeCore」などのレイアウトに関係するほかにも、膨大なvirtual methodを提供してくれます。詳しくはMSDNをご覧ください。

そう、実際には、ユーザが何か独自のコントロールを生み出したい場合、UIElementが提供する機能以上のことは行えません。 しかし、UIElementは十分すぎる機能を提供してくれます。自分で実装する気力さえあれば、きっとあなたのソリューションを見つけることができます。

さて

だいぶお酒が回ってきたので、今日はここまでにしたいと思います。

この記事について

基本要素の概要 - MSDNを見るとよくわかるかもしれません。