LRTKレフィクシア株式会社

3D図面AR表示でglTF書き出し時の座標欠落を防ぐ4対策

3D図面AR表示でglTFの座標欠落が起こる理由

3D図面をglTF形式へ書き出し、現場でAR表示すると、形状や色は正常に表示されているにもかかわらず、本来の絶対座標へ配置できないことがあります。この状態は、単純なファイル破損ではありません。モデルの形状を構成する相対的な座標は残っていても、現場のどこへ配置するかを示す原点情報や座標変換条件が失われている可能性があります。

3D図面を画面上で閲覧するだけであれば、モデルが原点付近へ移動していても大きな問題にならないことがあります。建物や構造物の形を確認する用途では、モデル全体の位置よりも、部材同士の位置関係や寸法が維持されていることが重視されるためです。一方、3D図面を現実空間に重ねるAR表示では、モデルの原点、方向、縮尺、高さを現場座標と一致させなければなりません。

glTFは、3Dモデルの形状、ノード階層、材質、画像、アニメーションなどを効率よく受け渡すための形式です。ただし、測量成果で使用する平面座標系の名称や、工事基準点の点名、標高の基準、現場固有の任意座標系まで、すべての受け渡し先が同じ意味で理解できるように自動保存する形式ではありません。

そのため、元の3D図面では絶対座標を持っていたとしても、書き出し処理の途中でモデル中心が原点へ移されたり、大きな平面座標が省略されたりすることがあります。書き出し元の環境が、表示安定性や互換性を優先してローカル座標へ変換する場合もあります。

座標欠落には複数の状態があります。代表的なのは、元の原点座標が失われてモデルがゼロ付近へ移動する状態です。そのほかにも、水平軸と鉛直軸が入れ替わる、座標の正負が反転する、ミリメートルとメートルの換算が抜ける、標高が相対高さへ変わる、親ノードに記録されていた移動量が削除されるといった問題があります。

これらの問題は、モデルを開いただけでは発見できないことがあります。形状が崩れていなければ、書き出しに成功したように見えるからです。しかし、現場でAR表示すると、モデルが遠く離れた場所に出る、地面の下へ沈む、横倒しになる、基準点では合うのに離れた地点でずれるといった現象として表れます。

また、大きな絶対座標をそのまま頂点へ保持することにも注意が必要です。3Dデータで一般的に使われる数値表現では、値が大きくなるほど、非常に小さな差を保持しにくくなる場合があります。数十万や数百万という座標値に対して、数ミリメートルから数センチメートルの形状差を同時に扱うと、表示や計算の過程で細かな位置関係が不安定になる可能性があります。

したがって、3D図面をglTFへ書き出してAR表示する場合は、絶対座標をそのまま残すことだけを目的にするのではなく、モデル内部のローカル座標と、現場へ配置するための絶対座標情報を分けて管理する考え方が重要です。元の位置へ復元できる情報を確実に残し、書き出し後に検証することで、座標欠落を防ぎやすくなります。

対策1 座標系・軸方向・単位を変換前に固定する

最初の対策は、glTFへ書き出す前に、元の3D図面が使用している座標の定義を明確にすることです。座標値だけを保存しても、その値が何を意味しているか分からなければ、正しい位置へ復元できません。

まず確認するのは、元の3D図面がどのような座標で作成されているかです。公的な平面座標を使用しているのか、工事基準点を原点とする任意座標なのか、建物や構造物の内部だけで通用するローカル座標なのかを区別します。

座標値が大きいからといって、必ずしも絶対座標とは限りません。設計時に便宜上設定された値や、別の座標から一定量を加減した値である可能性があります。座標系の名称、系番号、変換履歴、原点の設定方法を確認し、担当者の推測だけで処理しないことが重要です。

次に、各軸の意味を確認します。土木測量や設計図面で使用する座標軸と、3D表示で使用する軸は、同じ名称でも方向が一致するとは限りません。元データのX軸が南北方向、Y軸が東西方向、高さがZ軸である場合でも、glTFへの書き出し時には高さが別の軸へ変換されることがあります。

