点群から生成したメッシュをOBJ形式でアップロードしたところ、形状は正しく表示されるのに、写真の模様だけが横へずれる、上下が反転する、複数の面に同じ画像が繰り返される、といった問題が起こることがあります。こうした現象は一般に「UVがずれる」と表現されますが、実際にはUV座標そのものだけでなく、OBJファイル、MTLファイル、テクスチャ画像、アップロード先の描画仕様のいずれかに原因がある場合があります。
点群OBJアップロードの実務では、形状データだけを確認して作業を終えると、アップロード後にテクスチャの不整合が見つかり、再出力や再送信が必要になりがちです。特に、点群から三角形メッシュを生成した後で面を削減した場合、別名保存を繰り返した場合、テクスチャ画像を軽量化した場合は、形状と画像の対応関係が崩れていないかを丁寧に確認する必要があります。
この記事では、点群OBJアップロード後にUVがずれる代表的な原因を整理し、ファイル構成の確認からUV座標の補正、テクスチャ画像の復元、トポロジーを保った再出力まで、4つの修正法を実務の順序に沿って解説します。特定のソフトウェアに依存しない考え方としてまとめているため、利用中の3D編集環境やアップロード先に合わせて確認項目を置き換えながら進められます。
点群OBJでUVがずれる仕組みを理解する
OBJ形式では、立体の頂点座標とテクスチャ座標は別々の情報として記録されます。頂点座標は主に
v
で始まる行、テクスチャ座標は主に
vt
で始まる行に格納され、面を表す
f
の行が、それぞれの頂点番号とUV番号を組み合わせて参照します。つまり、立体の形が正しいことと、画像が正しい位置に貼られることは別の問題です。頂点の並びが合っていても、面が参照するUV番号が違えば、テクスチャだけがずれて見えます。
また、OBJ単体に画像が埋め込まれているとは限りません。一般的にはOBJからMTLファイルを参照し、MTLファイルからテクスチャ画像を参照する構成が使われます。OBJ内の
mtllib
がMTLファイルを指定し、面のまとまりに対する
usemtl
が使用する材質を指定します。MTL内では
map_Kd
などの記述によって画像ファイルが指定されます。この連鎖のどこかが古いファイルを向いていたり、ファイル名の大文字小文字が一致していなかったりすると、意図した画像が読み込まれないことがあります。
UV座標は一般に横方向をU、縦方向をVとして扱います。多くのデータでは0から1付近の範囲に収まりますが、必ずその範囲内でなければならないわけではありません。範囲外の値を繰り返し表示として扱う環境もあれば、端の画素に固定する環境もあります。そのため、編集環境では正常に見えていたモデルが、別のアップロード先では模様が繰り返されたり、端に引き伸ばされたりすることがあります。
なお、面情報を持たない純粋な点だけのOBJでは、一般的な面へのUVマッピングをそのまま利用できない場合があります。点群OBJという呼び方をしていても、実際の対象が点群から生成した三角形メッシュなのか、点だけを記録したOBJなのかを最初に区別することが重要です。面が存在しないデータで画像が表示されない場合は、UVのずれではなく、アップロード先が点ごとの色や点スプライトに対応していない可能性も考えられます。
修正前に症状を分類する
UVの不具合を効率よく直すには、最初からUVを全面的に作り直すのではなく、見え方から原因の範囲を絞ることが大切です。モデル全体の画像が同じ量だけ横や縦へ移動している場合は、UV全体のオフセットやMTL側の変換指定が疑われます。上下だけが逆になっている場合は、V方向の原点解釈が異なる可能性が高くなります。特定の面だけが飛び地のような画像を参照している場合は、面とUVインデックスの対応が崩れている可能性があります。
画像が細かく反復して見える場合は、UV値が0から1の範囲を大きく超えているか、アップロード先が範囲外のUVを繰り返し表示している可能性があります。反対に、画像の端が引き伸ばされたように見える場合は、範囲外のUVが端の画素へ固定されている可能性があります。同じOBJでも表示環境によって症状が変わるため、編集時のプレビューだけで正常と判断しないことが重要です。
一部の領域だけ解像感が極端に低い、模様の境界が面の途中で切れる、同じ場所に複数の画像片が重なるといった症状は、テクスチャ画像の縮小や切り抜き、アトラスの再配置が関係していることがあります。UVは元画像の寸法そのものではなく、画像内の相対位置を示すことが多いため、単純な縦横比維持の縮小だけなら見え方が保たれる場合があります。しかし、切り抜き、余白追加、複数画像の結合、縦横比変更を行うと、同じUV値でも指す画素位置が変わります。
切り分けでは、まず元データ、編集後データ、アップロードしたデータの三つを区別します。ファイル名だけで判断せず、更新日時、ファイル容量、頂点数、面数、UV数、画像寸法を照合します。可能であれば、アップロード前のローカル環境とアップロード後の表示を同じ視点から比較し、ずれ方が全体的か局所的かを記録します。画面の印象だけでなく、どの領域で、どの方向へ、どの程度ずれたかを言葉にしておくと、修正後の確認も行いやすくなります。
原因1：OBJ・MTL・テクスチャの組み合わせが違う
点群からメッシュとテクスチャを生成すると、OBJ、MTL、複数の画像ファイルが同時に出力されることがあります。その後、OBJだけを別のフォルダーへ移動したり、画像だけを圧縮し直したりすると、同じ案件名でも世代の異なるファイルが混在します。形状は最新のOBJ、材質は一つ前のMTL、画像はさらに古い撮影時点のものという組み合わせになると、ファイルは読み込めても、面と画像の対応が一致しません。
特に注意したいのは、ファイル名を変えた後の参照です。OBJ内で指定されたMTL名、MTL内で指定された画像名、実際のファイル名が完全に一致している必要があります。大文字と小文字、全角と半角、空白、記号、拡張子の表記が異なると、環境によっては別ファイルとして扱われます。ローカル環境では自動的に補完されて表示できても、アップロード先では厳密に判定され、画像が見つからないことがあります。
画像が見つからない場合、アップロード先が代替色や別の材質を表示することがあります。その結果、利用者はUVがずれたと感じますが、実際には正しいテクスチャが読み込まれていないだけということもあります。複数の材質が使われているモデルでは、一部の
usemtl
だけが存在しない材質名を参照し、特定の面群だけ表示がおかしくなる場合もあります。
さらに、圧縮ファイルへまとめる際にフォルダー階層が変わると、相対パスの解決に失敗することがあります。MTLが
textures/image_01.jpg
を参照しているのに、圧縮後は画像がOBJと同じ階層へ移動している場合、参照先は一致しません。絶対パスが残っている場合は、作業端末では表示できても、アップロード先からはその端末内の保存場所へアクセスできないため、読み込みに失敗します。
この原因の特徴は、UV編集をしていないのに突然ずれたこと、同じ形状でもファイル一式を変えると症状が変わること、材質ごとに不具合の有無が分かれることです。修正前にUVを展開し直すのではなく、まず正しい世代のファイルが一組になっているかを確認する必要があります。
原因2：UV原点や上下方向の解釈が異なる
画像は多くの場合、左上を起点として画素位置を数える考え方で扱われます。一方、3DのUV空間では、V方向の起点を下側として扱う環境もあります。この違いを編集環境や変換処理が吸収している間は問題が見えませんが、OBJを書き出して別の環境へ渡すと、V方向が反転して上下逆に表示されることがあります。
典型的な症状は、横方向の位置は合っているのに、上にあるはずの模様が下へ移り、下にあるはずの模様が上へ移る状態です。UVのV値を反転する処理は一般に
V' = 1 - V
の形で考えられますが、元のUVが0から1の範囲外にある場合や、画像に繰り返し設定がある場合は、単純反転だけで期待どおりにならないことがあります。作業前にUV範囲を確認し、どの座標系を基準にするかを決める必要があります。
上下反転だけでなく、UVの原点やオフセットの違いによって、画像全体が一定量だけ移動することもあります。MTLの画像参照に拡大率や位置補正に相当する情報が付いている場合、アップロード先がその指定へ対応していないと、編集環境と同じ表示になりません。逆に、編集環境が独自設定として保持していた変換がOBJやMTLへ十分に書き出されず、アップロード時に失われることもあります。
UVが0から1の範囲外へ伸びている場合は、表示側のラップ処理にも影響されます。繰り返し表示を前提に作った地面や壁面が、アップロード先では端固定として処理されると、画像の端が広い範囲へ引き延ばされたように見えます。反対に、端固定を想定したUVが繰り返し表示されると、細かな模様が連続して現れます。これはUV座標の値が壊れているのではなく、範囲外の座標をどう描画するかという仕様差です。
この原因を見分けるには、UV全体を表示し、島の形が保たれたまま上下または一定方向へ移動しているかを確認します。局所的に面が入れ替わっているのではなく、全体が規則的に変化しているなら、インデックス破損よりも原点、反転、スケール、オフセットの問題を優先して疑うべきです。
原因3：テクスチャ画像の寸法や余白が変わっている
UV座標が同じでも、参照する画像の内容が変われば貼り付け位置は変わります。たとえば、元画像の周囲を切り取ってから同じファイル名で保存すると、UVが指していた相対位置に別の画素が来ます。画像の左側を10パーセント切り取った場合、以前は建物の角を指していたU座標が、切り取り後には別の壁面を指す可能性があります。
単純な縮小では、縦横比と画像全体の構成が保たれていれば、UVの対応関係は維持されることがあります。しかし、縦横比を変えたリサイズ、片側だけへの余白追加、回転、上下反転を伴う保存では、UVと画素の関係が変わります。軽量化を目的に画像編集を行う際は、解像度だけでなく、キャンバス寸法、縦横比、余白、向き、色空間、保存形式をまとめて確認する必要があります。
複数のテクスチャを一枚にまとめたアトラス画像では、さらに注意が必要です。各UV島はアトラス内の特定領域を参照しているため、画像を並べ替えたり、島の間隔を詰めたりすると、UVも同じ比率で再配置しなければなりません。画像だけを再パックしてOBJ側のUVを更新しないと、別の部位の写真が貼られます。見た目としては大きなUVずれですが、原因は画像側の再配置です。
画像に余白を追加する処理も見落とされがちです。画像寸法を処理しやすい大きさへそろえるため、右側や下側へ透明または単色の余白が追加されることがあります。元の内容が画像全体の一部へ縮小配置されると、UV値は同じでも実画像の位置が変わります。アップロード先が透明部分を別の色で表示すると、ずれに加えて白い縁や黒い帯が現れることもあります。
この原因の特徴は、UV島の形や配置は正しく見えるのに、画像上の模様だけが合わないことです。元画像と現在の画像を重ねて比較し、同じ画角、同じ余白、同じ縦横比になっているかを確認すると切り分けやすくなります。画像のファイル名が同じでも中身が同じとは限らないため、寸法と内容の両方を確認することが重要です。
原因4：面の削減や再三角形化で参照関係が変わっている
点群から生成したメッシュは面数が多くなりやすいため、アップロード前に軽量化することがあります。面の削減そのものが必ずUVを壊すわけではありませんが、処理方法によっては頂点、面、UVの対応関係が再構成されます。形状の見た目がほぼ同じでも、UVの境界をまたいで頂点が統合されると、異なる画像領域を参照していた面が同じUVへまとめられ、にじみや飛びが発生します。
OBJでは、同じ空間座標にある頂点でも、面ごとに異なるUVを参照できます。これはUVシームを表現するうえで重要です。ところが、座標だけを基準に重複頂点を統合すると、本来別々に保持すべきUV境界まで一つにまとめられる場合があります。その結果、境界付近の面が不正な補間を行い、画像が斜めに引き延ばされたように見えます。
四角形以上の面を三角形へ分割する順序が変わる場合にも注意が必要です。同じ四つの頂点を持つ面でも、どちらの対角線で分割するかによって、三角形内部のUV補間結果が変わります。平面に近い部分では差が目立たなくても、歪んだ面や大きな面では、テクスチャの線が曲がったり、境界がずれたりすることがあります。編集環境とアップロード先で三角形化の方法が異なる場合、書き出し時に三角形を確定させておくほうが安定します。
面の並び替えや不要面の削除後に、OBJの
f
行が存在しないUV番号を参照すると、読み込みエラーになる場合があります。一方で、一部の環境では無効な参照を無視したり、代替値で処理したりするため、エラーにならず表示だけが崩れることもあります。頂点数、UV数、面数が大きいモデルでは目視確認が難しいため、書き出し後の検証機能で無効な参照や孤立したUVを調べることが有効です。
この原因の特徴は、特定の面やシーム周辺だけが崩れること、面削減や結合を行った後から問題が発生したこと、UVの一部が細長く伸びたり離れた場所へ飛んだりしていることです。全体反転や画像寸法の問題とは異なり、局所的で不規則なずれになりやすいため、修正にはトポロジーとUVの対応を保った再出力が必要です。
修正法1：正しいファイル一式をそろえて参照を直す
最初の修正法は、OBJ、MTL、テクスチャ画像を正しい一式としてそろえ、参照関係を整理することです。UVの再編集より負担が小さく、実際にはこの作業だけで解決するケースがあります。まず、同じ出力処理で生成されたファイルを一つの作業用フォルダーへ集めます。別の日時に生成したOBJや画像を混ぜず、元データから改めて一式を書き出す方法が安全です。
次に、OBJ内の
mtllib
が実在するMTLを指しているか確認します。MTL内では、材質名と画像参照を確認し、指定された画像が同じフォルダー構成に存在するかを見ます。アップロード先で扱いやすくするには、必要なファイルだけを簡潔な階層へまとめ、参照を相対パスにそろえる方法が適しています。端末固有の保存場所を含む絶対パスは避けます。
ファイル名は、半角英数字と必要最小限の記号で統一すると、環境差による読み違いを減らせます。大文字小文字も含めて参照記述と実ファイル名を一致させます。画像の拡張子だけを書き換えるのではなく、実際の画像形式と拡張子が一致していることも確認します。見た目上は同じ名称でも、末尾に空白が含まれていたり、似た記号が使われていたりする場合があるため、コピーと手入力を混在させないほうが安全です。
複数材質がある場合は、各
usemtl
に対応する材質定義がMTL内に存在するかを確認します。使われていない古い材質定義や画像参照は削除してもよいですが、削除前に元データを保管します。アップロード用のフォルダーを作成したら、そのフォルダーだけを別の確認環境で開き、外部フォルダーに依存せず正しく表示できるかを試します。ここで表示できなければ、アップロード前の参照関係に問題があります。
最後に、圧縮して送る場合は、圧縮前後で階層が変わっていないかを確認します。圧縮ファイルの中に不要な親フォルダーが重なっていると、アップロード先がOBJとMTLの相対位置を想定どおり解決できないことがあります。OBJ、MTL、画像を展開したときに同じ関係が保たれる構成にし、アップロード後の自動変換が完了してから表示を確認します。
修正法2：UVの上下反転・拡大縮小・オフセットを補正する
正しい画像が読み込まれており、ずれ方が全体的で規則的な場合は、UV座標を補正します。上下反転が明確で、UVが0から1を基準に配置されているなら、V方向を反転することで直る可能性があります。ただし、反転前に複製データを作り、元のUVを保持します。反転後は一部だけでなく、モデル全体とシーム周辺を確認します。
画像全体が一定量だけ横または縦へ移動している場合は、UV島をまとめて平行移動します。移動量を感覚だけで決めると再調整が増えるため、画像上の基準点を選びます。建物の角、路面標示、構造物の端など、形状と画像の両方で確認しやすい場所を複数選び、U方向とV方向の差を測ります。一点だけを合わせると回転や縮尺のずれを見逃すため、離れた位置にある複数点で整合を確認します。
画像の模様が全体的に大きすぎる、または小さすぎる場合は、UVのスケールを調整します。UV島の中心を基準に拡大縮小するのか、原点を基準にするのかで結果が変わるため、基準点を固定します。縦横比が変わって見える場合は、UとVを同じ倍率で変えるのではなく、画像側の縦横比変更がないかを先に確認します。画像が変形しているのにUVだけで合わせると、局所的には合っても別の場所でずれが残ります。
範囲外のUVが使われている場合は、アップロード先の繰り返し処理に依存しない形へ直すことも検討します。模様の反復が意図した表現なら、繰り返し回数をUVへ明示的に持たせる方法もありますが、対応仕様が異なる環境へ渡す場合は結果が変わる可能性があります。公開用データでは、重要な部分を0から1付近の範囲へ収め、必要に応じて画像側へ模様を配置する方法が安定することがあります。
補正後は、UV島が画像の境界ぎりぎりへ接していないかも確認します。画像縮小や内部変換で画素の補間が行われると、隣の領域の色が境界へにじむことがあります。複数のUV島を一枚の画像へ配置している場合は、島の周囲に十分な余白を設けます。補正は単に位置を合わせる作業ではなく、アップロード後の縮小表示や遠景表示でも境界が破綻しない状態を目指します。
修正法3：テクスチャ画像の寸法と配置を元に戻す
UVの配置が正しいのに画像内容だけが合わない場合は、テクスチャ画像を元の寸法と配置へ戻します。最も確実なのは、OBJと同時に生成された未加工の画像へ差し替えることです。元画像が残っていない場合は、編集履歴やバックアップから、切り抜き前、余白追加前、回転前の状態を探します。
画像を軽量化する必要がある場合は、縦横比とキャンバス全体の構成を維持したまま解像度を下げます。内容を切り取らず、左右や上下の余白比率を変えず、画像の向きを保持します。画像形式を変換する場合も、透明部分の扱いや色の見え方が変わることがあるため、変換後の画像を単体で確認し、さらにOBJへ割り当てた状態で確認します。
アトラス画像を再作成した場合は、画像内の各領域の位置と大きさに合わせてUVも同時に更新します。旧アトラスと新アトラスの対応表を作り、どの材質領域がどこへ移動したかを管理すると、取り違えを防げます。画像だけを差し替えて見た目を合わせるのではなく、UV島と画像領域の関係を一組として扱います。
余白追加が必要な処理では、元画像を単純に縮小して中央へ置くのではなく、UVが参照する範囲を保つ方法を選びます。どうしても内容の配置が変わる場合は、追加した余白の比率に応じてUVを変換します。たとえば、元画像が新しいキャンバスの左上領域へ縮小配置されたなら、UとVの範囲もその領域へ収まるように縮尺と位置を調整する必要があります。
画像を差し替えた後は、近景だけでなく縮小表示も確認します。高解像度では問題がなくても、縮小時に境界の色が混ざり、細いずれが見えることがあります。特に構造物の輪郭や文字、路面の線などはずれが目立ちやすいため、複数の表示倍率で確認します。また、アップロード先で画像が自動圧縮される場合は、元画像の余白や境界処理に余裕を持たせることが有効です。
修正法4：トポロジーを保ってOBJを再出力する
局所的なUV崩れや、面削減後に発生した不規則なずれは、OBJを再出力して修正します。ここで重要なのは、形状だけでなく、UVシーム、材質境界、面の三角形化を含めて保持することです。元の高密度モデルからやり直せる場合は、問題が発生する前の状態へ戻り、処理工程を一つずつ適用して、どの段階でUVが崩れるかを確認します。
面数を減らすときは、UV境界と材質境界を保護できる設定を使います。境界をまたいだ頂点統合を避け、テクスチャの特徴が大きい部分では削減率を下げます。平坦で模様が少ない領域と、構造物の輪郭や文字がある領域を同じ条件で処理すると、重要部分のUVが崩れることがあります。モデル全体の面数だけでなく、見た目に影響する領域を基準に調整します。
書き出し前に面を三角形へ確定すると、アップロード先で異なる分割が行われるリスクを減らせます。ただし、三角形化の前後でUVが保たれているかを確認します。大きく歪んだ四角形や多角形は、分割方向によって内部の見え方が変わるため、重要面では手動または制御された方法で対角線を決めることが望まれます。
OBJを書き出した後は、同じ編集環境で開き直すだけでなく、別の確認環境でも読み込みます。書き出し元が内部データを保持したまま表示していると、実際に保存されたOBJの不具合を見逃すことがあります。一度作業環境を閉じ、出力したOBJ、MTL、画像だけを使って再読込すると、保存されたファイルの状態を確認できます。
さらに、OBJ内の面参照を検証し、頂点番号とUV番号が有効範囲にあるかを確認します。存在しない番号、0として扱われる不正な番号、意図しない負数インデックス、面ごとに不足しているUV参照がないかを調べます。負数インデックス自体はOBJの表現として使われることがありますが、アップロード先によって対応状況が異なるため、互換性を重視するなら正のインデックスへ変換して出力する方法も検討します。
再出力後は、頂点数、UV数、面数、材質数、画像数を記録し、修正前と比較します。数が変わること自体は問題ではありませんが、意図しない大幅な変化があれば処理条件を見直します。最終的には、形状、UV、材質、画像を一体として検証し、アップロード先での変換後表示まで確認して完了とします。
アップロード前の検証手順を標準化する
UVずれを再発させないためには、担当者の経験だけに頼らず、アップロード前の検証手順を標準化することが重要です。まず、作業開始時に元データを複製し、編集用と保管用を分けます。OBJ、MTL、画像の世代が混ざらないよう、案件名、取得日、編集段階、出力番号を含む命名規則を決めます。ただし、長すぎる名前や特殊文字は避け、参照記述と実ファイル名を一致させます。
次に、出力直後のローカル確認を行います。形状が欠けていないか、面の向きが不自然でないか、テクスチャが全体に適用されているか、UVシーム周辺ににじみがないかを確認します。上面、側面、斜面、構造物の角など、方向の異なる領域を選び、近景と遠景の両方で見ます。モデル全体を一方向から眺めるだけでは、裏側や底面のずれを見逃します。
ファイル確認では、OBJからMTL、MTLから画像への参照が相対パスで解決できるかを見ます。作業端末の別フォルダーや一時保存場所へ依存していないことを確認し、アップロード用フォルダーだけで再読込します。画像寸法と縦横比を記録し、軽量化前後で内容の配置が変わっていないかを比較します。
その後、アップロード先と同等の条件で試験します。本番データが大きい場合は、問題が起こりやすい領域を含む小さな検証用モデルを作り、先にアップロードして仕様を確認する方法があります。UV範囲外の扱い、上下方向、画像形式、材質数、ファイル階層、面数の上限などは、利用環境によって差があるため、実データを一度に送る前に確認しておくと手戻りを減らせます。
アップロード後は、変換処理の完了を待ってから確認します。処理途中の低解像度表示や一時的な代替画像を、最終結果と誤認しないようにします。表示がおかしい場合は、同じファイルを何度も上書きするのではなく、出力番号を変えて比較できるようにします。修正内容、アップロード日時、結果を記録すると、どの変更が有効だったかを追跡できます。
検証の合格基準も明確にします。全体が表示されるだけではなく、基準点となる模様が形状上の正しい位置にあること、上下反転がないこと、材質ごとの欠落がないこと、シームに過度なにじみがないこと、遠景でも大きな破綻がないことを確認します。点群OBJアップロードでは、形状確認とテクスチャ確認を別項目として扱うことで、UV関連の見落としを減らせます。
点群取得から公開までの流れを見直す
UVずれは、アップロード直前の操作だけでなく、点群取得、メッシュ生成、写真との対応付け、テクスチャ生成、軽量化、書き出し、送信という一連の工程のどこかで生じます。そのため、最終ファイルだけを何度も直すより、工程全体を見直したほうが早く解決する場合があります。
点群取得の段階では、対象物の周囲を十分に観測し、写真の重なりや明るさの差を小さくすることが、後工程のテクスチャ品質につながります。死角が多い場所や反射の強い面では、テクスチャ生成時に画像の対応が不安定になり、UVの配置が正しくても見た目に継ぎ目が現れることがあります。これはファイル破損とは限らず、元画像の情報量や撮影条件に由来する可能性があります。
メッシュ生成後は、形状修正とUV修正の順序を決めます。大きな穴埋め、面削減、不要部分の削除を行った後で最終UVを作ると、途中のトポロジー変更による再作業を減らせます。一方、すでに高品質なUVがあるモデルを軽量化する場合は、UV境界を保護する設定を使い、工程ごとに別名保存します。
現場で取得したデータを複数の担当者が扱う場合は、どのファイルが原本で、どれが公開用かを明確にします。ファイルの受け渡しでは、OBJだけを送らず、MTLと画像を含む一式を共有します。修正履歴には、面削減、画像縮小、UV反転、材質統合など、見た目へ影響する操作を記録します。これにより、アップロード後に問題が起きても、原因となり得る変更を早く特定できます。
点群取得から位置情報の確認、データ整理、共有までを一貫して見直したい場合は、現場運用に合わせてLRTK Phoneの活用を検討する方法もあります。取得後のOBJ変換やUV調整は使用する処理環境に応じて必要になりますが、元データの管理方法と公開用データの作成手順をあらかじめ分けておくことで、点群OBJアップロード時の取り違えや再作業を減らしやすくなります。
まとめ
点群OBJアップロード後にUVがずれるときは、すぐにUVを作り直すのではなく、症状を全体的なずれと局所的な崩れに分けて確認します。全体が上下反転しているなら原点解釈、一定方向へ移動しているならオフセット、画像の内容だけが合わないなら寸法や切り抜き、特定の面だけ崩れるなら面とUVインデックスの対応を優先して疑います。
修正の基本は、正しいOBJ・MTL・画像を一式でそろえること、UVの反転・縮尺・位置を規則的に補正すること、画像の寸法と配置を元に戻すこと、トポロジーとUV境界を保ってOBJを再出力することの4点です。どの方法でも、元データを残し、修正前後を比較できる状態で進めることが重要です。
また、アップロード前に別環境で再読込し、形状とテクスチャを分けて確認すると、公開後の手戻りを減らせます。点群取得からメッシュ生成、軽量化、ファイル整理、アップロードまでの流れを標準化し、OBJ、MTL、画像を常に一組として管理してください。現場データの取得と整理の段階から運用を整えたいときは、LRTK Phoneを含めた点群活用の流れも確認し、後工程で扱いやすいデータ管理へつなげることが大切です。