点群や3D計測データをOBJ形式へ変換し、クラウドや管理システムへアップロードしたところ、元の編集環境では分かれていた建物、地面、設備、計測区画などのグループが一つにまとまってしまうことがあります。ファイル自体は読み込めているため、一見すると正常に変換できたように見えますが、後から部位ごとの表示切替や確認をしようとすると、グループ階層が失われていることに気づくケースがあります。
点群 OBJ アップロードでこの問題が起きる原因は、単純なアップロード失敗とは限りません。OBJのデータ構造、書き出し時の統合設定、オブジェクト名の扱い、マテリアル単位の再編成、読み込み側の仕様などが関係します。特に重要なのは、OBJでは一般的な3D編集環境のような多段の親子階層をそのまま完全保存できるとは限らないという点です。
そのため、「階層を保持して書き出したつもりなのに消えた」という場合は、まずOBJで何を保持できるのかを整理したうえで、書き出し設定を確認する必要があります。本記事では、点群や3D計測データをOBJへ変換するときに確認したい5つの設定と、アップロード後のグループ消失を防ぐ実務上の考え方を解説します。
点群OBJでグループ階層が消える理由
点群 OBJ アップロードでグループが消える問題を理解するには、最初にOBJ形式の特徴を押さえておく必要があります。OBJは比較的単純なテキストベースの3Dデータ形式で、頂点座標、面、テクスチャ座標、法線、グループ名、オブジェクト名などを記述できます。そのため、形状を別の環境へ受け渡す用途では扱いやすい形式です。
一方で、3D編集ソフトや点群処理環境にあるような複雑なシーン構造を、そのまま保存することを主目的とした形式ではありません。たとえば、元データ側で「現場A」という親グループの下に「地盤」「構造物」「配管」があり、さらに「構造物」の下に「橋台」「橋脚」が配置されていたとしても、この親子関係をOBJだけで同じ構造として表現できるとは限りません。
OBJにはグループを示す情報やオブジェクトを区別する情報を記述できますが、一般的なシーン管理で使われる任意の深さを持つツリー構造とは性質が異なります。そのため書き出し元で階層表示されていても、OBJ化した時点で「複数のグループが並列に並ぶ状態」に変換される場合があります。
さらに、書き出し時に「すべてのオブジェクトを結合」「単一メッシュとして出力」「マテリアルごとにまとめる」といった処理が有効になっていると、OBJ内のグループ情報そのものが減ることがあります。逆にOBJ内にはグループ情報が残っていても、アップロード先がその情報を使用せず、すべての頂点や面を一つのモデルとして読み込む場合もあります。
つまり、グループ階層が消えたときには、「元データ」「OBJへの書き出し」「OBJファイル内部」「アップロード先での読み込み」という複数の段階を分けて考える必要があります。
また、「点群OBJ」という表現にも注意が必要です。OBJは三角形などの面を持つ3Dモデルで広く使われますが、頂点情報を扱うこともできます。ただし、点だけで構成されたデータやポイント要素の扱いは、読み込み先によって対応状況が異なります。点群をOBJへ変換する過程でメッシュ化されている場合と、頂点主体の状態で出力されている場合では、グループ情報の扱われ方も変わります。
そのため、ファイル拡張子がOBJであるというだけで、元の点群構造やレイヤー構造まで完全に維持されると考えないことが重要です。
設定1 グループ名とオブジェクト名を書き出す
最初に確認したいのが、グループ名やオブジェクト名をOBJへ書き出す設定です。
OBJでは、形状データとは別に、グループやオブジェクトを区別するための記述を持たせることができます。元データに複数のオブジェクトが存在していても、この識別情報を書き出さなければ、読み込み側から見ると連続した一つの形状データとして扱われやすくなります。
書き出し画面に「グループを書き出す」「オブジェクト名を保持する」「オブジェクトをOBJグループとして出力する」といった意味の設定がある場合は、その状態を確認します。具体的な名称は使用しているソフトウェアによって異なりますが、重要なのは元データ側の区切りをOBJ内の識別情報へ反映させることです。
たとえば、現況計測データを「地面」「擁壁」「側溝」「建物」の4種類に整理している場合、それぞれの名称がOBJ内にも残っていれば、読み込み側が対応している場合には個別のグループとして認識できる可能性があります。
反対に、形状だけを書き出す設定になっていると、見た目には同じ3Dモデルでも、どこからどこまでが地面で、どこが擁壁なのかという論理的な区切りが失われます。点群 OBJ アップロード後に形状自体は正常なのにグループだけ消えている場合、最初に確認すべき項目です。
ここで注意したいのは、グループ名を書き出したからといって、元の階層構造が完全に保存されるわけではないことです。OBJに保存された複数のグループが、アップロード先ではすべて同じ階層に並ぶこともあります。
元の編集環境では「造成工事」の下に「施工前」と「施工後」があり、その下にさらに複数の計測区画があるような構成でも、OBJに変換すると「施工前」「施工後」「区画A」「区画B」といったグループが同じレベルで扱われることがあります。
この違いを知らずに「グループを書き出す」にチェックを入れるだけでは、期待した結果にならない場合があります。OBJで保持したいのが単純な区分なのか、多段階の階層なのかを先に整理しておくことが重要です。
また、書き出し後は実際のOBJファイルをテキストとして確認する方法もあります。OBJはテキスト形式なので、グループやオブジェクトを示す記述が含まれているかを確認できます。書き出し元では設定を有効にしたつもりでも、変換工程によって情報が削除されていることがあるためです。
点群 OBJ アップロードを繰り返す業務では、設定画面だけを見るのではなく、「最終的に生成されたOBJに識別情報が残っているか」という観点を持つと原因を切り分けやすくなります。
設定2 オブジェクトの結合や統合を無効にする
2つ目は、書き出し時のオブジェクト結合設定です。
3Dデータを書き出す機能には、複数のオブジェクトを一つの形状へ統合する設定が用意されている場合があります。これはファイル構造を単純化したり、読み込み処理を軽くしたりする目的では便利ですが、グループを保持したい場合には注意が必要です。
たとえば、地面、建物、擁壁、側溝を別々のオブジェクトとして管理していても、書き出し時に「単一オブジェクトへ統合する」という処理が実行されれば、生成されたOBJでは区切りが失われる可能性があります。
特に点群からメッシュを生成した後にOBJへ変換する工程では、軽量化処理と同時にメッシュ結合が行われることがあります。頂点数や面数を減らす処理そのものが問題なのではなく、その際にオブジェクト境界まで統合されてしまうことが問題です。
そのため、点群 OBJ アップロード後にも部位単位で表示や非表示を切り替えたい場合は、書き出し時に各オブジェクトを分離した状態で保持できる設定を選びます。
ここで「別オブジェクト」と「別ファイル」は分けて考える必要があります。一つのOBJファイル内に複数のオブジェクトを記録できる場合もあるため、必ずしも複数ファイルへ分割しなければならないわけではありません。ただし、アップロード先が一つのOBJファイルを常に一つのモデルとして処理する仕様であれば、ファイルを分けるほうが確実なケースもあります。
たとえば、施工前地形と施工後地形を明確に切り替えて確認したい場合、両方を一つのOBJへまとめるより、それぞれ独立したOBJとして管理したほうが扱いやすい場合があります。一方、同時表示が必要な構造物の部材は、一つのOBJ内でオブジェクトを分けるほうが管理しやすいこともあります。
したがって、結合設定を単純にすべて無効にするのではなく、「アップロード後に何単位で操作したいか」を基準に決めることが重要です。
また、不要な結合は座標確認にも影響します。元データでは複数のオブジェクトがそれぞれ別の基準点やローカル変換を持っていた場合、統合処理によって座標変換が適用された状態で固定されることがあります。グループ消失と位置ずれが同時に起きた場合は、単なる名称の問題ではなく、統合時の座標処理まで確認する必要があります。
点群 OBJ アップロード前には、最終的なOBJの形状だけでなく、「どの単位で分かれているか」を確認する習慣をつけることが有効です。
設定3 マテリアル単位の再編成を避ける
3つ目は、マテリアルを基準としたグループ再編成の設定です。
OBJでは形状に加えて、材質情報を別のファイルと組み合わせて扱うことがあります。色やテクスチャを維持したい場合には重要な仕組みですが、書き出し設定によってはオブジェクト構造よりマテリアルの区切りが優先されることがあります。
たとえば、「地面」と「擁壁」が別オブジェクトでも、両方に同じマテリアルが設定されている場合、マテリアル単位で統合する処理が有効になっていると、一つのまとまりへ再編成される可能性があります。
逆に、一つのオブジェクトの中に複数のマテリアルが使われている場合、元は一つだったオブジェクトが複数に分割されることもあります。
このような再編成が起きると、点群 OBJ アップロード後のグループ構造が元データとは異なります。「グループが全部消えた」というより、別の基準で組み替えられた結果として、期待した階層に見えなくなっていることもあります。
現場計測データでは、色やテクスチャは見た目を確認するための情報であり、施工区画や構造物の区分は管理上の情報です。この二つを同じ基準で扱うと、書き出し後の管理が複雑になります。
そのため、書き出し時には「オブジェクト単位を保持するのか」「マテリアル単位でまとめるのか」を確認します。グループ構造を重視する場合は、マテリアルを理由にオブジェクト境界が変更されない設定が適しています。
特に注意したいのが、同じ名称のマテリアルが複数のオブジェクトに使われているケースです。書き出し元では別々のオブジェクトでも、同名マテリアルを基準に処理すると、読み込み側で同じグループとして扱われる可能性があります。
また、マテリアル情報を使わない運用であれば、必要性を確認したうえで形状とグループ構造を優先した単純なOBJを作る方法もあります。反対に、写真由来のテクスチャを必要とする3Dモデルでは、マテリアル関連ファイルや画像ファイルのパスも含めて管理する必要があります。
重要なのは、形状区分と外観情報を混同しないことです。
「施工区画Aだから同じグループにしたい」という要求と、「同じ色だから同じマテリアルにしたい」という要求は別です。書き出し設定がどちらを優先しているかを確認することで、アップロード後の予期しない再編成を防ぎやすくなります。
設定4 グループ名を一意で単純な名称にする
4つ目は、グループ名やオブジェクト名の付け方です。
OBJ自体にグループ情報が残っていても、名称が重複していると、読み込み側で同一グループとして扱われることがあります。特に複数の階層で同じ名称を使用している場合は注意が必要です。
たとえば、「施工前」という親グループの中に「地面」というオブジェクトがあり、「施工後」にも「地面」というオブジェクトがあるとします。元の編集環境では親グループが異なるため区別できますが、OBJへ変換した際に親子関係が失われ、「地面」という名称だけが残ることがあります。
読み込み側が名称を基準にグループをまとめる仕様であれば、施工前の地面と施工後の地面が同じグループとして扱われる可能性があります。
この問題を避けるには、書き出す前に名前を一意にします。「施工前_地面」「施工後_地面」のように、親グループの意味を名称に含めておけば、多段階層が平坦化されても元の関係を推測できます。
同様に、「A」「B」「001」のような短すぎる名称だけで管理すると、別案件のデータと混ざったときに意味が分からなくなります。現場名、計測時期、区画、対象物など、後から識別するために必要な情報を適度に含めることが重要です。
ただし、名称を長く複雑にしすぎることも避けたほうがよいでしょう。使用する環境によっては、一部の文字や記号の扱いが異なることがあります。文字コードや使用可能文字に関する実装差もあるため、互換性を優先する場合は、できるだけ単純で規則的な名称にします。
また、ファイル名、オブジェクト名、グループ名、マテリアル名で同じ名称を無秩序に使うと、問題発生時の切り分けが難しくなります。
たとえばファイル名を「現場A_施工後.obj」、グループ名を「A01_地盤」、オブジェクト名を「A01_ground」のように、役割を分けた命名規則を決めておけば、アップロード後にどの情報が残ったのか確認しやすくなります。
点群 OBJ アップロードを複数人で行う場合は、個人ごとに名称の付け方が異ならないようにすることも重要です。書き出し設定が同じでも、命名規則がバラバラであれば、アップロード後のデータ構造を統一できません。
特に長期案件では、数か月後に同じ現場を再計測することがあります。そのとき「地面」「地面2」「新地面」のような名称が増えていくと、どのデータがどの時点のものなのか判別しにくくなります。
OBJの階層表現に限界があるからこそ、名称自体に管理情報を持たせることが有効です。
設定5 多段階層はOBJだけで管理しない
5つ目は、OBJに保存できる構造の限界を前提として書き出し方法を決めることです。
点群 OBJ アップロードで最も誤解されやすいのが、「元データの階層をすべてOBJへ保存できる」と考えてしまうことです。
一般的な3D編集環境では、フォルダのように親グループと子グループを何段階にも設定できます。さらに、それぞれのオブジェクトが座標変換、表示状態、属性情報などを持つ場合があります。しかしOBJは、そのようなシーン全体の構造を詳細に保存するための形式ではありません。
そのため、複数階層が必要な案件では、OBJだけで階層情報を表現しようとしないことが重要です。
たとえば、「工区」「施工段階」「構造物」「部材」という4段階で管理している場合、最終的なOBJでは名称に階層情報を含めて平坦化する方法があります。「工区A_施工後_擁壁_天端」のような名称にすれば、階層そのものは失われても、名称から所属を判断できます。
別の方法として、管理単位ごとにOBJファイルを分けることもできます。「工区A」「工区B」を別ファイルにし、その中で構造物ごとのグループを保持する方式です。ファイル数は増えますが、アップロード先がファイル単位で表示切替できる場合には管理しやすくなります。
さらに、元の階層関係を別途管理情報として残す方法もあります。OBJを最終形状データとして使用し、どのファイルがどの工区や施工段階に属するかは、フォルダ構成や管理表など別の仕組みで管理します。
重要なのは、OBJに向いている情報と、別の方法で管理すべき情報を分けることです。
形状を確認するためのデータであればOBJが適していても、複雑なプロジェクト構造、属性、施工履歴、版管理まで一つのOBJで表現しようとすると無理が生じます。
点群 OBJ アップロード前に「この階層は形状データとして必要なのか、それとも管理上必要なのか」を整理すると、適切なファイル分割方法を決めやすくなります。
アップロード先の仕様も重要です。一つのOBJ内に複数グループがあっても、アップロード先がそれらを個別表示できなければ、書き出し側だけで解決することはできません。その場合は、表示を切り替えたい単位でOBJを分割するほうが確実です。
つまり5つ目の設定とは、単なるチェック項目ではなく、「OBJに任せる構造の範囲を決める」という書き出し方針そのものです。
点群OBJを書き出す前に確認したいデータ構造
5つの設定を確認する前に、元データがどのような構造になっているかを整理しておくことも重要です。
点群や3Dモデルを扱っていると、画面上の階層表示と、実際のデータ構造が同じだと思いがちです。しかし、画面上ではフォルダに見えていても、単なる表示整理用のグループであり、書き出し対象となる実体ではないことがあります。
たとえば、画面上で「建築」「土木」「設備」というフォルダに分かれていても、実際の書き出し対象はすべて同じメッシュに統合されている場合があります。この状態では、OBJ書き出し設定を変更しても元のフォルダ構造を復元できません。
反対に、画面上では一つのモデルに見えていても、内部では多数の小さなオブジェクトに分かれていることがあります。この場合、すべてを保持してOBJへ書き出すと、アップロード先で大量のグループが生成され、操作性が悪くなる可能性があります。
したがって、「階層を全部残す」ことが必ずしも正解ではありません。
現場で必要なのは、アップロード後に意味のある単位で分かれていることです。
施工管理であれば、施工前と施工後を切り替えられることが重要かもしれません。維持管理であれば、構造物ごとに分けられることが重要な場合があります。土量確認であれば、計測範囲や基準面が区別できることのほうが重要です。
書き出す前に、最終利用者がどの単位でデータを操作するのかを決めます。
そのうえで、不要な細分化は統合し、必要な区切りだけを残します。OBJは比較的単純な形式だからこそ、この事前整理がアップロード後の使いやすさを大きく左右します。
点群OBJアップロード後に階層が消えたときの切り分け
実際にアップロードした後でグループが消えていた場合は、原因を順番に切り分けます。
最初に確認するのは、元データです。書き出し直前の状態で、必要なオブジェクトが本当に分離されているかを確認します。単に表示上のフォルダで分かれているだけではなく、形状データとして別オブジェクトになっているかを見ることが重要です。
次に、生成されたOBJを確認します。別の確認環境でOBJを読み込み、グループやオブジェクトが分離されているかを調べます。
ここでグループが残っていれば、書き出し自体は正常であり、アップロード先の読み込み処理で統合されている可能性があります。
一方、この時点ですでに一つのオブジェクトになっているなら、書き出し設定または書き出し前の変換処理を見直します。
さらに確実に確認したい場合は、OBJをテキストとして調べます。形状データそのものをすべて読む必要はありません。グループやオブジェクトを示す記述が期待どおり存在するかを確認するだけでも、原因の範囲を絞れます。
グループ名がまったく含まれていなければ、書き出し時に情報が削除されている可能性があります。名称は存在するのにアップロード後に区別できなければ、読み込み側が対応していない、または別の基準で統合していることが考えられます。
この切り分けを行わず、何度も同じOBJを書き出してアップロードすると、設定変更の効果が分からなくなります。
検証時には、小規模なテストデータを作る方法も有効です。たとえば3つの単純な形状を「GROUP_A」「GROUP_B」「GROUP_C」と明確に分け、それをOBJへ書き出します。アップロード後に3つが区別されるか確認すれば、対応状況を短時間で判断できます。
大規模な点群や高密度モデルを使って毎回検証する必要はありません。
また、問題が階層だけなのか、座標やマテリアルも変化しているのか確認します。複数の問題が同時に起きている場合は、書き出し時に大きな再構成処理が行われている可能性があります。
点群 OBJ アップロードでは、「ファイルを開けたから正常」と判断せず、位置、形状、グループ、色、テクスチャなど、業務で必要な情報がそれぞれ保持されているかを確認することが重要です。
グループ構造を残したい現場での運用方法
グループ階層の問題は、書き出し設定だけでなく運用方法を統一することで発生しにくくできます。
まず有効なのが、OBJへ変換する直前のデータを保存しておくことです。書き出しのためにオブジェクトを統合したり、名称を変更したりすると、元の編集データへ戻れなくなることがあります。
特に点群から生成した3Dモデルでは、軽量化、不要部分削除、メッシュ統合など複数の処理を行うことがあります。最終OBJだけを残していると、グループが消えた際に再編集が難しくなります。
そのため、元データ、編集後データ、アップロード用データを段階的に分けて管理すると安全です。
次に、アップロード用OBJの命名規則を統一します。工区、計測日、施工段階、対象物など、業務上必要な区分を決めておけば、OBJ内部の階層が平坦化されても整理しやすくなります。
さらに、初めて使用する書き出し設定は、本番データでいきなり使わず、小規模なモデルで確認することが有効です。
一度正常な設定が決まったら、その条件を標準化します。担当者によって「結合する」「結合しない」「マテリアル単位にする」といった判断が変わると、同じ現場でもアップロード結果が異なってしまいます。
書き出し条件を統一することは、ファイルの互換性だけでなく、後工程の作業時間を減らすうえでも重要です。
また、点群データそのものを共有したいのか、点群から生成した3D形状を共有したいのかも明確にします。
点群をOBJへ変換する場合、元の点群が持っていた属性や分類情報がそのまま維持されるとは限りません。必要な情報が座標付きの3D形状であれば問題ありませんが、点ごとの詳細な分類や属性まで必要であれば、OBJだけで運用する方法が適しているかを事前に確認する必要があります。
現場では「OBJに変換できるか」よりも、「変換後も目的の作業ができるか」で判断することが大切です。
点群OBJアップロードを安定させるためのまとめ
点群OBJのグループ階層が消えるときは、単純なアップロードエラーではなく、OBJの構造と書き出し設定の違いを確認する必要があります。
まず確認したいのは、グループ名やオブジェクト名をOBJへ書き出す設定です。必要な識別情報が出力されていなければ、形状だけが一つにつながった状態として読み込まれる可能性があります。
次に、複数オブジェクトを単一形状へ結合する設定を確認します。アップロード後にも部位ごとに操作したい場合は、必要な区切りを残した状態で書き出すことが重要です。
マテリアル単位の再編成にも注意が必要です。形状のグループと外観用のマテリアルは目的が異なるため、マテリアルを基準とした統合や分割によって、元のグループ構造が変化しないか確認します。
名称については、重複を避け、一意で規則的なグループ名を使用します。OBJで多段階層を完全に再現できない場合でも、名称に工区や施工段階などの情報を含めることで、平坦化された後でも所属を判断しやすくなります。
そして最も重要なのは、OBJだけですべての多段階層を管理しようとしないことです。アップロード後に明確に分けて扱う必要がある単位は、OBJファイル自体を分割したり、別の管理情報と組み合わせたりする方法を検討します。
点群 OBJ アップロードでは、「形状が表示されたか」だけを成功基準にすると、後からグループ消失、名称重複、テクスチャの不整合、座標の扱いなどの問題が見つかることがあります。書き出し前とアップロード後で、形状、位置、グループ、名称、外観を一つずつ確認する運用が重要です。
現場で取得した3Dデータを活用する目的は、単にファイルを保存することではありません。施工前後の比較、構造物の位置確認、記録の共有、現況の可視化など、後工程で使える状態にすることが重要です。
そのためには、OBJを書き出す段階から、アップロード後に誰がどの単位でデータを見るのかを想定しておく必要があります。複雑な階層をそのまま持ち込もうとするのではなく、必要なグループを整理し、名称を統一し、必要に応じてファイルを分けることで、扱いやすい3Dデータになります。
また、現場で3D計測からデータ確認までの流れを効率化したい場合は、取得時点から位置情報を含めたデータ管理を考えることも重要です。LRTK Phoneのように現場で位置情報を扱いながら計測や記録を進められる環境を活用すれば、後工程でファイルだけを見て位置関係を推測する負担を減らしやすくなります。
点群や3DモデルをOBJとしてアップロードする際は、形式変換だけを目的にするのではなく、その後の確認、共有、比較まで含めて書き出し方法を決めることが、安定したデータ運用につながります。