glTFでは、メートルを基本単位として扱い、Y軸を上方向とする構成が基本です。そのため、元の3D図面でZ軸を高さとしている場合は、軸の入れ替えや回転が行われる可能性があります。この変換自体は問題ではありません。問題になるのは、どの変換が行われたかを記録せず、AR表示側でもう一度同じ変換を適用してしまうことです。

たとえば、書き出し時にZ軸の高さをY軸へ変換したにもかかわらず、AR表示側でもZ軸をY軸へ変換すると、モデルが横倒しになったり、前後方向と高さ方向が入れ替わったりします。反対に、変換が必要なのに適用されていなければ、モデルが垂直に立たず、地面と直角に交差するような表示になることがあります。

軸方向は、名称だけでなく実際の方向として記録します。元の東方向、北方向、高さ方向が、書き出し後のどの軸の正方向へ対応するかを残します。正負の向きも重要です。軸が同じでも正方向が逆であれば、モデルが基準点を挟んだ反対側へ配置されます。

単位についても、書き出し前に固定します。元の3D図面がミリメートル単位で作成されている場合、長さ1,000の部材は1,000メートルではなく1メートルを意味します。glTFへ書き出す際に0.001倍する処理が必要ですが、書き出し機能が自動変換する場合と、元データ側で変換する場合があります。

単位換算を二重に行うと、モデルが本来の1,000分の1になります。換算を一度も行わなければ、モデルが1,000倍になります。この誤りは、絶対座標のずれと混同されやすいため、位置を確認する前に既知寸法を測定する必要があります。

原点付近ではモデルが合って見えるものの、原点から離れるほどずれが増える場合は、単位や縮尺が一致していない可能性があります。平行移動の誤りであれば、モデル全体がほぼ同じ量だけずれます。一方、縮尺の誤りでは、基準点からの距離に応じてずれが拡大します。

高さの基準も明確にします。元データの高さが標高なのか、工事基準点からの比高なのか、建物の床面をゼロとした相対高さなのかによって、AR表示時の処理が変わります。高さの数値が残っていても、基準が異なれば地面より上に浮いたり、地下へ沈んだりします。

実務では、書き出し前に座標条件を文書化します。記録する内容は、座標の種類、原点の名称、原点座標、水平軸の対応、鉛直軸の対応、軸の正負、長さの単位、高さの基準、北方向、書き出し時に行う変換です。

さらに、モデル内に複数の確認点を設定します。原点だけではなく、原点から離れた地点、異なる高さにある地点、モデルの方向を判断できる地点を選びます。原点一つだけでは平行移動しか確認できず、回転、軸反転、縮尺の誤りを見逃す可能性があります。

書き出し前の段階で座標条件を固定しておけば、glTF内の軸や単位が元データと異なっていても、逆変換によって元の絶対座標へ戻せます。重要なのは、変換を行わないことではなく、行った変換を再現できるようにすることです。

対策2 絶対座標とローカル原点を分けて管理する

2つ目の対策は、現場の絶対座標と、glTFモデル内部で使用するローカル座標を分離することです。すべての頂点へ大きな絶対座標を直接持たせる方法は分かりやすく見えますが、細かな形状の保持や複数環境での表示に不利になる場合があります。

たとえば、構造物が広い平面座標上にあり、各頂点が数十万や数百万の値を持っているとします。構造物自体の大きさが数十メートルで、部材の詳細が数センチメートル単位で作られている場合、非常に大きな位置と小さな形状差を同じ数値表現で扱うことになります。

数値が大きくなるほど、表現できる細かな間隔が粗くなる場合があります。その結果、頂点がわずかに移動する、近接した面がちらつく、細い部材の位置が不安定になるといった問題が起こる可能性があります。特に、現場でセンチメートル単位の位置確認を行う場合は、絶対座標をそのまま頂点へ持たせる方法が適しているかを検討する必要があります。

実務的な方法は、モデル付近にローカル原点を設定し、元の絶対座標から原点座標を差し引いてglTFへ書き出すことです。元の点の座標をX、Y、H、ローカル原点をX0、Y0、H0とすると、モデル内部ではXからX0を差し引いた値、YからY0を差し引いた値、HからH0を差し引いた値を使用します。

