点群OBJのグループ名が消えると実務で何が起きるのか
点群や点群から生成したメッシュをOBJ形式で書き出し、クラウドやビューアへアップロードすると、編集時に設定していたグループ名が表示されなくなることがあります。元のデータでは「地表」「建物」「樹木」「道路」「設備」のように分けていたにもかかわらず、アップロード後には全体が一つのモデルとして見える状態です。
グループ名が表示されなくても、頂点座標や面形状が残っていれば、外観だけでは大きな問題に見えないことがあります。しかし、実務ではグループ名が対象範囲を識別する重要な手掛かりになります。グループ単位で表示と非表示を切り替える、不要な範囲を選択する、計測日ごとの差分を確認する、修正対象だけを差し替えるといった作業では、名前を操作単位として利用できるかどうかが作業時間を左右します。
たとえば、複数日に取得した点群を一つのOBJへまとめている場合、グループ名が利用できなくなると、どの部分がどの計測日に対応しているのか判断しにくくなります。地表と仮設物を分けていたデータでも、アップロード後に一体の選択単位として扱われると、体積計算や断面確認の対象を選ぶ際に追加の切り分け作業が必要になります。
点群 OBJ アップロードでグループ名が消える問題は、書き出し操作だけが原因とは限りません。元データの階層構造、OBJへの変換方法、書き出し時の結合処理、アップロード先の読み込み仕様、名前に使用した文字など、複数の要因が関係します。
また、グループ名が本当にOBJから消失している場合と、OBJ内には残っているもののアップロード先の画面に表示されない場合は区別する必要があります。前者は書き出し元での修正が必要ですが、後者は読み込み先の仕様や表示機能の問題であり、同じ設定変更では解決できません。
問題を切り分けるときは、元データ、書き出したOBJ、アップロード先の三段階を分けて確認します。元データに名称が保存されているか、OBJ内部に名称を示す命令が記録されているか、アップロード先がその命令を利用しているかを順番に調べると、不要な再書き出しや再アップロードを減らせます。
OBJに保存されるグループ名の基本構造
OBJは、頂点、面、線、点、法線、テクスチャ座標などをテキストとして記録できる形式です。代表的な命令では、頂点座標をv、面をf、線をl、点要素をp、オブジェクト名をo、グループ名をgで表します。材質ライブラリの参照にはmtllib、使用する材質の指定にはusemtlが使われます。これらは役割が異なり、材質名があるからグループ名も保持されるという関係ではありません。Paul Bourke+1
たとえば、g groundという行の後に複数のf行が続いていれば、それらの面はgroundというグループに属する要素として記録されます。続いてg buildingが記録され、その後に別の面が並んでいれば、そこから後の面にはbuildingというグループ指定が適用されます。
gは単純な階層名ではなく、後続する要素の所属を指定する命令です。OBJの仕様では、一つのg行に複数のグループ名を並べることができ、その場合、後続要素は同時に複数のグループへ属します。そのため、g north groundは「north ground」という空白を含む一つの名称ではなく、northとgroundという二つのグループ名として解釈されます。Paul Bourke+1
ただし、gがOBJ内に存在しているだけで、必ずアップロード先の画面にグループ名が表示されるわけではありません。読み込み側がgを無視する場合、内部形式へ変換する際に統合する場合、読み込んではいても利用者向けの選択単位として公開しない場合があります。
oとgの扱いにも注意が必要です。oは名前付きオブジェクト、gは後続要素のグループ指定に使われますが、編集環境のレイヤー、フォルダー、オブジェクト、選択セットがどちらへ変換されるかは書き出し機能によって異なります。元環境の「オブジェクト名」が常にoへ、レイヤー名が常にgへ変換されると決めつけることはできません。
点群OBJでは、頂点座標を示すvが大量に記録される一方、点要素を示すpが書き出されない場合があります。一部の表示環境はvだけのファイルも点群として表示しますが、gは後続する要素の所属を指定する命令であり、頂点定義そのものをグループへ割り当てる命令ではありません。点としての所属を明示するには、pで頂点番号を参照する構造が必要です。Paul Bourke+1
点群から面を生成したOBJであれば、fとgの組み合わせでグループと面の対応を記録しやすくなります。一方、vだけで構成された点群OBJでは、書き出し元や読み込み先が独自の解釈を行わない限り、標準的な要素所属としてグループと各点の関係を表しにくくなります。
OBJが保持できる構造は比較的平坦です。元データにある複雑な親子階層、点ごとの分類属性、取得日時、座標参照系、作業履歴などを、そのまま完全に保存する用途には向きません。したがって、元データで見えている情報が、OBJへ書き出せばすべて同じ形で残るとは限りません。
元データの階層とOBJのグループは同じではない
点群の編集環境では、データをフォルダー、レイヤー、オブジェクト、分類、選択グループ、計測範囲などに分けて管理できます。しかし、これらの構造がすべてOBJのgとして書き出されるわけではありません。
たとえば、画面上で「地表」というレイヤーに点が表示されていても、そのレイヤーが表示条件や検索条件として設定されているだけで、独立したオブジェクトとして保存されていない場合があります。この状態でOBJへ書き出すと、見た目では分類されていた点群が、一つの頂点一覧として保存されることがあります。
分類コードや属性値によって色分けしている場合も同様です。属性を使って地表、植生、構造物を分けていても、その属性がOBJのグループへ自動変換されるとは限りません。分類を維持したい場合は、書き出し前に分類ごとの点や面を独立したオブジェクトへ分離する処理が必要になることがあります。
元データに多段階の階層がある場合も注意が必要です。「現場」「計測日」「対象物」という三段階の階層を作成していても、OBJには親子階層をそのまま表す一般的な命令がないため、一つの名称へ連結される、最上位または最下位の名称だけが残る、同じ階層へ平坦化されるといった変換が起こり得ます。
親子関係を持つ構造をOBJへ変換する際、同じ子グループ名が複数の親の下に存在すると、平坦化後に区別できなくなる可能性があります。元データでは「北側」の下に「地表」、「南側」の下にも「地表」があっても、両方を単にg groundとして出力すれば、OBJ上では同じ名前のグループです。読み込み先が一つのグループとして表示しても、仕様上不自然ではありません。
書き出し前には、維持したい情報がどの種類の構造として保存されているかを確認することが重要です。単なる表示レイヤーなのか、独立したオブジェクトなのか、点ごとの属性なのかによって、適切な変換方法が異なります。
グループ名を残したい場合は、元データ上で対象ごとに独立したオブジェクトまたは書き出し対象を作成し、それぞれに重複しない名前を付けてからOBJへ変換する方法が分かりやすくなります。ただし、利用する編集環境やアップロード先によって対応状況が異なるため、小規模なテストデータによる確認が欠かせません。
原因1：グループ情報を書き出す設定が無効になっている
グループ名が消える基本的な原因は、OBJの書き出し設定でオブジェクト名やグループ情報が出力されていないことです。元データに正しい名前が設定されていても、書き出し対象に名称情報が含まれていなければ、OBJには形状情報だけが保存されます。
OBJの書き出し画面には、オブジェクト名、グループ、レイヤー、材質グループ、選択範囲などに関する項目が用意されていることがあります。設定名は環境によって異なり、「オブジェクトを書き出す」「グループを保持する」「レイヤーをグループへ変換する」といった名称でも、実際にoとgのどちらが出力されるかは同じとは限りません。
互換性や処理の単純化を優先する設定では、すべての要素が一つのオブジェクトとして保存されることがあります。この状態では、o defaultやg defaultのような一つの名称だけが記録され、元の複数名称は出力されません。
元データでグループが設定されているように見えても、書き出し対象として認識されていない場合があります。たとえば、表示を切り替えるためだけのフォルダーやフィルターは、OBJのグループ命令へ変換されないことがあります。書き出し対象にできるのが独立したオブジェクトだけという環境もあります。
この原因を確認するには、書き出したOBJの複製をテキストエディターで開き、行頭のg またはo を検索します。元データに複数のグループがあるにもかかわらず、該当行が一つもない場合、名称情報はOBJへ書き出されていません。
gやoが一つだけ存在している場合も、元データの構造が統合されている可能性があります。元のグループ数と、OBJ内に記録された異なる名称の数を比較すると、書き出し段階で情報が失われたかどうかを判断しやすくなります。
ファイル内に存在しないグループ名は、アップロード先の表示設定だけでは復元できません。まずOBJ自体に名称が含まれていることを確認し、その後にアップロード先の読み込み方法を調べる必要があります。
原因2：結合や最適化によってグループが統合されている
二つ目の原因は、OBJを書き出す際の結合処理や最適化処理です。ファイル容量を抑えたり、表示処理を単純化したりするために、複数のオブジェクトを一つへまとめる設定が使われることがあります。
全オブジェクトの結合が有効になっていると、地表、構造物、植生などを別々に管理していても、一つの頂点一覧や面一覧へ統合されます。形状そのものは維持されても、元のgやoの切り替えが削除され、単一の名称に置き換えられる場合があります。
同じ材質を使用する面をまとめる処理にも注意が必要です。グループが異なっていても同じ材質を使用している場合、書き出し元またはアップロード時の変換処理が材質単位へ再編成することがあります。ただし、材質単位の結合を行えば必ずgが消えるわけではありません。形状最適化とグループ保持を別々に扱える環境もあるため、実際の出力結果を確認する必要があります。
点群から作成したメッシュでは、近接頂点の結合や重複頂点の削除も行われることがあります。頂点を共有するだけでグループが消えるとは限りませんが、最適化処理が面の並び順、オブジェクト境界、名称命令まで再構成すると、元の区分が維持されない可能性があります。
階層を平坦化する設定も影響します。複数階層を一つのOBJへまとめるとき、親の名称だけを残して子グループを削除したり、複数の名称を一つへ連結したりすることがあります。同名グループを一つの表示単位にまとめる読み込み環境では、元データ上の別々の対象を区別できなくなることがあります。
結合処理の影響を調べる際は、元データ全体を使う必要はありません。二つまたは三つの小さなグループを作り、それぞれに分かりやすい名称を付けて書き出します。結合を有効にした場合と無効にした場合のOBJを比較すれば、どの設定がgやoの出力に影響しているかを確認できます。
軽量化と構造保持を両立できない場合は、用途別にファイルを分ける方法があります。編集や再利用を目的とする保存用OBJでは名称と分割を維持し、閲覧だけを目的とする配信用OBJでは必要に応じて統合します。一つのファイルだけですべての用途を満たそうとすると、構造保持と表示性能のどちらを優先するか判断が必要になることがあります。
原因3：アップロード先がグループ情報を読み込んでいない
三つ目の原因は、OBJにはグループ名が保存されているものの、アップロード先がその情報を利用していないことです。この場合、書き出し元の設定を変更しても、表示結果が変わらない可能性があります。
OBJを読み込める環境であっても、OBJに含まれるすべての命令へ対応しているとは限りません。形状表示を主目的とする環境では、頂点、面、法線、テクスチャ座標、材質を読み込み、gやoを選択単位として扱わない場合があります。
アップロード時に独自の内部形式へ変換する環境では、元のグループ構造が保持されないことがあります。特に大規模な点群やメッシュは、表示を高速化するために空間的な小区画へ再分割されることがあります。このとき、OBJ内のグループではなく、位置や描画効率に基づく内部単位で管理されると、元の名称を画面上で利用できない場合があります。
oとgのどちらを利用するかも読み込み環境によって異なります。OBJ内にgが記録されていても、アップロード先がoだけをモデル分割に利用していれば、一つのオブジェクトとして表示される可能性があります。反対に、oを表示せず、gだけを選択単位として扱う実装もあり得ます。
アップロード後にファイル名だけがモデル名として表示され、内部のオブジェクト名やグループ名を画面へ出さない構成もあります。この場合、名称が完全に失われたとは限りませんが、利用者がグループ単位で表示、選択、差し替えを行えなければ、実務上はグループを利用できない状態です。
対応状況を確認するときは、「OBJをアップロードできるか」だけでなく、「OBJ内のoとgを保持し、画面上の操作単位として利用できるか」を確認する必要があります。ファイル形式への対応と、内部の名称情報への対応は別の問題です。
切り分けには、同じOBJを別の確認環境へ読み込む方法が有効です。別環境ではグループ名が表示され、特定のアップロード先だけで利用できない場合は、読み込み側の仕様である可能性が高くなります。複数の環境で名称が表示されない場合は、OBJ内の命令と要素の対応を優先して調べます。
原因4：グループ名の文字や重複が変換されている
四つ目の原因は、グループ名に使用した文字、空白、記号、文字数、重複などです。OBJはテキスト形式ですが、名称の文字コードや許容文字、長さ制限への対応は、書き出し元と読み込み先によって差があります。
日本語を含むグループ名がOBJに書き出されても、アップロード先が同じ文字コードとして解釈できなければ、文字化け、置換、既定名への変更が起こる可能性があります。ただし、日本語が必ず使用できないわけではありません。書き出し元と読み込み先の組み合わせで正常に扱える場合もあるため、利用環境でのテストが必要です。
空白を含む名称には特に注意が必要です。OBJのg行では空白が複数のグループ名を区切るため、g north groundは一つの名称ではなく二つの名称として扱われます。人が読む表示名として空白を使いたい場合でも、OBJ内の識別名では空白を避けるほうが安全です。
全角空白と半角空白が混在している場合は、見た目が似ていても異なる文字です。書き出し時やアップロード時に一方だけが置換されると、元の名称との照合が難しくなります。
スラッシュ、円記号、コロン、引用符、疑問符などの記号について、すべての読み込み環境に共通する禁止規則があるわけではありません。しかし、アップロード先の識別子、パス、データベース項目として再利用される際に変換される可能性があるため、仕様を確認できない場合は避けるのが無難です。
同じグループ名を複数箇所で使うこと自体は、OBJ上では同じ名前のグループを再度指定する意味になります。元データで別の親階層に属していた対象を区別したい場合、平坦化後も同じ名前を使うと、読み込み先で一つのグループとして表示される可能性があります。これは上書きエラーと決めつけるのではなく、名称だけでは別対象を識別できない状態と考えるべきです。
大文字と小文字の扱い、名称の最大長、先頭文字に関する制約は、アップロード先の実装に依存します。OBJの一般論として「必ず区別される」「必ず短縮される」「先頭は英字でなければならない」と断定せず、利用先の仕様とテスト結果を基準にします。
互換性を優先するなら、OBJ内のグループ名は半角英数字を基本にし、短く重複しない文字列へ統一します。アンダースコアは多くの環境で使われますが、原仕様へ厳密に寄せる場合は半角英数字だけで試験し、アンダースコアを使う場合はアップロード先で保持されることを確認します。
書き出し設定1：オブジェクト名とグループ名を出力する
グループ名を保持するための一つ目の設定は、OBJの書き出し画面でオブジェクト名とグループ名の出力を有効にすることです。
書き出し設定には、「オブジェクト名を書き出す」「グループを書き出す」「レイヤー名をグループへ変換する」「要素ごとに分割する」といった項目が用意されていることがあります。設定名だけでは出力結果を判断しにくいため、書き出したOBJにoとgのどちらが記録されるかを実際に確認します。
アップロード先がどちらを利用するか分からない場合は、可能であればoとgの出力条件を変えた小さなテストファイルを作成します。同じ構造を両方の命令で出力できる環境もありますが、読み込み先によっては二重の分割として見える場合があるため、本番データへ適用する前に確認します。
最初から大規模な点群を使わず、二つの小さな対象で検証すると効率的です。一つをgroundtest01、もう一つをbuildingtest01とし、書き出したOBJ内に両方の名称があるかを確認します。
メッシュの場合は、g groundtest01の後に対象となるf行が続き、次のg buildingtest01の後に別のf行が続くかを確認します。名称だけが存在しても、後続する要素がなければ空のグループとして無視される可能性があります。
点群の場合は、g pointgroup01の後に対象頂点を参照するp行が続き、次のg pointgroup02の後に別のp行が続く構造になっているかを確認します。v行だけでは、標準的な点要素としての所属を明示できません。
元データが分類属性だけを持ち、独立した書き出し対象へ分かれていない場合は、書き出し前に分類ごとに分離します。地表、構造物、植生などを個別のオブジェクトまたは選択範囲に変換し、重複しない名称を付けてからOBJへ出力します。
書き出し後は、元データの区分数とOBJ内の名称数だけでなく、各名称の後に必要な要素が存在するかを比較します。元データに四つの区分があり、OBJにも四つの異なるgまたはoが記録され、対象のfまたはpが対応していれば、書き出し段階では構造が保持されている可能性が高いと判断できます。
書き出し設定2：結合と階層統合を無効にする
二つ目の設定は、複数のオブジェクトやグループを一つへまとめる処理を無効にすることです。グループ名を残したい場合、軽量化や単純化を目的とした結合設定が情報消失の原因になることがあります。
確認したい項目は、全オブジェクトの結合、選択要素の統合、単一メッシュとしての出力、材質単位の結合、階層の平坦化などです。これらの設定名や処理内容は環境によって異なるため、「最適化」という名称だけで判断せず、出力後のgとoを比較します。
近接頂点の結合や重複頂点の削除については、グループ名を必ず消すとは限りません。頂点を共有したまま、面ごとのグループを維持できる場合もあります。どの処理が形状だけを最適化し、どの処理がオブジェクト構造まで変更するかを分けて確認します。
設定の影響を確認するには、同じテストデータを複数の条件で書き出します。結合を有効にしたOBJと無効にしたOBJを比較し、gとoの数、名称、頂点数、点要素数、面数、ファイル容量を確認します。
グループ名が維持される設定が見つかったら、その条件を記録します。点群OBJは点数や面数が多いため、担当者ごとに設定が異なると、同じ元データから別の構造のOBJが生成されることがあります。
表示性能を高める必要がある場合は、保存用と配信用のOBJを分けます。保存用ではグループ、オブジェクト、材質などの情報を可能な範囲で保持し、配信用では用途に応じて結合や軽量化を行います。
結合を無効にしたからといって、ファイル容量が必ず大幅に増えるわけではありません。名称を示す行自体は形状データに比べて小さいため、容量増加が大きい場合は、頂点の重複、面の分割、点要素の記述、材質やテクスチャの構成など、別の要因も確認します。
書き出し設定3：グループ名を互換性の高い命名規則に統一する
三つ目の設定は、グループ名を互換性の高い形式へ統一することです。名称がOBJに記録されていても、読み込み先で扱えない文字や変換対象の文字が含まれていると、置換や既定名への変更が起こる可能性があります。
最初の検証では、半角英字と半角数字だけを使った短い名称を用います。「北側地表」の代わりにgroundnorth01、「第1計測範囲」の代わりにsurveyarea01のような文字列を使い、アップロード後も保持されるか確認します。
先頭を英字に統一する方法は、さまざまな識別子へ転用される運用で変換を避けるための社内規則としては有効です。ただし、OBJ仕様そのものに「必ず先頭を英字にする」という一般的な必須条件があると説明するのは適切ではありません。利用先の制約が確認できない場合に、保守的な命名規則として採用します。
単語の区切りに空白は使いません。読みやすさのために区切りが必要な場合、アンダースコアを利用できるか小さなテストで確認します。アンダースコアが問題なく保持される環境ではground_north_01のような形式を使用できますが、最も単純な互換性試験ではgroundnorth01のような半角英数字のみの名称を使います。
大文字と小文字はどちらかへ統一します。すべて小文字に統一しておけば、読み込み先が大文字と小文字を区別しない場合でも、意図しない表記揺れを減らせます。
一つのOBJ内で区別したい対象には、重複しないグループ名を付けます。現場、範囲、分類、連番などを組み合わせますが、すべての情報を名称へ詰め込むと長くなるため、アップロード後の識別に必要な要素だけを残します。
日本語の表示名が必要な場合は、OBJ内の識別名と日本語の説明名を別に管理します。site01groundnorth01が「第1現場・北側地表・第1範囲」に対応することを管理情報へ記録しておけば、OBJの互換性を優先しながら、人が理解しやすい名称も維持できます。
書き出し前に、空白の除去、文字の統一、重複名への連番付与を行います。利用先で使用可能な文字と最大長が公開されている場合は、その仕様に合わせます。公開されていない場合は、小さなテストOBJで名称の保持を確認してから本番データへ適用します。
書き出し設定4：点群では点要素を出力するかグループ別に分ける
四つ目の設定は、点群OBJでvだけを書き出すのではなく、可能であれば点要素を示すpも出力することです。メッシュではfが頂点を参照するため、gと面の所属を表しやすくなりますが、点群ではvが座標定義にすぎず、点としての要素を別に示さない書き出しがあります。
書き出し機能に「点を要素として出力する」「ポイントプリミティブを出力する」「頂点のみではなく点として保存する」といった設定がある場合は、テストデータで有効にします。出力後にp行が存在し、その前のgが意図した名称になっているかを確認します。
たとえば、最初のグループをg pointgroup01とし、その後のp行で対象頂点番号を参照します。次のグループをg pointgroup02とし、別のp行で別の頂点番号を参照すれば、グループと点要素の対応を明示できます。
ただし、書き出し元がpへ対応していても、アップロード先が点要素またはgを読み込まなければ、画面上のグループとして利用できない場合があります。pを出力すれば必ず解決すると断定せず、書き出し元と読み込み先の両方で確認します。
書き出し元がpの出力に対応していない場合、またはアップロード先がvだけの点群を一つの集合として扱う場合は、グループごとにOBJファイルを分ける方法が確実です。各ファイルが別モデルとして管理される環境であれば、ファイル名を名称の代替として利用できます。
グループ別に分ける場合も、各ファイルで原点、座標値、軸方向、縮尺の解釈を変えないことが重要です。OBJ自体に業務上の座標参照系や単位運用が十分に埋め込まれるとは限らないため、別の管理情報にも記録します。
点群からメッシュを生成している場合は、点群のグループをそのまま保持するのか、生成後の面を新しいグループとして整理するのかを決めます。メッシュ化によって点数や境界が変わるため、元点群の分類と生成面のグループを同一視できない場合があります。
OBJとMTLの役割を混同しない
OBJ本体とMTL、テクスチャ画像を同じ構成で管理することは、外観を正しく再現するために重要です。しかし、MTLやテクスチャをそろえること自体は、gやoを保持する設定ではありません。
OBJでは、mtllibが材質ライブラリを参照し、usemtlが後続要素へ使用する材質を指定します。グループ名はOBJ本体のg、オブジェクト名はoで記録されるため、MTLが欠けてもgやoの行が自動的に消えるわけではありません。Paul Bourke+1
OBJだけをアップロードし、MTLやテクスチャ画像を含めなかった場合、形状は表示されても色分けや模様が失われることがあります。元のグループを色だけで見分けていた場合、すべて同じ外観になり、グループが統合されたように見える可能性があります。しかし、これは名称情報の消失とは別の現象です。
OBJ、MTL、テクスチャ画像のファイル名を変更する場合は、内部の参照名も一致させます。OBJ内のmtllibと実際のMTLファイル名が異なると、材質が読み込まれない場合があります。画像を使用する場合も、MTLからの参照関係を維持します。
フォルダー構成を変更するときは、アップロードする一式だけで参照が成立するかを確認します。元の作業環境にしか存在しない画像へ依存していると、別の環境では外観を再現できません。
材質名をグループ名の代わりに使う方法には限界があります。usemtlは外観を指定する情報であり、構造を示すgやoと同じではありません。同じ材質を複数のグループで使えば、材質だけでは対象を区別できません。
したがって、グループ構造はgまたはoで確認し、材質とテクスチャは外観を維持する補助情報として別に確認します。アップロード後に名称が消えたのか、色分けだけが消えたのかを分けて判断することが重要です。
点群OBJアップロード前にファイル内部を確認する方法
点群OBJをアップロードする前にファイル内部を確認すると、名称の欠落を早い段階で発見できます。OBJはテキスト形式なので、専用の解析機能がなくても基本構造を確認できます。
最初にOBJの複製を作り、テキストエディターで開きます。点群OBJは容量が大きくなることがあるため、元ファイルを直接編集しないことが重要です。大容量ファイルを一般的な編集環境で開けない場合は、内容を変更せずに行頭検索や部分表示ができる確認方法を利用します。
まず行頭のg を検索し、元データで設定したグループ名が記録されているか確認します。続いてo を検索し、オブジェクト名が出力されているかを確認します。
名称が見つかったら、その後にどの要素が続いているかを確認します。メッシュであればf、線であればl、点要素を明示するOBJであればpが続いているかを見ます。途中に別のgやoが現れれば、そこから所属または名称の指定が切り替わります。
グループ名だけが記録され、そのグループに属する要素が一つもない場合は、読み込み先で空のグループとして無視される可能性があります。名称の切り替え位置と、対象要素の並び方が対応していることが重要です。
元データの区分数と、OBJ内の異なる名称の数も比較します。ただし、一つのg行に複数のグループ名を指定できるため、単純な行数だけでは正確に数えられません。g行の内容を確認し、同じ名称の再指定と、異なる名称の数を分けて数えます。
同じ名称が複数回記録されている場合は、意図した再指定なのか、元の別対象が同名になっているのかを確認します。別対象を区別したいのに同じ名称になっている場合は、書き出し前の命名規則を修正します。
文字化けや置換も確認します。元データでは日本語名だったものがOBJ内で読めない文字列になっている場合は、アップロード先でも正しく扱えない可能性があります。半角英数字のテスト名では保持されるかを比較します。
OBJを書き出し元へ再度読み込む試験も有効です。新規データとして読み込み、グループ名、頂点数、点要素数、面数、材質、位置、縮尺を確認します。再読み込み時点で名称が利用できなければ、アップロード先より前の段階に原因がある可能性が高くなります。
グループ名が消えたときの切り分け手順
グループ名が消えた場合は、設定を一度に変更するのではなく、どの段階まで情報が残っているかを順番に確認します。
最初に、書き出し前の元データを確認します。グループ名が一時的な表示名ではなく、データとして保存されているかを確認します。元データを保存して開き直した後も同じ名称が表示されることが一つの目安です。
次に、OBJ内のgとoを確認します。目的の名称が存在しなければ、書き出し設定または元データの構造に原因があります。名称が存在する場合は、後続するf、l、pとの対応、文字化け、空白、記号、重複を調べます。
点群OBJでは、vだけか、pも出力されているかを確認します。gの後にvが並んでいても、頂点定義を標準的な点要素の所属として解釈しない読み込み先があります。可能であればpを出力したテストと、グループ別に分割したテストを比較します。
その後、同じOBJを別の確認環境へ読み込みます。別環境では名称が表示される場合、特定のアップロード先がgまたはoを利用していない可能性があります。別環境でも利用できない場合は、OBJ内の名称と要素の対応を再確認します。
gとoのどちらに対応しているかを調べるには、二種類の小さなテストOBJを作る方法があります。一方は主にgで区分し、もう一方は主にoで区分します。アップロード結果を比較すれば、読み込み先がどの命令を操作単位として扱うかを推測しやすくなります。
文字の影響を調べる場合は、groupa01とgroupb01のような半角英数字だけの名称へ変更します。単純な名称では保持され、元の名称だけが変換される場合は、文字コード、空白、記号、長さなどが原因である可能性があります。
結合処理の影響を調べる場合は、結合を無効にしたテストOBJを作成します。元の区分数とOBJ内の名称、アップロード後の選択単位が対応するかを確認します。
点群全体を毎回アップロードする必要はありません。少数の点または面だけを含む小さなデータで設定差を確認すれば、試験時間を短縮できます。
グループ名が保持される条件が見つかったら、元の大規模点群へ適用します。ただし、データ量が増えるとアップロード時の変換方式や処理制限が変わる場合もあるため、まず本番に近い一部分で確認します。
確認時には、名称だけでなく、座標、軸方向、縮尺、頂点数、点要素数、面数、色、材質、テクスチャも記録します。グループ名を残すために変更した設定が、別の情報へ影響していないかを確認することが重要です。
アップロード先がグループに非対応の場合の代替策
アップロード先がOBJのgやoを操作単位として扱わない場合は、書き出し設定だけでグループ名を表示させることは難しくなります。その場合は、グループごとにOBJファイルを分割する方法が現実的です。
地表、建物、植生、設備などを別々のOBJとして書き出し、ファイル名を識別情報として使用します。アップロード後に各ファイルが別のモデルとして管理される環境であれば、表示の切り替えや差し替えを行いやすくなります。
分割する際は、すべてのOBJで同じ原点、座標値、軸方向、縮尺の解釈を使用します。書き出し時に「選択範囲の中心を原点にする」といった処理が個別に適用されると、各ファイルが異なる位置へ配置される可能性があります。
点群を分割する前に、共通の基準位置と単位運用を決めておくことが重要です。OBJ以外の管理情報にも座標参照系、単位、変換条件を記録しておけば、再配置や再書き出し時の混乱を減らせます。
連続したメッシュを分割する場合は、境界の隙間や重複にも注意します。境界上の面や頂点をどちらのファイルへ含めるかによって、面の欠落、重なり、法線の不連続が発生することがあります。
ファイル名には、現場、分類、範囲、連番などを含めます。data1やdata2のような名称では、後から内容を判断しにくくなります。利用先で許容される文字を確認し、短く重複しない名称に統一します。
更新時には版や計測時期を別の管理情報にも記録します。ファイル名だけへすべての情報を詰め込むと長くなり、アップロード先で省略表示されることがあります。画面で識別する情報と、履歴として残す情報を分けます。
グループ数が多い場合、すべてを別ファイルにすると管理が複雑になります。実際に表示を切り替える単位、修正する単位、担当者へ渡す単位を基準に分割します。
たとえば、樹木一本ごとに分ける必要がなければ、植生全体を一つのOBJにまとめます。一方、地表と構造物を別々に解析する場合は、それぞれを分割しておくと対象を選びやすくなります。
ファイル単位の分割は分かりやすい代替策ですが、アップロード先が複数ファイルの位置関係を維持できること、同時表示できること、ファイル数の上限や処理時間に問題がないことも確認します。
点群OBJを安定して管理するための運用ルール
点群OBJのグループ名を安定して維持するには、個別の書き出し設定だけでなく、元データからアップロードまでの運用を統一することが重要です。
まず、元データ、編集用データ、アップロード用OBJを分けて保存します。元データには取得時の情報を残し、編集用データでは分類やグループを整理します。アップロード用OBJは、利用する環境の仕様に合わせて生成します。
OBJだけを唯一の保存データにしないことも大切です。OBJは形状の受け渡しに利用しやすい形式ですが、元データが持つ点ごとの分類、取得時刻、座標参照系、親子階層、処理履歴などを同じ形で保持できない場合があります。OBJへ変換する前のデータを残しておけば、名称や区分が失われても再書き出しできます。
書き出し条件を記録します。oとgの出力、pの出力、結合設定、座標変換、軸方向、単位運用、材質出力、テクスチャ参照などを記録しておくと、同じ条件で再作成できます。
命名規則も統一します。使用する文字、名称の長さ、現場識別子、分類名、連番の付け方を決めます。担当者ごとに異なる名称を使うと、書き出し時の重複やアップロード後の混同が起こりやすくなります。
アップロード前の確認項目も固定します。OBJ内のgとo、点群であればp、メッシュであればf、異なる名称の数、頂点数、座標、軸方向、縮尺、材質、テクスチャを確認します。毎回同じ順序で確認すれば、設定ミスを早期に発見できます。
小さな検証用OBJを用意しておく方法も有効です。二つのグループ、既知の座標、必要に応じて異なる材質を持つ簡単なOBJを作成し、アップロード先の更新後や設定変更後に読み込みます。検証用データが正常に扱われれば、本番データ固有の問題と読み込み仕様の問題を分けやすくなります。
重要な情報をグループ名だけに依存させないことも必要です。計測日、担当者、座標参照系、単位、処理条件、修正履歴などは、別の管理情報として残します。
点群OBJをアップロードした後は、元データとの比較を行います。各グループまたは各ファイルの表示状態、位置、形状、色を確認し、意図した構造が維持されているかを確認します。
グループ名が表示されない場合でも、すぐに同じ条件でアップロードを繰り返すのではなく、OBJ内にgまたはoが残っているかを先に調べます。OBJに名称がなければ書き出し条件を修正し、名称がある場合はアップロード先の対応状況を確認します。この順番を守ることで、原因に合わない作業を減らせます。
まとめ
点群OBJのグループ名が消える主な原因は、名称情報の出力が無効になっていること、結合や平坦化によって構造が統合されていること、アップロード先がgやoを操作単位として利用していないこと、名称の文字や重複が読み込み環境で変換されていることです。
グループ名を保持するには、第一にoとgの出力を確認し、第二に単一オブジェクトへの結合や階層統合を避けます。第三に名称を短く重複しない半角英数字を基本として統一し、利用先で確認できた場合にアンダースコアなどを使用します。第四に、点群ではpによる点要素の出力を確認し、対応できない場合はグループ別ファイルへ分けます。
材質やテクスチャを使用している場合は、OBJ、MTL、画像ファイルの参照関係も維持します。ただし、MTLは外観を表す情報であり、gやoを保持する仕組みではありません。名称が消えたのか、色分けだけが消えたのかを分けて確認します。
アップロード前にはOBJをテキストとして確認し、gやoが存在するか、目的の名称が記録されているか、その後に対象となるf、l、pが続いているかを調べます。小さなテストデータを使えば、大規模な点群を何度も処理することなく、設定差を比較できます。
アップロード先がグループ情報に対応していない場合は、グループごとにOBJを分割し、ファイル名を識別情報として利用します。その際は、原点、座標、軸方向、縮尺の解釈を統一し、アップロード後も正しい位置関係で重なることを確認します。
点群を継続的に活用するには、取得、分類、書き出し、アップロード、確認までの手順を統一することが重要です。現場で取得したデータを確認しながら点群活用へつなげる運用を検討する際は、LRTK Phoneを起点とした計測とデータ管理も確認してみてください。