じゅころぐAR

AR/VRメインのブログ。時々ドローン。

どうして空間共有で先に座標系の逆変換(inverse)を行うのか?

先日、Cloud Anchorを使ったオブジェクト共有の記事を書きましたが、Matrix4x4を使った座標変換の説明で若干モヤっとしなかったですか?
Cloud Anchorを基点にした座標系で位置を伝えるのに、なんで送信側がCloud Anchor座標系への逆変換(inverse)を使うのかです。

正直、記事を書いている途中も半信半疑(でも実装上は正しい)という状態だったのですが、何か降りてきたようで、今ならわかりやすく説明できる気がする!

やりたいこと

Andy君がCloud Anchor、オレンジのピンが共有したい地点だとします。(説明を簡単にするため、とりあえず回転は考えない)

f:id:jyuko49:20180621125708p:plain

座標系が異なる他のデバイスに正しく位置を教えるには、Cloud Anchor(Andy君)から見てココ!というCloud Anchor座標系で位置を伝える必要があります。(下図の赤いベクトル)

f:id:jyuko49:20180621125811p:plain

座標変換には行列を使うのが簡単で、UnityではMatrix4x4を使えば良さそうです。

正変換→逆変換:NG

まず、間違えた実装の方から。

Matrix4x4にCloud Anchorのposition、rotationを与えると、デバイス座標系→Cloud Anchor座標系の変換を行う行列ができます。
Cloud Anchorの座標系に変換する行列なんだから、これで変換をかけた座標を渡せばいけるでしょ!
と、最初は思ってました。

実際に変換すると、デバイス→Cloud Anchorの座標変換と同じだけピンを移動(青い矢印)させた地点の座標が返ります。

f:id:jyuko49:20180621125610p:plain

結果としては上図の赤い矢印で、最初に求めたかったベクトルと違います。

この座標を別のデバイスに伝えて、逆変換をしてみましょう。
Cloud Anchorの座標系から見た座標が今求めたベクトルなので、Cloud Anchorを基準にデバイスの座標系に変換すれば、元に…

f:id:jyuko49:20180621125615p:plain

戻らないですね!(・∀・)

実機テストでこれだけ盛大に位置がズレたら、流石に計算が間違っていると気付きました。

逆変換→正変換:OK

それならばと送信側でMatrix4x4.inverseによる逆変換をかけてみました。押してダメなら引いてみろ理論です。

逆変換なのでオレンジのピンの座標に対して、Cloud Anchor→デバイスの変換(青い矢印)がかかります。

f:id:jyuko49:20180621125612p:plain

結果として得られる座標は、Cloud Anchorから見たピンの位置(求めたかったベクトル)をデバイス座標系で表したものです。

この座標を別のデバイスに伝えて、さらにCloud Anchor座標系に変換します。
今求めた座標をデバイス→Cloud Anchorで変換すると、

f:id:jyuko49:20180621125613p:plain

できてそう!!

まとめ

理論から入るのもいいですけど、とりあえず動く実装を見つけるのも大事ですね。
正しく動いていれば、理論は後から付いて来ます。