点群OBJをアップロードした際に、「頂点インデックスが範囲外です」「存在しない頂点が参照されています」「面情報を解析できません」といったエラーが表示されることがあります。書き出し元では正常に見えていても、別の閲覧環境やクラウドへ渡した段階で読み込みが止まる場合があります。
頂点インデックス範囲外エラーは、OBJに記録された頂点、テクスチャ座標、法線などの一覧と、面、線、点などの要素が参照する番号の関係が成立していないときに起こります。たとえば、有効な頂点が10万個しか定義されていない時点で、面が10万1番目の頂点を参照していれば、その面を正しく構成できません。
ただし、原因は単純な番号の入力ミスだけではありません。頂点を削除した後に参照番号を更新していない場合、複数のOBJを結合するときに番号の補正を忘れた場合、v行の構文エラーで読み込み処理が停止または行を受理できなかった場合、頂点番号とUV番号や法線番号を混同した場合にも問題が発生します。
点群から作成されたOBJは、頂点数や面数が非常に多くなることがあります。そのため、一部の行に不整合があっても、テキストを目視するだけでは原因を見つけにくいのが実情です。やみくもに再書き出しを繰り返すのではなく、参照範囲、構文、属性別の番号体系、編集履歴、最小データという順番で切り分けることが重要です。
この記事では、「点群 OBJ アップロード」で解決方法を探している実務担当者に向けて、頂点インデックス範囲外エラーを直すための5つの検証手順を解説します。エラー行だけを削除して通すのではなく、形状と属性の整合性を保った修正を目指します。
点群OBJで頂点インデックス範囲外エラーが発生する仕組み
OBJは、行頭のキーワードによって頂点、テクスチャ座標、法線、面、線、点などを記録するテキスト形式です。一般的なポリゴンOBJでは、頂点位置をv、テクスチャ座標をvt、法線をvn、面をf、線をl、点要素をpで表します。OBJの要素には面だけでなく点や線も含まれるため、f行が正常でもl行やp行の参照が不正なら、読み込みに失敗する可能性があります。([The Library of Congress][1])
頂点位置は、たとえばv 1.25 2.50 3.75のように記録されます。正の頂点番号は通常1から始まり、v行が現れた順番で1、2、3と割り当てられます。f 1 2 3は、頂点1、2、3を使う面を示します。正のインデックス0は1始まりの番号体系に含まれないため、一般的なOBJの参照としては無効です。([The Library of Congress][1])
検証では、ファイル末尾までに存在するv行の総数だけを見るのではなく、各f、l、p行が現れた時点までに必要な頂点が定義済みかも確認します。OBJは先に頂点データを定義し、その番号を後続の要素から参照する構造が基本です。最終的な頂点総数以下の番号でも、参照行より後ろにしか定義がない場合は、厳格な読み込み処理で不正と判断される可能性があります。([The Library of Congress][1])
OBJでは負のインデックスも使用できます。負の番号はファイル全体の最終要素から数えるのではなく、その要素行が記録された位置までに定義済みの同種データを後ろから数えます。頂点参照の-1は、その時点で直前に定義された頂点を指します。UVと法線も、それぞれ独立した一覧を基準に解決します。ただし、負のインデックスへの対応には読み込み環境ごとの差があるため、アップロード先の仕様が不明な場合は、正の絶対番号へ変換したファイルでも比較する方が安全です。([The Library of Congress][1])
oで始まるオブジェクト名やgで始まるグループ名が途中にあっても、v、vt、vnの番号が自動的に1へ戻るわけではありません。これらの配列はOBJファイル単位で管理され、オブジェクトやグループをまたいで参照できます。グループごとに面番号を1から再開した内容を単純に連結すると、後半の形状が前半の頂点を参照したり、必要な番号が存在せず範囲外になったりします。([NVIDIA Docs][2])
点群OBJという呼び方にも注意が必要です。v行とp行で点要素を表すOBJもあれば、点群から三角形面を生成し、大量のf行を持つメッシュOBJもあります。また、頂点データだけを書いたOBJは、頂点一覧は持っていても表示対象となる点、線、面の要素を持たない状態です。読み込み先によっては空の形状として無視または拒否されるため、検証用ファイルでは点群ならp、メッシュならfを含めてデータ種別を明確にします。OBJの対応要素は読み込み環境によって異なり、面だけを受け付けて点や線を受け付けない実装もあります。([The Library of Congress][1])
頂点行の一部が不正な場合の動作も、読み込み環境によって異なります。不正行を見つけた時点で処理を中断する実装もあれば、警告を出して行を受理しない実装もあります。後者では、書き出し側が想定した頂点数と読み込み側が受理した頂点数に差が生じ、後続参照が範囲外になることがあります。「不正なv行は必ず読み飛ばされる」と断定せず、最初に報告された参照行より前の構文エラーも調べることが重要です。
検証前に保全しておきたいファイルと情報
検証を始める前に、問題が発生したOBJを複製し、変更を加えていない原本を保存します。調査中に頂点行や面行を書き換えると、当初の不整合や発生工程を追跡できなくなることがあります。元データから再書き出しできない場合は、特に原本の保全が重要です。
OBJがMTLや画像ファイルを参照している場合は、それらも同じ時点の組み合わせとして保存します。頂点インデックス範囲外エラーの直接原因が材料情報でなくても、修正後には面、UV、材料、画像の対応が保たれているかを確認する必要があります。OBJはMTLやテクスチャを外部ファイルとして参照できるため、OBJだけを差し替えると表示確認の条件が変わることがあります。([The Library of Congress][1])
エラー画面に行番号、要素名、参照番号、処理段階が表示される場合は、その内容を記録します。行番号が示されているときは、その一行だけでなく、直前までのv、vt、vnの累計数、直前のoやg、材料切り替え、行継続の有無も確認します。
ファイル容量、更新日時、書き出し日時、転送日時も記録します。転送元と転送先のバイト数が異なれば欠損を疑えますが、同じ容量でも内容が一致するとは限りません。可能であればチェックサムやハッシュ値を比較し、転送前後の内容が同一であることを確認します。
編集履歴には、頂点削除、ノイズ除去、面生成、簡略化、範囲分割、複数ファイル結合、UV削除、法線再計算、テキスト置換などを残します。頂点番号の不整合は、OBJを書き出した直後よりも、書き出し後の加工や連結で生じることが多いためです。
同じOBJを複数の読み込み環境で確認することも切り分けに役立ちます。ただし、ある環境で開けたことだけを正常判定には使えません。不正な面や未対応要素を無視する実装もあるため、表示の成否に加え、読み込み前後の頂点数、面数、線数、点数、警告内容も比較します。
検証手順1 頂点数と参照番号の範囲を照合する
最初の検証では、OBJに記録された頂点数と、f、l、pが参照する頂点番号を照合します。単純な最大値だけでなく、各要素行が現れた時点の定義済み頂点数を使うと、未来の頂点を参照している記述や、負の相対参照の不足も検出できます。
頂点数を数えるときは、最初のトークンが完全にvである行だけを対象にします。vtはテクスチャ座標、vnは法線、vpはパラメータ空間の頂点であり、幾何頂点のvとは別の一覧です。文字列がvから始まる行をすべて数えると、頂点数を過大に見積もります。([NVIDIA Docs][2])
正の頂点参照では、0を不正として検出し、番号がその行までに定義済みのv数を超えていないかを確認します。たとえば、その時点でv行が50000個なら、正の頂点参照として使用できる上限は50000です。ファイル末尾でさらに頂点が追加されていても、先に現れた面が50001を参照していれば、順序上の問題として扱います。
負の頂点参照では、その要素行より前に定義済みの頂点数をN、負の番号をiとしたとき、絶対番号はN+i+1として求められます。Nが100で-1なら100、-100なら1です。計算結果が1未満になる参照は、定義済み頂点より前を指すため範囲外です。負のUV番号と法線番号は、それぞれその行までのvt数とvn数を基準に別々に計算します。([The Library of Congress][1])
f 100/20/5 200/30/6 300/40/7のような面では、斜線で区切られた最初の値100、200、300が頂点番号です。検証手順1では、まずこの先頭値をv一覧と照合します。300/40/7全体を一つの整数として扱ってはいけません。
l行では、頂点番号だけのl 10 20 30に加え、実装やデータによって頂点/テクスチャ座標の形式が使われることがあります。頂点範囲の検証では斜線より前をvと照合し、UVを含む場合は後の手順でvtとも照合します。p行は点要素として一つ以上の頂点番号を参照するため、列挙されたすべての番号を確認します。([The Library of Congress][1])
最大参照番号が最終的な頂点総数以下でも、参照関係が正しいとは限りません。途中のv行を削除して面を更新しなければ、削除位置より後ろの番号は一つずつ前へずれます。多くの参照は範囲内に残るものの、本来とは別の頂点へ接続され、末尾付近の参照だけが範囲外になることがあります。
そのため、数値範囲の検証後には、異常に長い辺、遠く離れた領域を結ぶ面、原点へ伸びる形状、分割境界の破綻がないかも確認します。範囲内であることは必要条件ですが、正しい旧番号と新番号の対応が保たれていることまでは保証しません。
大容量OBJでは、v数、行ごとの累計v数、正負インデックス、0、範囲外参照、最初の異常行を自動的に集計します。修正前後で同じ項目を比較すると、エラーを消しただけで別の参照ずれを作っていないか判断しやすくなります。
検証手順2 面・線・点要素の構文を確認する
参照番号の範囲に明らかな問題がない場合は、f、l、pと、それらが参照するv、vt、vnの構文を確認します。数字が範囲内でも、空白、斜線、行継続、見えない文字、欠損によって意図と異なる解析になることがあります。
面は一般に三つ以上の頂点参照を必要とします。f 12 13 14は三角形ですが、f 12 13は面として成立しません。線は少なくとも二つの頂点参照、点要素は一つ以上の頂点参照を持つ形で確認します。OBJの面参照には、f 12 13 14、f 12/4 13/5 14/6、f 12//3 13//4 14//5、f 12/4/3 13/5/4 14/6/5といった形式があります。([DIRS][3])
斜線の前後へ空白を入れないことが重要です。法線だけを指定する場合は12//3とし、12/ /3のように分割しません。12/4/のように末尾だけ空欄にする記述も互換性上の問題になりやすいため、法線を使わないなら12/4、頂点だけなら12へ整理します。
インデックスは整数として記録します。f 12.0 13.0 14.0のような小数表記は、座標値としては数値でも、参照番号としては適切ではありません。全角数字、全角空白、桁区切りのカンマ、不可視の制御文字が混ざっていないかも確認します。
改行については、単に一行が長いだけで直ちに不正とは限りません。OBJ仕様には、行末のバックスラッシュを使って長い行を継続する方法があります。一方、継続記号なしでf 1 2 3が途中分割された場合や、二つの命令がf 1 2 3f 4 5 6のように連結された場合は、正常な要素として解析できません。([The Library of Congress][1])
コメントは#で始まる行として扱う方法が最も互換性を確保しやすい運用です。参照トークンの途中へ注記を挿入すると、読み込み処理によっては後半を解釈できず、必要な頂点数を満たさない面になることがあります。
ファイル末尾が途中で切れていないかも確認します。f 100 200、v 12.5 4.2、12/3/のような不完全な行で終わっている場合は、書き出し中断や転送途中のファイルを疑います。容量の比較に加え、末尾の改行、最終命令、チェックサムも確認します。
参照先のv行には、少なくともX、Y、Zの数値が必要です。標準的なOBJでは追加成分を持つ表現や、頂点色を後置する慣例もあるため、数値が三つを超えるだけで一律に削除してはいけません。アップロード先が受け付ける構文を確認し、必要なら互換性の高いX、Y、Zだけの検証ファイルを別に作ります。([The Library of Congress][1])
小数点としてカンマを使ったv 12,5 4,2 8,1は、多くのOBJ読み込み処理で三つの浮動小数点数として扱えません。科学表記は処理できる実装もありますが、対応状況は一律ではありません。問題の切り分けでは、同じ値を一般的な小数表記へ変換した小規模ファイルでも比較します。
エラー行だけを削除して終わらせないことも重要です。報告された面行より前にある頂点定義が不正で、読み込み処理が中断している可能性や、受理されたデータ数が書き出し側の想定と異なる可能性があります。最初の警告や構文エラーから順番に調べます。
検証手順3 頂点・UV・法線の番号体系を分けて調べる
OBJでは、頂点、UVとして使われるテクスチャ座標、法線が別々の配列として記録されます。三種類の番号は独立しており、件数が一致する必要はありません。f 500/700/300であれば、500はv、700はvt、300はvnを参照します。([NVIDIA Docs][2])
検証では、v数と各面トークンの一番目、vt数と二番目、vn数と三番目を個別に照合します。エラーメッセージが「頂点インデックス」とだけ表示されても、実際にはUVまたは法線の参照範囲が原因となっていることがあります。
UVを削除した場合は、vt行だけでなく、面の二番目の参照も削除または再構築します。vt行がないのにf 1/1 2/2 3/3が残っていれば、存在しないテクスチャ座標を参照しています。法線を削除した場合も、vn行がないのにf 1//1 2//2 3//3が残らないようにします。
斜線の削除は意味を変えるため注意が必要です。12//3は頂点12と法線3を参照しますが、12/3へ変えると頂点12とテクスチャ座標3を参照する意味になります。12/4/3から法線だけを外すなら12/4、UVと法線の両方を外すなら12とします。
面ごとにUVや法線の有無が異なる構成はOBJで表現できます。一方、一つの面の内部で参照形式が不規則に混在するデータは、読み込み先による解釈差を生みやすいため、書き出し元の意図とアップロード先の対応を確認します。ファイル内のすべての面を同じ形式へ無理に統一する必要はありませんが、各トークンが参照する一覧との整合は必須です。([DIRS][3])
l行に頂点/テクスチャ座標形式が含まれる場合は、線の頂点番号だけでなくUV番号もvt一覧と照合します。p行は頂点番号を確認します。法線参照は面の構文として扱い、線や点へ面と同じ三成分形式を機械的に適用しないようにします。([Paul Bourke][4])
未使用のUVや法線を削除して一覧を短くした場合は、残った要素に新しい連番を割り当て、対応する参照をすべて更新します。頂点の旧番号と新番号の対応表をUVや法線へ流用してはいけません。三種類は独立した配列であり、別々の対応表が必要です。
負の番号でも同じ考え方です。-1/-1/-1は、直前の頂点、直前のテクスチャ座標、直前の法線をそれぞれ参照します。三種類が同じ通し番号や同じ件数であることを意味しません。正の番号へ変換するときも、その面行までに定義済みのv、vt、vn数を別々に使います。
手作業の一括置換では、頂点番号を直すつもりがUV番号や法線番号まで変更されることがあります。斜線で区切られた位置を識別し、対象の番号体系だけを変換できる処理を使用します。
検証手順4 削除・分割・結合による番号ずれを確認する
頂点インデックス範囲外エラーは、書き出し後の頂点削除、範囲分割、複数OBJの結合、グループ整理、テキスト編集で発生しやすい問題です。どの工程でv、vt、vnの順序や件数が変わったかを確認します。
OBJのv行には明示的な番号が書かれていません。番号はファイル内の出現順で決まるため、途中のv行を一つ削除すると、それより後ろの頂点番号が一つずつ前へずれます。不要頂点を除去するときは、その頂点を使う面、線、点を削除または再構築し、残った頂点へ新しい連番を割り当て、全参照を旧番号から新番号へ変換します。
重複頂点の統合も同様です。座標が同じ複数頂点を一つへまとめれば頂点総数は減ります。統合処理が参照を自動更新することを確認し、v行だけを整理しないようにします。統合後には、面積がゼロの面や同じ頂点を複数回参照する面が生じていないかも確認します。
OBJを分割した場合は、切り出したファイルごとに使用頂点を抽出し、通常は1から連番を振り直します。元ファイルの頂点50001以降を新しいOBJへ移したのに、面がf 50001 50002 50003のままなら、新しいファイルの頂点数によっては範囲外になります。
複数OBJを結合するときは、後から追加するファイルの正の参照へオフセットを加えます。最初のOBJに頂点1000個があり、二つ目の面がf 1 2 3なら、頂点一覧を後ろへ追加した後はf 1001 1002 1003に変換します。単純連結では番号が範囲内に残ることもありますが、二つ目の面が一つ目の頂点を参照して形状だけが崩れます。
結合時のオフセットは番号体系ごとに異なります。最初のOBJに頂点1000個、UV1500個、法線800個がある場合、二つ目の面へ加える値はvが1000、vtが1500、vnが800です。線がUV参照を持つ場合は、その二番目の番号にもUV用オフセットを適用します。OBJのv、vt、vnは独立しつつ、ファイル内ではオブジェクトやグループをまたぐグローバルな配列として扱われます。([NVIDIA Docs][2])
oやg、usemtlの切り替えはインデックスをリセットしません。後半グループの面番号を1から再開した場合、前半の頂点を誤参照します。番号が範囲内ならエラーにならないため、グループ境界の形状確認が必要です。
負のインデックスを含むOBJでは、頂点行と要素行の並び順を変えるだけで参照先が変わります。各グループの直後にあった面をファイル末尾へまとめると、同じ-1でも別の頂点を指します。正の番号へ変換するときは、変換対象の行までに定義済みの各配列数から絶対番号を計算します。
編集前後のv、vt、vn、f、l、pの行数を比較します。頂点数だけが減って要素数がまったく変わっていない場合は、削除頂点を使う要素が残っていないか確認します。結合後の最大参照番号が一つ目のOBJの範囲内に偏っている場合は、後続ファイルへ必要なオフセットが加えられていない可能性があります。
検証手順5 最小データを再書き出して原因を切り分ける
ここまでの検証で原因が特定できない場合は、元データから小さな範囲を再書き出しし、アップロードできる最小構成を作ります。大容量のOBJを何度も編集するより、正しい最小データへ要素を一つずつ追加する方が、原因を再現しやすくなります。
点群として検証する場合は、数個以上のv行に加え、それらを参照するp行を含めます。たとえば、三つの頂点ならp 1 2 3を付けます。頂点行だけのファイルは要素を持たないため、読み込み先が空データとして拒否しても、v行の構文異常とは断定できません。点要素を受け付けないアップロード先では、点群OBJ自体が対象外である可能性も確認します。([The Library of Congress][1])
メッシュとして検証する場合は、三つの有効なv行とf 1 2 3から始めます。この最小三角形が読み込めれば、基本的な頂点と面の構文は受理されている可能性が高まります。次に実データの小範囲へ置き換え、頂点数と面数を増やします。
基本形状が成功したら、UVを追加します。UV追加後に失敗する場合は、vtの構文、面または線のUV参照、斜線の位置、正負インデックスを確認します。次に法線を追加し、vn数と面の三番目の番号を照合します。材料やグループは、その後に追加します。
小規模データが正常なら、中規模、本番規模の順で試します。本番規模だけが失敗する場合も、直ちに「容量上限」とは断定しません。特定範囲に不正参照が含まれる、書き出しが途中で切れる、アップロード先に明示された上限があるなど、複数の可能性を分けて確認します。
全体を前半と後半に分け、失敗する側をさらに半分へ分ける方法も有効です。ただし、分割のたびに頂点、UV、法線の番号を再構築しなければ、分割作業そのものが新しいエラーを作ります。元データ側で範囲選択して再書き出すか、参照更新を伴う構造的な分割処理を使います。
特定グループだけで失敗する場合は、そのグループ開始時点のv、vt、vn累計数と、最初のfまたはlの参照を確認します。番号が1へ戻っている場合は、グループごとのローカル番号をファイル全体の番号へ変換していない可能性があります。
範囲外番号が常に一定数だけ大きい場合は、オフセットの重複加算を疑います。常に一定数だけ小さい場合は、必要なオフセットが不足している可能性があります。ただし、一定差が見つかっただけで全ファイルへ一括補正せず、その差が生じた対象ファイル、グループ、番号体系を確定します。
元データから再生成できない場合は、有効な要素が実際に使用するv、vt、vnを抽出し、それぞれへ新番号を割り当てます。旧番号と新番号の対応表を三種類別々に作り、f、l、pを更新します。範囲外参照を含む要素は、元の参照先を復元できるか、要素を除去するしかないかを判断します。
範囲外の面を削除すれば読み込みが通る場合がありますが、削除は修復ではなく欠損になる可能性があります。数量算出、出来形確認、断面確認などへ使うデータでは、削除した面の位置と件数を記録し、結果へ影響しないか確認します。周辺点から面を再生成する場合も、推定形状であることを区別します。
検証用ファイルは、点要素のみ、最小三角形、UV追加、法線追加、中規模、全体など、条件が分かる別名で保存します。同じ名前を上書きし続けると、どの条件を試したか分からなくなり、アップロード先のキャッシュや履歴とも混同しやすくなります。
修正時に避けたい危険な対処方法
最も避けたいのは、範囲外番号をすべて最大頂点番号へ置換する方法です。たとえば、50001以上をすべて50000へ変えると、複数の面が同じ頂点へ集中し、面積のない面や細長い面が生じます。エラーが消えても正しい形状にはなりません。
頂点番号から一定値を一括で引く方法も、オフセット誤りの範囲と番号体系を確定していない段階では危険です。ファイルの一部だけがずれている場合、正常な面や別のグループまで変更します。UVや法線へ同じ値を適用すると、独立した配列の参照も壊します。
v行だけを削除して容量を減らす方法も避けます。頂点を削除するなら、その頂点を使うf、l、pを処理し、残る参照を新番号へ変換します。vtやvnだけを削除して面参照を残す方法も同じ理由で不適切です。
別の読み込み環境で開き、そのまま保存し直すだけの方法も注意が必要です。不正な面や未対応要素が読み込み時に破棄されていれば、欠損した状態が新しいOBJへ固定されます。保存前後の頂点数、面数、UV数、法線数、線数、点数を比較します。
アップロード成功だけを修正完了の基準にしないことも重要です。番号ずれで別の有効頂点を参照している場合、範囲外エラーは出ません。複数方向から形状を確認し、異常な長辺、離れた範囲の接続、原点への引き伸ばし、穴、UVのずれがないかを確認します。
元ファイルへ直接上書きすることも避けます。原本、検証用、修正版、アップロード用を分け、どの処理を行ったかを記録します。
エラーを再発させない点群OBJの管理方法
再発防止では、取得または生成直後の元データを変更せずに保管し、ノイズ除去や範囲削除は複製データで行います。元データがあれば、不整合を作った加工工程を外して再書き出しできます。
不要な点や面は、OBJテキストから後で行削除するのではなく、可能な限り書き出し元のデータ上で除外します。書き出し処理に頂点、UV、法線と要素参照の再構築を任せる方が、手作業の番号ずれを減らせます。
分割後は、各ファイルでv、vt、vnの件数と参照範囲を確認します。結合時は、追加するOBJごとの三種類の件数を記録し、それぞれのオフセットを個別に適用します。オブジェクト名やグループ名だけで番号範囲を判断しません。
編集後には、v、vt、vn、f、l、pの行数、正負参照の有無、0、最初の範囲外行、座標範囲を記録します。修正前後で座標の最小値と最大値が大きく変わっていないかを調べると、意図しない接続や変換を発見しやすくなります。
転送後は、容量だけでなくハッシュ値を比較します。更新日時や容量が変化している間は、書き出しや同期が完了していない可能性があるため、アップロード対象にしません。
ファイル名には、対象範囲、取得日、編集段階、書き出し条件、版番号などを含めます。複数人で作業する場合は、頂点削除、分割、結合、UV削除、法線再計算など、番号へ影響する操作と担当者を記録します。
アップロード後は全体表示だけでなく、分割境界、グループ境界、点密度が急変する場所、編集範囲の端部を拡大します。番号ずれは、処理の切り替わり位置に現れやすいためです。
点群OBJアップロード前の最終確認
アップロード直前には、書き出しと転送が完了し、検証対象のファイル版が確定していることを確認します。原本と修正版を混同せず、必要ならハッシュ値を記録します。
次に、最初のトークンがvである行を数え、f、l、pの各行について、その時点までの定義済み頂点数と参照番号を照合します。正の0、定義済み数を超える正の番号、解決結果が1未満になる負の番号を検出します。
UVを含む面や線では、vt数と対応するUV番号を照合します。法線を含む面では、vn数と三番目の番号を照合します。正負インデックスは、各要素行の位置までの累計数を番号体系ごとに使います。
面、線、点の要素数が足りているか、斜線の形式が正しいか、インデックスが整数か、継続記号なしの不自然な改行や命令連結がないかを確認します。v、vt、vnに数値以外の文字や全角区切りが混ざっていないかも調べます。
OBJを分割した場合は、各ファイルの参照を新しい配列へ再構築したかを確認します。複数OBJを結合した場合は、v、vt、vnへ別々のオフセットを適用したかを確認します。oやgの直後で番号が1へ戻っている場合は、意図した参照かを必ず調べます。
負のインデックスを含む場合は、正の番号へ変換したOBJでも比較します。アップロード先が点要素または線要素を受け付けるかも確認し、点群検証ではp、メッシュ検証では最小のfを含めます。
小規模、中規模、本番データの順で試し、失敗条件を記録します。本番だけが失敗しても、明示された上限を確認する前に容量原因と断定しません。
アップロード成功後は、頂点数、面数、線数、点数、欠損位置、異常な接続、UVや法線の表示を確認します。数値範囲が正常でも、本来とは別の頂点へ接続されている可能性があるためです。
まとめ
点群OBJの頂点インデックス範囲外エラーは、v、vt、vnの一覧と、f、l、pが参照する番号の関係が成立していないときに発生します。正のインデックスは1から始まり、オブジェクトやグループが変わっても配列番号は自動的にリセットされません。負のインデックスは、要素行の位置までに定義済みの各配列を基準に解決します。([The Library of Congress][1])
検証手順1では、最終的な頂点総数だけでなく、各要素行の時点までに定義済みの頂点数と参照を照合します。手順2では、面、線、点の要素数、斜線、整数、改行、行継続、頂点行の数値構文を確認します。
手順3では、頂点、UV、法線を独立した番号体系として調べます。面のv/vt/vnだけでなく、UV参照を持つl行も確認し、属性一覧を削除または並べ替えた場合は対応する参照を同時に更新します。
手順4では、頂点削除、分割、結合、グループ整理による番号ずれを確認します。結合時のオフセットは、頂点、UV、法線で別々に計算します。手順5では、点群ならvとp、メッシュなら三つのvと最小のfを使い、正常な最小構成から属性と範囲を段階的に追加します。
修正後は、アップロードできたことだけで完了とせず、頂点数や面数、欠損位置、異常な接続、UVや法線を確認します。エラー行の削除や最大番号への置換で通すのではなく、旧番号と新番号の対応を保って構造的に修復することが重要です。
現場で取得した点群を整理し、計測から確認、共有までの流れを効率化したい場合は、LRTK Phoneを使った点群計測の運用も確認できます。([Lefixea Irtk][5])