この方法であれば、glTF内の座標値を数十メートルから数百メートル程度に抑えやすくなります。現場へAR表示するときは、保存しておいた原点の絶対座標を再び適用し、モデルを本来の位置へ戻します。

ただし、原点を差し引くだけでは対策になりません。差し引いた原点情報を失うと、モデルの相対形状しか残らず、絶対座標へ復元できなくなります。座標欠落を防ぐためには、ローカル原点の絶対座標をモデルと一体的に管理する必要があります。

原点情報には、単なる数値だけでなく、その意味も記録します。たとえば、原点のX、Y、Hという三つの値があっても、XとYのどちらが東西方向なのか、単位がメートルなのか、高さが標高なのかが分からなければ正しく利用できません。

原点には固定した識別名を付けます。工事基準点を使用する場合は、その点名を記録します。モデル中心を原点にする場合は、どの範囲から中心を求めたかも残します。モデル中心を自動計算する方式では、形状を追加しただけで中心位置が変わることがあるため、更新運用には注意が必要です。

設計変更や施工段階の更新を繰り返す場合は、固定した原点を使用したほうが管理しやすくなります。モデルの形状が変わっても原点が変わらなければ、同じ配置条件で更新ファイルを差し替えられます。

複数モデルを同時に扱う場合は、共通原点を使用する方法と、モデルごとに個別原点を使用する方法があります。共通原点を使えばモデル間の位置関係を管理しやすくなりますが、対象範囲が広いと各モデルのローカル座標値が大きくなる可能性があります。

モデルごとに個別原点を設定すれば、各モデル内部の座標値を小さく保ちやすくなります。ただし、AR表示時にモデルごとの原点を正しく適用する仕組みが必要です。どちらを採用する場合でも、原点の設定方法を案件内で統一します。

原点移動を二重に行わないことも重要です。元データ側ですでに工事基準点を原点へ移しているのに、書き出し機能がさらにモデル中心を原点へ移すと、二段階の移動が発生します。どちらか一方の移動量を記録していなければ、本来の位置へ戻せません。

反対に、元データの絶対座標を頂点へ残したまま、ルートノードにも原点の絶対座標を設定すると、表示時に座標が二重加算される場合があります。モデルが本来の位置より大きく離れ、ずれ量が原点座標に近い場合は、絶対座標を二重に適用していないか確認します。

ローカル原点方式では、変換の順番も固定します。一般的には、glTF内のローカル座標を読み込み、軸方向を合わせ、単位を調整し、必要な回転を適用した後、絶対座標上の原点へ平行移動します。回転と平行移動の順番が変わると、回転中心や移動方向が変わることがあります。

絶対座標とローカル原点を分けることで、glTF内部の数値を扱いやすくしながら、現場座標への復元性を維持できます。座標を一つのファイル内へ無理に押し込むのではなく、形状を表す座標と、現場へ配置する情報を役割別に管理することが重要です。

対策3 ノード階層と変換行列を整理して書き出す

3つ目の対策は、glTFへ書き出す前に、3D図面内のノード階層と変換行列を整理することです。モデルの最終位置は、頂点座標だけで決まるとは限りません。親ノードと子ノードに設定された平行移動、回転、縮尺が組み合わされて、画面上の位置が決まる場合があります。

たとえば、メッシュの頂点自体は原点付近にあり、親ノードに大きな平行移動が設定されているモデルがあります。この状態では、親ノードの変換が適用されることで、モデルが設計上の位置へ表示されます。

書き出し時にメッシュだけを選択し、親ノードを除外すると、親ノードが持っていた移動量や回転が失われる可能性があります。書き出されたglTFは正常に開けても、すべての部材が原点付近へ集まったり、モデル全体が別の位置へ移動したりします。

反対に、親ノードの変換を頂点へ適用した後も、同じ変換がノードに残っていると、移動や回転が二重に適用されます。変換を確定する処理を行う際は、頂点へ反映した変換がノード側から削除されているかを確認します。

