点群データや点群から作成したメッシュをOBJ形式でアップロードしたとき、形状は表示されるのに色が反映されない、一部だけ既定の色になる、意図しない材質へ切り替わるといった問題が起こることがあります。原因は一つではありませんが、OBJファイルのusemtlとMTLファイルのnewmtlに記録されたマテリアル名へ空白が含まれていると、読み込み環境による解釈差が表面化する場合があります。
OBJとMTLは行単位のテキスト形式です。実装によっては、キーワードの後ろに続く行末までを一つの名前として扱います。一方で、空白で区切られた最初の語だけを名前として取得する実装もあります。そのため、同じusemtl wall outerという記述でも、ある環境ではwall outer、別の環境ではwallとして扱われる可能性があり、空白を含む名前は交換用データとして安定しにくいと考えられます。
ただし、空白を含む名前があらゆるソフトウェアで必ず無効になるという意味ではありません。また、色が出ない原因をマテリアル名だけに限定するのも適切ではありません。OBJに頂点を示すv行しかなく、点要素を示すp行や面を示すf行がない場合、読み込み側が独自に点群表示していても、usemtlの適用方法は環境ごとに異なります。頂点座標の後ろへ色成分を追加する頂点色の表現も広く使われていますが、これは元来のOBJ仕様に含まれない拡張的な扱いであり、対応状況は一様ではありません。
本記事では、「点群 OBJ アップロード」で検索している実務担当者に向けて、空白を含むマテリアル名を互換性の高い名前へ修正する4つのルールを解説します。OBJとMTLの参照関係、重複名の防止、一括置換の範囲、純粋な点群とメッシュの違いまで確認し、原因を取り違えない進め方を整理します。
点群OBJでマテリアル名の空白が問題になる理由
OBJは、頂点座標、テクスチャ座標、法線、点、線、面、グループ、オブジェクト、マテリアル参照などを行単位で記録する形式です。頂点座標はv、点要素はp、面はf、マテリアルの切り替えはusemtlで表されます。点群をOBJとして書き出したデータでは、多数のv行に加えてp行が記録される場合もあれば、作成ソフト独自の方法で頂点だけが並ぶ場合もあります。点群から面を生成したデータでは、f行、法線、UV、マテリアル参照が含まれることがあります。
マテリアルの色や透明度、テクスチャ画像などは、一般に別のMTLファイルへ記録されます。OBJ側ではmtllibで参照するMTLファイルを示し、usemtlで以降の要素へ使用するマテリアル名を指定します。MTL側ではnewmtlでマテリアル定義を開始します。
たとえば、OBJ側が次の記述であれば、MTL側には同じ名前の定義が必要です。
text usemtl wall_outer
text newmtl wall_outer
空白を含まないこの例では、wall_outerを一つの識別名として扱いやすくなります。一方、次のような記述は処理系による差が生じやすくなります。
text usemtl wall outer
行末までを値として読む処理ではwall outerを一つの名前として保持できることがありますが、空白区切りのトークンを一つだけ読む処理ではwallだけが取得されることがあります。OBJ側とMTL側が同じ見た目で書かれていても、片方の解析方法が異なれば参照が成立しません。このため、公開仕様上の可否を一律に断定するより、空白を含む名前は相互運用上のリスクがあると捉えるのが安全です。
注意したいのは、目で見える半角空白だけではありません。全角空白、タブ、連続した空白、改行前の余分な空白、文字列の先頭に入った空白も、比較や置換を難しくします。多くの読み込み処理は行頭や行末の空白を除去しますが、その方法は統一されていません。したがって、末尾空白が必ず名前の一部になると断定するのではなく、不要な空白を事前に除去して解釈差を減らすことが現実的です。
また、MTLが正常に読み込まれても、点群の表示色へ反映されるとは限りません。元来のOBJでは、v行は頂点データを定義し、pやfなどの要素が頂点番号を参照します。裸のv行だけを点として表示する機能や、v x y z r g bのような頂点色の拡張表現は、読み込み側の対応に依存します。点群OBJで色が出ない場合は、マテリアル名の空白と同時に、データが点要素なのか、面を持つメッシュなのか、頂点色方式なのかを確認する必要があります。
ファイルを書き出した環境では正常でも、アップロード時の変換、サーバー側の最適化、表示用形式への変換を経ると、別の解析ライブラリが使われることがあります。その途中で空白を含む名前の扱いが変われば、作成元だけでは再現しない不具合になります。交換用の点群OBJでは、特定のソフトウェアで読めることより、複数の工程で同じ名前として解釈されることを優先した方が安全です。
修正前に理解したいOBJとMTLの参照関係
マテリアル名を変更する前に、OBJとMTLがどの情報で結び付いているかを整理します。一部分だけを書き換えると、空白はなくなっても参照関係が切れ、結果として色やテクスチャが表示されなくなるためです。
OBJ側では、一般にmtllibから始まる行でMTLファイルを参照します。
text mtllib scene_materials.mtl
その後、usemtlから始まる行で使用するマテリアルを切り替えます。
text usemtl ground_surface
MTL側では、newmtlから始まる行で対応するマテリアルを定義します。
text newmtl ground_surface
ここで、mtllibの後ろにあるものはMTLファイル名であり、usemtlとnewmtlの後ろにあるものはマテリアル名です。両者は別の対象なので、マテリアル名だけを修正する作業と、MTLファイル名を修正する作業を分けて考えます。
たとえば、次の記述は注意が必要です。
text mtllib site materials.mtl usemtl ground surface
usemtl ground surfaceは空白を含むマテリアル名として解釈する実装と、groundだけを取得する実装があり得ます。さらにmtllibは、実装や資料によって複数のライブラリ名を空白で並べる形として扱われることがあるため、site materials.mtlを空白入りの一つのファイル名として安全に表現できるとは限りません。引用符やバックスラッシュによるエスケープも、すべてのOBJ読み込み環境で共通に使える規則ではありません。MTLファイル名についても、site_materials.mtlのように空白を避ける方が相互運用しやすくなります。
修正時には、OBJ内のすべてのmtllibとusemtl、参照先MTL内のすべてのnewmtlを確認します。一つのOBJが複数のMTLを参照している場合や、複数のOBJが一つのMTLを共有している場合は、関連するファイル全体を一つのデータセットとして扱います。
名前の照合では、大文字と小文字、半角と全角、アンダースコアとハイフン、前後の空白を区別します。OBJ/MTLのすべての読み込み環境が大文字と小文字を同一視するという共通規則は期待できません。Ground_Surfaceとground_surfaceを別名として扱う前提でそろえる方が安全です。
同じ文字列に見えても、全角空白やタブが混ざっている場合があります。通常の表示では判別しにくいため、空白文字やタブを可視化できるテキスト編集環境を使うと確認しやすくなります。ただし、ファイル全体の空白を変更してはいけません。OBJの座標値や頂点番号も空白で区切られているため、対象行と名前部分を限定する必要があります。
修正前には、元の名前、修正後の名前、対象OBJ、対象MTLを対応表として残します。これにより、同じ名前が複数回現れた場合や、別のファイルから共有されている場合でも、変更漏れと重複を確認できます。
修正ルール1 空白文字を安全な区切り文字に置き換える
最初の修正ルールは、マテリアル名に含まれる空白を、運用上扱いやすい区切り文字へ置き換えることです。OBJ/MTLのすべての実装で使用可能文字が完全に統一されているわけではないため、交換用途では半角英小文字、数字、アンダースコアを中心にする方法が無難です。これは形式上の絶対条件ではなく、解釈差と文字コード問題を減らすための命名方針です。
たとえば、次の名前があるとします。
text newmtl Outer Wall North
修正後は次のようにします。
text newmtl outer_wall_north
空白を削除してouterwallnorthとすることもできますが、単語の境界が分かりにくくなります。アンダースコアを使えば、名前を一つのトークンに保ちながら意味を読み取りやすくできます。
ハイフンを含む名前がOBJ/MTLで直ちに無効になるわけではありません。したがって、ハイフンが必ず演算記号やオプションとして誤認されると断定するのは適切ではありません。ただし、社内スクリプト、データベース、別形式への変換など後工程まで含めて命名規則を一つにするなら、アンダースコアへ統一すると比較と検索が簡単になります。
置換対象には、半角空白、全角空白、タブなどを含めます。
text north wall north wall north wall
これらは見た目が似ていても文字列として異なります。連続する空白は一つのアンダースコアへまとめ、先頭と末尾の空白は削除します。north___wallや_north_wall_のような結果を残すと、参照名の照合や重複検査が複雑になります。
日本語のマテリアル名も、対応する読み込み側が同じ文字コードと文字正規化を扱えれば利用できる場合があります。しかし、元来のOBJ/MTLはASCII系のテキストとして広まった形式であり、日本語や全角記号の扱いは実装差が出やすい部分です。複数環境へ渡すデータでは、north_wallやground_surfaceのようなASCII範囲の名前へ変換すると問題を減らしやすくなります。
名称を英数字へ変える際は、同じ意味の用語を複数の表記へ分散させないようにします。たとえば「地表面」をground、ground_surface、surface_groundと案件ごとに変えると、同じ分類かどうか判断しにくくなります。変換前後の用語表を作り、使用する単語と順序を統一します。
重要なのは、置換範囲をマテリアル名へ限定することです。OBJの頂点行は次のように空白で値を区切ります。
text v 12.345 67.890 1.234
この空白をアンダースコアへ変えると、頂点座標を解析できなくなります。OBJ側はusemtl行の名前部分、MTL側はnewmtl行の名前部分を主な対象とします。MTLファイル名も変更する場合は、実ファイル名とOBJ側のmtllibを同時に更新します。
修正ルール2 OBJとMTLのマテリアル名を完全一致させる
二つ目の修正ルールは、変更後のマテリアル名をOBJ側のusemtlとMTL側のnewmtlでそろえることです。OBJだけを変更してMTLの定義を残すと、参照先が見つからず、既定色や未設定の表示になる可能性があります。
修正前が次の組み合わせだとします。
text usemtl Outer Wall
text newmtl Outer Wall
修正後は両方を同じ文字列へ変更します。
text usemtl outer_wall
text newmtl outer_wall
outer_wallとouter-wall、Outer_Wallとouter_wallは、見た目が似ていても同一文字列ではありません。読み込み側が自動的に大小文字や記号を正規化すると期待せず、書き出された文字列をそろえます。
一つのマテリアルがOBJ内で複数回使われている場合、すべてのusemtl行を同じ新名へ変更します。一部に旧名が残ると、モデルの一部だけ別の材質になったり、マテリアル未設定になったりします。大規模なメッシュでは、点や面の欠損に見えて原因を誤認することもあります。
複数のOBJが一つのMTLを共有している場合は、MTL側のnewmtlを変更するとすべてのOBJへ影響します。関連するOBJを一括して更新するか、共有MTLを複製してデータセットごとに独立させるかを事前に決めます。反対に、一つのOBJが複数のMTLを参照する場合は、異なるMTL内に同じnewmtl名がないかも確認します。
マテリアル名を変えても、map_Kdなどが参照する画像ファイル名まで同じ名前へ変える必要は通常ありません。マテリアル名と画像パスは別の値です。一括置換で画像ファイル名やディレクトリ名の一部まで書き換えると、テクスチャ参照が切れるため、対象行を限定します。
MTL内に同じnewmtl名が複数回ある状態も避けます。重複定義があると、最初の定義、最後の定義、または上書き結果のどれを採用するかが読み込み実装によって異なる場合があります。空白をアンダースコアへ変えた結果、もともと別名だったwall northとwall_northが同じ名前になる可能性があるため、変換後の重複検査が必要です。
完全一致の確認は、目視だけでなく名前集合の照合で行うと確実です。OBJからusemtlの値を抽出し、MTLからnewmtlの値を抽出して比較します。OBJで使用されているのにMTLへ定義がない名前、MTLに定義されているのにOBJから参照されない名前、重複定義された名前を分けて確認します。
修正ルール3 重複しない短い命名規則へ統一する
三つ目の修正ルールは、空白を置換するだけでなく、変換後も一意になる命名規則へ統一することです。単純な置換では、異なる元名が同じ新名へ集約されることがあります。
たとえば、次の二つが同じMTL内にあるとします。
text newmtl wall north newmtl wall_north
空白をアンダースコアへ置換すると、どちらもwall_northになります。もともと同じ材質を重複して登録していただけなら統合できる場合がありますが、色、透明度、テクスチャが異なるなら別名を維持しなければなりません。
衝突する場合は、方位、部位、状態、用途など、元データの意味に基づく識別子を付けます。
text wall_north_existing wall_north_planned
名前には識別に必要な情報だけを含めます。案件名、担当者名、作業回数などを無制限に追加すると、名前が長くなり、差し替え時に変化しやすくなります。分類と部位を一定の順序で並べ、同じ材料には同じ語を使用します。
英字は小文字へ統一し、数字を使う場合は桁数をそろえると並べ替えやすくなります。
text area_01 area_02 area_03
先頭が数字の名前をOBJ/MTLが必ず拒否するという共通規則はありません。そのため、01_groundが形式上不正だとは断定できません。ただし、後工程のデータベースやスクリプトが英字始まりの識別子を要求する場合は、ground_01のように統一すると連携しやすくなります。ここはOBJ自体の制約ではなく、利用する処理系全体の条件として決めます。
記号も、OBJ/MTLだけを見れば利用できる実装がありますが、引用符、スラッシュ、バックスラッシュ、コロンなどはファイルパスや別形式で特別な意味を持つことがあります。交換用データでは、使用文字を英小文字、数字、アンダースコアへ絞ると、後工程の例外処理を減らせます。
元名、新名、対象ファイル、変更日を記録します。修正済みOBJを再出力するとき、元ソフト側の名前が戻ってしまうことがあります。対応表があれば同じ変換を再適用でき、アップロード済みデータとの名称差を抑えられます。
同じ現場で複数の担当者が書き出す場合は、「空白を使わない」だけでなく、単語の順序と使用語も共通化します。north_wall、wall_north、n_wallが混在すると、自動照合や分類が難しくなります。規則は複雑にしすぎず、空白なし、英小文字、単語間はアンダースコア、同名禁止という基本から始めます。
修正ルール4 一括修正後にアップロード前検証を行う
四つ目の修正ルールは、名前を変更しただけで完了とせず、OBJ、MTL、画像ファイルの整合性を検証することです。置換漏れ、重複、参照先の不足、保存時の文字コード変更などが残っている可能性があります。
最初に、OBJ内のmtllibが示すMTLファイルが実際に存在するかを確認します。ファイル名を空白なしへ変更した場合は、実ファイル名とmtllibの両方が一致している必要があります。大文字と小文字を区別する環境へアップロードする可能性も考え、表記を完全にそろえます。
次に、OBJ内のすべてのusemtlについて、参照先MTLに同じnewmtlがあるかを確認します。MTL内のnewmtlが重複していないか、変換前の名前が残っていないかも調べます。
空白検査では、キーワードと値を区切る空白まで消さないようにします。次の空白は必要です。
text usemtl ground_surface
問題にしているのは、名前の内部や不要な前後空白です。
text usemtl ground surface
修正前後で、頂点行、点要素行、面行の数が意図せず変化していないことも確認します。マテリアル名だけを変更したのにv、p、fの件数が変わっている場合は、置換範囲や保存処理を誤った可能性があります。行数やファイルサイズの比較は簡易的な確認ですが、大きな破損の発見に役立ちます。
保存時の文字コードと改行コードも確認します。すべての環境が同じ文字コードへ対応するとは限りません。元データが正常に読めていた場合は、名前をASCII範囲へそろえたうえで、不要な文字コード変換を避ける方が安全です。編集ソフトが拡張子を自動追加していないかも確認します。
アップロード前には、可能であれば別の表示環境でも読み込みます。ただし、一つの表示環境で成功しただけでは、最終アップロード先での成功を保証できません。最終確認は実際のアップロード先で行い、マテリアルが切り替わる境界、既定色になりやすい部分、透明度やテクスチャを使う部分を拡大して確認します。
大容量データでは、代表的なマテリアルを含む小さなサンプルを先に作る方法が有効です。空白を修正した名前、複数のusemtl切り替え、MTLと画像参照を含む最小構成で試し、問題がなければ同じ変換規則を全体へ適用します。
手作業でマテリアル名を修正する基本手順
少数のOBJとMTLであれば、内容を確認しながら手作業で修正できます。最初に、OBJ、MTL、テクスチャ画像を含む元データ一式を複製し、元ファイルを直接上書きしないようにします。
OBJをテキストとして開き、mtllibを検索します。参照しているMTLファイルを確認し、同じデータ一式に存在するかを調べます。複数のmtllib行や複数名の記述がある場合は、すべての参照先を記録します。
次に、OBJ内のusemtlを検索します。キーワードの後ろを単純に空白で一語だけ取得するのではなく、現在の作成元がどの名前を意図しているかを確認します。空白入りの名前が使われている場合は、対応するMTLのnewmtlと照合します。
MTLを開き、newmtlを検索します。OBJ側の名前に対応する定義があるか、同じ名前が複数回定義されていないか、空白やタブが混在していないかを確認します。
変更前後の対応表を作ります。たとえば、Ground Surfaceをground_surface、North Wallをnorth_wall、Area Outsideをarea_outsideへ変更します。この時点で、新名が重複しないことを確認します。
その後、MTL側のnewmtlとOBJ側のusemtlを同じ新名へ変更します。MTLファイル名に空白があり、アップロード先で問題になる可能性がある場合は、実ファイル名とOBJのmtllibを同時に変更します。画像ファイル名やmap_Kdのパスは、必要がない限り変更しません。
置換後は旧名を再検索します。旧名がコメントや画像パスの一部にある場合は、機械的に変更せず、その行の意味を確認します。新名についてもOBJとMTLの両方を検索し、定義と使用箇所が対応しているかを確認します。
保存後は、拡張子、文字コード、改行、ファイル名を確認します。最後にOBJ、MTL、必要な画像を同じアップロード単位でまとめ、サンプル表示と本番環境での確認を行います。正常だった修正済みデータと対応表を一緒に保管すると、次回の差し替えでも同じ命名を維持できます。
大量の点群OBJを一括修正するときの注意点
多数のOBJやMTLを扱う場合は、一括処理によって作業を効率化できます。ただし、ファイル全体の空白を無条件に置換する方法は使用できません。頂点座標、法線、UV、点番号、面の頂点番号、MTLの数値設定も空白で区切られているためです。
自動処理では、行頭のキーワードを判定し、OBJのusemtlとMTLのnewmtlだけを対象にします。MTLファイル名も正規化する場合は、OBJのmtllibと実ファイル名を別工程で対応させます。
名前部分を取得するときは、処理対象の実データを先に調査します。空白入りマテリアル名を行末まで一つの名前として書き出すソフトもあれば、もともと空白を区切りとして使うデータもあります。自動処理が作成元の意図を判定できない場合は、勝手に修正せず、警告として止める方が安全です。
正規化処理では、前後空白を削除し、内部の連続した空白文字を一つのアンダースコアへ変換し、英字の大小を統一します。全角文字を英数字へ置き換える場合は、単純な自動翻訳ではなく、事前に定めた対応表を使います。
異なる元名が同じ新名になった場合は、自動的な上書きや連番追加を避けます。wall northとwall_northの衝突が発生したら、両者のMTL設定を比較し、同一材質として統合できるか、別の識別子が必要かを判断します。
処理結果には、元名、新名、対象OBJ、対象MTL、変更箇所数、警告内容を記録します。変更箇所数がゼロ、極端に多い、OBJに使用名があるのにMTLに定義がないといった結果は、対象判定や参照関係に問題がある合図です。
OBJとMTLを別々の一覧として処理するだけでは、共有関係を見落とす可能性があります。OBJのmtllibから参照先をたどり、データセット単位で検証します。同じMTLを複数OBJが共有している場合は、変更の影響範囲を先に把握します。
一括処理後は、単純なデータだけでなく、複数マテリアル、テクスチャ、透明度、点要素または面を含む代表データを抽出して確認します。サンプルで問題がないことを確認してから全体へ適用し、元データ、変換途中、検証済みを分けて保管します。
空白を修正しても読み込めない場合の確認項目
マテリアル名の空白を修正しても色が反映されない場合は、別の原因を順番に確認します。最初に、mtllibが実在するMTLファイルを参照しているか、MTLがアップロード対象に含まれているかを調べます。
OBJだけをアップロードし、外部ファイルを受け付けない環境では、形状だけが表示され、MTLや画像が反映されないことがあります。アップロード先が、OBJ、MTL、テクスチャ画像を個別選択するのか、同じフォルダ構成でまとめるのか、圧縮ファイルとして受け付けるのかを確認します。
テクスチャを使用している場合は、MTL内のmap_Kdなどが示す画像ファイル名とパスを確認します。作成元端末だけで成立する絶対パスでは、サーバー側から画像を取得できません。相対パスでも、ディレクトリ階層、大小文字、空白、特殊文字の扱いがアップロード先と合わない場合があります。
OBJの内容が純粋な点群か、点要素を持つか、面を持つメッシュかも確認します。v行だけのデータを点として表示する機能は実装依存です。p行があっても、点要素へのMTL適用を表示側が実装していない場合があります。面を持つOBJではusemtlが面の前に置かれているか、想定する範囲で切り替わっているかを確認します。
頂点色を使用している場合は、v x y z r g bのような追加値を読み込み先が扱えるかを確認します。これは広く利用される拡張表現ですが、元来のOBJ仕様に含まれる必須機能ではありません。色値を0から1として扱うか、0から255として扱うかなども、作成元と読み込み先で一致しない場合があります。
面を含むデータでは、f行の頂点参照が有効か、UVが必要なテクスチャにvtがあるか、法線の有無で表示が大きく変わっていないかを確認します。形状の一部が表示されない問題を、マテリアル欠落と取り違えないことが大切です。
MTLの定義内容も確認します。dやTrの解釈は実装差があり、透明度が意図と逆になる場合があります。Kdが背景色に近い、テクスチャ画像が透明、照明モデルの対応が限定されているといった理由で、マテリアルが未設定のように見えることもあります。
同じnewmtl名の重複、改行の欠落、制御文字、BOM、保存時の文字コード変更も確認します。特に一括編集後は、二つの行が結合していないか、newmtlやusemtlのキーワードが壊れていないかを調べます。
切り分けが難しい場合は、一つのマテリアルと少数の点または面だけを含む最小構成を作ります。最小構成で正常なら、元データの重複、参照範囲、画像パス、データ量に原因がある可能性が高まります。最小構成でも失敗する場合は、アップロード先が対応するOBJ/MTLの範囲や、点群の色表現を見直します。
点群OBJアップロードを安定させる運用方法
マテリアル名の空白問題は、書き出し後の修正だけでなく、作成段階から命名規則を統一することで再発を減らせます。最も単純な方法は、マテリアル作成時点から空白を含まない名前を使用することです。
書き出し前には、マテリアル名、オブジェクト名、グループ名、MTLファイル名、テクスチャ画像名を確認します。すべてを同じ規則へそろえる必要はありませんが、空白、全角文字、大小文字、特殊記号の扱いは共通化します。
作成環境では日本語の説明名を使い、アップロード用に書き出す段階でASCII範囲の名前へ変換する運用も可能です。その場合は、変換前後の対応表を保存し、再出力時にも同じ名前が生成されるようにします。
アップロード前検査は定型化します。mtllibの参照先が存在するか、すべてのusemtlに対応するnewmtlがあるか、変換後の名前が重複していないか、名前内部に空白が残っていないか、必要な画像がそろっているかを確認します。
さらに、データが点群、点要素、メッシュ、頂点色、MTL方式のどれを使っているかを記録します。同じOBJ拡張子でも、色の持ち方と表示対象が異なるため、マテリアル名だけを共通検査しても十分ではありません。
検査を目視だけに依存せず、名前抽出、空白検出、参照照合、重複検出を自動化すると確認漏れを減らせます。ただし、自動処理が衝突や曖昧な名前を見つけた場合は、自動で統合せず、担当者が設定内容を比較できるようにします。
差し替え時には、同じ意味のマテリアル名を維持します。内容が変わっていないのに名前だけ変えると、アップロード先の表示設定や後工程の分類が引き継がれない場合があります。名称変更が必要なら、理由と対応関係を記録します。
提出条件には、使用可能文字、名前の重複禁止、関連ファイルのまとめ方、頂点色またはMTLの対応範囲を含めます。「空白を使わない」だけでなく、どの形式で色を保持するかまで示すと、アップロード後の差し戻しを減らせます。
点群OBJは、座標だけでなく、点や面の要素、マテリアル、画像、ファイル参照が組み合わさる場合があります。LRTK Phoneを含む現場データの取り扱いを整理する際も、取得後のファイルを一式で管理し、アップロード先が対応する色表現と参照方法を事前に確認することが重要です。
まとめ
点群OBJのマテリアル名に空白が含まれていると、読み込み実装によって行末までを一つの名前として扱う場合と、最初の空白までを名前として扱う場合があり、OBJ側のusemtlとMTL側のnewmtlが一致しなくなる可能性があります。空白入りの名前がすべての環境で無効とは限りませんが、交換用データでは避けた方が安全です。
一つ目の修正ルールは、半角空白、全角空白、タブをアンダースコアなどへ置き換え、前後の不要な空白を削除することです。二つ目は、OBJ側のusemtlとMTL側のnewmtlを同じ文字列へそろえることです。
三つ目は、置換後の重複を確認し、短く一意な命名規則へ統一することです。四つ目は、mtllib、usemtl、newmtl、画像参照、点または面の要素、保存形式を確認してからアップロードすることです。
ハイフンや数字始まりがOBJ/MTLで必ず無効になるとは断定できません。使用文字を英小文字、数字、アンダースコアへ絞るのは、OBJの絶対的な制約ではなく、複数の読み込み環境や後工程で解釈差を減らすための運用ルールです。
一括処理では、ファイル全体の空白を置換してはいけません。v、p、fなどのデータも空白で区切られているため、usemtlとnewmtlの名前部分を中心に変更します。元名と新名の対応を残し、重複が見つかった場合は設定内容を確認してから新しい識別名を付けます。
空白を修正しても色が出ない場合は、MTLや画像ファイルの不足、mtllibや画像パスの不一致、重複定義、透明度、頂点色の対応、点要素へのマテリアル対応を確認します。特に、v行だけの点群、p行を持つ点群、f行を持つメッシュでは、色の適用方法が同じとは限りません。
書き出し時点から命名規則とアップロード前検査を統一し、OBJ、MTL、画像を一つのデータセットとして管理することで、環境差による読み込み不具合を減らしやすくなります。