点群OBJで頂点・UV索引不一致が起きる理由
点群OBJをアップロードしたときに、形状は表示されるものの表面の画像が大きくずれる、一部の面だけ画像が引き伸ばされる、細長い三角形が空間を横切る、途中で読み込みが停止するといった問題が起きることがあります。このような症状が出たときに確認したいのが、OBJファイル内に記録された頂点索引とUV索引の対応関係です。
OBJでは、三次元空間上の位置を表す頂点、画像上の位置を表すUV座標、面の向きに使われる法線などが、それぞれ別の配列として記録されます。頂点は一般にvで始まる行、UV座標はvtで始まる行、法線はvnで始まる行に保存されます。これらを組み合わせて面を作るのが、fで始まる面定義です。
たとえば、f 1/4 2/5 3/6という面定義がある場合、1番目の頂点には4番目のUV、2番目の頂点には5番目のUV、3番目の頂点には6番目のUVが組み合わされています。ここで重要なのは、頂点番号とUV番号が同じである必要はないことです。OBJでは、頂点索引とUV索引が独立して管理されています。
一つの三次元頂点が、複数の面から共有されることもあります。さらに、同じ三次元位置にある頂点であっても、テクスチャ画像の継ぎ目では異なるUV座標を割り当てる必要があります。そのため、同じ頂点番号が面によって異なるUV番号と組み合わされることは珍しくありません。頂点数とUV数が一致しないことも、必ずしも異常ではありません。
一方で、面定義が存在しない頂点番号を参照している、UV番号がUV座標の総数を超えている、索引番号として0が使われている、データ結合後にUV番号だけが更新されていないといった状態は、実際の不整合です。これらの問題があると、読み込み側が面と画像の正しい対応を判断できなくなります。
点群OBJアップロードで問題を切り分ける際は、「頂点とUVの件数が同じか」ではなく、「各面の各角が、存在する頂点とUVを正しい書式で参照しているか」を確認することが基本です。件数比較だけで異常判定すると、正常なOBJを誤って修正してしまうおそれがあります。
また、点群を保存したOBJと、点群から生成した面モデルのOBJは、構造が異なる場合があります。点だけを記録するOBJでは、頂点行だけが並び、面定義やUV座標が存在しないことがあります。このようなファイルに対して、面モデルと同じUV検査を適用しても意味がありません。最初に、対象ファイルが点だけを持つのか、面を持つのか、さらに画像を貼り付けるためのUVを持つのかを確認する必要があります。
点群から面を生成し、その表面に撮影画像やオルソ画像を割り当てたOBJでは、頂点、面、UV、材質、画像という複数の情報が連携しています。表示異常が起きた場合は、頂点・UV索引だけでなく、UV座標値、材質の指定、画像ファイルの配置まで段階的に確認することが大切です。
確認項目1 頂点数とUV数だけで異常判定していないか
最初の確認項目は、頂点数とUV数を単純に比較し、数が違うだけで不一致と判定していないかです。OBJの頂点とUVは独立した配列であり、原則として一対一対応を求められるものではありません。
立方体の角を考えると、三次元形状としては一つの頂点を複数の面が共有できます。しかし、その立方体の表面を平面上の画像へ展開すると、同じ角が画像上では複数の離れた位置に現れることがあります。その場合、三次元頂点は一つでも、UV座標は複数必要です。したがって、UV数が頂点数より多くても、正常な構造である可能性があります。
反対に、複数の頂点が同じUV座標を参照する構成も考えられます。単色部分や意図的に同じ画像位置を共有する面では、UV数が頂点数より少なくなる場合があります。件数差だけでは、異常かどうかを判断できません。
確認すべきなのは、面定義から参照されている索引の範囲です。正の索引だけを使うOBJで、頂点行が1万行ある場合、面定義の頂点索引は通常1から1万までの範囲に収まる必要があります。UV行が8000行であれば、UV索引は通常1から8000までの範囲で参照されます。8001以上のUV番号が出ていれば、存在しないUVを参照している可能性があります。
ただし、最大索引が総数より小さいからといって、異常とは限りません。ファイル内に使われていない頂点やUVが残っている場合、最大参照番号は総数より小さくなります。変換処理の途中で削除された面があれば、参照されない頂点やUVが残ることもあります。この状態はファイル容量の面では非効率ですが、直ちに読み込み不能になるとは限りません。
点群OBJアップロードの前には、まずv、vt、vn、fの各行数を集計します。そのうえで、面定義に含まれる頂点索引、UV索引、法線索引の最小値と最大値を別々に調べます。頂点総数とUV総数を混同せず、それぞれの配列に対して範囲確認を行うことが重要です。
また、面定義のない点群OBJでは、UV索引を確認する対象そのものが存在しません。点要素を示す記述が含まれる場合でも、点ごとの色がUVではなく頂点行の追加成分として記録されることがあります。点群の色情報が見えないからといって、すぐにUV不一致と判断するのは適切ではありません。
ファイルの用途も確認する必要があります。点群として座標だけを受け渡す目的なら、UVや画像がなくても問題ありません。一方、点群から生成した面モデルへ現場画像を貼り付ける目的なら、面定義とUV参照が必要です。用途に応じた構造になっているかを先に整理すると、不要な修正を避けられます。
頂点数とUV数の件数差は、調査の出発点にはなりますが、合否判定の基準にはできません。最終的には、各面に記録された頂点とUVの組が有効かどうかを確認します。同じ頂点番号に複数のUV番号が割り当てられていても、それが画像の継ぎ目や材質の境界に沿っているなら、正常な可能性が高いと考えられます。
確認項目2 面定義の索引書式が正しくそろっているか
OBJの面定義には、含まれる情報によって複数の書式があります。頂点だけを参照する場合はf 1 2 3、頂点とUVを参照する場合はf 1/1 2/2 3/3、頂点と法線だけを参照する場合はf 1//1 2//2 3//3、頂点・UV・法線をすべて参照する場合はf 1/1/1 2/2/2 3/3/3のように記述されます。
特に注意したいのが、斜線が二つ連続するv//vn形式です。この形式では、中央のUV索引が省略され、最後の番号が法線索引を表します。読み込み処理や変換処理がこの書式を正しく区別できないと、法線番号をUV番号として読み取ってしまうことがあります。
ファイル内で異なる書式が混在していること自体は、直ちに不正とは限りません。UVを持つ面と持たない面が、同じOBJに記録される場合もあるからです。しかし、アップロード先が混在書式に対応していない場合は、一部の面が欠落したり、読み込みが停止したりする可能性があります。
さらに問題になりやすいのは、一つの面の中で書式が不ぞろいになっているケースです。たとえば、f 10/20 11 12/22という面では、1番目と3番目の角にはUVがありますが、2番目の角にはUVがありません。このような面は、画像上の三角形を正しく決められないため、読み込み側でエラーとなる可能性があります。
f 10/20 11//21 12/22のように、頂点とUVの形式と、頂点と法線の形式が同じ面に混在している場合も注意が必要です。文字列としては斜線を含んでいても、それぞれが表す情報は異なります。面定義を検査するときは、斜線の有無だけでなく、斜線の間に番号があるかどうかまで確認しなければなりません。
面定義を自動検査する場合は、各f行を空白で区切り、各要素をさらに斜線で分解します。そして、同一面内で要素数と空欄位置が一致しているかを調べます。三角形であれば三つの角、四角形であれば四つの角が、同じ種類の索引情報を持っているかを確認します。
区切り文字にも注意が必要です。OBJでは一般に半角空白やタブで項目が区切られます。全角空白、全角の斜線、見た目の似た別の文字が混入すると、読み込み側が正しく分割できない可能性があります。手作業で編集したファイルや、表計算形式を経由して加工したファイルでは、意図しない文字への置換が起きることがあります。
面定義の途中に改行が入っていないかも確認します。大きな多角形を一行で記録した場合、行が極端に長くなります。転送や編集の途中でその行が分割されると、2行目以降がOBJの命令として認識されず、面が欠落する可能性があります。互換性を重視するなら、大きな多角形を三角形や四角形へ分割しておく方法が考えられます。
ただし、面分割を行う際には、頂点番号だけでなく、頂点とUVの組を維持しなければなりません。四角形を二つの三角形へ分割するときに、頂点の順番だけを使ってUVを新たに割り当てると、画像がねじれることがあります。元の面で指定されていた各角の組を、そのまま三角形へ引き継ぐ必要があります。
特定のグループや材質の範囲から書式が変わっている場合は、異なる条件で書き出された複数のデータが統合された可能性があります。グループを示す行や材質を切り替える行の前後を確認し、どの位置から面定義の形式が変わったかを特定すると、原因となった工程を追いやすくなります。
確認項目3 索引の開始番号と参照範囲が正しいか
OBJの正の索引は、基本的に1から始まります。最初に記録された頂点は1番、最初のUV座標も1番として参照されます。ところが、データを処理するプログラムの内部では、配列の先頭を0番として扱うことがよくあります。そのため、独自の変換処理や書き出し処理を使ったときに、内部の0始まりの番号がそのままOBJへ書き込まれることがあります。
たとえば、f 0/0 1/1 2/2という面定義がある場合、0番の頂点や0番のUVは通常存在しません。アップロード先によっては、ファイル全体の読み込みを中止することがあります。別の処理では、0を欠損値として扱い、該当面だけを無視する場合もあります。その結果、面が部分的に抜け落ちる可能性があります。
0が見つかったからといって、すべての索引へ一律に1を加えるのは危険です。ファイル全体が一貫して0始まりで書き出されているなら、補正できる可能性があります。しかし、一部の面だけに0がある場合は、未設定の値を0で出力した、データ結合時の計算を誤った、面の一部だけUVが欠落したといった別の原因が考えられます。
0始まりかどうかを判断するには、頂点索引とUV索引の最小値、最大値、出現範囲を確認します。頂点がN個あり、面定義の頂点索引が0からNマイナス1まで広く使われているなら、0始まりで書き出された可能性があります。UVも同様に、0からUV総数マイナス1まで使われているかを確認します。
ただし、未使用要素があるファイルでは、最大索引が総数より小さくなることがあります。そのため、最小値と最大値だけで断定せず、先頭付近の面を補正して表示し、元の形状や画像と一致するかを確認することが大切です。
正の索引が1から始まっていても、途中で範囲外の番号が現れることがあります。頂点が5000個しかないのに、面が5001番の頂点を参照していれば不整合です。UVが3000個しかないのに、3005番のUVを参照している場合も同様です。
範囲外の索引が一つだけ見つかった場合、その面だけを削除すれば表示できることがあります。しかし、安易な削除は形状の欠損につながります。また、最初に範囲外となった面より前で、頂点行やUV行が欠落している可能性もあります。本来存在するはずだった行が一つ欠けると、その後の参照全体がずれていることがあります。
複数のOBJを結合した場合は、索引のオフセット計算を重点的に確認します。二つ目のOBJの頂点番号には、一つ目のOBJに含まれる頂点数を加える必要があります。UV番号には、一つ目に含まれるUV数を加えます。頂点数とUV数は一致しないことがあるため、同じ加算値を使ってはいけません。
たとえば、最初のデータに頂点が1万個、UVが1万2000個ある場合、二つ目のデータの頂点索引には1万を加え、UV索引には1万2000を加える必要があります。両方へ1万を加えると、二つ目のデータのUVが、最初のデータの末尾付近を誤って参照します。形状は正常でも、表面画像だけがずれる典型的な原因になります。
結合境界を確認するには、オブジェクト名、グループ名、材質の切替、座標値の変化などを手掛かりにします。境界後の最初の面で、頂点索引とUV索引がどの番号から始まっているかを確認します。頂点番号は後半の範囲へ移っているのに、UV番号だけ小さな番号へ戻っていれば、UVオフセットの加算漏れが疑われます。
確認項目4 負の索引が行ごとの定義数で解釈されているか
OBJでは、正の索引に加えて負の索引を使うことができます。負の索引は、面定義が記述された時点までに存在する要素を、末尾から数えて参照する仕組みです。
たとえば、ある面定義の直前までに頂点が100個記録されている場合、頂点索引の-1は100番目、-2は99番目、-3は98番目を表します。UV索引も同様ですが、UVについてはその時点までのUV総数を基準に計算します。
負の索引で特に起きやすい間違いは、ファイル全体を読み終えた後の最終件数を基準にして、すべての負値を変換してしまうことです。負の索引は、その面が登場する位置までの定義数で解釈しなければなりません。
OBJの先頭にすべての頂点とUVが記録され、その後にすべての面が並ぶ構成であれば、最終件数と面記述時点の件数が一致します。しかし、頂点と面をブロックごとに交互に記録する構成では、面ごとに基準数が異なります。後から追加された頂点を含めた最終件数で計算すると、途中の面が誤った頂点を参照します。
頂点とUVで基準数が異なる点にも注意が必要です。f -3/-3 -2/-2 -1/-1と記録されていても、頂点の-3とUVの-3は、それぞれ別の配列を基準にします。その面の直前までに頂点が100個、UVが120個あるなら、頂点の-3は98番、UVの-3は118番です。
変換処理が頂点数だけを基準にしてUVの負索引まで解決すると、形状は合っているのに画像がずれることがあります。法線索引がある場合も、法線の累計数を別に保持する必要があります。
アップロード先によっては、負の索引を正しく処理できないことがあります。その場合は、アップロード前に正の索引へ変換すると安定する可能性があります。ただし、単純な文字列置換ではなく、OBJを先頭から順番に読みながら、現時点までの頂点数、UV数、法線数を記録して変換しなければなりません。
正の索引への変換後は、すべての値が1以上で、その時点までに定義された各要素の累計数以下になっていることを確認します。変換結果が0以下になる場合は、参照可能な範囲を超えて過去へ戻っていることになります。これは不正な負の索引です。
負の索引を誤って解釈した場合、離れた位置の頂点同士を結ぶ巨大な三角形ができることがあります。UV側だけが誤っている場合は、画像の一部が別の面へ貼り付いたり、一点から放射状に引き伸ばされたりします。問題がファイル全体へ均一に出るとは限らず、負の索引を使っている面だけに現れることもあります。
検査時には、負の索引を含む面の行番号を抽出し、その行の直前までにあるv、vt、vnの累計数を確認します。問題の面だけを小さなOBJとして切り出す場合は、負の索引をそのまま残すと参照基準が変わるため、切り出し前に正の索引へ変換しておく必要があります。
確認項目5 面分割やデータ結合で対応関係が崩れていないか
点群から三角形の面を生成する処理、四角形や多角形を三角形へ分割する処理、複数のOBJを統合する処理では、頂点とUVの組が崩れやすくなります。処理後に形状だけを確認し、UVの対応を確認しないと、アップロード時に初めて画像のずれへ気付くことがあります。
面の各角は、頂点番号だけで構成されているわけではありません。UVや法線がある場合は、頂点番号、UV番号、法線番号を一つの組として扱う必要があります。1/10という組と1/250という組は、同じ三次元頂点1を使っていますが、画像上では異なる位置を参照しています。
このような複数のUVを持つ頂点は、テクスチャ画像の継ぎ目で必要になります。三次元形状としては一つにつながっていても、二次元画像へ展開した際に離れた場所へ配置されることがあるためです。最適化処理で「頂点番号が同じならUVも統一できる」と判断すると、画像の継ぎ目が壊れます。
反対に、頂点とUVの組を一対一でしか扱えない形式へ変換する場合は、同じ座標の頂点を複製する必要があります。三次元位置が同じ頂点行が複数できても、各頂点へ異なるUVを割り当てるための意図的な複製であれば異常ではありません。後工程で重複頂点を自動削除すると、再びUVの継ぎ目が壊れる可能性があります。
四角形を三角形へ分割する場合も、頂点とUVの組を維持します。f 1/10 2/20 3/30 4/40という四角形を分割するなら、たとえばf 1/10 2/20 3/30とf 1/10 3/30 4/40のように、各角の組をそのまま引き継ぎます。
頂点番号だけを先に三角形へ分け、その後でUV番号を別の配列順から割り当てると、対応がずれる可能性があります。頂点の並び順を反転する場合は、UVの並び順も同じ順序で反転させなければなりません。片方だけを反転すると、画像が鏡像になったり、面の内部で交差したように見えたりします。
不要な面を削除した後に、未使用頂点や未使用UVを整理する処理にも注意が必要です。未使用頂点を削除すると、残った頂点の番号が変わります。その場合は、すべての面に記録された頂点索引を新しい番号へ更新しなければなりません。
UVも同様です。重複したUVを統合したり、使われていないUVを削除したりした場合は、全面のUV索引を更新します。頂点配列だけを再番号付けし、UV配列を元のままにすることは可能ですが、面定義にある頂点番号だけを確実に更新する必要があります。反対に、UV配列を整理した場合はUV番号だけを更新します。
データ結合では、頂点、UV、法線のオフセットを別々に計算します。一つ目のデータの頂点数とUV数が異なる場合、二つ目のデータへ加える値も異なります。この処理を一つの共通変数で行うと、どれかの配列がずれます。
また、複数の画像を使うOBJでは、同じUV範囲が材質ごとに繰り返し使われることがあります。二つ目の材質のUV番号が小さいからといって、必ずしもオフセット漏れとは限りません。実際に同じUV配列を共有している可能性もあります。材質の割り当てと画像ファイルの構成を確認したうえで判断する必要があります。
面分割や結合後の確認では、変換前後の頂点数、UV数、面数を比べるだけでなく、面ごとの頂点番号・UV番号の組を比較します。すべてを比較できないほど大きなOBJでは、データの結合境界、画像の継ぎ目、材質の切替位置、面密度が変わる位置を重点的に確認します。
確認項目6 書き出しからアップロードまでに行が欠落していないか
元の作業環境では正常に表示できるのに、点群OBJアップロード後だけエラーや表示崩れが起きる場合は、書き出しから転送までの間にファイル内容が変化していないかを確認します。
OBJはテキスト形式なので、頂点やUVが一行ずつ記録されます。転送の途中でファイルの末尾が欠けたり、長い行が途中で改行されたりすると、その後の索引参照が成立しなくなることがあります。ファイル容量が大きいほど、保存領域不足、転送中断、処理時間超過などの影響を受ける可能性があります。
まず、書き出し直後のOBJと、実際にアップロードしたOBJが同じ内容かを確認します。ファイル名や容量だけでは、内容が同一とは限りません。内容全体から算出した検査値を比較すると、1文字でも変化しているかを確認できます。
圧縮して受け渡した場合は、圧縮前のファイルと、展開後のファイルを比較します。共有領域へ保存した場合も、取得した側のファイルが元と一致しているかを確認します。転送後に自動変換や文字コード変換が行われる環境では、改行や一部の文字が変化する可能性があります。
次に、ファイル末尾を確認します。最後の頂点行やUV行が途中で切れていないか、最後の面定義が必要な数の索引を持っているかを見ます。三角形の面であれば、通常は三つの角が必要です。末尾がf 100/200 101/201のように二つの角だけで終了していれば、書き出しや転送が途中で止まった可能性があります。
行数の比較も有効です。書き出し元とアップロード対象で、v、vt、vn、fの行数をそれぞれ数えます。総行数が同じでも、行種別の内訳が異なる場合があります。たとえば、行頭に余分な文字が付いたため、vt行として認識されなくなっている可能性があります。
改行が失われ、二つの行が一つにつながることもあります。v行の末尾に次のvt行が続いてしまうと、その行全体が不正な頂点行として解釈される可能性があります。UVが一行欠けた扱いになれば、面定義の参照範囲にも影響します。
数値の書式にも注意します。小数点の記号が変わった、桁区切りが挿入された、数値の途中に空白が入ったといった変化があると、一行の項目数が変わります。非常に大きい値や小さい値が指数表記で記録され、アップロード先がその書式を処理できない場合、一部の頂点やUVが読み飛ばされる可能性もあります。
UV索引が正しいにもかかわらず画像が表示されない場合は、関連ファイルの不足も確認します。OBJにはUV座標そのものは記録できますが、どの画像を使うかは材質定義や外部画像との組み合わせで管理されることがあります。画像ファイルがない、材質定義がない、参照先のファイル名が一致しないといった場合は、UV不一致ではなくても表面が白や黒になる可能性があります。
ファイル名の大文字と小文字、拡張子、相対的な配置関係も確認します。参照上の名前と実際のファイル名が一文字でも異なると、画像を見つけられないことがあります。扱いにくい記号や過度に長いファイル名は避け、OBJ、材質定義、画像を同じ作業単位として管理すると安全です。
大容量OBJで原因箇所を特定しにくい場合は、ファイルを範囲ごとに分けて試験します。前半だけなら正常にアップロードでき、後半を追加すると失敗する場合は、追加した範囲に不正な行が含まれている可能性があります。ただし、分割時に索引を振り直すなら、頂点とUVの対応を維持する必要があります。
表示症状から不一致の原因を切り分ける方法
頂点・UV索引の問題は、表示された症状からある程度切り分けられます。形状と画像の両方が崩れるのか、形状は正しく画像だけが崩れるのかによって、優先して確認する項目が変わります。
読み込み開始直後に処理が停止し、何も表示されない場合は、先頭付近の面定義を確認します。0索引、範囲外索引、数値以外の文字、同一面内の書式混在などがあると、最初の不正面で処理が止まる可能性があります。
エラーに行番号が示される場合でも、その行だけが原因とは限りません。それより前の頂点行やUV行が欠落したため、その面で初めて範囲外参照が発生した可能性があります。エラー行の前後だけでなく、直前までの頂点数とUV数を確認します。
形状は正しいものの、画像が全体的に一定量ずれている場合は、UV索引の開始番号やオフセットを確認します。すべての面でUVが一つずつずれて見えるなら、0始まりと1始まりの取り違えが考えられます。二つ目のグループ以降だけずれる場合は、データ結合時のUVオフセット漏れが疑われます。
一部の三角形だけが空間を横切るように伸びている場合は、その面の頂点索引を確認します。三つの頂点のうち一つだけが離れた場所を参照すると、極端に細長い面ができます。座標値そのものが異常に大きい可能性もあるため、索引と参照先座標の両方を確認します。
形状は正常でも、画像だけが三角形状に引き伸ばされる場合は、UV索引またはUV座標値を確認します。一つのUVだけが画像上の遠く離れた位置を参照している、三つのUVがほぼ同一点になっている、数値が極端に大きいといった状態が考えられます。
正しい面と画像がずれた面が交互に現れる場合は、四角形を二つの三角形へ分割した処理を確認します。偶数番目と奇数番目の三角形で、UVの並び方が異なっている可能性があります。頂点順とUV順が同じ向きになっているかを見ます。
一部の面だけ画像が鏡のように反転している場合も、面の頂点順とUV順を確認します。頂点の順番だけを逆にし、UVの順番を変えていない場合、画像の向きが反転する可能性があります。
画像の継ぎ目に沿って線や裂け目が出る場合は、同じ三次元頂点に複数のUVを割り当てるべき場所が統合されていないかを確認します。形状の頂点を統合する処理によって、テクスチャの境界まで統合されると、画像が不自然につながります。
反対に、継ぎ目ではない場所へ多数の切れ目が出る場合は、本来同じUVを共有できる場所が過剰に分割されたか、別の面のUVを参照している可能性があります。材質の切替位置や画像境界と症状の位置が一致しているかを確認します。
表面が白や黒になるだけで、形状に問題がない場合は、UV索引不一致だけに原因を限定しないことが重要です。材質定義の不足、画像ファイルの不足、ファイル名の不一致、画像形式への未対応などでも同様の症状が出ます。
調査では、頂点索引、UV索引、UV座標値、材質、画像ファイルの五つを分けて確認します。頂点索引が正しく形状が正常なら、次にUV索引を見ます。UV索引が範囲内なら、参照先のUV座標値を確認します。それも正常なら、材質と画像の参照へ進みます。この順番で確認すると、原因の異なる問題を混同しにくくなります。
頂点・UV索引不一致を安全に修正する手順
頂点・UV索引の修正を行うときは、元のOBJを直接上書きしないことが重要です。OBJ、材質定義、画像ファイルを一つの組として複製し、修正用の版を作成します。元ファイルを残しておけば、修正によって別の問題が発生した場合に比較できます。
修正前には、頂点数、UV数、法線数、面数を記録します。面定義で使われている各索引の最小値と最大値、0の出現数、負の索引の出現数、範囲外参照の行番号も記録します。修正後に同じ検査を行い、意図した問題だけが解消されたかを確認します。
0始まりが原因であると判断できた場合は、対象となる索引へ1を加えます。ただし、頂点索引とUV索引を別々に確認し、どちらが0始まりなのかを判断します。両方が0始まりとは限りません。
一部の0が欠損値として使われている場合は、単純な加算では直りません。その面が本来どの頂点やUVを参照するはずだったのかを、隣接面や変換前データから確認します。元データから再書き出しできる場合は、推測による修正より再書き出しを優先した方が安全です。
データ結合時のオフセット漏れなら、結合境界以降の索引だけを修正します。頂点には先行する頂点数、UVには先行するUV数、法線には先行する法線数を加えます。頂点数をすべての索引へ共通して加えないように注意します。
負の索引を正の索引へ変換する場合は、ファイルを先頭から順に処理します。各面が登場した時点までの頂点数、UV数、法線数を基準にして、それぞれを正の番号へ変換します。変換後の番号が、その時点の定義数を超えていないかも確認します。
未使用頂点や未使用UVを削除する場合は、最初に面から使用中の索引をすべて集めます。次に、旧番号と新番号の対応表を作成します。その対応表を使って頂点行やUV行を並べ直し、すべての面定義を新番号へ更新します。
同じ座標の頂点が複数あるからといって、無条件に統合してはいけません。異なるUVが割り当てられている頂点は、テクスチャの継ぎ目を維持するために複製されている可能性があります。頂点を統合する場合は、座標だけでなくUVと法線の組まで確認します。
修正後は、文法上の検査だけでなく、表示結果も確認します。全体形状、画像の向き、画像境界、材質境界、データ結合位置、ファイルの先頭と末尾を重点的に見ます。
さらに、座標範囲や外形寸法が修正前後で変わっていないかを確認します。UVを直す作業の途中で頂点座標を誤って変更すると、画像は改善しても測量や施工に使う座標が変わってしまいます。点群OBJでは、見た目だけでなく座標の保持が重要です。
小さな範囲で修正方法を検証してから、全体へ適用する方法も有効です。問題のある面を含む小さな範囲を切り出し、修正後にアップロードできるかを確認します。成功した処理を同じ条件で全体へ適用すれば、大容量ファイルを何度も処理する負担を減らせます。
点群OBJアップロード前の検査を標準化する方法
頂点・UV索引不一致は、アップロード後の目視確認だけに頼ると発見が遅れます。アップロード前に一定の検査を行う運用を決めておくと、手戻りを減らせます。
最低限確認したいのは、v、vt、vn、fの各行数、正の索引の範囲、0索引の有無、負の索引の有無、同一面内の書式混在、数値として解釈できない項目の有無です。面を持たない点群OBJの場合は、UV検査の対象外であることも判定します。
検査結果は、合格や不合格だけでなく、問題のある行番号と内容を記録します。たとえば、「UV索引が範囲外」という結果だけでなく、どの面の何番目の角が、UV総数をいくつ超えているかを残します。具体的な情報があれば、書き出し担当者や変換処理の担当者が原因を追いやすくなります。
ファイルを受け渡す工程では、元データ、書き出し直後、アップロード直前の三段階で内容を管理すると効果的です。各段階でファイルの検査値を記録すれば、どの工程で変化したかを判断できます。
書き出し直後から不整合があれば、変換処理や出力設定を見直します。アップロード直前までは正常で、転送後に内容が変化していれば、圧縮や共有方法を確認します。ファイル自体は変化していないのにアップロード後だけ問題が出るなら、アップロード先が対応するOBJの書式やファイル構成を確認します。
OBJ、材質定義、画像のファイル名と配置も標準化します。同じ案件で古い画像と新しいOBJが混ざると、UV索引が正しくても表示が合いません。版番号や作成日を管理し、対応するファイルを一つのフォルダにまとめます。
点群から面を作る前の品質確認も欠かせません。重複点、飛び点、欠測、急激な密度差があると、面生成時に極端に細長い三角形ができることがあります。これは頂点索引の不一致ではありませんが、表示上は似た症状になります。
UVを作る前に面の形状を確認し、細長すぎる面や裏返った面を整理しておくと、画像の割り当ても安定しやすくなります。点群取得、点群整理、面生成、UV生成、OBJ書き出し、アップロードという工程ごとに確認項目を設けることが大切です。
試験用の小さなOBJを準備しておく方法もあります。単純な三角形、四角形、複数のUVを持つ頂点、複数材質、負の索引などを含む小さなファイルを使えば、アップロード環境がどの書式に対応しているかを確認できます。
実案件の大容量OBJだけで試験すると、失敗しても原因を特定しにくくなります。構造を把握できる小さな試験データで対応範囲を調べ、その結果に合わせて実案件のOBJを書き出すと、効率的にアップロードできます。
点群OBJを継続的に扱う場合は、同じ書き出し条件と検査手順を使用します。担当者ごとに設定が異なると、あるファイルは三角形、別のファイルは大きな多角形、あるファイルは正の索引、別のファイルは負の索引というように、構造がばらつきます。
構造のばらつきが増えるほど、アップロード先との相性問題や変換時の不具合が起きやすくなります。用途に合う書式を決め、頂点、UV、面、材質、画像の出力条件をそろえることが、安定運用につながります。
まとめ
点群OBJの頂点・UV索引不一致を見抜くには、頂点数とUV数が同じかどうかだけを確認しても不十分です。OBJでは、三次元位置を表す頂点と画像上の位置を表すUVが独立して管理されています。一つの頂点が複数のUVと組み合わされることもあり、件数が異なっていても正常な場合があります。
確認の基本は、各面の各角が、存在する頂点とUVを正しい書式で参照しているかを見ることです。頂点数とUV数の単純比較、面定義の書式、索引の開始番号、負の索引、面分割やデータ結合、転送中の欠落という六つの観点から順番に確認すると、原因を整理しやすくなります。
形状と画像の両方が崩れる場合は頂点索引を優先して確認し、形状が正常で画像だけがずれる場合はUV索引やUV座標値を確認します。表面が単色になる場合は、材質定義や画像ファイルの参照も確認し、すべてを索引不一致として扱わないことが大切です。
修正するときは元ファイルを保管し、頂点、UV、法線を別々の配列として扱います。面の各角に記録された組を維持し、結合時のオフセットや再番号付けを正確に行います。修正後は見た目だけでなく、座標範囲、面数、ファイル内容が意図せず変化していないかも確認します。
点群OBJアップロードを安定させるためには、取得した点群をOBJへ変換した後だけでなく、点群取得、点群整理、面生成、UV生成、書き出し、転送までを一つの工程として管理することが重要です。現場で点群を取得し、後工程で扱いやすいデータへつなげる運用を整えたい場合は、LRTK Phoneを活用した点群取得とデータ管理も選択肢になります。