glTFでは、ノードの位置を平行移動、回転、縮尺として表す方法と、これらをまとめた変換行列として表す方法があります。どちらの方法でも表示できますが、書き出し元と読込側で変換の扱いが一致していなければ、最終位置が変わる可能性があります。

実務では、絶対位置をどこで管理するかを決めます。頂点へ直接反映するのか、ルートノードの平行移動として持たせるのか、glTF外の座標情報として管理するのかを統一します。同じモデル内で複数の方法を混在させると、座標欠落や二重変換の原因になります。

AR表示を前提にする場合は、glTF内部をローカル座標で整理し、現場への絶対配置を外部の座標変換として管理する方法が分かりやすい場合があります。この方法では、ルートノード付近の座標を小さく保ち、AR表示時に原点座標と方向を適用します。

回転については、軸変換のための回転と、現場の北方向へ合わせる回転を区別します。元データの高さ軸をglTFの上方向へ合わせる処理と、モデルを現場の方位へ向ける処理は、目的が異なります。

書き出し時に軸変換の回転を適用し、AR表示時に方位回転を適用する場合は、それぞれの回転量と適用順序を記録します。両方を一つの回転として扱うと、原因の切り分けが難しくなります。

モデルが横倒しになる場合は、鉛直軸の変換を確認します。モデルが正しい高さを持っていても、高さを表す軸が前後方向として解釈されれば、構造物は地面へ寝た状態になります。単に90度回転して修正するのではなく、元の高さ軸とglTFの上方向の対応を確認します。

モデルが180度反転する場合は、水平軸の正負や北方向の設定を確認します。基準点一つだけで位置を合わせると、180度反転したモデルでもその点だけは一致します。原点から離れた二つ目の確認点を使い、方向を検証する必要があります。

縮尺についても、単位換算とノード固有の拡大縮小を分けます。ミリメートルからメートルへの変換はデータ単位を統一するための処理です。一方、ノードに設定された縮尺は、モデルの見た目や部材配置を構成するために使用されている場合があります。

ルートノードに0.001の縮尺が残っているモデルを、読込側がさらにミリメートルからメートルへ変換すると、二重縮小が発生します。書き出し後にモデルが極端に小さい場合は、頂点座標だけでなく各ノードの縮尺を確認します。

親子階層を単純化する場合は、階層解除の前後で確認点の位置を比較します。親ノードを削除するだけでは、子ノードが受けていた変換が失われる可能性があります。親の変換を子へ正しく反映し、最終的な位置が変わらない状態で階層を整理します。

非表示の補助要素にも注意が必要です。表示されていない空のノードや基準オブジェクトが、複数部材の親になっている場合があります。見えている部材だけを選択して書き出すと、座標変換に必要な親要素が除外されることがあります。

書き出し対象を確認する際は、形状を持つメッシュだけでなく、位置、回転、縮尺に関係する上位ノードも調べます。必要な変換を頂点やルートノードへ整理してから、不要な補助要素を除外します。

複数のモデルを同じAR表示環境へ読み込む場合は、ノード構成も統一します。あるモデルは頂点に位置を持ち、別のモデルは親ノードに位置を持つ状態では、同じ変換処理を適用できません。

ルートノードの役割、原点ノードの名称、軸変換の位置、単位換算の方法を案件内で統一すると、書き出し担当者が変わっても同じ結果を得やすくなります。変換行列の整理は、見た目を整えるためだけでなく、絶対座標へ復元できる構造を作るために必要な工程です。

対策4 座標情報を別途保存し再読込で検証する

4つ目の対策は、絶対座標へ戻すための情報をglTF本体だけに依存させず、座標管理情報として別途保存し、書き出したファイルを再読込して検証することです。

書き出し処理がエラーなく終了しても、座標が正しく引き継がれているとは限りません。形状、材質、画像が正常であっても、原点、軸対応、高さ基準、回転量などが欠落している可能性があります。

座標管理情報には、元の座標系、ローカル原点の絶対座標、原点の識別名、水平軸と鉛直軸の対応、軸の正負、単位、高さ基準、北方向、回転量、縮尺、書き出し日時、元データの版を記録します。

