点群OBJをアップロードすると色が入れ替わるのはなぜか
点群OBJをクラウドや3D表示環境へアップロードしたとき、元データでは赤かった部分が青くなったり、複数の区画が同じ色になったり、前回まで正常だった点群の色が突然変わったりすることがあります。形状や座標は正しく表示されているにもかかわらず色だけがおかしい場合、疑うべき項目の一つがOBJとMTLに記録されている材質名の重複です。
OBJは形状や頂点、点、面などの情報を記録できるテキスト形式ですが、色や材質に関する情報を別のMTLファイルへ分離して管理する構成がよく使われます。この構成では、OBJ側に「どの材質を使うか」という参照名が記録され、MTL側にはその名前に対応した色やテクスチャなどの設定が記録されます。
問題になるのは、異なる色を持つ複数の材質に同じ名前が付いている場合です。たとえば、一つ目の点群では「material_1」が赤、二つ目の点群では同じ「material_1」が青として定義されているとします。それぞれを単独で開くと正常でも、複数データを統合したり、複数のMTLを一度に読み込ませたりすると、読み込み側は同名の材質を区別できなくなる場合があります。
その結果、先に読み込んだ赤の設定が青に置き換わる、逆に後から読み込んだ設定が無視される、すべて同じ色として表示されるといった現象が起こります。どちらの材質定義が採用されるかは読み込み側の実装やデータの並び方によって変わることがあるため、「自分の環境では正常だから問題ない」と判断するのは危険です。
点群OBJをアップロードする業務では、現場ごとのデータを後から統合することも少なくありません。計測範囲を分割して取得した場合、複数人でデータを作成した場合、同じ出力設定を繰り返し利用した場合には、似た材質名が大量に生成されることがあります。そのため、点群 OBJ アップロード時の色崩れを解決するときは、単純に画面の色設定だけを見るのではなく、OBJとMTLの参照関係まで確認する必要があります。
OBJとMTLで色が決まる基本構造
材質名重複の原因を理解するには、まずOBJとMTLがどのようにつながっているかを把握しておくことが重要です。
OBJには、関連するMTLファイルを指定する記述が入ることがあります。代表的なのが「mtllib」です。たとえば次のような記述です。
mtllib site_data.mtl
これは、OBJの材質情報をsite_data.mtlから読み込むという意味を持ちます。
OBJ内では、さらに「usemtl」という記述によって、以降の点や面にどの材質を適用するかを指定する構成があります。
usemtl area_red
一方、MTL側では次のように材質を定義します。
newmtl area_red
Kd 1.0 0.0 0.0
「newmtl」の後ろにある文字列が材質名です。OBJ側のusemtlで指定された名前とMTL側のnewmtlで定義された名前が一致することで、読み込み側が対応関係を判断します。
ここで重要なのは、材質の対応が「何番目の材質か」ではなく、基本的に名前によって結び付けられる点です。
たとえばOBJ側に「usemtl area_red」と書かれているのに、MTL側では「newmtl area_blue」しか存在しなければ、正しい材質を割り当てられません。また、同じ「newmtl area_red」がMTL内に複数存在し、それぞれ異なる色を持っていれば、どちらを採用すべきかが曖昧になります。
点群をOBJとして扱う場合には、頂点そのものに色成分を付加する形式が使われることもあります。ただし、頂点色の扱いはデータを作成する環境や読み込み側によって差があります。一方、材質を使って点群をグループ分けしているOBJでは、usemtlとnewmtlの対応が表示結果へ直接影響します。
したがって、点群OBJで色がおかしいときには「OBJだから色はOBJファイルの中だけを見ればよい」と考えないことが大切です。MTLが存在するデータでは、OBJとMTLを一組として確認する必要があります。
特に点群 OBJ アップロードの場面では、OBJだけをアップロードしてMTLを忘れている問題と、MTLは存在しているものの材質名が衝突している問題を分けて考える必要があります。前者では色が付かない、既定色になるといった症状が出やすく、後者では色が別の場所と入れ替わったり、一部だけ違う色になったりする症状が出やすくなります。
材質名の重複が起きる主な原因
材質名の重複は、手作業で同じ名前を付けた場合だけに発生するものではありません。実務では、データ作成から統合、アップロードまでの工程の中で自然に発生することがあります。
代表的なのが、分割出力した点群を後から統合するケースです。
たとえば広い現場をA区画、B区画、C区画に分け、それぞれ別々にOBJとして出力したとします。各OBJが同じ出力処理から生成されていると、どのファイルでも最初の材質が「material_0」、次が「material_1」のような共通名称になることがあります。
単独ファイルでは問題ありません。A区画のmaterial_0はA区画のMTLだけを参照するからです。しかしA区画とB区画のOBJやMTLを統合すると、material_0という名前が複数存在する状態になります。
もう一つ多いのが、異なる作業日に作成したデータを同じフォルダへ集約する場合です。
初日の点群に「point_001」という材質があり、翌日の点群にも「point_001」があれば、元のファイルが別でも統合後には衝突する可能性があります。ファイル名に日付を付けていても、内部の材質名まで変わっているとは限りません。
また、OBJファイルだけを結合してMTLを後からまとめる作業でも重複が起きます。OBJの頂点番号や点番号を正しく調整していても、usemtlの名前をそのまま残していれば、形状は正常なのに材質だけ誤って共有されることがあります。
MTLを複数読み込ませる構成にも注意が必要です。OBJでは複数の材質ライブラリを扱うデータが存在しますが、別々のMTLに同じnewmtl名が記録されていると、読み込み側で同名材質が衝突する可能性があります。
さらに、テンプレート化された出力処理も原因になります。現場名や区画名とは無関係に「red」「blue」「mat1」「mat2」など固定された名称を毎回利用していると、単独運用では便利でも、後から統合したときに重複しやすくなります。
ファイル名だけを変更したケースも見逃せません。
「area_A.obj」と「area_B.obj」のようにOBJファイル名を変更していても、ファイル内部のusemtlが両方とも「material_1」、対応するMTLのnewmtlも両方とも「material_1」であれば、内部的には同じ名前です。外から見たファイル名が異なることと、内部識別子が一意であることは別の問題です。
この違いを理解しておくと、点群 OBJ アップロード時のトラブル調査が大幅に行いやすくなります。
材質名重複で発生する代表的な症状
材質名が重複したときの症状は、必ずしも「完全に色が消える」とは限りません。むしろ一見すると正常に見えるため、原因の発見が遅れるケースがあります。
よくあるのが、二つの色が入れ替わる現象です。赤として設定した範囲が青になり、青だった範囲が赤になるように見えます。
実際には色そのものが交換されたのではなく、同じ材質名に異なる設定が定義された結果、期待していた定義とは別の材質設定が使われています。
次に多いのが、複数の区画が同じ色になる現象です。
たとえばA区画の材質名とB区画の材質名が両方とも「mat_01」であれば、読み込み時に一つの材質として扱われる可能性があります。Aを赤、Bを緑に設定したつもりでも、両方が赤または緑になることがあります。
一部だけ色が変わる場合もあります。
OBJ内部で複数回usemtlが切り替えられている場合、衝突した名前を使っている部分だけが誤表示となり、重複していない材質は正常に見えるためです。全体のうち数％だけ色がおかしい場合でも、材質名の一覧を確認する価値があります。
ローカルでは正常なのにアップロード後だけ色が変わるという症状も重要です。
これは、作成時の表示環境とアップロード先で材質の読み込み方法が異なる場合に起こります。一方では最初に定義された材質を使い、別の環境では後から読み込んだ定義を使うといった違いがあると、まったく同じOBJとMTLでも表示結果が変わる可能性があります。
そのため、材質名が重複したデータを「特定の環境で正常だった」という理由だけで安全と判断しないことが重要です。
さらに、ファイルを追加した瞬間に既存データの色が変わる症状もあります。
最初のOBJだけでは正しく表示されていたのに、二つ目のOBJを追加した後、一つ目まで別の色になるケースです。この場合、新たに読み込んだMTL内の材質名が既存の名前と衝突した可能性を確認します。
形状、座標、点数がおおむね正しく、色だけが読み込み順やファイル追加によって変化する場合は、材質名の重複が有力な確認項目になります。
修正法1 材質名をファイル全体で一意にする
最も基本的で効果の高い修正は、すべての材質名を一意にすることです。
材質名を「red」「material1」のような汎用名称だけで管理するのではなく、現場、取得日、区画、データ番号などを組み合わせます。
たとえばA区画の一つ目の材質であれば「siteA_area01_mat001」、B区画なら「siteA_area02_mat001」のように、他のデータと衝突しにくい名称にします。
重要なのは、色ごとに名前を付けるだけでは十分ではないという点です。
「red」という名称は分かりやすいものの、別のデータでも同じ名前を使用する可能性が高いため、統合時の衝突を防げません。「現場識別子＋区画識別子＋材質番号」のように、そのデータ固有の情報を含める方が安全です。
MTLでは次のように変更します。
変更前が、
newmtl material_1
Kd 1.0 0.0 0.0
であれば、変更後は、
newmtl siteA_area01_material_001
Kd 1.0 0.0 0.0
とします。
別のデータでは、
newmtl siteA_area02_material_001
Kd 0.0 0.0 1.0
のようにします。
これで同一環境に読み込んでも材質名が衝突しにくくなります。
ただし、MTLだけを書き換えれば修正完了というわけではありません。OBJ側にはusemtlで元の名前が記録されているため、次の修正法で説明する参照先の変更も同時に必要です。
大規模な点群OBJでは、材質数が数十、数百になる場合があります。その場合に一つずつ手で名称変更すると、入力ミスの方が大きな問題になります。
一定の規則で機械的に接頭辞を追加できるようにしておくと安全です。元の「material_001」を完全に別名へ変えるより、「A01_material_001」のように元の識別情報を残しながら固有文字列を追加すると、OBJとMTLの照合もしやすくなります。
材質名は人間が読みやすいことも重要ですが、最優先すべきなのは重複しないことです。
修正法2 OBJ側のusemtl参照を材質名と同時に修正する
MTLのnewmtlを変更したら、OBJ側のusemtlも必ず同じ名前へ変更します。
この対応を忘れると、材質名の重複問題は解消しても、今度はOBJから材質を見つけられない状態になります。
たとえばOBJに次の記述があるとします。
usemtl material_1
MTL側を、
newmtl siteA_area01_material_001
へ変更した場合、OBJ側も、
usemtl siteA_area01_material_001
に変更する必要があります。
この二つは必ず一対として考えます。
点群OBJの修正でありがちな失敗は、MTL内のnewmtlだけを検索して重複を解消し、OBJ内のusemtlをそのまま残してしまうことです。その状態では材質参照が切れ、色が表示されない、既定色になる、別の材質へフォールバックするなど、別の症状が発生する可能性があります。
安全に変更するには、まずMTLのnewmtlを一覧化し、次にOBJ内のusemtlを確認します。
たとえば元の材質名が「material_1」で、対象データにその名前が一種類しか存在しないことを確認できれば、OBJとMTLの両方で同じ文字列を置換できます。
一方、すでに同一ファイル内に複数の「material_1」が存在している場合は、単純な一括置換では修復できないことがあります。どのusemtlがどのnewmtlを意図していたかを判断する必要があるからです。
その場合には、材質切り替え位置、元の分割ファイル、点群の区画、色設定などを基に対応関係を復元します。
元データが複数ファイルに分かれているなら、統合済みファイルを直接修正するよりも、統合前のOBJとMTLを使って個別に名称変更してから再統合する方が安全です。
たとえばA.objとA.mtlのすべての材質へ「A_」を追加し、B.objとB.mtlには「B_」を追加してから統合します。こうすれば、どの材質がどの元データに属していたかを保ったまま重複を解消できます。
大容量データでは、OBJを不用意に通常の文書編集環境で開くと処理が重くなることがあります。そのため、文字列置換を行う場合でも、元ファイルを残して複製したデータで作業することが重要です。
文字コードや改行形式まで不要に変更すると、材質名とは無関係な問題を増やす可能性があります。修正対象はできるだけnewmtl、usemtl、必要に応じてmtllib周辺に限定し、頂点座標や点番号などを触らない方が安全です。
修正法3 MTLファイルを整理して重複定義をなくす
三つ目の修正法は、MTLファイルそのものを整理する方法です。
点群OBJを何度も結合していると、一つのOBJに対して複数のMTLが存在したり、一つのMTLの中に同じnewmtlが何度も出てきたりすることがあります。
たとえば次のような状態です。
newmtl section_01
Kd 1.0 0.0 0.0
newmtl section_01
Kd 0.0 1.0 0.0
同じsection_01という名前に赤と緑の二つの定義があります。
人間が見れば「どちらかの名前を変更し忘れている」と判断できますが、読み込み処理にとっては曖昧なデータです。
このような場合は、まず各newmtlを一意にします。
newmtl section_A_01
Kd 1.0 0.0 0.0
newmtl section_B_01
Kd 0.0 1.0 0.0
そのうえでOBJ側もsection_A_01とsection_B_01を正しく参照するように修正します。
複数MTLが存在している場合には、必要に応じて材質ライブラリを整理することも有効です。
A.mtlに「material_1」、B.mtlにも「material_1」が存在する状態を残すより、統合運用を前提に一つの管理用MTLへ整理し、すべてのnewmtlを一意にした方がトラブルを発見しやすくなります。
ただし、複数MTLを一つへまとめること自体が目的ではありません。重要なのは、OBJから参照される材質名が曖昧にならないことです。
同時に確認したいのが、MTLから参照されるテクスチャファイルです。
点群OBJの色が材質の数値設定ではなく画像ファイルから取得されている場合、材質名を直しても画像参照が誤っていれば正しい色にはなりません。
たとえば異なる区画のMTLがどちらも同じ画像ファイル名を参照し、フォルダへコピーするときに片方が上書きされていれば、材質名を一意にしても同じ画像を読むことになります。
したがってMTLを整理するときは、newmtlの重複だけでなく、画像参照がある場合は参照先も重複していないか確認します。
点群 OBJ アップロードで問題が起きている場合、OBJ、MTL、関連ファイルの三者をセットとして扱うことが重要です。
ファイル名、内部の材質名、参照ファイル名という三つの階層があるため、「OBJ名を変えたから大丈夫」「MTLを別名にしたから大丈夫」とは限りません。内部参照まで含めて整合していることが必要です。
修正法4 再出力時の命名ルールを統一して再発を防ぐ
材質名を一度修正しても、同じ出力方法を続けていれば次の点群で再び重複する可能性があります。そのため、継続運用では修正作業よりも再発防止の方が重要です。
まず決めたいのが材質名の命名規則です。
現場識別子、計測日、区画、連番などを組み合わせ、他のOBJと統合しても重複しにくい形式を採用します。
たとえば「現場A・区画03・材質005」という意味を持つ名前であれば、別区画や別現場の材質と区別できます。
名称が多少長くなっても、後から原因を追跡できるメリットの方が大きい場合があります。
特に避けたいのが、毎回「material_0」から番号を振り直す運用です。
単独ファイルだけを扱うのであれば問題が起こらないこともありますが、現場では後から統合する可能性があります。最初から統合を前提とした名前を付けておけば、後工程で大量の置換を行う必要がありません。
次に、OBJとMTLを出力した直後の確認工程を決めます。
アップロードして初めて確認するのではなく、出力直後にnewmtlの重複、usemtlとの対応、mtllibの参照を確認します。
特に複数OBJを統合する場合は、統合前の時点で各ファイルへ固有の接頭辞を付与しておくと安全です。
A区画ならA、B区画ならBといった短い識別子でも、単純なmaterial_001の重複を大きく減らせます。
アップロード用ファイルを作成した後には、まず小さなデータで確認する方法も有効です。
全点群を一度にアップロードして色の異常を発見すると、原因となる材質を探す範囲が広くなります。そこで、代表的な数区画だけを含む検証データを作成し、色が正しく表示されるかを確認してから本番データへ進めます。
色が正しいだけでなく、材質を切り替える境界も確認します。
赤から青へ変わる予定の位置が正しいか、別の区画まで同じ色が連続していないかを見ることで、材質名の取り違えを発見しやすくなります。
命名ルールは担当者個人の判断に任せるのではなく、チームの出力ルールとして固定することが大切です。
同じ点群を複数人が扱う環境では、ある担当者が「A_001」、別の担当者が「area1_001」、さらに別の担当者が「mat001」と付けていると、重複を完全に防げないだけでなく管理も難しくなります。
統合を想定した一貫した命名規則を決めることで、点群 OBJ アップロード後のトラブルを減らせます。
点群OBJアップロード前に確認したい関連項目
材質名を一意にしても、点群OBJの色が正常になるとは限りません。色崩れには複数の原因があるため、材質名を修正した後も関連項目を確認する必要があります。
まず確認したいのが、mtllibの参照です。
OBJ内で指定されているMTLファイル名と、実際にアップロードするMTLファイル名が一致している必要があります。
OBJ側が、
mtllib site.mtl
となっているのに、実ファイルを「site_new.mtl」へ変更していれば、正しく読み込まれない可能性があります。
ファイルを整理するときに名前だけ変更した場合は特に注意が必要です。
次に確認したいのが大文字と小文字です。
環境によってファイル名の扱いが異なる可能性があるため、「Site.mtl」と「site.mtl」を同じものとして扱えることを前提にしない方が安全です。
材質名でも、大文字小文字だけを変えて別材質として区別する命名は避けた方が管理しやすくなります。
空白や特殊な記号を多用した材質名も、データ交換を考えると避ける方が無難です。
複雑な名前にするより、英数字やアンダースコアなどを組み合わせ、規則的に管理した方がトラブルを減らせます。
テクスチャ画像を利用するデータでは、画像ファイルの相対的な配置も確認します。
作成元では同じフォルダに画像が存在していたものの、アップロード時にはOBJとMTLだけを選択して画像を含めていないというケースがあります。
この場合、材質名が完全に正しくても元の見た目は再現できません。
また、OBJそのものに独自形式の頂点色情報が含まれている場合には、アップロード先がその表現方法に対応しているかも確認項目です。
材質による色と頂点色は同じ仕組みではありません。「MTLがあるから必ずMTLだけで色が決まる」と決めつけず、元データの色がどこに記録されているかを確認する必要があります。
点群データでは、色以外にも座標系、単位、原点位置などの違いがアップロード後の表示へ影響します。
材質名を修正する作業では頂点行を変更しないようにし、色の修正と座標修正を一度に行わないことも重要です。
複数の要素を同時に変更すると、結果が改善した場合でも、どの変更が効いたのか分からなくなります。
大容量の点群OBJで安全に修正する進め方
点群OBJはデータ量が大きくなりやすいため、数行のMTLだけを扱う場合とは違った注意が必要です。
まず元データを直接上書きしないことが重要です。
修正前のOBJ、MTL、関連ファイルを一式保存し、作業用の複製を作ります。材質名の置換を間違えた場合でも、元データが残っていればやり直せます。
次に、いきなり全材質を変更せず、一つの区画で試験します。
たとえば色が入れ替わっているA区画とB区画だけを対象に材質名を一意化し、アップロード結果を確認します。
この試験で症状が解消すれば、同じ方法を他の区画へ展開できます。
逆に症状が変わらなければ、材質名以外の原因を疑えます。
大容量ファイルでは、一括置換の条件を慎重に設定します。
たとえば「material_1」を単純に置換すると、「material_10」「material_11」など別の名前の一部まで誤って変える可能性があります。
材質名の境界を正確に確認し、usemtlやnewmtlの行を対象に変更する方が安全です。
修正後には、newmtlの数とusemtlで参照される名前を比較します。
usemtlに存在する名前がMTLにない場合、その材質は参照切れです。
逆に、MTLに定義されているもののOBJから一度も参照されない材質が大量に残っている場合は、不要な定義が蓄積している可能性があります。
不要材質を削除することはファイル管理の単純化につながりますが、削除するときは本当に参照されていないことを確認します。
点群OBJではファイル容量の削減を優先するあまり、色表示に必要な情報まで消してしまわないよう注意が必要です。
また、修正したOBJを保存した後は、ファイルサイズが異常に変化していないかも確認します。
材質名の変更だけなら、OBJ全体の容量が劇的に増減することは通常ありません。大きく変化した場合は、保存処理によって別の情報が変更されていないか確認した方が安全です。
色が直らないときに切り分けるポイント
材質名を一意にしたにもかかわらず色が直らない場合は、原因を段階的に切り分けます。
最初に確認したいのは、修正したMTLが実際に参照されているかです。
古いMTLをOBJが参照したままでは、新しいMTLを修正しても表示結果は変わりません。OBJ内のmtllibを確認し、使用するMTL名と一致していることを確認します。
次に、usemtlとnewmtlが完全に対応しているか確認します。
たとえばusemtlが「area_A_001」で、newmtlが「areaA_001」なら別名です。目視では似ていても、一文字違えば一致しません。
材質名の先頭や末尾へ意図しない文字が入っていないかも確認します。
次に、材質の色設定自体を確認します。
newmtlが一意でも、複数材質に同じ色が設定されていれば当然同じ色に見えます。「名前が異なる＝色も異なる」わけではありません。
逆に、材質の色設定が異なるのに同じように表示される場合は、アップロード先が利用している材質情報や表示設定を確認する必要があります。
テクスチャを使っている場合は、参照画像の取り違えを確認します。
材質Aと材質Bが別名でも、両方が同じ画像を参照していれば表示が似る可能性があります。
画像ファイル名が重複し、コピー時に上書きされたケースも考えられます。
さらに、キャッシュされたデータではなく修正版を読み込んでいるかも確認します。
ファイル名を変えずに何度もアップロードしていると、作業者自身が旧版と新版を取り違えることがあります。修正テストでは、OBJ、MTL、関連ファイルの版を明確に区別できる名前にしておくと確認しやすくなります。
原因調査で有効なのは、できるだけ小さな検証データへ縮小する方法です。
大量の材質を含むOBJで調べるより、問題の材質二つだけを含むデータで比較した方が、材質名、色設定、参照関係を追いやすくなります。
二つの材質を一意な名前へ変更したら正常になるのであれば、材質名衝突の可能性は高まります。
一意化しても変化しないのであれば、テクスチャ参照や頂点色情報、読み込み側の対応形式など、別の要因へ調査範囲を移せます。
このように、一度にすべてを変更するのではなく、一つずつ原因を除外していくことが点群OBJのトラブル解決では重要です。
点群OBJを継続運用するための管理方法
点群OBJを継続的にアップロードする業務では、単発の修正方法だけでなく、データ管理の設計が重要になります。
まず、OBJとMTLを必ず一つのデータ単位として管理します。
OBJだけを別フォルダへ移動したり、MTLだけを後から置き換えたりすると、どの組み合わせが正しいのか分からなくなります。
現場名、取得日、区画、更新版などが分かる単位でまとめて管理すると、材質トラブルが発生したときにも元データへ戻りやすくなります。
次に、統合前データを残します。
A区画、B区画、C区画を統合した完成OBJしか残っていないと、材質名の衝突が見つかったときに、どの定義がどの区画由来なのか追跡するのが難しくなります。
統合前のデータを保持していれば、AにはA_、BにはB_というように元ファイル単位で安全に材質名を変更できます。
また、ファイル名と材質名の規則を関連付けておくと管理しやすくなります。
ファイル名が「site01_area03.obj」であれば、材質名も「site01_area03_mat001」のようにしておけば、材質だけを見ても出所を判断できます。
これは色の修正だけでなく、不要材質の整理やデータ統合時の確認にも役立ちます。
さらに、アップロード前の検査項目を固定化します。
OBJから参照しているMTLが存在するか、usemtlに対応するnewmtlが存在するか、newmtlの重複がないか、関連画像がそろっているか、代表箇所の色が正しいかという流れを毎回確認すれば、アップロード後に初めて問題へ気付くケースを減らせます。
点群データは現場で繰り返し取得するほど蓄積量が増えます。
初期の数ファイルでは手作業で管理できても、数十、数百のOBJを扱う段階になると、人の記憶だけに依存した運用は難しくなります。
だからこそ、材質名は「今見て分かる名前」だけでなく、「後から別データと混ぜても衝突しない名前」にすることが重要です。
点群 OBJ アップロードで安定した表示を維持するには、ファイルを作成した時点から統合後の利用まで考えた命名と管理が必要になります。
まとめ
点群OBJをアップロードした際に色が入れ替わる現象は、表示側の単純な不具合とは限りません。OBJから参照されるMTLの中で材質名が重複し、異なる色の定義が同じ名前で管理されていることが原因になる場合があります。
OBJではusemtlによって材質名を参照し、MTLではnewmtlによって材質を定義する構成が一般的です。この名前が重複すると、複数の材質を正しく区別できず、色の入れ替わり、複数区画の同色化、一部だけの色崩れ、追加アップロード後の表示変化などにつながる可能性があります。
修正では、まず材質名をファイル全体で一意にします。そのうえで、MTLのnewmtlだけではなくOBJのusemtlも同じ名前へ変更します。複数のMTLを使用している場合は重複定義や参照ファイルを整理し、今後の出力では現場名、区画、連番などを組み合わせた命名規則を採用することが重要です。
また、色の問題は材質名だけで発生するとは限りません。mtllibの参照先、関連画像、材質設定、頂点色情報、ファイルの取り違えなども確認し、一つずつ原因を切り分ける必要があります。
点群OBJは、計測範囲が広くなり、複数時点や複数区画のデータを統合するほど管理が複雑になります。そのため、アップロード時だけ対処するのではなく、取得、出力、命名、統合、確認までを一つの流れとして整えておくことが重要です。
現場で取得した点群を座標情報と合わせて管理し、計測から3Dデータ活用までの流れを効率化したい場合は、LRTK Phoneを活用した点群取得・共有の運用も検討できます。点群OBJを書き出した後の管理だけでなく、データを取得する段階から用途を意識して整理することで、その後のアップロードや3D活用をより進めやすくなります。