点群OBJのグループ構造を保つ必要性
点群OBJをアップロードした後、地面、建物、構造物、設備、植生、仮設物などに分けていたデータが一つにまとまり、個別に選択できなくなることがあります。形状自体は表示されていても、分類単位が失われると、必要な部分だけを表示したり、不要な部分を非表示にしたりする作業が難しくなります。
点群データをOBJとして扱う実務では、単に三次元形状を表示できればよいとは限りません。確認対象ごとの表示切り替え、計測対象の選択、修正範囲の限定、別担当者への引き渡し、更新箇所の差し替えなどを考えると、グループ構造を保つことには大きな意味があります。
たとえば、現況地形と計画形状を同じデータ内に含める場合、それぞれを別グループとして維持できれば、表示を切り替えながら比較できます。地面と構造物を分けておけば、地表だけを確認したいときや、構造物だけを再書き出したいときにも便利です。設備を種類別に分けておけば、個別の確認や修正も行いやすくなります。
一方、アップロード後にすべてが一つの選択単位へ結合されると、小さな修正でもデータ全体を再処理しなければならない場合があります。不要な部分だけを削除することが難しくなり、作業効率が下がる可能性があります。複数人で同じデータを使用する場合には、どの部分が何を表しているのかも伝わりにくくなります。
そのため、点群OBJのグループ構造を保つ設定は、見た目を整えるためだけのものではありません。後工程でデータを選択し、確認し、編集し、共有するための管理設定です。書き出し時に分類単位を整理しておくことで、その後の確認や修正を進めやすくなります。
ただし、作成元で見えている階層が、そのままOBJへ保存されるとは限りません。OBJで記録できる情報と、アップロード先が読み取って選択単位へ変換する情報には違いがあります。元データ、書き出し設定、関連ファイル、アップロード設定を一連の流れとして確認することが重要です。
OBJで保持できるグループ情報の考え方
OBJは、頂点座標や面情報などをテキストで記録する三次元データ形式です。一般的なOBJには、頂点を表すv、テクスチャ座標を表すvt、法線を表すvn、面を表すfに加え、点要素を表すp、オブジェクト名を表すo、グループを表すg、使用するマテリアルを示すusemtlなどを記録できます。
ここで注意したいのは、OBJのグループと、作成元の編集環境にある階層構造が同じではないことです。作成元では、親グループの中に複数の子グループがあり、さらにその下に個別の要素が配置されていることがあります。しかし、OBJのoやgは、このような任意の深さを持つ親子階層をそのまま保存する仕組みではありません。
作成元で三段階の階層を作っていても、OBJでは名前付きのオブジェクトやグループとして平坦化される可能性があります。OBJでグループ構造を保つという場合は、元の階層を完全に再現することより、実務上必要な選択単位や分類単位を維持することを目標にするのが現実的です。
また、オブジェクトとグループは似ていますが、同じ情報ではありません。書き出し元によっては、独立した形状をオブジェクトとして出力し、面や点の集合をグループとして出力します。別の環境では、レイヤー名やマテリアル区分をグループ名へ変換することもあります。
OBJのgは、その後に続く面、線、点などの要素を一つ以上の名前付きグループへ割り当てるために使われます。ただし、アップロード先がgを選択単位として採用するとは限りません。オブジェクト情報だけを読む環境、グループ情報を優先する環境、マテリアル単位へ再構成する環境などがあるためです。
マテリアルも、グループを見分けるための補助として使われる場合があります。異なるグループへ別々のマテリアルを割り当てておけば、アップロード後に色や質感の違いで分類を確認できます。ただし、マテリアルが異なるからといって、必ず別グループとして選択できるわけではありません。
グループ構造を安定して保つには、オブジェクト名、グループ名、マテリアル名の役割を分けて整理する必要があります。どれか一つだけに依存すると、アップロード先の実装によって分類が失われる可能性があります。小さなテストデータを使い、どの情報が選択単位として反映されるか確認してから本番データを書き出すことが安全です。
グループ構造がアップロード時に崩れる主な原因
グループ構造が崩れる原因は、書き出し前、書き出し時、アップロード時の三段階に分けて考えると整理しやすくなります。どの段階で情報が失われたかによって、見直す設定が異なります。
書き出し前の原因として考えられるのは、画面上では分かれて見えるものの、内部的には一つのオブジェクトになっていることです。色やレイヤーが異なっていても、形状が結合済みで、書き出し機能がその分類をoやgへ変換しなければ、OBJでも一つのまとまりとして扱われる可能性があります。
レイヤー分けも注意が必要です。作成元でレイヤーを分けていても、書き出し設定がレイヤー情報をOBJのオブジェクト名やグループ名へ変換しなければ、分類は保存されません。表示管理のためのレイヤーと、OBJへ実際に記録される区切りは別のものとして確認する必要があります。
書き出し時には、すべての形状を一つにまとめる設定が有効になっている場合があります。単一オブジェクトとして書き出す設定や、同じマテリアルを持つ要素を統合する設定がある場合、元データの分類が減少することがあります。ただし、設定名や処理内容は書き出し元によって異なるため、実際のOBJ内にoやgが残っているかを確認することが重要です。
点群から面を生成する過程で、すべての点や面が一つの形状へ統合されることもあります。元の点群に分類属性があっても、面生成後の形状が単一オブジェクトになり、分類属性がOBJのグループへ変換されなければ、書き出し時に元の分類を復元することは困難です。面生成前後のどちらでグループ分けを行うかも重要になります。
アップロード時には、インポート処理や最適化が影響することがあります。複数オブジェクトの結合、同一マテリアル単位への再構成、簡略化、小部品の除去などが行われると、見た目を大きく変えずに選択単位が変わる場合があります。
名称の問題も原因になります。日本語、空白、特殊記号、長すぎる名前、同じ名前の重複などは、アップロード先や変換先の命名規則によって省略、置換、分割されることがあります。特にg行では空白が複数のグループ名の区切りとして解釈されるため、一つの名称として空白を含めたい場合には互換性の問題が生じやすくなります。
座標や単位の不一致によって、一部のグループが見えなくなる場合もあります。実際にはグループが消えたのではなく、遠く離れた場所に配置されたり、極端に小さく表示されたりしている状態です。画面上で見つからないからといって、すぐに結合や欠落と判断しないことが大切です。
さらに、OBJ、MTL、テクスチャ画像の参照が切れると、色分けが失われ、複数のグループが一つに見えることがあります。この場合、選択単位としては分離されていても、外観が同じためにグループ境界を判断しにくくなります。
設定1 オブジェクトとグループを分けて書き出す
最初に確認したいのは、アップロード後に個別操作したい範囲が、書き出し前に独立したオブジェクトまたはグループとして整理されているかどうかです。グループ保持を成功させるには、書き出し設定より前に、元データの分け方を確定する必要があります。
まず、アップロード後の用途を基準に分類単位を決めます。地面だけを非表示にしたい場合は、地面を独立した選択単位にします。建物ごとに確認したい場合は、建物単位で分けます。設備の種類ごとに編集する場合は、設備分類をオブジェクトまたはグループとして整理します。
分類を細かくしすぎると、グループ数が増え、アップロード後の一覧が扱いにくくなります。反対に、まとめすぎると必要な部分だけを選択できません。作業後にどの範囲を表示、非表示、削除、修正、差し替えする可能性があるかを考えて決めることが重要です。
元データで一つのオブジェクトになっている場合は、必要な境界で分離します。単に色を変えるだけではなく、個別に選択できる状態にします。一つの対象を選択したとき、他の対象まで同時に選択されないことを確認します。
書き出し設定では、オブジェクト名を出力する項目、グループ情報を出力する項目、選択した形状を個別に扱う項目などを確認します。設定名はソフトウェアによって異なるため、項目名だけで判断せず、テスト出力したOBJ内にoやgが意図どおり記録されているかを確認します。
一方、すべてを単一オブジェクトへ結合する設定は、グループ保持を優先する場合には避けます。同じマテリアルを持つ形状をまとめる設定や、書き出し時に形状を統合する設定がある場合も、テストデータで結果を比較します。
作成元に親子階層がある場合は、どの階層をOBJの名前として残すかを決めます。すべての階層を維持できない場合は、最終的な選択単位となる名称を各オブジェクトへ付けます。親グループ名と子グループ名をつなげた一意の名前へ変換すると、階層が平坦化されても分類を追跡しやすくなります。
たとえば、区域、分類、番号という順番で名称を付けておけば、親子関係が失われても同じ区域のグループを一覧上で見つけやすくなります。ただし、アップロード先に文字数制限や命名規則がある場合を考え、短い分類コードや連番を利用します。
点要素を含むOBJでは、頂点座標を示すv行だけでなく、その頂点を点要素として参照するp行が使われます。書き出し元がv行だけを並べる独自形式を出力する場合、それを点群として受け付けるかは読み込み側の実装に依存します。標準的な点要素として扱わせたい場合は、pが出力されているかも確認します。
点要素のpとグループのgが記録されていても、アップロード先がすべての点を一つの点集合へ変換する場合があります。この可能性がある場合は、分類単位ごとにOBJファイルを分割する方法も検討します。
ファイル分割は、OBJ内部のグループを読み取らないアップロード先でも、ファイル単位の分離を維持しやすい方法です。ただし、各ファイルの原点や単位を統一しなければ、アップロード後に位置がずれることがあります。共通座標で書き出せる状態を作ってから分割します。
書き出し後は、OBJをテキストとして確認し、意図したオブジェクト名やグループ名が複数記録されているかを調べます。点群として出力した場合は、vだけでなくpも記録されているかを確認します。作成元の画面だけで判断せず、実際の出力内容まで確認することが重要です。
設定2 グループ名とファイル名を統一する
グループ名は、単なる表示用の文字ではなく、アップロード後にデータを識別するための管理情報です。名前が正しく読み取られなければ、形状が分離されていても、どのグループが何を表すのか分からなくなります。
名称には、半角英数字とアンダースコアを中心に使用すると、異なる環境間でも扱いやすくなります。日本語の名称を正常に読み込める環境もありますが、書き出し元、アップロード処理、変換先、閲覧側のすべてが同じ文字処理に対応しているとは限りません。
空白は避けるのが安全です。特にOBJのg行では、空白で区切られた複数の名称を、一つの要素が属する複数グループとして扱えるため、意図した一つの名称が複数名として解釈される可能性があります。複数の単語をつなげる必要がある場合は、アンダースコアなどを使用します。
斜線、円記号、コロン、引用符などの特殊記号も避けます。これらはファイルパスや他形式の区切り文字として扱われる場合があり、変換時に置換される可能性があります。括弧や全角記号も、互換性を優先する場合は使わない方が管理しやすくなります。
グループ名は一意にします。作成元では親階層が異なるため同じ名前を使えても、OBJへ変換した際に階層情報が平坦化されると、同じ名称のグループが並ぶことになります。読み込み側によっては、同名グループを同じ集合として扱ったり、名称を自動変更したりする場合があります。
名称は、分類、区域、番号の順で付けると整理しやすくなります。たとえば、地面、構造物、設備などの分類を表す文字列に、区域番号や連番を加えます。更新時にも同じ名前を使えるよう、担当者の判断だけで名称を変えないことが大切です。
OBJ本体、MTL、テクスチャ画像のファイル名にも同じ命名規則を適用します。グループ名だけを整理しても、関連ファイルに空白や特殊記号が含まれていれば、アップロード先の処理や圧縮ファイルの展開方法によって参照関係が切れることがあります。
大文字と小文字も統一します。保存環境によっては大文字と小文字を同じものとして扱いますが、別の環境では異なるファイルとして扱われます。OBJ内のMTL参照と実際のファイル名、MTL内の画像参照と実際の画像名で、大文字と小文字が一致していないとファイルが見つからない場合があります。
実務では、すべて小文字へ統一するなどの規則を決めておくと管理しやすくなります。ただし、既存の参照関係がある状態でファイル名だけを変更してはいけません。OBJ内のmtllib参照や、MTL内の画像参照も合わせて修正する必要があります。
書き出し後に手作業で改名するより、可能な限り元データ側で名称を確定してから書き出します。再書き出しのたびに同じファイル名とグループ名が生成されれば、更新前後の比較や差し替えも行いやすくなります。
更新番号を付ける場合は、グループ名そのものに日付や担当者名を加える方法より、OBJファイル名や別の管理情報で版を区別する方が安全です。グループ名が更新のたびに変わると、アップロード先で既存グループとの対応を追いにくくなります。
設定3 MTLとテクスチャの参照関係を維持する
OBJのグループ構造とMTLは別の情報ですが、実務では両方を組み合わせてデータを確認することが多くあります。グループごとに色やテクスチャを分けている場合、MTLの参照が切れると、すべて同じ外観になり、構造が失われたように見えることがあります。
OBJでは、マテリアル定義を別のMTLへ記録し、OBJ側のmtllibからそのファイルを参照する構成が一般的です。MTLには、マテリアル名、色、透明度、テクスチャ画像の参照などが記録されます。OBJ側ではusemtlによって、その後の要素へ使用するマテリアルを指定します。
アップロード時には、OBJだけを送るのではなく、OBJが参照するMTLと、MTLが参照する画像も一緒に用意します。OBJだけで形状を表示できたとしても、マテリアルや画像が欠けると、グループの外観による区別が失われます。
関連ファイルは、アップロード先の対応が不明な場合、同じフォルダーへまとめた単純な構成から試します。OBJ、MTL、画像を同じ階層に置き、参照先をファイル名で表せる構成にすると、別の環境へ移動しても参照を維持しやすくなります。
作成元の端末内にある保存場所を示す絶対パスが記録されている場合、別の端末やアップロード先では同じ場所が存在しません。書き出し機能が相対パスやファイルの複製に対応している場合は、その機能を利用します。
画像を下位フォルダーへ分ける場合は、書き出し後にフォルダー構造を変更しないことが重要です。画像フォルダーの名前や位置を変えると、MTLから画像を見つけられなくなることがあります。アップロード先が下位フォルダーを扱えるかどうかも事前に確認します。
仕様が不明な場合は、OBJ、MTL、画像を一つのフォルダーへまとめた構成でテストします。複雑なフォルダー構造は管理しやすい場合もありますが、アップロード先が圧縮ファイル内の階層を期待どおりに扱わない可能性があります。
マテリアル名も重複を避けます。同じマテリアル名を複数の意味で使うと、変換先で一つのマテリアルとして扱われることがあります。ただし、マテリアル名を分けること自体がグループ分離を保証するわけではありません。選択単位はoやgで保持し、マテリアルは外観の補助として使用するのが基本です。
アップロード先に同一マテリアルの形状をまとめる処理がある場合、グループごとに異なるマテリアル名を付ける方法が切り分け用のテストとして役立つことがあります。ただし、これは受け側の実装に依存する回避策であり、標準的なグループ保持方法ではありません。
点群の色を頂点ごとに記録している場合も注意が必要です。OBJの頂点行へ色の値を追加する表現は複数のソフトウェアで使われていますが、元のOBJ仕様で統一された必須機能ではなく、すべてのアップロード先が同じ方法を解釈するとは限りません。頂点カラーに対応していない環境では、点群やメッシュが単色で表示されることがあります。
したがって、色の違いだけでグループを表現しないことが大切です。色が失われても分類できるよう、オブジェクト名やグループ名を設定します。マテリアルやテクスチャは、構造を確認しやすくする補助情報として利用します。
関連ファイルを圧縮してアップロードする場合は、圧縮前の相対的な配置を維持します。不要な親フォルダーを追加したり、OBJだけを別の階層へ移動したりすると、アップロード先が必要なファイルを見つけられない場合があります。
本番アップロード前には、関連ファイル一式を新しい一時フォルダーへ複製し、そのフォルダーだけでOBJを表示できるか確認します。元の作業フォルダーに依存せず表示できれば、参照関係を持ち運べる状態になっている可能性が高くなります。
設定4 座標・単位・変換を確定してから書き出す
座標、単位、原点、回転などの設定が異なると、グループ自体は残っていても、正しい位置関係で表示されません。一部のグループだけが遠くへ移動すると、アップロード後に消えたように見えることがあります。
OBJの頂点座標は数値として記録されますが、標準的なOBJには、その数値がメートル、ミリメートル、センチメートルのどれを表すかという線形単位の情報がありません。また、上方向がY軸かZ軸かというシーンレベルの情報も標準では指定されません。そのため、書き出し元とアップロード先で単位と軸の解釈を合わせる必要があります。
書き出し前に、すべてのグループが同じ単位を使用しているか確認します。あるグループをメートル相当、別のグループをミリメートル相当の数値で書き出すと、アップロード後の大きさに大きな差が生じます。
作成元では個別の倍率設定によって正しく見えていても、OBJへ書き出す際に、倍率が頂点座標へ反映される処理と、別の変換設定で扱われる処理があります。書き出し前に拡大縮小を確定し、画面上の大きさと出力される座標値の関係を確認します。
移動や回転も確定します。作成元の階層内で、親オブジェクトの移動や回転によって子オブジェクトの位置が決まっている場合、OBJへの変換で階層が平坦化されると、変換の適用方法によって位置が変わる可能性があります。
OBJは複雑な親子変換をそのまま保持するシーン形式ではないため、最終的な位置、回転、倍率を各形状の頂点座標へ反映して書き出せるか確認します。見た目が正しいだけでなく、再読み込み後も各形状の位置関係が再現されることが重要です。
複数のOBJへ分割する場合は、共通原点を維持します。選択した形状の中心を自動的に原点へ移す設定を使用すると、各ファイルをアップロードした際にすべてが同じ位置へ重なったり、本来の位置関係が失われたりします。
分割書き出しでは、案件全体の原点を固定し、各グループをその座標のまま出力します。個別ファイルを読み込んだときにも、共通原点を基準として正しい位置へ並ぶ状態を作ります。
一方、測量や地理的な座標を含むデータでは、座標値が非常に大きくなることがあります。表示環境や内部の数値精度によっては、大きな座標値を持つデータで細かな描画や操作が不安定になる場合があります。
その場合は、案件内の基準点を決め、すべてのグループへ同じ移動量を適用してローカル座標へ変換する方法があります。重要なのは、すべてのグループへ同じ変換を適用することです。グループごとに異なる移動を行うと、相対的な位置関係を復元できなくなります。
ローカル座標へ変換した場合は、元の座標へ戻すための移動量を記録します。基準点、移動方向、単位、軸の向きを案件情報として保存し、更新時にも同じ変換を使用します。
上下方向として使用する軸も確認します。作成元とアップロード先で上方向の解釈が異なると、データ全体が横倒しになったり、上下が反転したりする場合があります。一部のオブジェクトだけ回転の適用状態が異なると、グループごとに向きが変わることもあります。
書き出し後は、グループ名だけでなく位置関係も確認します。地面の上に建物があるか、設備が所定の位置にあるか、高さや距離が想定どおりかを調べます。グループ一覧に名前が残っているだけでは、構造を正しく維持できたとはいえません。
設定5 アップロード時の結合と最適化を制御する
OBJにグループ情報が残っていても、アップロード時の処理によって選択単位が変わることがあります。特に、複数オブジェクトの結合、マテリアル単位への再構成、面の簡略化、小部品の除去などは、グループ構造へ影響する可能性があります。
アップロード画面に、すべてを単一オブジェクトとして読み込む設定がある場合は無効にします。複数形状を結合する、シーンを統合する、単一メッシュへ変換するなどの意味を持つ項目も確認します。
このような設定は、データ量を減らしたり表示を軽くしたりする目的では便利です。しかし、形状の見た目を保ちながら選択単位だけを一つにする場合があるため、グループを個別操作したい用途では、最初の検証時に無効にするのが安全です。
重複頂点を統合する設定にも注意します。ただし、同じ位置にある頂点を共有または統合しただけで、OBJのgによる要素の所属が必ず消えるわけではありません。グループは面や線や点などの要素に付く区分であり、頂点の共有とは別の概念です。
一方で、読み込み側が頂点統合と同時に複数メッシュを一つの内部オブジェクトへ再構成する場合や、選択単位をメッシュ単位だけに限定する場合は、結果として個別選択ができなくなることがあります。そのため、頂点統合の有無だけで原因を断定せず、オブジェクト結合やグループ読込の設定と分けて検証します。
近接頂点を一定距離以内で結合する処理も、形状や境界を変える可能性があります。地面と構造物、隣接する設備、重なり合う部材などが近い場合、意図しない接続や小形状の変形が起こることがあります。ただし、これもグループ名が必ず消える処理とは限りません。
最初のアップロードでは、頂点統合や近接結合を無効にし、OBJの区分がそのまま読まれるかを確認します。その後、必要に応じて設定を有効にし、個別選択、グループ一覧、形状の境界がどう変わるかを比較します。
同一マテリアルの形状を統合する設定も確認します。表示処理を効率化するため、同じマテリアルを持つ複数の形状を一つにまとめる実装があります。グループごとに選択したい場合は、この統合を無効にするか、切り分け用テストとして一時的にマテリアル名を分けて結果を比較します。
自動簡略化や面数削減は、細かな形状や小さな部品へ影響することがあります。小さな設備、薄い面、細い部材などは、設定によって形状が大きく変わったり、除去されたりする場合があります。
グループ名が一覧に残っていても、中の形状が簡略化で失われれば、画面上では空のグループに見えることがあります。最初は簡略化を無効にしてアップロードし、その後に必要な範囲で段階的に設定します。
アップロード後は、見た目だけでなくオブジェクト一覧やグループ一覧を確認します。期待した名称が並んでいるか、名称が置換されていないか、選択したときに対象の形状だけが反応するかを調べます。
一つの名称を選択した際にすべての形状が同時に選ばれる場合は、アップロード先が内部的に単一オブジェクトへ変換している可能性があります。反対に、名称が自動変更されていても個別に選択できれば、実務上必要な分離は維持されている場合があります。
設定を検証する際は、一度に複数項目を変更しないことが大切です。結合、簡略化、単位、軸方向を同時に変えると、どの設定が結果へ影響したか分からなくなります。一項目ずつ変更し、同じテストデータで比較します。
点群だけのOBJでグループを維持する方法
OBJは面を持つ三次元形状に広く使われますが、点要素を記録するpも仕様上用意されています。ただし、点要素を含むOBJの対応状況は、一般的なポリゴン面を持つOBJより読み込み側の差が出やすいため注意が必要です。
OBJでは、v行が頂点座標を定義し、p行が一つ以上の頂点番号を参照して点要素を定義します。v行だけを並べたファイルを点群として読み込むソフトウェアもありますが、それは読み込み側の独自対応である場合があり、別の環境で同じように表示されるとは限りません。
グループを持つ点群OBJを作る場合は、g行の後に、そのグループへ属するp要素が記録されているか確認します。gは後続の点要素にも適用できますが、読み込み側がその区切りを選択単位として利用するとは限りません。
小さなテストデータを作り、三つのグループを離れた位置へ配置してアップロードします。各グループには異なる名前を付け、対応するp要素を分けて記録します。グループ一覧が一つしか表示されない場合や、すべての点が一括選択される場合は、アップロード先が点要素のグループを個別管理しない可能性があります。
その場合は、分類単位ごとにOBJファイルを分割する方法が有効です。地面、建物、設備などを別ファイルにすれば、アップロード先がOBJ内部のgを無視しても、ファイル単位で管理できる場合があります。
ファイルを分割する際は、座標、単位、原点を統一します。各グループを個別に書き出した結果、原点が変わると、アップロード後に本来の位置へ配置できません。共通座標のまま書き出す設定を使用します。
ファイル名には分類を表す一意の名称を付けます。アップロード後に内部グループ名が失われても、ファイル名から内容を判断できるようにします。更新時にも同じ名称を使用し、差し替え対象を明確にします。
点群から面を生成できる場合は、グループごとに面を持つ形状へ変換してからOBJを書き出す方法もあります。ただし、面生成によって形状、密度、穴、細部の表現が変化するため、点群本来の点位置を保持したい用途では慎重な判断が必要です。
アップロード後の閲覧や大まかな選択が主目的であれば面生成が有効な場合がありますが、元の点位置を使った確認や解析が必要であれば、点要素のまま分割する方法や、点群向け形式を使用する方法も検討します。
アップロード前に実施したい確認手順
本番データをアップロードする前に、小さなテストデータで設定を確認します。大容量の点群OBJを使って試行錯誤すると、書き出しとアップロードを繰り返すだけで多くの時間がかかります。
テストデータには、少なくとも三つのグループを用意します。それぞれの形状、大きさ、位置を変え、画面上で見分けやすくします。面を持つテストでは平面、立体、小さな部品などを用意し、点要素を試す場合は離れた位置に複数の点集合を作ります。
各グループには、一意の短い名前を設定します。空白や特殊記号を避け、半角英数字とアンダースコアを中心にします。マテリアルを使用する場合は、必要に応じて異なる名前を付けます。
書き出し後は、OBJ、MTL、画像ファイルがそろっているか確認します。OBJの容量が想定より極端に小さい場合は、書き出し対象が不足している可能性があります。反対に極端に大きい場合は、不要な要素や重複したデータが含まれていないかを確認します。
OBJをテキストとして開き、意図したoやgの名称が記録されているかを検索します。面を持つデータではf、点要素ではpが存在するかも確認します。すべての頂点情報を読む必要はありませんが、名称の直後に想定した要素が続いているかを確かめます。
次に、作成元とは別のOBJ確認環境で読み込みます。ここでオブジェクトやグループが分かれていれば、書き出し時点ではおおむね意図した区分が残っていると判断できます。ただし、確認環境と本番のアップロード先で対応機能が同じとは限りません。
別の環境でも一つにまとまっている場合は、元データまたは書き出し設定を見直します。作成元で独立した形状になっているか、oやgの出力が有効か、単一オブジェクトへの結合が有効になっていないかを確認します。
アップロード時には、結合や簡略化を無効にした状態から試します。OBJの構造をできるだけ変更せず読み込み、グループが維持されるかを確認します。
アップロード後は、グループ一覧、個別選択、表示切り替え、座標、縮尺、色、テクスチャを確認します。名前が残っているだけでなく、各グループを個別に操作できることが重要です。
正常に読み込めたら、必要に応じて最適化設定を一項目ずつ有効にします。どの設定までグループを維持できるかを記録し、本番データにも同じ条件を適用します。
グループ構造が消えた場合の切り分け方
アップロード後にグループが消えた場合は、元データ、OBJ、アップロード結果の順番で確認します。最初からアップロード先の問題と判断せず、どの段階で情報が失われたかを特定します。
最初に、作成元で対象が独立しているかを確認します。一つの要素を選択したときに他の要素まで選ばれる場合は、書き出し前から同じ選択単位になっています。レイヤーや色が異なるだけでは、OBJのoやgとして維持されない場合があります。
次に、書き出したOBJ内に意図した名称があるか確認します。名称が存在しなければ、書き出し設定または元データの分類に原因があります。点群として出力した場合は、vだけでなく点要素を示すpが存在するかも確認します。
OBJ内に複数の名称があり、別の確認環境でも個別に選択できる場合は、アップロード時の処理が原因と考えられます。単一オブジェクト化、グループ無視、マテリアル単位への統合、簡略化などの設定を見直します。
それでも一つに統合される場合は、アップロード先がOBJのoやgを個別選択へ反映しない可能性があります。この場合は、設定変更だけで解決できないことがあります。分類単位ごとにファイルを分割する方法を検討します。
名称だけが消えている場合は、文字種、空白、重複、長さを確認します。半角英数字とアンダースコアを中心にした一意の名前へ変更して再書き出しします。
グループ一覧には表示されるものの形状が見えない場合は、座標と単位を確認します。遠く離れた位置にある、極端に小さい、上下方向が異なるなどの可能性があります。データ全体を表示し、想定外に広い範囲へ配置されていないかを調べます。
すべて同じ色になっている場合は、MTLと画像の参照を確認します。外観が失われただけで、グループ自体は分離されている場合があります。個別選択や表示切り替えができるか確認します。
点要素のOBJで統合される場合は、アップロード先が点を一つの点集合として扱っている可能性があります。面を持つテストデータでは分離され、pを使った点要素では統合される場合、この可能性を疑います。
問題の切り分けでは、一度に一つの条件だけを変えます。複数の設定を同時に変更すると、原因を特定できません。同じテストデータを使い、書き出し設定とアップロード設定を段階的に比較します。
実務で再発を防ぐ運用ルール
点群OBJのグループ構造を安定して維持するには、担当者ごとの判断に任せず、案件内で共通の運用ルールを決めることが重要です。
最初に、グループの分類基準を決めます。地面、建物、構造物、設備、植生、仮設物、不要物など、案件で使用する分類を統一します。同じ種類の対象を担当者によって異なる粒度で分けないようにします。
次に、命名規則を定めます。使用できる文字、分類コード、区域番号、連番の順番を決めます。名称を見ただけで内容を判断でき、同じ案件内で重複しない形式にします。
書き出し設定も記録します。オブジェクト名とグループ名の出力、点要素の場合のp出力、マテリアル出力、単位の解釈、軸方向、原点、座標変換、結合設定などを確認項目として残します。
アップロード設定についても、単一オブジェクト化、簡略化、マテリアル単位の統合、頂点統合などの状態を記録します。正常に読み込めた条件を保存しておけば、担当者が変わっても同じ結果を再現しやすくなります。
共有用フォルダーには、確定したOBJ、MTL、テクスチャ画像だけを収録します。作業途中のファイル、古い版、使用していない画像、似た名前の複製などが混在すると、誤った組み合わせでアップロードする原因になります。
更新時は、前回のデータと比較します。グループ数、名称、要素種別、座標範囲、ファイル構成、容量などを確認し、意図しない結合や欠落がないかを調べます。
アップロード先の処理が変更される可能性もあるため、長期間継続する案件では定期的にテストデータを読み込みます。以前と同じ設定でも、アップロード後の結果が変わる場合があります。
グループ構造をOBJ内部で維持できない環境では、無理に一つのファイルへまとめないことも重要です。分類単位でOBJを分割し、ファイル名と共通座標によって管理した方が、確実で扱いやすい場合があります。
まとめ
点群OBJのグループ構造を保ってアップロードするには、元データの整理、書き出し設定、関連ファイル、座標設定、アップロード時の処理を一連の流れとして確認する必要があります。
一つ目の設定は、アップロード後に個別操作したい単位を、独立したオブジェクトまたはグループとして書き出すことです。作成元のレイヤー表示だけに頼らず、OBJ内にoやgが記録されているかを確認します。点要素を扱う場合は、頂点のvだけでなく点要素のpが出力されているかも確認します。
二つ目の設定は、グループ名とファイル名を互換性の高い形式へ統一することです。半角英数字とアンダースコアを中心に使用し、空白、特殊記号、同名の重複を避けます。
三つ目の設定は、OBJ、MTL、テクスチャ画像の参照関係を維持することです。MTLはグループ構造そのものを保存するものではありませんが、色やテクスチャによる確認を維持するために必要です。関連ファイルの配置と参照名を一致させます。
四つ目の設定は、座標、単位、原点、回転、拡大縮小を確定してから書き出すことです。OBJには標準的な単位や上方向の指定がないため、書き出し元とアップロード先の解釈を合わせます。グループ名だけでなく、グループ間の位置関係まで正しく保たれているか確認します。
五つ目の設定は、アップロード時の単一オブジェクト化、簡略化、マテリアル単位の統合などを制御することです。頂点統合だけでグループが必ず消えるわけではないため、各処理を分けて検証します。最初は最適化を抑えた状態で読み込み、構造を確認してから必要な処理を一項目ずつ追加します。
点要素のOBJで内部グループが維持されない場合は、分類単位ごとにOBJを分割する方法も有効です。その際は、すべてのファイルで座標、単位、原点を統一します。
現場で取得した点群を継続的に活用するには、計測後の書き出しやアップロードまで見据えたデータ管理が欠かせません。点群の取得、確認、共有を一つの流れとして整えたい場合は、LRTK Phoneを利用した現場データの活用方法も確認してみてください。