特に、原点の絶対座標だけを保存して終わらせないことが重要です。同じ三つの数値でも、並び順、軸方向、単位、高さの意味が違えば、配置結果は一致しません。第三者が見ても同じ変換を再現できる情報を残します。

座標情報は、モデルと同じ管理単位で保存します。ファイル名だけで関連付けると、名称変更や複製によって取り違えが起こる可能性があります。モデルと座標情報に共通の識別情報を設定し、どの座標情報がどのglTFに対応するかを明確にします。

glTF内には、追加情報を保持できる領域を使用できる場合があります。ただし、そこへ独自の座標情報を保存しても、すべての表示環境が自動的に理解するとは限りません。書込側と読込側の両方で項目の意味を統一できる場合に利用し、外部の座標管理情報も併用すると安全です。

書き出した後は、必ず再読込を行います。書き出しに使用した環境へ読み戻すだけではなく、可能な範囲で実際のAR表示に近い読込処理でも確認します。書き出し元の環境が、欠けた情報を内部的に補って表示している可能性があるためです。

再読込後は、モデルが開けることだけでなく、寸法、軸方向、原点からの位置、ノード変換を確認します。元データと同じ見た目であることは重要ですが、それだけでは絶対座標への復元性を確認できません。

書き出し前に設定した複数の確認点を使用し、glTF内のローカル座標から絶対座標を計算します。復元した座標と元データの座標を比較し、水平位置と高さの差を記録します。

確認点は、原点付近だけでなく、モデルの端部や高さの異なる点を含めます。原点付近の一点だけでは、平行移動の誤りしか検出できません。離れた点を使うことで、回転、軸反転、縮尺の誤りを確認できます。

復元計算では、実際のAR表示と同じ変換順序を使用します。軸変換、単位換算、回転、平行移動の順序が違うと、同じ設定値でも最終座標が変わることがあります。

許容差は、使用目的に合わせて決めます。概略的な完成イメージを確認するAR表示と、施工位置や出来形を照合するAR表示では、求められる精度が異なります。現場測位の精度、モデルの作成精度、表示距離も考慮して判定します。

glTFの構造が形式上正しいことを確認する検査と、現場座標が正しいことを確認する検査は分けて考えます。形式上の検査に合格していても、原点情報が別の値になっていれば、現場では正しい位置へ表示できません。

更新モデルを書き出すたびに、確認点の検証を繰り返します。形状だけを変更したつもりでも、書き出し設定、原点計算、階層構造が変化し、座標に影響することがあります。

検証結果には、確認点名、元の絶対座標、glTF内のローカル座標、復元した絶対座標、差分、使用した原点、変換条件を残します。前回の書き出し結果と比較できるようにすると、設定変更による位置ずれを早期に発見できます。

最終的には、glTF本体、座標管理情報、確認点情報、検証結果を一組の成果として管理します。モデルだけを受け渡すのではなく、現場へ配置するために必要な情報をまとめて引き継ぐことが、座標欠落防止の基本です。

4対策を組み込んだ実務的な書き出し手順

実際の運用では、4つの対策を個別の注意事項として扱うのではなく、標準的な書き出し手順へ組み込むことが重要です。担当者ごとに作業方法が異なると、同じ元データから異なる座標のglTFが作られる可能性があります。

最初に、元の3D図面を複製し、書き出し専用の作業データを作成します。元データを直接編集すると、原点移動や軸変換を元へ戻せなくなる場合があります。作業データには、元データの版と作成日が分かる情報を付けます。

次に、元データの座標条件を確認します。座標の種類、系の設定、任意座標の原点、単位、水平軸、鉛直軸、高さ基準を記録します。不明な項目がある場合は、数値だけを見て推定せず、設計資料や基準点成果との対応を確認します。

その後、複数の確認点を設定します。モデル原点に近い点、水平距離が離れた点、高さが異なる点を選びます。構造物の角、道路中心線上の点、基礎天端、床面など、元データと現場の双方で識別しやすい位置が適しています。

続いて、ローカル原点を設定します。原点には、更新後も変わらない工事基準点や管理点を使うと、差し替え運用が安定します。モデル中心を使用する場合は、形状更新によって中心が変わらないか確認します。

