点群をOBJ形式で書き出し、アップロード先で確認したところ、現場区画、計測日、部位、作業工程などで分けていたまとまりが一つに統合されて見えることがあります。元の編集環境では個別に選択、非表示、差し替えができたのに、アップロード後は全体を一括でしか扱えず、後工程の作業が進めにくくなる状態です。
この現象は、必ずしもファイル破損やアップロード失敗を意味しません。OBJには、頂点などの幾何情報に加えて、オブジェクト名を示すo、グループを示すg、面を示すf、線を示すl、点要素を示すpなどの記述があります。一方で、どの記述を書き出すか、読み込み側がどこまで解釈するかは実装によって異なります。特に、頂点レコードだけで表現された点群風のOBJは、一般的な面モデルと同じ方法でグループを再現できない場合があります。([Paul Bourke][1])
本記事では、「点群 OBJ アップロード」で検索する実務担当者に向けて、グループ分けが消える代表的な5つの原因を整理します。アップロード前の確認方法、消失後の復旧方法、再発防止の運用まで、特定のソフトウェアに依存しない形で解説します。
点群OBJのグループ分けが消えるとはどういう状態か
点群OBJのグループ分けが消える状態とは、書き出し前には複数の単位に分かれていたデータが、読み込み後に一つの選択単位や表示単位として扱われることです。たとえば、外壁、床、天井、設備、地盤を分けていたデータが、アップロード後には全点をまとめてしか選択できなくなる状態が該当します。計測日ごとに分けていたデータが統合され、古い計測と新しい計測を個別に表示できなくなる場合もあります。
ただし、見た目が一つになっただけでは、構造情報が本当に削除されたとは断定できません。アップロード先の画面がオブジェクト名やグループ名を表示していないだけで、内部変換データには区分が残っている可能性があります。反対に、画面上では色分けされていても、色や材質が違うだけで、独立したグループとして選択できないこともあります。
また、編集環境で使われる「グループ」という言葉は、OBJのgと同じ意味とは限りません。フォルダ階層、レイヤー、選択セット、分類属性、部材カテゴリ、オブジェクト、材質はそれぞれ別の情報です。書き出し元でフォルダ状に見えていた階層が、そのままOBJのgやoへ変換されるとは限らないため、元の分類が何として保存されるのかを確認する必要があります。
OBJでは、頂点レコードはファイル全体で参照される一覧として扱われ、gやoは主に後続の要素を区分するために使われます。そのため、グループ名の直後に頂点レコードが並んでいるだけのファイルを、すべての読み込み環境が「その頂点はそのグループに属する」と解釈するわけではありません。点群としての互換性は、pなどの要素記述と読み込み側の対応状況に左右されます。([Paul Bourke][1])
実務では、グループ消失によって不要範囲だけを非表示にできない、施工前後を切り替えられない、対象部位だけを差し替えられないといった問題が起こります。数量計算や出来形確認で使う場合は、誤った範囲を対象にするリスクもあります。そのため、画面表示だけで判断せず、元データ、OBJ内部、中間変換、圧縮構成、読み込み後の選択単位を順に確認することが重要です。
原因1 OBJファイルにグループ記述が出力されていない
最も基本的な原因は、生成されたOBJに元の分類情報が書き込まれていないことです。元の編集画面で複数のレイヤーやフォルダに分かれていても、OBJ出力時に単一オブジェクト化、結合、統合、選択要素の一括出力などが行われると、分類が一つにまとめられることがあります。
OBJ内部では、一般にoで始まる行が名前付きオブジェクト、gで始まる行がグループを示します。点群用途では、座標を示すvだけでなく、点要素を示すpが使われる場合があります。面モデルならf、線ならlが要素の参照関係を示します。oやgがまったくない場合、読み込み側が元の区分を復元するための明示的な名称情報はありません。([Paul Bourke][1])
確認するときは、OBJをテキストとして開き、o 、g 、p 、f 、l を検索します。巨大なファイルを通常の文書編集ソフトで開くと動作が重くなるため、大容量ファイルに対応した閲覧方法を使うか、コピーした検証用ファイルで確認します。oやgが複数存在するかだけでなく、それぞれの後にどの要素記述が続いているかを見ることが重要です。
ここで注意したいのは、グループ名が複数並んでいるだけでは十分ではないことです。グループ切り替え後に対応するp、f、lなどがなければ、読み込み側が区分を再構成できない場合があります。特にvは座標定義であり、要素の所属を直接示す記述ではないため、gとvの並びだけを根拠にグループ保持を期待するのは安全ではありません。
書き出し設定では、元のオブジェクトを維持する、レイヤーごとに出力する、選択対象を結合しない、オブジェクト名を保持する、といった機能を確認します。設定名は環境によって異なるため、名称だけでなく処理内容を見ます。初回は全データではなく、二つの小さなグループを使ってテストすると、設定差を短時間で判断できます。
検証用データでは、二つのグループを離れた位置に配置し、異なる名称を付けます。アップロード後に名称一覧と選択単位を確認し、別々に扱えるかを見ます。色だけ変えると、材質差と構造差を混同しやすいため、位置と名称も変えておくと判断しやすくなります。
書き出し機能がOBJ内のグループ保持に対応していない場合は、グループごとに別OBJとして出力する方法が現実的です。一つのファイル内に階層を残すことより、後工程で個別表示や差し替えができることを優先します。ファイル分割は数が増える欠点がありますが、読み込み側のg対応に依存しにくい方法です。
原因2 アップロード先が複数グループを統合している
二つ目の原因は、OBJにoやgが含まれていても、アップロード先がそれらを選択単位として保持しないことです。OBJの読み込み機能は環境ごとに対応範囲が異なり、形状は表示できても、名称、グループ、点要素、材質などの一部が取り込まれないことがあります。
この場合、元のOBJは正しくても、アップロード後の内部形式へ変換される過程で単一データとして扱われます。表示画面に階層パネルがない、グループ名を表示する機能がない、インポート時に統合する設定が有効になっている、といった状況が考えられます。ただし、具体的にどの最適化処理で統合されるかはサービスごとに異なるため、根拠なく「軽量化のため必ず統合される」と断定してはいけません。
切り分けには、同じOBJを別の読み込み環境で開きます。別の環境では複数の選択単位として認識されるのに、特定のアップロード先だけで一つになるなら、読み込み側の仕様または設定が原因である可能性が高いです。どの環境でも一つになるなら、書き出し時点または中間変換で区分が失われている可能性を優先して調べます。
アップロード先に、オブジェクトを結合する、階層を保持する、同名要素を統合する、複数ファイルを一つのモデルとして扱う、といった設定がある場合は、説明文を確認します。設定を変更した際は、名称一覧だけでなく、個別選択、表示切り替え、再出力の結果まで確認します。画面上の表示が分かれていても、再出力時に統合されることがあるためです。
読み込み側がOBJのグループを利用しない仕様なら、同じファイルを再アップロードしても改善しません。その場合は、グループ単位のファイル分割、アップロード後のレイヤー作成、対応している別形式への変更などに切り替えます。選択単位を確保することが目的なら、元の階層を完全再現することにこだわらず、読み込み先で確実に扱える単位へ変換する方が安全です。
施工前と施工後を比較する用途では、二つを別ファイルにするだけでも管理しやすくなります。建物の階ごとに切り替えるなら階別ファイル、工区ごとに確認するなら工区別ファイルが有効です。細かな部材まで分割すると運用が複雑になるため、実際に表示、計測、差し替えを行う単位に合わせます。
原因3 変換工程でオブジェクト名やグループ名が失われている
三つ目の原因は、元データからOBJへ至る途中の変換工程で、名称や分類が削除または別の情報へ置き換えられることです。点群は、計測時の形式、編集用形式、交換用点群形式、メッシュ形式などを経由してOBJになる場合があります。各形式が保持できる情報は同じではないため、変換回数が増えるほど確認箇所も増えます。
元データでレイヤーとして管理されていた分類が、中間形式では分類コードや色として保存され、OBJ変換時にgへ変換されないことがあります。反対に、名称だけは残っていても、要素との対応が失われる場合があります。重要なのは、名称が表示されるかではなく、各名称に対応する点、線、面を個別に選択できるかです。
名称の扱いにも注意が必要です。文字コード、使用可能文字、最大長、空白、記号、同名の扱いは読み書きする環境によって異なります。全角文字や日本語が常に使えないという意味ではありませんが、複数の環境をまたぐ場合は、短い英数字とアンダースコアを中心にした識別子を併記すると照合しやすくなります。「文字が正規化されるから必ず統合される」とは言えないため、実際の変換結果で確認します。
変換工程を調べるときは、各段階でグループ数、名称、要素数を記録します。元データで10区分、中間形式で10区分、OBJで1区分なら、最後の変換設定を見直します。中間形式の時点で1区分なら、それ以前の書き出し工程が原因です。段階ごとの記録があれば、推測ではなく、どこで情報が減ったかを特定できます。
書き出し時の対象範囲も確認します。可視要素のみ、選択要素のみ、アクティブなレイヤーのみ、といった設定が有効だと、非表示または未選択のグループが出力されません。この状態は統合ではなく欠落ですが、アップロード後にグループ数が減るため、利用者には同じ問題に見えることがあります。
命名規則は、案件識別子、日付、工区、分類を一定の順序で組み合わせ、一意になるようにします。たとえば、同じ「地盤」という名称を複数箇所で使うのではなく、区画識別子を付けて重複を避けます。変換後に名称が短縮された場合でも、先頭部分で識別できる構成にすると確認しやすくなります。
可能であれば、中間変換を減らし、元の編集環境から直接OBJを出力します。直接出力できない場合は、分類属性を保持できる中間形式を選び、各工程で区分数を確認します。ファイルサイズだけでは分類欠落を判断できないため、点数、要素数、座標範囲、名称一覧を併せて記録します。
原因4 頂点だけの点群として書き出されている
四つ目の原因は、OBJがvで始まる頂点座標だけを持ち、点群の各まとまりを区分する要素記述を持っていないことです。これは点群をOBJとして扱うときの重要な注意点です。
OBJでは、vは幾何頂点の座標を定義します。面はf、線はl、点要素はpが頂点番号を参照して構成します。gは後続要素のグループを切り替えるために使われるため、頂点一覧だけのファイルでは、標準的な要素単位のグループ関係を表しにくくなります。頂点データはオブジェクトやグループごとの独立配列ではなく、ファイル内で共有される一覧として扱われる点にも注意が必要です。([Paul Bourke][1])
たとえば、g area_aの後に多数のvがあり、その後にg area_bと別のvが続いていても、読み込み側がその並びを頂点所属として解釈する保証はありません。読み込み環境によっては、すべてのvを一つの頂点集合として描画します。グループ単位で点を保持したいなら、pがグループごとに正しく記述されているか、読み込み側がpとgの組み合わせに対応しているかを確認します。
頂点だけのOBJかどうかは、ファイル内を検索して判断します。vは大量にあるのに、p、l、fが見当たらない場合は、頂点一覧として出力されている可能性があります。ファイル先頭だけでは要素記述が末尾にまとめられている場合を見逃すため、全文検索を使います。
この問題を解決するために、全体をメッシュ化すればよいとは限りません。メッシュ化すると面単位でグループを作りやすくなる一方、点間が補間され、実測していない面が生成されることがあります。樹木、配管、足場、細い部材、遮蔽部分などでは、目的に合わない形状が生じる可能性があります。
点の位置や色をそのまま確認したい場合は、グループごとに別ファイルへ分ける方法が適しています。部材単位の面編集が必要なら、必要範囲だけをメッシュ化します。点群形式のまま分類属性を保持したい場合は、アップロード先が対応する点群向け形式を確認し、OBJ以外を選ぶことも検討します。
対策の順序としては、まずpを含めて書き出せるか確認し、次に小規模データで読み込み側の対応を試します。それでもグループが維持されない場合は、ファイル分割または別形式へ切り替えます。OBJに変換できることと、点群の分類を互換的に渡せることは同じではありません。
原因5 関連ファイルや格納構成が正しく引き継がれていない
五つ目の原因は、実際のグループ構造ではなく、材質、色分け、複数ファイル、フォルダ階層によって区分していたデータを、OBJ内のグループとして扱っていると誤認していることです。OBJ本体、材質ファイル、画像、複数OBJの構成が崩れると、元の区分が消えたように見える場合があります。
OBJでは、材質ライブラリをmtllibで参照し、要素へ適用する材質をusemtlで指定できます。MTLは色やテクスチャなどの外観情報を定義するものであり、gやoによるグループ構造そのものを定義するファイルではありません。そのため、MTLが欠けてもOBJ内のgやoが削除されるわけではありませんが、色分けに依存して区分を見ていた場合は、全体が同じ外観になり、一つに統合されたように見えます。([The Library of Congress][2])
まず、構造としてのグループ消失と、外観上の区分消失を分けて確認します。名称一覧に複数のグループが残り、個別選択もできるなら、問題は材質または表示設定です。名称が一つしかなく、全体を一括選択するしかないなら、構造上の統合を疑います。
複数OBJをフォルダや圧縮ファイルで管理していた場合は、アップロード先がその階層を分類として扱うか確認します。フォルダ名が画面上のレイヤーへ変換される環境もあれば、圧縮内の全OBJを同じ階層へ展開する環境もあります。同名ファイルがあると、アップロード時または展開時に区別できない可能性があるため、ファイル名は一意にします。
OBJとMTL、画像の参照では、ファイル名、大文字と小文字、拡張子、相対パスを確認します。元の仕様ではOBJからMTLを参照する構成が定められていますが、現代の読み込み環境が許容する配置やパスは一律ではありません。アップロード先の案内がある場合は、その構成を優先します。([The Library of Congress][2])
圧縮して送る場合は、圧縮前だけでなく、圧縮ファイルを別の場所へ展開した状態でも確認します。OBJが開けるか、材質が表示されるか、複数ファイルが維持されるか、同名ファイルがないかを見ます。長すぎる名称や特殊記号は環境差の影響を受けやすいため、簡潔な名称にします。
この原因への対策は、OBJ内の真のグループ、材質による色分け、ファイル分割、フォルダ分類を明確に区別することです。どの情報を後工程で選択単位として使うのかを決め、それをアップロード先が確実に保持できる方法で渡します。
点群OBJをアップロードする前の確認手順
グループ消失を防ぐには、アップロード後に初めて確認するのではなく、書き出し直後から段階的に検証します。確認順序を固定すると、どこで情報が失われたかを切り分けやすくなります。
最初に、元データの区分数と名称を記録します。何グループあるか、各グループがどの範囲にあるか、個別選択できるかを確認します。可能であれば、各区分のおおよその点数や要素数も控えます。書き出し前の画面記録を残しておくと、担当者間の認識差を減らせます。
次に、書き出し設定を確認します。単一オブジェクト化、結合、統合、可視要素のみ、選択要素のみ、レイヤー名保持、オブジェクト名保持などが対象です。設定項目の名称は製品ごとに異なるため、「何を残し、何をまとめる処理か」を確認します。
書き出したOBJでは、o、g、p、f、l、mtllib、usemtlを検索します。名称数だけでなく、要素記述との対応を確認します。gが複数あっても、後続要素がなければ期待どおりのグループにならない可能性があります。反対に、gがなくても複数のoや別ファイルで区分されている場合があります。
その後、アップロード前にローカル環境で開きます。元の編集環境だけでなく、可能であれば別の読み込み環境でも確認します。ローカルで既に一つなら書き出し側または変換工程、ローカルでは分かれていてアップロード後だけ一つなら読み込み側を中心に調べます。
関連ファイルを使う場合は、OBJ、MTL、画像の参照が成立しているかを確認します。色が消えただけなのか、グループ構造まで消えたのかを区別します。圧縮する場合は、別の場所へ展開した後にも同じ確認を行います。
本番データの前に、二つか三つの区分を持つ小規模な検証用OBJをアップロードします。区分名、位置、色を明確に変え、名称一覧、個別選択、表示切り替えを確認します。読み込み先で再出力できる場合は、再出力後の構造も確認します。
最後に、グループ数だけでなく、総点数、座標範囲、単位、色、欠落の有無を確認します。グループが残っていても、一部要素が出力対象から外れている場合があります。複数の確認項目を一度に記録すれば、再書き出しや再アップロードの回数を減らせます。
グループ分けが消えた後の復旧方法
すでにアップロード後のグループ分けが消えている場合は、元OBJに情報が残っているかを最初に確認します。元OBJに複数のoやgがあり、別の環境では個別選択できるなら、元データを再編集する必要はありません。アップロード方法、読み込み設定、ファイル分割、形式変更で復旧できる可能性があります。
読み込み先がOBJのグループを保持しない場合、最も確実なのは必要な単位ごとに別OBJへ分ける方法です。元データへ戻り、工区、計測日、施工前後、階など、実際に切り替えたい単位で個別出力します。ファイル名には案件識別子、区画、日付、版を含め、同名を避けます。
元データへ戻れない場合は、位置、色、高さ、材質、点密度などを利用して再分類します。ただし、自動選択には境界部の誤分類が含まれる可能性があります。数量計算や出来形判定に使う場合は、再分類結果を目視し、必要に応じて現場記録や写真と照合します。
OBJ内部に複数のgがあり、p、f、lなどの要素が正しく対応している場合は、グループごとに別OBJへ分割できることがあります。ただし、頂点番号はファイル全体の一覧を参照するため、単純に行を切り取るだけでは壊れる場合があります。分割時は、使用する頂点を抽出し、参照番号を振り直す処理が必要です。元ファイルを複製して保管し、小規模データで検証してから適用します。
材質だけが失われている場合は、OBJのmtllib、usemtlと、実際のMTL、画像ファイルの名称を照合します。大文字と小文字、拡張子、空白、相対パスまで確認します。構造上のグループは残っているなら、OBJを分割する前に材質参照を直す方が効率的です。
中間変換で名称や区分が消えた場合は、工程を一段ずつ戻ります。元データから直接OBJへ出力できるなら直接出力し、できない場合は区分情報を保持できる中間形式を選びます。各段階でグループ数、要素数、座標範囲を記録し、どこで減ったかを確認します。
アップロード済みデータしか残っておらず、統合時に名称や境界が削除されている場合は、完全な自動復元が難しいことがあります。その場合は、現場記録、取得日時、座標範囲、写真、作業日報などを基に再分類します。復旧した区分は元の分類と同一とは限らないため、復旧方法と判断根拠を残します。
復旧範囲は用途に合わせます。表示切り替えだけが目的なら粗い範囲分割でも対応できます。数量計算や出来形評価に使うなら、境界精度と欠落の確認が必要です。必要以上に細かな分類を再現しようとすると工数が増えるため、後工程に必要な単位を先に決めます。
グループ情報を維持するための運用ルール
再発を防ぐには、個人の書き出し設定だけでなく、案件全体の運用ルールを整えます。最初に、何をファイル単位で分け、何をOBJ内のグループとして持たせるかを決めます。重要な分類をすべてgだけに依存させると、読み込み先が対応しない場合に区分を失います。
実務では、最重要の分類をファイル単位にし、補助的な分類をOBJ内のgやoとして持たせる方法が扱いやすいです。たとえば、施工前と施工後を別ファイルにし、各ファイル内で工区を分けます。アップロード先がグループを統合しても、施工時点の区分はファイル単位で残ります。
命名規則は短く、一意で、並べ替えやすい形にします。案件識別子、取得日、工区、分類、版番号を一定の順序で付けます。使用文字を統一し、同名グループと同名ファイルを避けます。日本語名称を使う場合も、変換後の照合用に短い識別子を先頭へ付けると管理しやすくなります。
書き出し条件も固定します。座標系、単位、原点、色、グループ保持、統合の有無、点要素の出力、関連ファイルの配置を手順書にまとめます。設定画面の名称は更新で変わることがあるため、項目名だけでなく「複数オブジェクトを結合しない」など目的も記載します。
検証用データを常備することも有効です。二つ以上のグループ、離れた位置、異なる名称、既知の要素数を持つ小さなOBJを用意し、アップロード環境や変換手順が変わったときに読み込ませます。以前と結果が変われば、本番データを送る前に問題を発見できます。
元データと納品データは分けて保管します。元データには編集可能な分類構造を残し、納品用OBJには書き出し条件と版番号を対応付けます。上書きだけで運用すると、グループが残っていた版へ戻れなくなるため、変更前の版を保持します。
アップロード後の検収では、開けるかどうかだけでなく、グループ数、名称、選択単位、総点数、座標範囲、色、関連ファイルの読み込みを確認します。早い段階で確認すれば、元データや作業記録が残っているうちに修正できます。
共有先が複数ある場合は、用途別に出力を分けます。閲覧用には軽量な統合データ、編集用には区分を維持した分割データ、保管用には元構造を残したデータを用意します。一つのOBJですべての用途と読み込み環境に対応しようとすると、互換性と作業性の両方を損ないやすくなります。
点群取得の段階から分類単位を決めることも重要です。現場で計測範囲や工程を分けて記録すれば、後から曖昧な境界を再分類する手間を減らせます。LRTK Phoneで取得した点群を扱う場合も、アップロード後にどの単位で比較、計測、共有するかを先に決め、取得範囲とファイル名を整理しておくと管理しやすくなります。
まとめ
点群OBJをアップロードした後にグループ分けが消える主な原因は、OBJへoやgなどの区分が出力されていないこと、読み込み先が区分を保持または表示しないこと、中間変換で名称や対応関係が失われること、頂点レコードだけで点群が表現されていること、材質や複数ファイルによる区分をOBJ内のグループと混同していることです。
特に重要なのは、vは座標定義であり、gの直後に並ぶだけで頂点所属が互換的に表現されるとは限らない点です。点群としてグループを渡す場合は、pなどの要素記述と読み込み側の対応を確認します。また、MTLは外観情報であり、OBJのgやoそのものを保存するファイルではありません。
問題を切り分けるには、元データの区分数を記録し、OBJ内部のo、g、p、f、lを確認し、ローカル読み込みとアップロード後の結果を比較します。ローカルでは分かれるのにアップロード後だけ統合されるなら読み込み側、ローカルでも統合されるなら書き出し側や変換工程を中心に見直します。
グループ情報を確実に残したい場合は、一つのOBJ内の階層だけに依存せず、重要な分類をファイル単位でも分けることが有効です。命名規則、書き出し条件、圧縮方法、検収項目を標準化すれば、担当者や利用環境が変わっても再現性を保ちやすくなります。
点群の取得から共有までを安定させるには、後工程で必要な分類単位を先に決めることが欠かせません。現場で取得した点群を区画や工程ごとに整理し、OBJへの変換とアップロードを見据えて管理することで、再編集や再アップロードの手間を抑えられます。