点群OBJアップロード後にグループが消える問題とは
点群や三次元モデルをOBJ形式で書き出し、クラウド上の管理環境やブラウザ型の閲覧環境へアップロードした後、元データで設定していたグループが見えなくなることがあります。地面、建物、設備、樹木、仮設物などを分けていたにもかかわらず、アップロード後には全体が一つのデータとして表示される状態です。
この問題を調べる際は、点や面などの形状要素そのものが消えているのか、グループ名や分類だけが消えているのかを最初に分けて考える必要があります。表示範囲や形状がアップロード前とほぼ同じで、一覧上の名称や個別選択の単位だけがなくなっているのであれば、データ本体ではなく構造情報の読み込みや表示方法に原因がある可能性があります。
一方、特定のグループに含まれていた点や面まで表示されていない場合は、単なるグループ名の消失ではありません。変換処理で一部の要素が除外された、参照番号が崩れた、対応していない要素種別が無視された、データ量や処理時間の制限により処理が完了しなかったといった別の問題も考えられます。
点群OBJという呼び方にも注意が必要です。OBJでは座標を表す頂点を「v」で記述しますが、頂点行だけが並んでいることと、標準の点要素として定義されていることは同じではありません。点要素は「p」で頂点番号を参照して記述できます。面を持つメッシュOBJでは「f」、線では「l」、点では「p」が要素として使われます。頂点行だけのOBJを点群として表示できるかどうかは、読み込み側の独自対応に依存するため、互換性を確認する必要があります。OBJの仕様上、要素はグループへ整理できますが、実装ごとに対応範囲が異なります。([The Library of Congress][1])
元の編集環境で複数のレイヤーやフォルダーに分けていても、その構造がOBJへそのまま保存されるとは限りません。元データの階層、表示レイヤー、分類属性、選択セット、作業用フォルダーなどは、OBJのグループとは別の仕組みだからです。
そのため、点群OBJアップロード後にグループが消えた場合は、アップロード先だけを疑うのではなく、書き出し前の構造、書き出されたOBJの内容、変換途中の処理、アップロード先の対応範囲という順番で確認することが重要です。どの段階でグループ情報が失われたかを特定できれば、必要以上に元データを作り直さずに済みます。
OBJ形式でグループが表現される仕組み
OBJでは、頂点、テクスチャ座標、法線、点、線、面、オブジェクト名、グループ、マテリアル参照などが、基本的に行単位で記録されます。グループは先頭が「g」の行、オブジェクト名は先頭が「o」の行で表されます。
「g」は、それ以降に記述される点、線、面などの要素を、一つまたは複数の名前付きグループへ所属させる状態設定です。例えば「g ground」の後に面の定義が続けば、その面はgroundグループに属します。次に「g building」が現れれば、以降の要素にはbuildingが適用されます。また、「g wall buildingA」のように一行へ複数名を記述した場合、後続要素が両方のグループに属するという仕様です。単純に「gの行数＝グループ数」とは判断できません。([Paul Bourke][2])
グループとオブジェクト名は同じ意味ではありません。「o」は後続要素へ利用者定義のオブジェクト名を与える記述であり、「g」は要素を整理するグループ設定です。ただし、読み込み側が両者をどのような階層や選択単位へ変換するかは統一されていません。
ある書き出し環境では、元データの部材ごとに「o」が出力され、細かな分類に「g」が出力されることがあります。別の環境では「o」だけが使われたり、「g」だけが使われたり、すべてが一つの単位へまとめられたりします。書き出し元で見えている階層が、そのままOBJの親子構造になるとは限りません。
アップロード先も、すべてのOBJ記述を同じように解釈するとは限りません。「o」を分割単位として扱い「g」を表示しない場合や、「g」を読み込んでも個別選択の単位には使わない場合があります。内部では名前を保持していても、利用者向けの一覧には表示しない処理も考えられます。
点要素を含むOBJでも「g」は後続の点要素へ適用できます。ただし、点群として利用する際に「p」を解釈するか、頂点行だけを独自に点として描画するか、グループを点集合の選択単位へ変換するかは読み込み側によって異なります。メッシュでグループが維持できても、点だけのデータでは一つの点集合に統合される場合があります。
また、OBJは複雑な親子階層をそのまま表現する形式ではありません。元データに「建物」という親階層があり、その下に「壁」「柱」「床」がある場合でも、OBJ上では名前が同列に並ぶことがあります。親子関係が失われても個別名称が残る場合もあれば、書き出し設定によって一部だけが残る場合もあります。
したがって、元データの階層とOBJのグループを同一視しないことが大切です。アップロード後も維持したい分類がある場合は、その分類が「g」として出力されるのか、「o」として出力されるのか、ファイル分割へ置き換える必要があるのかを事前に確認します。
原因1：書き出し時にグループ情報が保存されていない
最初に確認すべき原因は、アップロード前のOBJに必要なグループ情報が含まれていないことです。元の編集画面では複数の項目に分かれていても、OBJを書き出す設定によっては、すべての要素が一つにまとめられます。
元データで表示されている分類が、OBJへ直接変換できない種類の情報である場合もあります。表示レイヤー、色分け、選択状態、作業用フォルダー、分類タグ、属性値などは、編集環境内部でのみ利用できる情報かもしれません。書き出し時にグループ名やオブジェクト名へ変換されなければ、OBJには記録されません。
この状態でアップロードすると、アップロード先がOBJを正しく処理していても、期待したグループは表示されません。もともとのOBJに該当する定義がないためです。書き出し元の画面だけを見て「グループを設定した」と判断せず、実際に生成されたOBJを確認する必要があります。
OBJはプレーンテキスト形式なので、容量が許せばテキスト確認手段で内容を調べられます。行頭が「g 」「o 」「p 」「l 」「f 」の行を検索し、どの種類の要素と分類情報が含まれているかを確認します。「g default」のような共通名称だけで全要素が処理されている場合は、実務上は一つのグループとして扱われる可能性があります。
確認時は「g」の行数だけを数えないことが重要です。一行に複数のグループ名を設定でき、同じ名称が複数回登場することもあります。グループ数を調べる場合は、各「g」行のトークンを抽出し、重複を除いた名称一覧と、各要素に適用される状態を確認します。
対策は、書き出し設定でグループやオブジェクト名の保持に関係する項目を有効にすることです。設定の名称は環境によって異なりますが、オブジェクト単位で書き出す、グループ名を保持する、部品を分離する、選択範囲ごとに出力するといった意味の設定を探します。
ただし、設定を有効にしただけで元の階層が完全に維持されるとは限りません。書き出し後のOBJを再度読み込み、期待する単位に分かれているかを確認してください。同じ環境へ読み戻すだけでは独自の解釈により見かけ上復元されることがあるため、可能であれば別の確認環境でも検証します。
書き出し機能がグループ保持に対応していない場合は、必要な単位ごとにOBJを分けて出力する方法が有効です。地面、建物、設備、植生などを別ファイルにすれば、アップロード先がOBJ内部の「g」を利用しなくても、ファイル単位で区別できます。
ファイルを分割する際は、すべてのOBJで同じ座標基準、同じ数値単位、同じ原点を維持します。OBJ自体には一般的な単位メタデータがないため、書き出し元と読み込み先の単位設定も合わせる必要があります。各ファイルを書き出すたびに中心位置を原点へ移動すると、アップロード後に互いの位置関係が崩れることがあります。
原因2：アップロード先がグループ定義を読み込まない
OBJ内にグループ情報が記録されていても、アップロード先がその情報を利用しない場合があります。OBJへの対応を案内している環境でも、OBJ仕様に含まれるすべての要素、グループ、自由曲面、マテリアル表現へ対応しているとは限りません。OBJは広く使われていますが、実装ごとの対応差がある形式です。([The Library of Congress][1])
頂点と面は読み込むものの、グループ名は無視する処理があります。形状表示には問題がないため、一見すると正常にアップロードできていますが、分類や選択単位だけが失われます。
アップロード先が「o」を個別要素として扱い、「g」を利用しない場合もあります。反対に、「g」を認識し、「o」を分割へ使わない場合もあります。この違いは、同じOBJを複数の環境で開くまで気づきにくい問題です。
また、グループ情報を内部で保持していても、画面上の階層一覧へ表示しないことがあります。表示や配信を効率化するため、複数要素を一つの描画単位へまとめている場合です。このとき、属性確認では名称が残っていても、通常の選択操作では全体が一つに見える可能性があります。
アップロード時に、結合、統合、最適化、単一モデル化、同一材質の集約などを意味する設定が有効になっている場合も確認してください。設定名称は異なっていても、複数要素を一つの処理単位へ変換すると、元のグループ単位で操作できなくなる可能性があります。
原因を確かめるには、小さなテスト用OBJを作る方法が効果的です。離れた位置に二つの簡単な形状または点集合を配置し、それぞれへ異なる「g」、異なる「o」、異なるマテリアル名を設定します。このOBJをアップロードし、名称表示、個別選択、非表示化、属性確認の結果を比べます。
小さなデータでも一つに統合される場合は、データ容量ではなくアップロード先の読み込み仕様に原因がある可能性が高いです。小さなデータでは分かれるのに、大規模データだけ統合される場合は、データ量に応じた最適化や変換条件が適用されている可能性を確認します。
アップロード先がグループ保持に対応していない場合、OBJ内部の記述を修正しても期待する表示にならないことがあります。その場合は、実務で切り替えたい単位ごとにファイルを分割し、アップロード後のフォルダー、レイヤー、タグ、データセット管理など、提供されている分類機能を利用する方法が現実的です。
ただし、細かなグループをすべて別ファイルにすると管理が複雑になります。元データのグループ数をそのまま再現するのではなく、閲覧、計測、比較、更新の際に個別操作する必要がある単位へまとめます。
原因3：変換や軽量化の工程でグループが統合されている
点群OBJを作成するまでに複数の工程を通している場合は、変換や軽量化の途中でグループ情報が失われている可能性があります。元データから直接OBJを書き出さず、中間形式への変換、座標調整、点数削減、面数削減、ノイズ除去などを行っているときに起こりやすい問題です。
変換処理の中には、頂点座標と面の参照だけを読み込み、「g」や「o」を出力しないものがあります。変換後も形状が正しく表示されるため、分類情報の消失に気づかないままアップロードしてしまうことがあります。
軽量化処理では、近接頂点の統合、重複面の削除、ポリゴン数の削減、不要属性の除去などが行われます。異なるグループをまたいで要素を再構成する処理では、元の所属を保持できず、一つのグループへまとめられたり、グループ設定自体が削除されたりする場合があります。
複数の要素を選択して単一オブジェクトへ結合した後にOBJを書き出した場合も、元の分類が失われやすくなります。結合後も色分けが残っていると、構造まで維持されているように見えますが、実際にはマテリアルだけが分かれている場合があります。
座標変換を行う処理にも注意が必要です。既存行の座標値だけを書き換える設計であれば「g」や「o」が残りやすい一方、頂点と要素を新しいOBJとして再構築する処理では、未対応の行が省略されることがあります。
この原因を調べるためには、各工程の前後でグループ名称、オブジェクト名称、要素数を比較します。元データから書き出した直後のOBJ、座標変換後のOBJ、軽量化後のOBJ、アップロード直前のOBJを残し、それぞれから「g」と「o」の名称一覧を抽出します。
例えば、書き出し直後には五十種類のグループ名があり、軽量化後にはdefaultだけになっている場合、軽量化工程が原因だと判断できます。ファイル容量だけを比較しても、グループ情報の消失は発見しにくい点に注意してください。名称行は、頂点や面の大量の記述と比べて容量が小さいためです。
対策として、グループごとに変換や軽量化を行い、処理後も別ファイルとして保存する方法があります。グループ情報を保持できない処理でも、ファイル単位の分類なら維持できます。
一つのOBJとして出力する必要がある場合は、使用する変換ツールが「g」「o」「usemtl」「mtllib」などを保持するかを事前に小規模データで確認します。処理後にグループを再設定できる場合もありますが、統合済みの形状だけから元の所属を完全に復元することは難しいことがあります。
自動変換処理を利用している場合は、未対応行を無条件で捨てる設計になっていないかを確認します。頂点、点、線、面、テクスチャ座標、法線だけでなく、グループ、オブジェクト名、マテリアル参照をどのように扱うかを仕様として決めておくと安全です。
原因4：グループ名の重複や文字の問題が発生している
グループ情報がOBJに残っていても、名称の問題によって期待どおりに識別されないことがあります。特に注意したいのが、異なる部分へ同じ名前が使われている状態です。
元データでは親階層が異なるため区別できていても、OBJでは親子関係が失われ、子要素の名前だけが出力されることがあります。例えば、建物Aと建物Bの両方に「wall」というグループがある場合、同じ名称の要素として扱われる可能性があります。
同名グループは仕様上、同じ名前のグループとして解釈されるのが自然です。元データでは別の場所にある二つの「wall」でも、名前だけをキーに整理する読み込み先では一つの項目へまとめられることがあります。グループ自体が消えたように見えなくても、数が減った場合は名称の重複を確認します。
対策として、親階層がなくても一意に識別できる名称を付けます。「wall」だけではなく、「area01_buildingA_wall」「area02_buildingB_wall」のように、区域、対象、部位などを名前へ含めます。
空白の扱いにも注意が必要です。OBJの「g」行では空白がグループ名同士の区切りとして使われるため、「building wall」を一つの名称として保存したつもりでも、仕様上はbuildingとwallという二つのグループ名として解釈される可能性があります。可搬性を優先する場合は、名称内の空白をアンダースコアへ置き換えます。([Paul Bourke][2])
日本語などの非ASCII文字についても、利用環境によっては文字化けや欠落が起こることがあります。元仕様の保守的な記述ではグループ名に英字や数字を使用する前提が示されており、現代のツールがUTF-8名を扱える場合でも、変換工程やアップロード先まで同じ扱いになるとは限りません。互換性を優先する場合は、半角英数字とアンダースコアで識別名を作り、日本語の表示名は別の管理表やアップロード先の属性で管理します。
大文字と小文字の扱いも統一します。読み込み側や後工程の管理機能によっては「Area01」と「area01」を別名称として扱う場合も、検索や正規化によって同じように扱う場合もあります。命名規則を小文字へ統一するなど、差が出にくい方法を採用します。
斜線、逆向きの斜線、引用符、コロン、セミコロンなどの記号も避ける方が安全です。OBJの解析だけでなく、圧縮ファイル、サーバー上の識別子、データベース登録、URL生成など、周辺処理で置換や拒否が起きる可能性があるためです。
大規模なデータでは、グループ名を目視で確認するのは現実的ではありません。アップロード前に名称一覧を抽出し、重複、空欄、空白、非推奨文字、長すぎる名称、命名規則違反を機械的に検査できる運用を整えると、同じ問題の再発を防ぎやすくなります。
原因5：グループとオブジェクトやマテリアルを混同している
点群OBJの構造を確認するときは、グループ、オブジェクト名、マテリアルを分けて考える必要があります。これらは画面上では似た分類に見えることがありますが、OBJ内では異なる情報です。
グループは「g」、オブジェクト名は「o」、使用するマテリアルは「usemtl」によって示されます。マテリアルの定義は通常、OBJから「mtllib」で参照される別のMTLファイルに記録されます。OBJの「usemtl」に書かれた名前は、MTL内の「newmtl」で定義されたマテリアル名と対応します。テクスチャ画像は、MTL内の「map_Kd」などの記述から参照されるため、OBJ名、MTL名、画像名をすべて同じ文字列にする必要があるわけではありません。各参照関係が正しく解決できることが重要です。([The Library of Congress][1])
元の編集画面で地面が茶色、建物が灰色、設備が青色に分かれている場合、それがグループによる分類とは限りません。一つのオブジェクトに複数のマテリアルを割り当てて色分けしているだけの場合があります。
このデータをアップロードし、MTLやテクスチャが正しく読み込まれなければ、すべてが同じ色で表示されることがあります。利用者から見るとグループが消えたように感じますが、実際に失われたのは色や材質の情報です。
反対に、グループは維持されていても、すべてに同じマテリアルが設定されているため、一つの形状に見えることもあります。階層一覧や個別選択を確認せず、色だけでグループの有無を判断するのは避けてください。
アップロード先が描画効率を優先して、同じマテリアルを使う要素を一つの描画単位へまとめる場合もあります。ただし、描画単位が統合されたことと、論理的なグループ情報が削除されたことは同じではありません。名称、属性、選択、非表示化の各機能でどの単位が維持されているかを確認します。
グループが必要な目的も整理しておきます。色分けだけが目的であれば、マテリアルによる分類で足りることがあります。個別に表示と非表示を切り替えたい、対象別に計測したい、施工区画ごとに更新したい場合は、アップロード先が利用できるグループ、オブジェクト、レイヤー、ファイル単位のいずれかで分割する必要があります。
元データでオブジェクトごとに分かれている場合も、OBJ書き出し時に「o」として保存されるとは限りません。すべてが一つの「o」にまとめられ、内部の「g」やマテリアルだけが分かれる場合があります。
対策として、テスト用データでは異なるグループ名、異なるオブジェクト名、異なるマテリアル名を設定し、アップロード後にどの情報が表示されるかを確認します。三つを意図的に別の名称にすれば、アップロード先がどの定義を採用しているかを判断しやすくなります。
MTLを利用する場合は、OBJの「mtllib」が実際のMTLファイルへ到達できるか、「usemtl」の名前がMTL内の「newmtl」と一致するか、MTLから参照される画像パスが正しいかを確認します。ただし、MTLが正常に読み込まれたことと、グループが維持されたことは別々に検証してください。
グループ消失を切り分ける確認手順
グループが消えたときは、思いついた設定を次々に変更するのではなく、工程ごとに原因を切り分けることが重要です。最初に、元データで期待する分類単位、名称、要素数、座標範囲を記録します。
次に、書き出した直後のOBJを確認します。「g」と「o」の記述が存在するか、名称が期待どおりか、重複していないかを調べます。点群として扱う場合は、点要素の「p」があるのか、頂点「v」だけを独自に点として扱う前提なのかも確認します。
グループ数を確認するときは、「g」行の本数ではなく、各行に記載されたグループ名を解析します。一行に複数名があり得ること、同じ名が再設定され得ること、後続要素が複数グループへ同時所属し得ることを考慮します。
書き出したOBJを別の確認環境へ読み込み、個別のグループとして認識されるかを確認します。ここでグループが表示されるなら、OBJ自体には必要な情報が含まれている可能性が高く、アップロード先の変換や表示機能を重点的に調べられます。
変換や軽量化を行っている場合は、各処理後のOBJについて同じ確認を行います。書き出し直後、座標変換後、軽量化後、アップロード直前というように段階を分け、どこで名称一覧や要素数が変化したかを記録します。
続いて、少量のテストデータをアップロードします。全体データでは処理時間が長く、設定変更の検証に時間がかかります。二つから五つ程度の分類だけを含むOBJを用意すると、グループ、オブジェクト、マテリアルの認識を短時間で確認できます。
テストでは、階層一覧に名称が出るかだけでなく、一つを選択したときに他の要素まで同時に選択されないか、個別に非表示化できるか、属性として名称が残っているかを確認します。名称が複数表示されても、操作単位では統合されている場合があります。
アップロード前後で頂点数、点要素数、線要素数、面数、表示範囲、座標、ファイル容量も比較します。グループ一覧だけが消え、形状が残っている場合と、特定範囲の形状まで欠落している場合では、調査すべき原因が異なります。
一つのOBJに複数グループを含めたテストと、同じ内容を複数OBJへ分割したテストを行う方法も有効です。分割した場合だけ正常に扱えるのであれば、アップロード先がOBJ内部の「g」を操作単位へ変換していない可能性があります。
最後に、確認結果を記録します。使用した書き出し設定、グループ名称、オブジェクト名称、要素数、変換条件、アップロード設定、結果を残しておけば、次回同じ種類のデータを処理するときに再検証する手間を減らせます。
グループを維持してアップロードする実践的な対策
グループ消失を防ぐためには、アップロード直前だけでなく、元データの整理段階から一貫した管理を行うことが大切です。
まず、アップロード後にどの単位で操作したいかを決めます。元データに数百の分類があっても、実際に表示を切り替えるのが地面、構造物、設備の三種類だけであれば、細かなグループをすべて維持する必要はないかもしれません。
反対に、施工区画別、計測日別、点検対象別に個別操作する必要がある場合は、その単位を確実に保持する必要があります。アップロード後の作業から逆算して、必要な分類を決めます。
次に、名称規則を統一します。区域、対象種別、部位、連番などを組み合わせ、各名称が一意になるようにします。名称だけを見て内容が分かり、親階層がなくても重複しない構成が理想です。
書き出し前には、不要な作業用データを削除または除外します。非表示の複製、仮の分類、空のグループ、確認用の形状などが混ざると、出力後の構造が複雑になります。
書き出し設定では、オブジェクト名やグループ名の保持を有効にします。元データのどの分類が「g」と「o」のどちらへ出力されるか、点要素を使う場合は「p」が出力されるかも確認してください。
書き出し後は、アップロード前検査を必須にします。名称一覧、重複の有無、頂点数、点・線・面の要素数、関連するMTLや画像ファイル、座標範囲を確認し、基準を満たしたデータだけをアップロードします。
変換や軽量化が必要な場合は、グループ保持に対応した工程を選びます。対応できない場合は、グループごとに処理して別ファイルとして保存します。
アップロード先で統合設定を変更できる場合は、個別操作を維持できる設定を選びます。ただし、統合を減らすと描画や管理の負荷が増える可能性があるため、大規模データでは実際の端末と回線で動作確認を行います。
アップロード後には、名称表示、個別選択、表示切り替え、位置、縮尺、色、テクスチャを確認します。グループだけに注目すると、書き出し設定の変更によって発生した座標や材質の問題を見落とす可能性があります。
元データ、書き出し直後、変換後、アップロード用の各ファイルは上書きせず保存します。問題が発生した場合に、一つ前の工程へ戻れる状態を保つことが重要です。
大容量の点群OBJを扱うときの分割方法
大容量の点群OBJでは、グループ情報を保持できたとしても、読み込みや表示の負荷が高くなることがあります。一つのファイルへすべての点や面をまとめるより、実務に合った単位で分割した方が安定する場合があります。
代表的な分割単位は、区域、階層、工種、計測日、対象物、施工段階です。どの方法が適切かは、アップロード後に行う作業で決まります。
区域ごとに確認するなら、座標範囲や施工区画で分割します。日ごとの変化を比較するなら、計測日ごとにファイルを分けます。設備単位で点検するなら、対象設備ごとに分けます。
分割後もすべてのファイルで座標基準、数値単位、原点を統一します。個別ファイルを自動的に中心化すると、重ねて表示した際に位置が合わなくなります。読み込み先に大きな座標値への制約がある場合は、共通のオフセット値を管理し、すべての分割ファイルへ同じ変換を適用します。
分割境界にも注意が必要です。対象物の途中で機械的に分割すると、一つの構造物が複数ファイルにまたがり、選択や計測が難しくなります。可能であれば、施工区画や部材境界など、実務上意味のある位置で分けます。
一方、ファイル数を増やしすぎると、アップロード漏れ、版の混在、名称重複、更新対象の間違いが発生しやすくなります。個別操作する必要がない細かなグループは、ある程度まとめる方が管理しやすくなります。
ファイル名には、区域、対象、日付、版番号などを含めます。ただし、長すぎる名称や特殊記号は避け、規則を統一してください。ファイル名とOBJ内部の「g」「o」の名称を対応させておくと、問題発生時に追跡しやすくなります。
管理表には、元データ名、出力ファイル名、含まれる範囲、座標条件、作成日、変換条件、名称一覧、アップロード先の登録名などを記録します。OBJ内部のグループが利用されない環境でも、ファイル単位で内容を追跡できます。
更新時は、変更された範囲だけを書き出して差し替えられるようにします。適切に分割されていれば、毎回全データを変換してアップロードする必要がなくなり、作業時間や誤更新のリスクを抑えられます。
消えたグループを復元するときの考え方
アップロード後にグループが消えた場合、最初にアップロード前のOBJを確認します。OBJ内に期待する「g」や「o」の名称が残っていれば、アップロード設定の見直し、別形式への変換、ファイル分割によって再現できる可能性があります。
アップロード前のOBJから分類情報が消えている場合は、変換前や書き出し前のデータへ戻ります。元データに分類が残っているなら、書き出し設定を変更して再作成する方法が最も確実です。
元データがなく、統合済みのOBJしか残っていない場合、完全な復元は難しいことがあります。グループは形状から必ず判断できる情報ではないためです。
互いに離れている形状であれば、接続していない要素ごとに分離できる場合があります。しかし、接触している部材、同じ場所に重なった点、連続した地表面などは、形状だけでは元のグループ境界を判断できません。
マテリアル、頂点カラー、座標範囲、法線方向、高さなどを利用して再分類できる場合もあります。ただし、これは元のグループを復元するというより、新しい条件で分類し直す作業です。元の分類と一致するとは限らないため、元図、管理表、計測記録などと照合します。
計測日や施工区画ごとの元ファイルが残っているなら、それらを個別に再変換する方法があります。一度結合したOBJを推測で分割するより、結合前のデータから作り直した方が正確です。
修正版をアップロードするときは、既存データをすぐに削除せず、別の版として登録します。旧版と比較し、グループ名、要素数、形状、座標、色、テクスチャに問題がないことを確認してから切り替えます。
復元作業後は、同じ問題を繰り返さないように、元データとアップロード用データの対応関係を記録します。書き出し設定や変換条件も保存しておくと、次回の更新作業を安定させられます。
点群OBJのグループ管理でよくある疑問
グループ名が表示されなくても、形状がすべて残っていれば問題ないと考える人もいます。全体を閲覧するだけであれば、大きな支障がない場合もあります。しかし、個別表示、範囲選択、計測、差分確認、更新が必要な業務では、グループ消失が作業効率へ影響します。
「g」と「o」のどちらを使えばよいかは、アップロード先の対応によって異なります。書き出し時に両方を保存できる場合でも、アップロード先がどちらを表示単位、選択単位、属性として採用するかをテストする必要があります。
日本語のグループ名が必ず使用できないわけではありません。ただし、元仕様の保守的な命名範囲や、複数の変換環境を経由する互換性を考えると、英数字とアンダースコアによる識別名が安全です。日本語の説明は、アップロード後の表示名や別の管理表に記録する方法があります。
圧縮してアップロードしたことが、直接グループ消失につながるとは限りません。正しく圧縮・展開されればOBJのテキスト内容は変わらないためです。ただし、アップロード先が要求するフォルダー構成と異なる場合や、関連するMTLやテクスチャが含まれていない場合は、材質や画像が表示されなくなることがあります。
頂点カラーからグループを復元できるかどうかは、色と分類が一対一で対応している場合に限られます。色が高さ、反射の強さ、撮影条件などを示している場合、元のグループとは一致しません。また、頂点カラーは元のOBJ仕様の中核機能ではなく、拡張的な慣行として扱われるため、読み込み先の対応確認が必要です。([The Library of Congress][1])
グループを増やすと名称や区切りの記述は増えますが、それだけで容量が大幅に増えるとは限りません。ただし、書き出しや分割の方法によって頂点が複製される場合は、容量が増える可能性があります。書き出し前後の頂点数と要素数を比較してください。
グループごとに別OBJへ分割した際に位置がずれる場合は、個別書き出し時に座標原点や単位変換が変わっている可能性があります。すべてのファイルで同じ座標値または同じ共通オフセットを保持し、自動中心化の設定を確認します。
アップロード後に名称を変更できる場合でも、元データ側の名称と対応を取ることが重要です。アップロード先だけで変更すると、次の更新時に元の名称へ戻ったり、どのグループに対応するか分からなくなったりします。
「g」の行数を数えればグループ数が分かるとは限りません。一行に複数名を記述でき、同じ名称を再度設定することもできるためです。正確に検査するには、名称の重複を除いた一覧だけでなく、各点、線、面にどのグループ状態が適用されているかを解析します。
頂点「v」だけを並べたOBJが、すべての環境で点群として表示されるとも限りません。標準の点要素は「p」で頂点を参照します。利用するアップロード先が「p」に対応するか、頂点だけの独自表現を許容するかを小さなファイルで確認してください。
まとめ
点群OBJアップロード後にグループが消える主な原因は、書き出し時にグループ情報が保存されていないこと、アップロード先がグループ定義を利用しないこと、変換や軽量化の工程で統合されること、名称の重複や文字の問題があること、グループとオブジェクト名やマテリアルを混同していることです。
問題が起きたときは、アップロード先の画面だけを見て判断せず、書き出し直後のOBJに「g」や「o」が存在するかを確認します。点を扱う場合は「v」だけなのか、点要素「p」があるのかも確認します。その後、変換前後の名称一覧と要素数を比較し、小規模なテストデータでアップロード先の対応を調べます。
特に、「g」の行数をそのままグループ数とみなさないことが重要です。「g」には複数のグループ名を記述でき、後続要素が複数グループへ属する場合があります。名称抽出、重複確認、要素への適用状態まで含めて検査します。
グループ情報を操作単位として維持できない環境では、実務上必要な単位ごとにOBJを分割する方法が有効です。元データの細かな階層をそのまま再現するのではなく、表示、計測、比較、更新で個別操作する単位に合わせて整理します。
また、OBJだけを原本として管理せず、分類や階層を保持できる元データを保存することが重要です。アップロード用OBJは派生データとして扱い、元データ、書き出し直後、変換後、アップロード用という各段階を残しておけば、グループが消えた工程を特定しやすくなります。
現場で取得した点群を継続的にアップロードする場合は、計測時点から区域名、対象名、日付、座標条件を統一しておくと、後工程での分類や更新が安定します。点群の取得から整理、共有までの流れを効率化する際は、LRTK Phoneを活用した現場計測の方法も確認してみてください。