ローカル原点の絶対座標を記録したうえで、モデルの各座標から原点座標を差し引きます。水平位置だけをローカル化し、高さは標高のまま残す運用も考えられますが、三軸で異なる原点を使用する場合は、その構成を明確に記録します。

次に、軸方向と単位をglTFの出力条件へ合わせます。元の高さ軸を上方向へ変換し、必要に応じてミリメートルからメートルへ換算します。自動変換の有無を確認し、同じ換算を二重に行わないようにします。

ノード階層を確認し、親ノードに残っている移動、回転、縮尺を整理します。絶対位置を外部管理する場合は、現場への大きな平行移動をglTF内部へ残さず、ローカル原点付近でモデルを構成します。

ただし、親ノードを単純に削除すると子ノードの位置が変わる可能性があります。親の変換を必要な形で子へ反映し、階層整理の前後で確認点のローカル座標が変わっていないかを確認します。

書き出し直前には、モデルの座標範囲を確認します。数十メートルの構造物であるにもかかわらず、頂点座標が数十万や数百万になっている場合は、絶対座標が残っている可能性があります。

反対に、数十メートルの構造物が0.01程度の範囲に収まっている場合は、縮尺を過剰に小さくしている可能性があります。座標範囲と既知寸法を併せて確認します。

書き出したglTFは、元の作業環境を閉じる前に再読込します。モデルの向き、寸法、部材配置、階層、縮尺を確認し、書き出し前の状態と比較します。

その後、保存したローカル原点と変換条件を使い、確認点を絶対座標へ復元します。元の座標との差がほぼ一定であれば、原点の加算漏れや二重加算を疑います。

原点から離れるほど差が増える場合は、縮尺や回転を確認します。一つの軸だけ符号が逆になっている場合は、軸の正負が反転している可能性があります。水平位置は合うのに高さだけずれる場合は、高さ原点や鉛直軸の対応を確認します。

座標検証に合格した後、実際のAR表示環境へ読み込みます。机上で正しい座標を復元できても、AR表示側で追加の軸変換や縮尺変更が行われれば、現場では一致しません。ファイル変換からAR表示までの一連の経路で最終確認します。

AR表示時のずれ方から原因を切り分ける方法

glTFをAR表示したときにずれが発生した場合、ずれ方を観察すると原因を切り分けやすくなります。すべてのずれを測位誤差として扱うと、モデル側の設定ミスを見逃す可能性があります。

モデル全体が同じ方向へほぼ一定量ずれている場合は、ローカル原点の加算漏れ、原点座標の入力ミス、平行移動の二重適用を確認します。ずれ量が非常に大きく、元の原点座標に近い場合は、絶対座標を二重に加算している可能性があります。

モデルが原点付近へ表示され、現場位置と大きく離れている場合は、書き出し時に原点情報が失われた可能性があります。形状が正常でも、現場へ配置する変換情報が残っていなければ絶対位置へ戻せません。

基準点付近では合うものの、離れるほど横方向のずれが増える場合は、回転角や方位設定を確認します。わずかな角度差でも、原点からの距離が長くなるほど横ずれが大きくなります。

基準点からの距離に比例して全方向へずれが増える場合は、縮尺や単位の不一致が考えられます。既知寸法を測定し、元データとglTFの長さが一致しているか確認します。

モデルが横倒しになっている場合は、鉛直軸の変換が正しくありません。高さ方向が前後方向へ割り当てられていないか、書き出し時とAR表示時に同じ軸変換を二重に行っていないかを確認します。

モデルが基準点を挟んで反対側へ表示される場合は、水平軸の符号反転を疑います。ある軸のプラス方向とマイナス方向が逆になると、原点からの距離を保ったまま反対側へ配置されます。

東西方向と南北方向が入れ替わっている場合は、二つの水平軸の対応を確認します。モデルがほぼ直角に回転しているように見える場合でも、回転設定ではなく軸の入れ替えが原因である可能性があります。

水平位置は合っているのに、モデル全体が同じ量だけ浮く、または沈む場合は、高さ原点や標高基準の不一致を確認します。標高を使用するモデルへ相対高さを適用したり、相対高さを標高として扱ったりすると、一定の高さ差が生じます。

