点群OBJをクラウドやWebビューアへアップロードするとき、形状や点数だけでなく、マテリアル情報の整理状態も読み込みの安定性に影響します。編集作業を繰り返したOBJには、現在の形状では使われていないマテリアル、参照先が存在しないテクスチャ、同じ内容で名前だけが異なる設定などが残りやすいためです。
未使用マテリアルが残っていても、必ずアップロードに失敗するとは限りません。しかし、OBJに付属するMTLファイルが必要以上に複雑になると、アップロード対象の判別、関連ファイルの収集、エラー原因の切り分けに時間がかかります。存在しない画像をMTLファイルが参照している場合は、アップロード後に色や模様が表示されないだけでなく、処理系によっては警告や読み込み停止の原因になることもあります。
特に、点群データをメッシュへ変換した後で不要な部材を削除した場合や、複数のデータを統合してからOBJを書き出した場合は、過去に使用していたマテリアルが残っていないか確認することが重要です。本記事では、点群OBJアップロード前に未使用マテリアルを削るための実務的な手順を、OBJ、MTL、テクスチャ画像の関係から順番に解説します。
点群OBJに未使用マテリアルが残る理由
OBJは、頂点座標、面、テクスチャ座標、法線などをテキストで記録できる3Dデータ形式です。マテリアルの具体的な設定は、一般にOBJ本体とは別のMTLファイルへ保存されます。OBJ内のmtllibという記述でMTLファイルを指定し、usemtlという記述で各面や要素に適用するマテリアル名を指定する構成がよく使われます。
MTLファイルでは、newmtlに続く名称によって一つのマテリアルが定義されます。色、透明度、反射に関係する値のほか、map_Kdなどの記述によってテクスチャ画像が指定されることがあります。このため、テクスチャ付きOBJをアップロードするときは、OBJだけではなく、MTLと画像ファイルの対応関係を保つ必要があります。
未使用マテリアルが残る代表的な原因は、編集途中でオブジェクトや面を削除したものの、マテリアル定義までは削除されなかったことです。多くの3D編集環境では、面からマテリアルの割り当てを外しても、マテリアル自体はデータ内に保持されます。そのままOBJを書き出すと、使われていない設定がMTLに含まれることがあります。
複数の点群やメッシュを統合した場合にも、未使用マテリアルが増えやすくなります。それぞれのデータに同じような色や画像が設定されていても、内部では異なるマテリアル名として扱われる場合があります。統合後に一部の形状だけを残すと、削除した形状に割り当てられていたマテリアルが残存します。
同じデータを繰り返し複製した場合は、元の名称に連番や識別文字が追加されたマテリアルが増えることもあります。見た目が同じであっても、内部では別の設定として存在するため、書き出されたMTLが長くなり、どれが必要な定義なのか分かりにくくなります。
点群からメッシュを生成した後、簡略化、穴埋め、分割、結合などを行った場合も注意が必要です。処理の過程で新しい面が作られたり、古い面が消えたりするため、編集前のマテリアル構成と最終形状の割り当てが一致しなくなることがあります。見た目だけを確認して問題がないように見えても、ファイル内部には不要な定義が残っている可能性があります。
一方、点だけで構成されたOBJでは、MTLや画像を使用しない場合もあります。頂点行に色情報を追加する独自の表現が使われることもありますが、頂点色の扱いは読み込み側によって異なります。点群OBJにMTLが付属していても、アップロード先が点のマテリアル表示に対応していなければ、MTLを添付する意味がないことがあります。
そのため、未使用マテリアルを削除する作業では、単にMTLを短くするのではなく、最終的なアップロード先で何を表示したいのかを先に整理することが重要です。色付きの面を表示したいのか、画像テクスチャを表示したいのか、座標を持つ点だけを登録したいのかによって、残すべきファイルが変わります。
未使用マテリアルを削除する前に確認したいこと
最初に確認したいのは、対象OBJが点だけで構成されているのか、面を持つメッシュとして構成されているのかという点です。OBJの拡張子が同じでも、内容は大きく異なります。頂点を示す行だけが中心であれば点群に近い構造ですが、面を示す行が多数含まれていればメッシュとして扱われています。
メッシュを含むOBJでは、マテリアルが面の外観に関係している可能性があります。不要と判断して削除したマテリアルが、実際には小さな面、内部面、離れた部材などへ割り当てられていることもあります。表示画面で見えないからといって、未使用であるとは限りません。
次に、アップロード先が受け付ける構成を確認します。OBJ単体だけを読み込む仕組みもあれば、MTLと画像を含む複数ファイルの登録に対応している仕組みもあります。複数ファイルを一つの圧縮ファイルとして登録する方式や、関連ファイルを同時に選択する方式もあります。
アップロード先がMTLに対応していない場合、マテリアルを整理しても表示には反映されない可能性があります。その場合は、OBJ本体の軽量化や点数削減を優先した方が効果的です。逆に、テクスチャ表示を必要とする場合は、MTLと画像の関係を崩さないことが最優先になります。
画像ファイルの利用条件も確認が必要です。画像形式、縦横寸法、一辺の最大サイズ、ファイル容量、透過情報への対応などは、利用する環境によって異なります。元の3D編集画面では表示できても、アップロード先では未対応という場合があります。
OBJ、MTL、画像のファイル名に空白、全角文字、特殊記号が含まれている場合は、整理作業と同時に見直すと安全です。すべての環境で問題になるわけではありませんが、ファイル参照の解釈差を減らすためには、半角英数字と分かりやすい区切り記号を中心にした名称が扱いやすくなります。
大文字と小文字の違いにも注意します。ある環境では同じ名前として扱われても、別の環境では異なるファイルとして判断されることがあります。MTLに記載された画像名と、実際の画像ファイル名は、大文字と小文字を含めて一致させることが重要です。
さらに、マテリアル整理の目的を明確にします。アップロードエラーを解消したいのか、ファイル容量を減らしたいのか、管理しやすい構成にしたいのかによって、作業範囲が変わります。MTLのテキスト量は、一般に高密度点群の頂点データや高解像度画像と比べれば小さいため、定義を数個削るだけでは容量が大きく減らないこともあります。
容量削減を目的とする場合は、未使用マテリアルに加えて、未参照の画像を削除することが重要です。特に高解像度画像が複数残っていると、OBJ本体より画像の合計容量が大きくなることがあります。未使用画像を整理すれば、アップロード時間や保存容量を減らせる可能性があります。
手順1 元のOBJ関連ファイルを複製して保管する
未使用マテリアルを削除する前に、元データ一式を複製します。OBJ、MTL、テクスチャ画像だけでなく、編集に使用した元の3Dデータがある場合は、そのファイルも変更前の状態で保管します。
マテリアル整理では、見た目に影響しないと思って削除した設定が、後から必要だったと判明することがあります。特に、細かな部材、裏面、内部面、透明部分などは、通常の視点では確認しにくいためです。元データを残しておけば、削除前の状態へ戻して割り当てを再確認できます。
複製先は、作業用と保存用を明確に分けます。元データを直接編集すると、上書き保存によって復元が難しくなる可能性があります。たとえば、元データを保管するフォルダと、整理後のアップロード用フォルダを分けておくと、ファイルの混在を防ぎやすくなります。
保存時には、OBJとMTLだけを残すのではなく、関連する画像もまとめて保管します。MTLに指定されている画像が不足していると、元の表示状態を再現できません。どの画像が使われているか判断できない段階では、先に削除せず、対象フォルダを丸ごと複製する方が安全です。
ファイル名に版を示す情報を付ける場合は、用途が分かるようにします。単に「新しい」「最終」といった名称を付けるだけでは、後から違いを判断しにくくなります。変更前、マテリアル整理後、アップロード確認済みなど、状態を区別できる名称にすると管理しやすくなります。
座標情報を持つ点群OBJでは、マテリアル整理と同時に形状編集を行わないことも重要です。複数の変更を一度に行うと、アップロード後に位置や表示が変わった場合、原因がマテリアルなのか座標変換なのか分からなくなります。最初は未使用マテリアルだけを整理し、そのほかの変更は別の工程として進めると安全です。
元データの保管後は、作業用フォルダ内に必要と思われるファイルを集めます。この段階では不要画像を確定できていなくても問題ありません。まずOBJが参照しているMTLを確認し、その次にMTLが参照している画像を確認する順番で整理します。
手順2 OBJから実際に使われているマテリアルを調べる
次に、OBJ内で実際に使用されているマテリアル名を調べます。3D編集環境でマテリアルの使用状況を確認できる場合は、各マテリアルがどの面へ割り当てられているかを表示します。割り当て面数がゼロであることを確認できれば、未使用である可能性が高いと判断できます。
ただし、編集環境上の表示だけで判断せず、書き出されたOBJの内容も確認することが重要です。編集データ内では削除済みでも、書き出し設定や内部データの状態によってMTLへ残ることがあります。反対に、編集画面には存在していても、OBJには書き出されていない場合もあります。
OBJをテキストとして確認するときは、mtllibとusemtlを探します。mtllibの後ろには、参照するMTLファイル名が記載されます。複数のMTLを参照する構成も考えられるため、一つだけだと決めつけずに確認します。
usemtlの後ろに記載されている名称は、その後に続く面や要素へ適用するマテリアルを示します。OBJ全体で登場するusemtlの名称を洗い出せば、実際に参照されているマテリアルの候補を把握できます。
MTL側では、newmtlの後ろに定義名が記載されています。OBJのusemtlに登場する名称と、MTLのnewmtlに登場する名称を照合します。MTLに定義されているものの、OBJのusemtlから一度も参照されていない名称は、未使用マテリアルの候補です。
名称の照合では、空白、記号、大文字と小文字に注意します。見た目が似ていても、文字列が一致していなければ別の名称として扱われます。名前の末尾に不要な空白が含まれている場合や、文字コードの違いによって正しく対応しない場合もあります。
OBJ内にusemtlが存在しない場合は、MTLが実際には使用されていない可能性があります。ただし、読み込み側の独自処理や、書き出し時の特殊な構成が使われている可能性もあるため、すぐにMTLを削除するのではなく、複製データで表示確認を行います。
同じマテリアル名がOBJ内に何度も登場すること自体は、異常とは限りません。形状の途中で別のマテリアルへ切り替え、その後に再び同じマテリアルへ戻る構成では、同一名称のusemtlが複数回記載されます。重要なのは登場回数ではなく、MTLの定義と正しく対応しているかどうかです。
複数のマテリアルが同じ画像を参照している場合もあります。この場合、一方のマテリアルが未使用でも、画像自体は別の使用中マテリアルから参照されている可能性があります。マテリアルを削除したからといって、関連画像も直ちに削除できるとは限りません。
実務では、使用中のマテリアル名、各マテリアルが参照する画像名、削除候補のマテリアル名を記録してから作業すると安全です。本文で箇条書きを使わずに説明すると、まずOBJ側の使用名を確定し、次にMTL側の定義名を照合し、最後に画像参照をたどるという順番です。この順序を守れば、必要な画像を誤って削除する可能性を下げられます。
点群OBJが多数の部材に分かれている場合は、見えない場所へ小さな面が残っていないか確認します。遠く離れた座標に孤立した面があると、通常の表示範囲では見つけにくいことがあります。マテリアルの割り当て面を選択し、対象箇所へ表示を移動できる機能がある場合は活用します。
手順3 未使用マテリアルと不要な画像を削除する
使用中のマテリアルを確認できたら、未使用マテリアルを削除します。編集元データがある場合は、3D編集環境上で不要なマテリアルを削除してからOBJを書き出し直す方法が基本です。MTLを直接編集するより、形状とマテリアルの対応を保ちやすいためです。
削除前には、対象マテリアルの割り当て数がゼロであることを再確認します。割り当て数を確認できない場合は、そのマテリアルだけを一時的に目立つ色へ変更し、表示中の形状に変化がないか確認する方法もあります。ただし、確認用の変更を残したまま書き出さないように注意が必要です。
編集環境によっては、画面上からマテリアルを削除しても、未使用の内部データとして残る場合があります。その場合は、未使用データを整理するための機能を利用します。名称や操作方法は環境によって異なりますが、未割り当てのマテリアル、画像、テクスチャ設定などをまとめて除去する処理が用意されていることがあります。
自動整理機能を利用するときは、対象範囲を確認します。マテリアルだけを削除するつもりでも、未使用と判断された画像、補助データ、非表示オブジェクトなどが同時に削除される場合があります。元データを複製したうえで実行し、処理後に表示を比較します。
MTLを直接編集する場合は、未使用のnewmtlから次のnewmtlの直前までを一つの定義として扱います。定義の途中だけを削除すると、別のマテリアルの設定と混ざる可能性があります。空行やコメントが含まれていても、どのnewmtlに属する記述なのかを確認してから削除します。
未使用マテリアルに画像指定が含まれている場合は、その画像がほかのマテリアルから参照されていないか調べます。ほかの使用中マテリアルでも同じ画像を参照しているなら、画像は残す必要があります。参照元が削除対象のマテリアルだけであることを確認できた画像は、アップロード用フォルダから除外できます。
画像名だけで判断するのは危険です。似た名称の画像が複数あり、実際に参照されている画像と不要画像を取り違える可能性があります。MTL内の記述と実際のファイル名を一つずつ照合します。
画像の重複も確認します。同じ内容の画像が異なる名前で複数保存されている場合、使用中マテリアルがどちらを参照しているかを確定します。内容が同じだからといって片方を削除すると、MTLの参照先が失われる可能性があります。重複を統合する場合は、MTLの画像名も同時に変更します。
複数のマテリアルが実質的に同じ設定である場合は、統合を検討できます。ただし、単なる未使用削除よりも影響範囲が広くなります。統合するには、OBJ内のusemtl名称を一つにそろえ、MTL側の定義も整理する必要があります。最初の作業では未使用マテリアルだけを削除し、重複統合は別工程として実施した方が原因を切り分けやすくなります。
点群の見た目が頂点色で表現されている場合は、MTLや画像を削除しても色が残ることがあります。一方、面へ画像を貼り付けている場合は、MTLやテクスチャ座標が欠けると外観を再現できません。削除後は、色がどの情報から生成されているのかを確認します。
不要画像を削除した結果、アップロード用フォルダ内には、OBJ、実際に参照されるMTL、使用中マテリアルから参照される画像だけが残る状態を目指します。説明書、確認用画像、古い書き出しファイルなどは、同じ圧縮ファイルへ入れず、別の管理フォルダへ移します。
手順4 MTLの記述とファイル参照を整理する
未使用マテリアルを削除した後は、MTL全体の記述を確認します。未使用部分を削除しても、使用中の定義に誤った画像パスや存在しないファイル名が残っていれば、アップロード後の表示問題は解消しません。
最初に、OBJのmtllibに記載されたMTL名と、実際のMTLファイル名を一致させます。拡張子を含めて確認し、大文字と小文字もそろえます。OBJを書き出した後にMTLの名前だけを変更した場合は、OBJ内の参照名も変更する必要があります。
次に、MTL内の画像参照を確認します。map_Kdなどに記載された画像名が、アップロード用フォルダ内の実ファイルと一致しているかを調べます。ほかの画像指定が使われている場合も、同じように参照先を確認します。
画像参照に端末内の絶対パスが残っている場合は注意が必要です。作業端末では表示できても、クラウド側から同じ場所を参照することはできません。ドライブ名や利用者固有のフォルダから始まるパスが記載されている場合は、画像をOBJやMTLと同じフォルダへ集め、相対的に解決できる記述へ整理します。
フォルダ階層を使う場合は、アップロード方法が階層構造を保持できるか確認します。圧縮ファイルで階層を保てる場合でも、読み込み側が下位フォルダの画像参照に対応していない可能性があります。対応状況が不明なときは、OBJ、MTL、画像を同じ階層へ配置する構成が比較的分かりやすくなります。
ファイル名の空白や特殊記号は、可能であれば整理します。名称変更後はMTL内の参照も必ず更新します。画像ファイルだけ名前を変えてMTLを修正し忘れると、テクスチャが読み込まれません。
MTL内に不要な空行やコメントが残っていても、通常は大きな問題になりません。しかし、整理の目的が保守性の向上であれば、意味の分からない古いコメントや重複した設定を見直す価値があります。ただし、読み込み環境によって解釈が異なる可能性がある設定を、根拠なく削除することは避けます。
透明度に関係する設定が複数記載されている場合は、読み込み側によって解釈が変わることがあります。表示に透明表現が必要でないなら、編集元で不透明な状態へ統一して再書き出しする方法もあります。直接編集する場合は、変更前後の表示を比較し、意図しない半透明や消失が起きていないか確認します。
マテリアル名も整理対象です。極端に長い名称、空白を多数含む名称、特殊文字を含む名称は、簡潔な半角英数字へ変更すると管理しやすくなります。ただし、MTLのnewmtlだけを変更してはいけません。OBJ内の対応するusemtlも同じ名称へ変更する必要があります。
文字コードの扱いにも注意します。日本語名を含むOBJやMTLがすべての環境で同じように処理されるとは限りません。アップロード時の互換性を重視する場合は、マテリアル名とファイル名を半角英数字中心に整えると、文字化けによる参照不一致を避けやすくなります。
MTLを編集したら、定義ごとにnewmtlが存在し、その後に設定が続いていることを確認します。削除作業によって、画像指定だけが定義の外へ残っていないか、使用中のnewmtl行を消していないかを見直します。
最後に、OBJ内で使用されているすべてのusemtl名称について、MTL側に対応するnewmtlが存在するか確認します。また、MTL側に残したすべてのnewmtl名称が、本当にOBJから参照されているかを再度確認します。この双方向の照合によって、定義不足と未使用定義の両方を発見できます。
手順5 再書き出し後にテストアップロードする
整理作業が終わったら、編集元からOBJを再書き出しします。直接MTLを編集した場合でも、可能であれば3D編集環境へ読み込み直し、形状と外観を確認してからアップロードします。
再書き出し時には、必要な項目だけを有効にします。面を持つデータでテクスチャを表示する場合は、マテリアル、テクスチャ座標、法線などの出力条件を確認します。点だけをアップロードする場合は、不要な面、法線、テクスチャ情報を含めない構成が適していることもあります。
ただし、情報を減らせば必ず良いとは限りません。アップロード先が表示に必要とする項目を削除すると、色が消える、陰影がおかしくなる、面が表示されないといった問題が起きます。利用環境の対応仕様に合わせて判断します。
再書き出し後は、作業前と作業後のファイル構成を比較します。MTL内のマテリアル数が減っているか、不要画像が除外されているか、OBJが正しいMTLを参照しているかを確認します。
ファイル容量も比較します。未使用画像を削除した場合は、全体容量が減少していることを確認できます。一方、MTLの定義だけを削除した場合は、容量差が小さいことがあります。容量がほとんど変わらなくても、ファイル構成が明確になり、エラー原因を追いやすくなる点には意味があります。
ローカル環境での確認では、OBJを新しい作業環境へ読み込みます。編集中のデータをそのまま表示するだけでは、外部ファイルの参照切れに気付けないことがあります。一度編集環境を閉じるか、別の読み込み画面を使い、書き出したOBJから表示を再現できるか確認します。
可能であれば、アップロード用フォルダを別の場所へコピーしてから読み込みます。元の画像保存場所に依存している場合、同じ端末内では誤った絶対パスでも画像が表示されることがあります。フォルダを移動して表示できれば、必要な関連ファイルが正しく集められている可能性が高まります。
テストアップロードでは、最初から本番データを公開せず、確認用の領域や限定公開の状態で登録します。アップロード完了だけでなく、処理後の表示まで確認します。アップロード処理が成功しても、テクスチャ変換や表示生成の段階で問題が起きることがあるためです。
表示確認では、全体形状、色、画像の向き、透明部分、裏面、離れた部材を確認します。視点を回転させ、近距離と遠距離の両方で見ます。マテリアルを削除した結果、特定方向からだけ面が見えなくなっていないかも確認します。
複数のマテリアルを使用している場合は、それぞれの外観が残っているか確認します。一つのマテリアルだけが正しく、ほかが単色表示になる場合は、画像参照や名称対応を見直します。
エラーが出た場合は、整理前のファイルと整理後のファイルを比較します。変更点を未使用マテリアルの削除に限定していれば、原因を絞り込みやすくなります。座標変換、点数削減、面の修復などを同時に実行すると、どの変更が影響したのか分かりにくくなります。
テストに成功したら、確認済みデータとして別名で保存します。本番アップロードに使ったOBJ、MTL、画像の組み合わせをそのまま保管し、後から同じデータを再登録できる状態にしておきます。
未使用マテリアル削除で起こりやすい失敗
最も多い失敗は、未使用だと思ったマテリアルが実際には一部の面へ割り当てられていたケースです。非常に小さい面、内側の面、遠く離れた面などは、通常の表示では発見しにくくなります。削除前に割り当て面を選択し、対象位置を確認することが大切です。
次に多いのが、マテリアルと同時に必要な画像を削除する失敗です。一つの画像を複数のマテリアルで共有している構成では、未使用マテリアルを削除しても画像は残す必要があります。画像ごとに参照元を確認しなければなりません。
MTLだけを整理し、OBJ側のusemtlを確認しないことも問題になります。MTLから定義を削除したのに、OBJがその名称を参照したままだと、読み込み側は対応する設定を見つけられません。既定色で表示されることもあれば、警告や読み込み失敗につながることもあります。
反対に、OBJ内のマテリアル名だけを変更し、MTL側を変更し忘れる失敗もあります。マテリアル名はOBJとMTLの間を結ぶ識別子です。両方を完全に一致させる必要があります。
画像ファイル名を整理した後、MTLの記述を更新し忘れるケースもあります。特に、空白や日本語を含む名称から半角英数字へ変更したときに起こりやすい問題です。ファイル名の変更は、参照元の変更と一組で実施します。
絶対パスが残ったままアップロードする失敗もあります。作業端末では画像が表示されるため、問題に気付きにくい点が特徴です。別のフォルダへ移動して読み込み直す確認が有効です。
拡張子の大文字と小文字が一致していない場合も注意が必要です。作業環境では読み込めても、アップロード先では別ファイルとして判断される可能性があります。MTLの記述と実ファイル名は、文字単位でそろえます。
未使用マテリアルを削除した結果、マテリアル番号や並び順が変わり、別の設定が割り当てられることを心配する担当者もいます。OBJとMTLでは一般に名称で対応するため、名称が正しく維持されていれば、単純な定義順の変更だけで別のマテリアルになるとは限りません。ただし、編集環境の内部では番号管理が使われる場合もあるため、再書き出し後の表示確認は必要です。
ファイル容量を減らす目的でMTLだけを編集し、期待したほど軽くならないこともあります。高密度な点群OBJでは、容量の大部分を頂点行が占めます。テクスチャ付きメッシュでは、画像ファイルが大きな割合を占めることがあります。容量削減が主目的なら、未使用マテリアル削除に加え、不要画像、過剰な画像解像度、点数、面数も確認します。
整理作業後に元データを上書きしてしまう失敗も避けなければなりません。アップロード後に一部の色が必要だと判明しても、元のマテリアルや画像を失っていると復元に時間がかかります。変更前データとアップロード用データを分けて保管します。
大容量の点群OBJを効率よく整理する方法
大容量の点群OBJでは、ファイルを開くだけでも時間がかかります。マテリアル整理のために何度も読み込みと書き出しを繰り返すと、確認作業が長期化します。そのため、最初に作業範囲を決め、同じ確認を繰り返さない運用が重要です。
まず、OBJが本当にMTLを参照しているか確認します。mtllibがなく、usemtlも存在しない場合は、マテリアル整理より点群本体の確認を優先できます。付属しているMTLが過去の書き出しで残っただけなら、複製環境でMTLを除外して読み込み結果を比較します。
次に、OBJ内で使われているマテリアル名を抽出します。大容量ファイルを一般的な編集画面で開くと動作が重くなる場合は、大きなテキストを扱える確認環境や、文字列を検索できる処理を利用します。必要なのは、すべての頂点を目視することではなく、mtllibとusemtlの出現状況を確認することです。
MTLはOBJより小さいことが多いため、先に全定義を確認し、使用中と未使用の候補を整理します。その後、OBJ側の参照を照合すれば、確認の順番を単純化できます。
案件ごとにファイル構成のルールを決めることも有効です。OBJ、MTL、画像を一つの案件フォルダに集め、アップロード用データには必要ファイルだけを入れます。元画像、加工前画像、確認用画像、報告書用画像などを同じフォルダへ入れないようにします。
マテリアル名の付け方も統一します。用途、対象、連番などを組み合わせ、同じ名称を繰り返し使わないようにします。ただし、名称を長くしすぎると管理しにくくなるため、簡潔で意味が分かる形式にします。
書き出し前のチェックを定型化すると、未使用マテリアルの蓄積を防げます。形状編集が終わった段階で未割り当てマテリアルを整理し、ファイル名を整え、関連画像だけを収集し、その後にOBJを書き出します。アップロード直前に初めて整理するより、修正範囲を小さくできます。
複数担当者で作業する場合は、誰がマテリアル整理を行い、誰がアップロード後の表示を確認するかを決めます。整理担当者と確認担当者が同じでも構いませんが、確認項目を記録しておくことが重要です。
点群OBJを分割してアップロードする場合は、分割単位ごとに必要なマテリアルと画像を整理します。全体で一つのMTLを共有すると、一部のOBJには不要な定義が大量に含まれることがあります。分割後の各OBJが参照する設定だけを残せば、ファイル構成を理解しやすくなります。
ただし、同じ画像を複数の分割データで使用する場合は、各アップロード単位へ画像を含める必要があるか確認します。クラウド上の共通画像を参照できるとは限りません。アップロード単位ごとに自己完結した構成を作る方が、再登録や引き継ぎを行いやすくなります。
大容量データのテストでは、最初に一部分だけを抽出した確認用OBJを作る方法もあります。マテリアル名、MTL、画像の構成を同じにし、点数や面数だけを減らしたデータでアップロード動作を確認します。参照関係に問題がなければ、本番データの処理へ進みます。
ただし、確認用データに使用中のすべてのマテリアルが含まれていなければ、未確認の設定が残ります。テスト用OBJには、各マテリアルが割り当てられた面を少なくとも一つずつ含めると、全体の表示を確認しやすくなります。
アップロード前に実施したい最終確認
アップロード前には、OBJ、MTL、画像の三つの階層で確認します。OBJでは、参照するMTL名と使用マテリアル名を確認します。MTLでは、使用マテリアルの定義と画像参照を確認します。画像では、実ファイルの存在、名称、形式、容量を確認します。
OBJ内にあるusemtl名称が、すべてMTL内に存在していることを確認します。また、MTLに残したnewmtl名称がOBJから参照されていることも確認します。前者は定義不足を防ぎ、後者は未使用マテリアルの残存を防ぐ確認です。
画像参照では、MTLに記載されたすべての画像がアップロード対象に含まれていることを確認します。反対に、アップロード用フォルダに入っている画像が、本当にMTLから参照されているかも確認します。参照されない画像は、元データの保管場所へ移します。
ファイル名は、OBJ内の記述、MTL内の記述、実ファイルの三者で一致させます。大文字と小文字、拡張子、空白、記号の違いを見落とさないようにします。
ローカル表示では、アップロード用フォルダだけを使ってOBJを読み込みます。元の編集フォルダに残っている画像を参照していないことを確かめるため、別の場所へコピーして確認するとより安全です。
点群やメッシュの位置も確認します。マテリアル整理だけを行ったつもりでも、再書き出し設定によって座標、単位、軸方向、原点が変わる可能性があります。整理前後で代表点の座標や全体の位置関係が変わっていないかを確認します。
面を持つOBJでは、面数、法線、テクスチャ座標が必要に応じて出力されているか確認します。点だけのOBJでは、不要な面情報が追加されていないか、頂点数が変わっていないかを確認します。
アップロード後は、処理完了の表示だけで判断せず、実際のビューアでデータを開きます。全体が表示されるか、色や画像が正しいか、視点移動で欠ける面がないかを確認します。
公開範囲や共有権限を設定できる環境では、表示確認が終わるまで限定的な状態にしておくと安全です。意図しない表示状態のデータを外部へ共有することを防げます。
確認が完了したら、使用したファイル一式を保存します。後から差し替えや再アップロードが必要になった場合に、同じ構成を再現できるようにします。整理前データ、整理後データ、アップロード確認済みデータを区別して保管すると、変更履歴を追いやすくなります。
まとめ
点群OBJアップロード前に未使用マテリアルを削除する作業は、単にMTLの行数を減らすことではありません。OBJがどのマテリアルを参照し、そのマテリアルがどの画像を参照しているかを順番に確認し、必要なファイルだけで完結する構成を作ることが目的です。
最初に元データを複製し、OBJ内のmtllibとusemtlを確認します。次に、MTL内のnewmtlと照合し、OBJから参照されていない定義を未使用候補として特定します。その後、不要なマテリアルを削除し、ほかの使用中マテリアルから参照されていない画像だけを除外します。
整理後は、MTLの画像パス、ファイル名、大文字と小文字、フォルダ階層を見直します。再書き出ししたOBJを別の場所から読み込み、アップロード用フォルダだけで外観を再現できるか確認することが重要です。
未使用マテリアルの削除だけで、点数の多いOBJ本体が大幅に軽くなるとは限りません。しかし、不要画像を除外できれば、データ全体の容量を削減できる可能性があります。また、ファイル構成が明確になるため、テクスチャが表示されない場合やアップロードに失敗した場合の原因を切り分けやすくなります。
点群OBJのアップロードを安定させるには、マテリアル整理だけでなく、座標、単位、点数、面数、ファイル名、関連ファイルの不足も併せて確認する必要があります。まずは今回の5つの手順でアップロード用データを整理し、確認済みのOBJ、MTL、画像を一つの組み合わせとして管理してください。
現場で取得した点群を効率よくクラウドへ登録し、位置情報を保ったまま確認する運用を検討している場合は、次にLRTK Phoneの活用方法をご確認ください。