点群OBJで複数MTLを指定すると材質が入れ替わる理由
点群OBJをアップロードした後、地面に設定した色が構造物へ表示されたり、異なる部材のテクスチャが入れ替わったりすることがあります。編集時には正しく表示されていたのに、別の閲覧環境やアップロード先でだけ異常が起きる場合は、OBJの形状そのものではなく、OBJとMTLの関連付けに問題がある可能性があります。
OBJは、頂点座標や面、線、点、グループなどの形状情報をテキスト形式で記録できるファイルです。一方、色や透明度、テクスチャ画像などの材質情報は、一般にMTLという別ファイルへ記録されます。OBJ内には参照するMTLの名前と、各形状に割り当てる材質名が書かれています。
一つのOBJから複数のMTLを参照すると、材質名や画像名が重複する可能性が高くなります。また、複数のMTLを読み込む順番や、同じ名前の材質が見つかった場合の処理は、閲覧環境によって異なることがあります。そのため、同じファイル一式を使っていても、ある環境では正しく見え、別の環境では材質が入れ替わることがあります。
点群 OBJ アップロードで材質の異常が発生した場合、画面上の見た目だけで原因を判断するのは困難です。テクスチャ画像が見つからないために別の色へ置き換えられている場合もあれば、同名材質の上書きによって、本当に異なる材質定義が選択されている場合もあります。
また、材質が入れ替わっているように見えても、実際には一方の材質が透明になって背後の面が見えていることや、面の向きが反転して別の面が表示されていることもあります。したがって、OBJ、MTL、画像ファイル、形状構成を順番に分けて確認する必要があります。
原因を効率よく特定するには、最初にOBJとMTLの仕組みを理解し、名称、参照先、適用範囲、アップロード後のファイル配置を一つずつ照合することが重要です。
OBJとMTLの関連付けを理解する
OBJでは、一般にmtllibという記述を使って参照するMTLファイルを指定します。OBJ内にmtllib material_a.mtlと書かれていれば、そのOBJはmaterial_a.mtlというファイルから材質定義を読み込もうとします。
複数のMTLを利用するOBJでは、mtllibが複数行に分かれていることがあります。一つのmtllib行に複数のファイル名が並ぶ構成もあります。ただし、複数MTLの記述方法や読み込み順については、すべての閲覧環境が同じように処理するとは限りません。
OBJ内で具体的な材質を割り当てるときには、一般にusemtlという記述が使われます。たとえばusemtl ground_surfaceと書かれていれば、その後に続く面などへground_surfaceという名前の材質が適用されます。次のusemtlが現れるまで、同じ材質が継続して使われる構成が一般的です。
一方、MTLではnewmtlという記述に続けて材質名を定義します。OBJ内のusemtl ground_surfaceに対応させるには、参照されるMTL内にnewmtl ground_surfaceという定義が必要です。
重要なのは、OBJとMTLの関連付けが材質名によって行われる点です。OBJ側で一番目に書かれたusemtlが、MTL側の一番目のnewmtlへ自動的に対応するわけではありません。文字列として同じ材質名を持つ定義が参照されます。
そのため、OBJ内のusemtlとMTL内のnewmtlで一文字でも違いがあれば、正しい材質を取得できない可能性があります。大文字と小文字、半角と全角、ハイフンとアンダースコア、数字と英字の見間違いにも注意が必要です。
複数のMTLに同じnewmtl名が存在すると、OBJ側のusemtlだけでは、どちらの定義を意図しているのかを明確に区別できません。一つ目のMTLで青色に設定されたmaterial_01と、二つ目のMTLで茶色に設定されたmaterial_01があれば、読み込み側がどちらを採用するかによって表示結果が変わります。
この仕組みを理解すると、複数MTLで材質が入れ替わる問題は、形状と材質が番号順にずれたのではなく、同名の定義が競合した結果である可能性が高いと分かります。
複数MTLで表示結果が変わりやすい主な原因
複数MTLで材質が入れ替わる代表的な原因は、材質名の重複です。複数のMTLに同じnewmtl名が含まれていると、読み込み側が先に見つけた定義を採用する場合もあれば、後から読み込んだ定義で上書きする場合もあります。
この状態では、MTLの読み込み順を変えるだけで表示される色や画像が変化することがあります。編集環境とアップロード先で読み込み順が異なれば、編集時には正常だったデータがアップロード後に崩れます。
次に考えられるのが、OBJ内のusemtlの位置ずれです。usemtlは、その行より後に記述される面などへ材質を適用します。新しいオブジェクトやグループが始まっても、usemtlが書かれていなければ直前の材質が継続することがあります。
たとえば地面の面を記述した後にusemtl groundが設定され、そのまま構造物の面が続いている場合、構造物用のusemtlが書かれていなければ、構造物にも地面の材質が割り当てられます。この状態は、材質が入れ替わったように見える原因になります。
ファイル名やパスの不一致も影響します。OBJが指定するMTLを読み込めなかった場合、閲覧環境は既定材質を使うことがあります。また、MTLから参照するテクスチャ画像が見つからなければ、画像の代わりにMTL内の単色値が表示される場合があります。
複数の材質が同じ単色値を持っていると、テクスチャの読み込みに失敗した際に、異なる材質がすべて同じ見た目になります。利用者には材質が統合されたり入れ替わったりしたように見えますが、実際には画像だけが欠落しています。
異なるフォルダに同名の画像が保存されている場合も注意が必要です。作業環境ではフォルダの違いによって区別できても、アップロード時に一つの階層へまとめられると同名ファイルが競合します。その結果、片方の画像だけが残り、複数の材質が同じ画像を参照することがあります。
再アップロード時に古いMTLや画像が残っていることもあります。同じファイル名で上書きを繰り返すと、閲覧環境やアップロード先の一時保存によって、修正前のファイルが使われる場合があります。OBJを修正したのに表示が変わらないときは、古い関連ファイルが残っていないかを疑う必要があります。
さらに、点群OBJの構成によっては、MTL自体が期待どおりに扱われないことがあります。面を持つメッシュと、頂点だけで構成された点群では、材質適用の対応状況が異なるためです。面用の材質指定を点要素へ適用できない閲覧環境では、OBJとMTLの記述が正しくても材質が反映されません。
確認1：mtllibとusemtlの対応を確認する
最初に確認するのは、OBJ内のmtllibとusemtlです。材質の表示異常が発生したときは、OBJをテキストとして開き、mtllibとusemtlを検索します。
まず、OBJ内に書かれているすべてのmtllibを確認します。指定されたMTLファイルが、実際のアップロード用フォルダに存在するかを照合します。似た名前のファイルがあるだけでは不十分です。拡張子、大文字と小文字、記号を含めて一致している必要があります。
複数のmtllibがある場合は、その記述順も確認します。材質名が重複していなければ順番の影響を受けにくいものの、同名材質がある場合は、読み込み順によって採用される定義が変わる可能性があります。
次に、OBJ内のusemtlを抽出します。使用されているすべての材質名について、参照されるMTL内に同じ名前のnewmtlが存在するかを確認します。
OBJにusemtl wall_surfaceがあるのに、MTL側がnewmtl wall-surfaceとなっていれば、両者は同じ材質として参照されない可能性があります。アンダースコアとハイフンの違いは目視で見落としやすいため、文字列をコピーして比較すると安全です。
材質名の末尾に不要な空白が含まれている場合もあります。テキスト編集時の操作や書き出し処理によって、見た目では判断しにくい空白文字が付くことがあります。材質名は短く単純な半角文字列へ整理すると、環境差を抑えられます。
OBJ内にusemtlがあるものの、対応するnewmtlがどのMTLにも存在しない場合、読み込み側はその材質を正しく取得できません。その際の動作は環境によって異なり、既定材質を使う場合、直前の材質を継続する場合、対象要素を材質なしで表示する場合などがあります。
逆に、MTLに多数のnewmtlが記述されていても、OBJから一度もusemtlで参照されていないものは表示に使われません。未使用材質が大量に残っていると確認作業が複雑になるため、参照状況を確かめたうえで整理することが重要です。
OBJにmtllibが書かれていない状態でusemtlだけが存在する場合もあります。編集環境が内部情報を使って材質を表示していても、OBJとMTLを別の環境へ移すと関連付けが失われます。書き出されたOBJ単体の記述を確認し、必要なmtllibが含まれていることを確かめます。
複数MTLを一つのmtllib行に書いている場合は、読み込み先の対応状況も確認します。対応差を減らすには、複数行に分ける、または一つのMTLへ統合する方法があります。ただし、統合時には材質名重複の解消が必要です。
確認2：複数MTL内の材質名重複を確認する
二つ目の確認は、複数MTL内にあるnewmtlの重複です。複数MTL指定で材質が入れ替わる場合、最も優先して確認したい項目です。
すべてのMTLをテキストで開き、newmtlから始まる行を抽出します。各MTLにどの材質名が定義されているかを一覧化し、同じ名前が複数のファイルに存在しないかを調べます。
たとえば、一つ目のMTLにnewmtl material_01があり、二つ目にもnewmtl material_01がある場合、OBJ内のusemtl material_01だけでは、どちらを使うべきかを区別できません。
一つ目のmaterial_01が白色、二つ目が赤色であれば、読み込み順によって外観が大きく変わります。両方が異なるテクスチャ画像を指定している場合は、部材に別の画像が表示されるため、材質が完全に入れ替わったように見えます。
重複が見つかった場合は、材質名を一意に変更します。単純なmaterial_01やdefaultのような名称は衝突しやすいため、対象区分が分かる文字列を含めます。地表用ならground_material_01、構造物用ならstructure_material_01というように、用途ごとに区別できる名前が適しています。
MTL側のnewmtlを変更したら、OBJ側の対応するusemtlも同じ名前へ変更します。MTLだけを変更すると、OBJから新しい材質名を参照できなくなります。
材質名を一括置換するときは、部分一致による誤変更に注意します。material_1を変更した際にmaterial_10やmaterial_11まで書き換えると、別の材質との対応が崩れます。行全体または完全一致を基準に置換し、変更後に旧名称が残っていないかを再検索します。
複数のOBJを結合しているデータでは、元のOBJごとに同じ材質名が使われていることがよくあります。個別のOBJでは問題がなくても、一つのOBJから複数MTLを参照した時点で衝突します。
この問題を防ぐには、OBJを結合する前に、各データの材質名へ固有の接頭文字を付けます。データAの材質にはarea_a、データBにはarea_bというように区別すれば、結合後も参照先を明確にできます。
大文字と小文字だけで材質を区別する方法は避けた方が安全です。Material_Aとmaterial_aを別名として扱う環境もありますが、処理の途中で同じ文字列として扱われる可能性があります。名称そのものを明確に変える方が環境差を抑えられます。
同じMTL内でnewmtlが重複している場合にも注意が必要です。複数MTL間だけでなく、一つのMTL内に同名定義が二つあると、後半の設定によって前半が上書きされることがあります。
重複を解消した後は、OBJ内のusemtl一覧と、MTL内のnewmtl一覧を再度比較します。OBJにだけ残る名称や、MTLにだけ存在する名称を確認し、変更漏れや未使用材質を整理します。
確認3：ファイル名と参照パスを確認する
三つ目の確認は、OBJからMTL、MTLから画像へ続く参照パスです。材質名が正しくても、関連ファイルを見つけられなければ、期待した表示にはなりません。
OBJのmtllibに、作業端末固有の絶対パスが記録されている場合があります。作業中はその場所にMTLがあるため表示できますが、別の端末やアップロード先には同じ保存先が存在しません。
アップロード用データでは、端末固有の保存場所に依存しない相対的な参照へ整理します。特別な理由がなければ、OBJとMTLを同じフォルダに置き、mtllibにはMTLのファイル名だけを記述する構成が分かりやすくなります。
MTLからテクスチャ画像を参照する場合も同様です。画像が別の階層に置かれていると、アップロード先がフォルダ構造を保持しない場合に参照できなくなります。
OBJ、MTL、画像を同じフォルダへまとめられる場合は、MTL内の画像参照にもファイル名だけを使用します。階層構造が必要な場合は、アップロード後にも同じ相対位置が維持されることを確認します。
ファイル名の大文字と小文字にも注意します。OBJ内がmaterial_A.mtlで、実際のファイル名がmaterial_a.mtlの場合、作業環境によっては同じファイルとして扱われても、アップロード先では別名として処理されることがあります。
画像についても、Texture01.jpgとtexture01.jpgは一致しない可能性があります。参照記述と実ファイル名を完全にそろえます。
空白、全角文字、特殊な記号を含むファイル名も、環境をまたぐ際の問題になり得ます。多くの環境で扱える文字であっても、アップロード処理や変換処理の途中で正しく解釈されない場合があります。
実務では、半角英数字とアンダースコアなどを中心にした短い名称へ統一すると管理しやすくなります。名称変更後は、OBJ内のmtllibやMTL内の画像参照も更新します。
異なるフォルダに同名ファイルがある構成は特に危険です。たとえば地表用フォルダと構造物用フォルダの両方にtexture.jpgがあり、内容が異なる場合、アップロード時に一つの保存領域へまとめられると片方が上書きされる可能性があります。
この場合は、ground_texture.jpgとstructure_texture.jpgのように、実体ごとに異なる名前を付けます。MTL内の参照も新しい名前へ変更します。
拡張子が重複していないかも確認します。画面上ではmaterial.mtlと見えていても、実際の完全な名前がmaterial.mtl.mtlになっていることがあります。拡張子を非表示にした状態で名前を追加すると起こりやすい問題です。
参照パスを整理したら、アップロード用フォルダを別の場所へ複製し、その複製だけでOBJを開けるかを確認します。元の作業フォルダに残るMTLや画像を参照している場合、移動後に材質が欠落します。
この試験により、アップロード用フォルダの外部へ依存していないことを確認できます。アップロード前の最終確認として有効です。
確認4：usemtlの位置と適用範囲を確認する
四つ目の確認は、OBJ内でusemtlが記述されている位置と、その材質が適用される要素範囲です。
OBJでは、usemtlの後に続く面などへ材質が適用され、次のusemtlが現れるまで同じ材質が続く構成が一般的です。そのため、新しい部材やグループの開始位置で材質指定を忘れると、直前の材質がそのまま引き継がれます。
オブジェクト名やグループ名が切り替わっていても、材質が自動的に初期化されるとは限りません。新しいグループが始まったからといって、前のusemtlが無効になるとは限らない点に注意が必要です。
材質が入れ替わっている部材を特定したら、その部材に対応する面の直前までOBJをさかのぼり、最後に記述されたusemtlを確認します。想定とは異なる材質名が書かれていれば、usemtlの位置ずれが原因です。
一つの部材の途中でusemtlが意図せず切り替わっている場合もあります。面の一部だけ別の材質になると、材質が混在したり、隣接する部材と入れ替わったりしたように見えます。
ただし、部材面ごとに異なる材質を使う設計であれば、途中のusemtlは必要です。不要かどうかを判断する前に、元データで意図された材質区分を確認します。
複数のOBJをテキストとして単純に結合した場合は、データの境界部分を重点的に確認します。一つ目のOBJの最後に指定された材質が、二つ目のOBJの先頭へ引き継がれることがあります。
二つ目のOBJで最初の面が記述される前にusemtlがなければ、一つ目のOBJの最後の材質が適用されます。結合時には、各オブジェクトやグループの開始直後に必要なusemtlがあるかを確認します。
形状を編集した後に、usemtlの位置だけが古い状態で残っている場合もあります。面を削除、移動、結合した結果、材質区間と実際の部材範囲が一致しなくなることがあります。
特にテキスト処理によって面の並びを変更した場合は、usemtlも同時に適切な位置へ移動しなければなりません。材質指定を残したまま面だけを並べ替えると、別の面群へ材質が適用されます。
問題の切り分けには、小さな検証用OBJを作る方法も有効です。二つの部材と二つの材質だけを残し、各部材の直前にusemtlを一つずつ設定します。
小さなOBJでも材質が入れ替わる場合は、材質名重複や読み込み側の複数MTL処理が原因である可能性があります。小さなOBJでは正常で、元の大きなOBJだけで異常が起こるなら、usemtlの配置や複雑な面構成を重点的に調べます。
確認5：テクスチャ参照とアップロード構成を確認する
五つ目の確認は、MTL内のテクスチャ参照と、アップロード後のファイル配置です。材質名の割り当てが正しくても、異なる画像が読み込まれれば材質が入れ替わったように見えます。
MTLには、材質ごとに参照する画像ファイルが記述されることがあります。すべてのMTLから画像参照を抽出し、どの材質がどの画像を使っているかを確認します。
同じ画像を複数材質で共有する設計であれば、同じファイル名が繰り返されても問題とは限りません。しかし、実体が異なる画像に同じ名前を付けている場合は競合します。
たとえば異なるフォルダに二つのsurface.jpgが存在し、内容が異なる場合、アップロード後にどちらか一方だけが保存される可能性があります。その結果、複数の材質が同じsurface.jpgを使うことになります。
異なる画像には、それぞれ固有の名前を付けます。材質名との対応が分かる画像名にすると、後から参照関係を追いやすくなります。
画像の拡張子と内部形式が一致していることも確認します。拡張子だけを変更した画像や、アップロード先が扱えない設定を含む画像は、正常に読み込まれない可能性があります。
画像を取得できなかった場合、閲覧環境はMTL内の単色設定を表示することがあります。複数材質の単色設定が同じであれば、テクスチャが失われたときにすべて同じ外観になります。
透明度を含む材質では、表示方法の違いも確認します。透明度に関する値の解釈が異なると、本来見えるはずの面が透明になり、背後の別材質が表に現れることがあります。この場合、材質名が入れ替わったのではなく、前面の材質が見えなくなっています。
アップロードには、OBJだけでなく、参照されるMTLとすべての画像を含めます。一部の画像を入れ忘れると、材質ごとに表示結果が異なります。
圧縮してアップロードする場合は、展開後の階層も考慮します。圧縮ファイル内に不要な最上位フォルダが追加されると、OBJとMTLの相対位置が変わることがあります。
実際にアップロードする前に、一度圧縮し、別の場所へ展開してからOBJを開きます。展開後のデータだけで正しく表示できれば、ファイル一式が自己完結している可能性が高くなります。
再アップロードでは、修正前と同じファイル名を使い続けると、古いMTLや画像の影響を切り分けにくくなります。検証時には、OBJ、MTL、画像へ同じ版を示す識別文字列を付けます。
たとえばOBJだけを新しい名前にしても、MTLや画像が旧名称のままでは、古い関連ファイルが使われる可能性があります。関連するファイルを一つの版としてそろえ、OBJとMTL内の参照も更新します。
アップロード後は、修正前のデータとは別の登録として開き、材質が正しく表示されるかを確認します。これにより、古いファイルや一時保存の影響を受けにくくなります。
複数MTLを一つにまとめるときの注意点
複数MTLへの対応差を減らすため、一つのMTLへ材質定義をまとめる方法があります。参照するMTLが一つになれば、読み込み順による不確定要素を減らせます。
ただし、複数のMTLを単純に連結するだけでは不十分です。同じnewmtl名が含まれていれば、一つのMTL内でも材質定義が競合します。
統合前に、すべての材質名を一覧化し、重複を解消します。必要に応じて材質名へ区分名を付け、OBJ内のusemtlも同じ名称へ変更します。
テクスチャ画像名についても同様です。異なる画像に同じ名前が使われている場合は、統合前に固有の名前へ変更します。MTL内の参照先も合わせて書き換えます。
材質名と画像名の整理が完了したら、各MTLの定義を一つのファイルへまとめます。その後、OBJ内のmtllibを統合後のMTLだけを参照する記述へ変更します。
統合前のMTLをアップロード用フォルダに残しておくと、誤って古いファイルを利用する可能性があります。検証が完了した後は、アップロード用フォルダに必要なMTLだけを残します。
MTL統合後は、OBJ内のすべてのusemtlが統合MTL内に存在することを確認します。また、同じnewmtlが複数回残っていないことも再確認します。
未使用の材質定義を削除すれば、ファイルを確認しやすくなります。ただし、削除前にはOBJ内から参照されていないことを確実に確認します。
統合したMTLを使って別の閲覧環境でも表示を試し、複数MTLのときに発生していた材質入れ替わりが解消するかを確認します。
一つのMTLにまとめても問題が続く場合は、usemtlの位置、画像参照、点群OBJの構造など、MTL数以外の原因を調べる必要があります。
点群OBJ特有の材質表示にも注意する
点群OBJと呼ばれるデータでも、内部構成は一様ではありません。頂点だけが並ぶデータ、点を表す要素を含むデータ、点群から作成した三角形面を持つデータでは、材質の適用方法が異なります。
MTLは一般に面などの形状へ材質を割り当てるために利用されます。頂点だけで構成されたOBJでは、usemtlが記述されていても、アップロード先が点への材質適用に対応していなければ反映されません。
点群の色を頂点ごとの属性として保存する表現もありますが、その扱いはすべての環境で共通しているわけではありません。書き出し元では色が見えていても、アップロード先では頂点色を認識せず、単色で表示されることがあります。
点群からメッシュを生成し、面へ材質を割り当てている場合は、一般的なusemtlの仕組みを利用しやすくなります。ただし、メッシュの簡略化や再生成によって面の順番が変わると、古い材質区分との対応が崩れる可能性があります。
形状を処理した後は、OBJだけでなくMTLも同じ時点のデータとして書き出します。古いOBJと新しいMTL、新しいOBJと古いMTLを混在させないことが重要です。
点群の分類結果を材質で表している場合も注意します。地面、構造物、植生などに異なる材質を割り当てていても、分類処理をやり直すと要素の所属や並び順が変わることがあります。
以前のusemtl配置やMTLを流用すると、新しい形状構成と一致しなくなる可能性があります。分類やメッシュ処理を更新した場合は、材質情報も再生成する方が安全です。
材質が入れ替わって見える場合は、面の向きも確認します。表面と裏面の扱いによって、本来の面が表示されず、反対側や背後の面が見えることがあります。
透明度や描画順も影響します。透明な面が重なっていると、閲覧方向によって表示される色が変化することがあります。この問題は材質名の整理だけでは解決できません。
点群OBJの表示異常を確認するときは、色がMTL、頂点属性、画像のどれによって表現されているかを最初に把握します。色の保存方法が分かれば、確認すべきファイルと記述を絞り込めます。
修正後の点群OBJを検証する手順
修正後は、全体を眺めるだけでなく、原因を再現できる方法で検証します。材質が似た色の場合、誤った割り当てを見逃しやすいためです。
検証用の複製では、各材質を一時的に大きく異なる色へ変更する方法があります。地面、構造物、設備などを明確に区別できる色へ変えれば、どの範囲にどの材質が適用されているかを確認しやすくなります。
割り当てが正しいことを確認した後で、本来の色やテクスチャへ戻します。正式データを直接変更せず、検証用の複製で実施することが重要です。
一つのMTLだけを一時的に外し、表示がどのように変化するかを確認する方法もあります。特定の部材だけ材質が失われるなら、そのMTLとの対応を確認できます。
複数MTLの順番を入れ替えたときに表示が変わる場合は、同名材質の競合が残っている可能性があります。順番に依存しない状態になるまで、材質名を整理します。
OBJ、MTL、画像を別のフォルダへ複製し、そのフォルダだけで開く試験も行います。作業フォルダの外部ファイルに依存していれば、移動後に材質や画像が失われます。
アップロード時と同じ方法で圧縮し、別の場所へ展開したデータでも確認します。圧縮前には正常でも、展開後の階層が変わると参照が切れることがあります。
アップロード後は、代表的な部材だけでなく、OBJの先頭付近、中間、末尾付近を確認します。usemtlの切り替え漏れは、複数データの結合境界や後半の部材で発生することがあります。
地表、壁面、設備、標識など、用途が異なる材質を選んで確認すると、同名材質や画像競合を見つけやすくなります。
修正内容も記録します。変更した材質名、統合したMTL、変更した画像名、修正したusemtlの位置を残しておけば、データを再書き出ししたときにも同じ処理を再現できます。
正式なアップロードへ進む前に、修正前と修正後の表示を比較します。ただし、同名ファイルの上書きでは古いデータが表示される可能性があるため、異なる版名で登録して比較します。
材質の入れ替わりを防ぐデータ管理方法
複数MTLのトラブルは、アップロード直前の修正だけでなく、日常的な命名と保存方法を整えることで防ぎやすくなります。
材質名には、案件やデータ区分、部材の用途を識別できる文字列を含めます。material_01やdefaultのような一般的な名称だけで管理すると、別データとの統合時に重複しやすくなります。
一つのOBJ一式の中では、すべての材質名が一意になるようにします。異なるMTLに分かれていても、同じ材質名を使わない方が安全です。
MTLや画像ファイルについても、別のデータと重複しにくい名称を付けます。material.mtlやtexture.jpgだけでは、コピーやアップロード時に上書きされやすくなります。
OBJ、MTL、画像は一つのデータ単位として管理します。OBJだけを更新し、以前のMTLや画像を使い続けると、usemtlとnewmtlの対応がずれる可能性があります。
形状を再書き出しした場合は、関連するMTLも同じ時点のものへ更新します。どのファイルが同じ版に属するかを明確にするため、共通の識別文字列を付ける方法が有効です。
作業用、確認用、アップロード用のフォルダを分けます。アップロード用フォルダには、実際に必要なOBJ、MTL、画像だけを配置します。
古いMTLや未使用画像が同じフォルダに残っていると、誤ったファイルを参照したり、同名ファイルが競合したりします。不要なファイルを除外することで、原因の切り分けも容易になります。
未使用材質を整理するときは、OBJ内のusemtlを検索してから削除します。MTL側で不要に見えても、OBJの一部から参照されている可能性があります。
複数OBJを統合するときは、結合後にまとめて修正するのではなく、結合前に各データの材質名と画像名を固有化します。事前に整理すれば、結合後の大きなOBJを手作業で修正する範囲を減らせます。
データを更新するたびに同じ名前で上書きせず、確認段階では版を分けて保存します。修正前後を比較できる状態にしておけば、変更によって別の材質が崩れた場合にも戻しやすくなります。
アップロード作業の手順を定型化することも重要です。OBJ内のmtllib確認、usemtlとnewmtlの照合、重複名の確認、画像参照の確認、別フォルダでの表示試験を毎回行えば、材質の入れ替わりを公開前に発見しやすくなります。
まとめ
点群OBJの複数MTL指定で材質が入れ替わる場合は、最初にOBJ内のmtllibとusemtlを確認し、参照先のMTLと材質名が実在するかを照合します。
次に、複数のMTLからnewmtlを抽出し、同じ材質名が重複していないかを確認します。同名材質が存在すると、読み込み環境によって先に読み込んだ定義または後から読み込んだ定義が採用され、表示結果が変わる可能性があります。
重複している材質には固有の名前を付け、OBJ内のusemtlも同じ名称へ変更します。大文字と小文字の違いだけに頼らず、明確に異なる文字列へ整理することが重要です。
ファイル名と参照パスについては、OBJ、MTL、画像の実際の配置と一致しているかを確認します。端末固有の絶対パス、異なるフォルダにある同名画像、大文字と小文字の不一致は、アップロード後の参照切れにつながります。
usemtlの位置も確認し、新しい部材やグループの開始位置で適切な材質へ切り替わっているかを調べます。オブジェクト名やグループ名が変わっても、材質が自動的に初期化されるとは限りません。
テクスチャ画像の欠落や競合も、材質が入れ替わったように見える原因です。異なる画像には固有のファイル名を付け、アップロード後もOBJ、MTL、画像の相対位置が維持される構成へ整理します。
複数MTLの読み込み差を抑えたい場合は、材質名と画像名の重複を解消したうえで、一つのMTLへ統合する方法があります。ただし、単純にファイルを連結するだけでは同名定義が残るため、統合前後の確認が必要です。
また、頂点だけで構成された点群OBJでは、MTLが期待どおりに適用されないことがあります。色がMTL、頂点属性、テクスチャ画像のどの方法で保持されているかを確認し、アップロード先の対応方法に合わせます。
修正後は、ファイル一式を別のフォルダへ移動し、そのフォルダだけで正しく表示できるかを確認します。アップロード時と同じ方法で圧縮、展開する試験も行うと、参照漏れや階層の問題を発見しやすくなります。
現場で取得した点群をOBJとして共有する場合は、形状の確認だけでなく、材質名、画像名、版管理を含めて一式を整理することが重要です。計測から点群データの作成、確認、共有までを現場で効率化したい場合は、LRTK Phoneを活用したデータ運用もあわせて検討するとよいでしょう。