高さが増えるほど縦方向の差が大きくなる場合は、高さ方向の縮尺や単位を確認します。水平軸だけ正しく単位換算され、高さ軸だけ元単位のまま残っている場合もあります。

一部の部材だけ位置がずれる場合は、モデル全体の原点ではなく、ノード階層や部材固有の変換を確認します。親ノードが異なる部材、個別の縮尺を持つ部材、別のローカル原点で作成された部材が混在している可能性があります。

複数の部材が原点へ重なって表示される場合は、親ノードの平行移動が欠落している可能性があります。各部材の頂点が親ノードのローカル座標で作られていると、親の変換を失った時点で同じ位置へ集まります。

細かな面が振動したり、近接面がちらついたりする場合は、大きな絶対座標を頂点へ直接持たせていないか確認します。ローカル原点を設定して座標値を小さくすると、表示が安定する場合があります。

更新したモデルだけ位置が変わる場合は、書き出し設定や原点計算が更新前と一致しているか確認します。モデル中心を原点として自動設定していると、形状の追加や削除によって原点が変わることがあります。

ずれの原因を調べる際は、一度に複数の設定を変更しないことも重要です。原点、回転、縮尺を同時に修正すると、どの変更が有効だったか分からなくなります。まず寸法、次に軸、次に原点、最後に現場方位というように、段階的に確認します。

複数モデルと更新データを安全に管理するポイント

実際の施工では、一つの3D図面だけを扱うとは限りません。工区別、構造物別、施工段階別に複数のモデルを作成し、設計変更のたびに更新することがあります。この運用では、モデルごとの座標管理方法が統一されていないと、AR表示時の位置関係が崩れます。

複数モデルを重ねる場合は、共通の座標仕様を定めます。水平軸、鉛直軸、単位、高さ基準、北方向、回転の適用順序を統一します。モデルごとに軸や単位が異なる場合は、書き出し時に共通仕様へ変換します。

共通原点を使用する場合は、すべてのモデルが同じ原点座標を参照していることを確認します。似た名称の基準点や、同じ点名で異なる座標を持つ管理データが混在しないようにします。

個別原点を使用する場合は、各モデルの識別情報と原点情報を確実に関連付けます。モデルを複製した際に、元モデルの原点情報が残ったままにならないよう注意します。

モデル間の接続部には共通の確認点を設定します。道路モデルと構造物モデル、地形モデルと設備モデルなど、異なるデータが接する場所で座標を照合します。個々のモデルが単独で正しく見えても、原点や回転が異なれば接続部に段差や隙間が生じます。

更新時には、形状変更と座標変更を分けて管理します。形状だけを変更した場合は、原点、軸、単位、回転条件を前回と同じにします。座標条件を変更する場合は、変更理由と影響範囲を記録します。

ファイル名だけで版を管理すると、どの座標情報と組み合わせるべきか分からなくなることがあります。モデルの識別情報、版、作成日時、元データ、座標管理情報、検証結果を関連付けます。

古いモデルを残す場合は、AR表示時に誤って読み込まないように状態を明確にします。作業中、確認済み、使用停止などの区別を設け、現場で使用する版を一つに絞ります。

座標設定を変更した更新モデルは、差し替え前に既存モデルと重ねて比較します。形状変更部分以外で大きな差が出る場合は、原点や変換条件が変わっている可能性があります。

長期間の工事では、基準点の管理状況にも注意します。現場の基準点が移設された場合や、新しい基準点を使用する場合は、旧モデルとの変換関係を整理します。同じ名称で異なる座標を使わないようにします。

複数担当者が書き出しを行う場合は、標準設定を共有します。担当者ごとの手作業に依存すると、単位換算や軸変換の適用漏れが発生しやすくなります。確認点と検証方法まで含めた手順として統一することが重要です。

現場で絶対座標との整合を確認する方法

glTFの書き出し後は、机上の検証に加えて、現場で絶対座標との整合を確認します。座標計算が正しくても、AR表示側の設定や現場で使用する基準が異なれば、実際の位置には一致しません。

最初に使用する確認点は、現場で位置を識別しやすく、座標が管理されている点が適しています。工事基準点、構造物角、既設物の明確な角部など、モデルと現場の双方で同じ位置を判断できる点を選びます。

一つ目の点では、モデル全体の平行移動を確認します。ただし、一点だけで一致しても、回転や縮尺が正しいとは判断できません。原点から離れた二つ目の点を確認し、モデルの方向と距離が一致するかを見ます。

さらに、高さの異なる三つ目の点を確認します。平面位置が正しくても、高さ基準が異なればモデルは地面から浮いたり沈んだりします。地表面だけではなく、天端、床面、基礎上面など高さを判断しやすい点を利用します。

現場でモデルを手動調整して一致させた場合は、調整量を記録します。画面上で位置を合わせただけでは、次回の表示や別の端末で同じ状態を再現できない可能性があります。

調整した平行移動量、回転量、高さ補正量を数値化し、それがglTFの原点情報、軸変換、現場基準のどこに起因するかを確認します。モデル側の誤りであれば、元データまたは書き出し設定を修正し、場当たり的な補正を残さないようにします。

現場確認では、測位状態や周囲環境による一時的な変動も考慮します。モデルのずれが時間とともに動く場合は、座標設定だけでなく、測位状態や端末姿勢の影響も考えられます。

一方、何度確認しても同じ方向へ同じ量だけずれる場合は、モデルの原点や変換条件に原因がある可能性が高くなります。時間的に変化するずれと、固定的なずれを分けて記録します。

現場全体を一度に確認するのではなく、基準点付近、離れた地点、高さの異なる地点の順で検証すると、原因を切り分けやすくなります。基準点付近で合わない場合は原点、離れた地点でずれる場合は回転や縮尺、高さだけずれる場合は高さ基準を確認します。

LRTK Phoneを利用して現場の座標を確認し、3D図面内に設定した確認点と照合すれば、glTFのローカル座標から絶対座標へ戻す処理を現地で検証できます。

現場確認の結果は、モデルの識別情報、使用した原点、確認点、測定日時、座標差とともに保存します。更新モデルを使用するときも同じ確認点を利用すれば、前回との比較がしやすくなります。

まとめ

3D図面をglTFへ書き出してAR表示する場合、モデルが正常に開けることと、絶対座標が正しく維持されていることは別の問題です。形状や材質が完全に表示されていても、原点情報、軸方向、単位、高さ基準、ノード変換が欠けていれば、現場の正しい位置へ配置できません。

座標欠落を防ぐ最初の対策は、書き出し前に座標系、軸方向、単位、高さ基準を固定することです。元データとglTFで軸や単位が異なっていても、変換内容を記録していれば元の絶対座標へ戻せます。

2つ目の対策は、絶対座標とモデル内部のローカル原点を分けることです。モデル付近に固定原点を設定し、glTF内の座標値を小さく保ちながら、原点の絶対座標を別途管理します。

3つ目の対策は、ノード階層と変換行列を整理することです。頂点、親ノード、ルートノード、外部座標情報のどこで位置を管理するかを統一し、移動、回転、縮尺の二重適用を防ぎます。

4つ目の対策は、座標管理情報をglTF本体とは別に保存し、書き出し後に再読込して検証することです。原点付近だけでなく、離れた点や高さの異なる点を使用し、絶対座標へ正しく復元できるかを数値で確認します。

複数モデルや更新データを扱う場合は、共通の座標仕様、固定原点、確認点、検証手順を使用します。形状更新のたびに原点や変換条件が変わらないようにし、モデル、座標情報、検証結果を一組で管理することが重要です。

最後に、机上の確認だけで終わらせず、現場の既知点と照合します。LRTK Phoneを使って確認点の座標と3D図面の位置関係を確かめることで、glTF書き出しから絶対座標によるAR表示までを一連の工程として検証できます。

現場を3Dで残して、あとから測る。
実際の画面と動画で使い方を確認できます。

LRTK Phoneの使い方・実例を見る
資料請求導入相談
現場をスマホで3DスキャンLRTK Phone実例を見る