LRTKレフィクシア株式会社

点群OBJアップロードで頂点番号0が使えない理由と5つの修正手順

点群OBJで頂点番号0のエラーが起きる理由

点群OBJをアップロードしたときに、「頂点番号が不正です」「頂点インデックスを解釈できません」「頂点0は存在しません」といった内容のエラーが表示されることがあります。元の点群は正常に表示できていたのに、OBJ形式へ変換した途端に読み込めなくなる場合、頂点番号の付け方が原因になっている可能性があります。

OBJ形式では、座標を記録する頂点定義と、その頂点を参照する要素が別々に記述されます。頂点座標は一般に行頭の

v

で定義され、点、線、面などは

p

、

l

、

f

といった行から頂点番号を参照します。この参照番号にはOBJ形式固有のルールがあり、最初の頂点は0番ではなく1番として扱われます。

一方、プログラムや配列を扱う処理では、最初の要素を0番とする設計が広く使われています。そのため、点群変換用の処理を独自に作成した場合や、複数形式を経由してOBJを書き出した場合に、内部で使われていた0始まりの番号がそのまま出力されることがあります。すると、座標自体は正しく並んでいても、参照行に書かれた

0

をOBJの読み込み側が有効な頂点番号として扱えず、アップロードが停止します。

この問題は、単純にファイル内の0をすべて1へ置換すれば解決するものではありません。座標値には

0

や

0.000

が含まれることがあり、負の座標、テクスチャ座標、法線、コメント、ファイル名などにも数字の0が現れます。無条件に置換すると、点群の位置や形状を壊すおそれがあります。

安全に修正するには、どの種類の行で頂点番号0が使われているのかを確認し、頂点定義と参照関係を保ったまま番号を直す必要があります。本記事では、「点群 OBJ アップロード」でエラーの原因を探している実務担当者に向けて、頂点番号0が使えない理由と、データを壊さずに修正するための5つの手順を解説します。

OBJ形式の頂点番号は1から始まる

OBJ形式に記録された頂点は、ファイル内に登場した順番に番号が付くものとして解釈されます。ただし、番号は0ではなく1から始まります。最初の

v

行が頂点1、次の

v

行が頂点2、その次が頂点3です。

たとえば、ファイルに3行の頂点定義がある場合、概念上は次のような対応になります。

v 10.0 20.0 30.0

は頂点1です。

v 11.0 20.0 30.0

は頂点2です。

v 10.0 21.0 30.0

は頂点3です。

この3点を点要素として参照する場合は、

p 1 2 3

のように記述します。三角形の面として参照する場合は、

f 1 2 3

のように記述します。ここで

p 0 1 2

や

f 0 1 2

とすると、頂点0を参照することになりますが、OBJ形式では通常、そのような絶対番号の頂点は定義されていません。

頂点番号が1から始まることは、座標値そのものとは関係ありません。頂点座標が

v 0 0 0

であっても問題はありません。この行は、X座標、Y座標、Z座標がすべて0の頂点を定義しているだけです。ここに含まれる0は座標値であり、頂点番号ではありません。

問題になるのは、

p

、

l

、

f

などの参照行に書かれた0です。たとえば

p 0

は頂点0を参照しようとする記述であり、

f 0 1 2

は頂点0、頂点1、頂点2から面を作ろうとする記述です。読み込み側が仕様に沿って厳密に解析している場合、これらは不正な参照として拒否されます。

OBJでは負の頂点番号が使われることもあります。負の番号は0より前の頂点を示すという意味ではなく、参照行の位置を基準として、直前に定義された頂点から相対的に数えるための記述です。一般に

-1

は直前の頂点、

-2

はその1つ前の頂点を表します。しかし、負の番号が利用できるか、どの要素で正しく解釈されるかは読み込み環境によって差が出ることがあります。

点群OBJのアップロード互換性を優先する場合は、正の番号を1から順に使う構成が確認しやすく、トラブルの切り分けもしやすくなります。

点群データでも頂点番号が必要になる場面

点群は多数の独立した点から構成されるため、「座標を

v

行で並べるだけなら頂点番号は不要ではないか」と考えることがあります。実際、頂点座標だけを読み込んで点として表示する処理では、参照行を持たないOBJが扱われる場合もあります。

しかし、すべてのアップロード先が、

v

行だけを点群として自動認識するとは限りません。読み込み側によっては、どの頂点を点として表示するかを

p

行で明示する必要があります。また、点群を線で結んだデータ、簡易メッシュ化したデータ、面を含む測量モデルでは、

l

行や

f

行が使用されます。このとき、各要素がどの頂点を使うかを頂点番号で指定します。

点群変換の途中で三角形メッシュが生成されている場合も、頂点番号が重要になります。見た目は点群として扱っているつもりでも、書き出されたOBJには大量の

f

行が含まれていることがあります。その中に1つでも頂点番号0が混入すると、ファイル全体の解析が停止する場合があります。

点群を複数の領域に分割してから結合した場合にも注意が必要です。各領域を個別に作成した段階では、すべてのファイルが頂点1から始まっています。これらを単純に連結すると、後半の参照番号が前半の頂点を指してしまいます。結合処理が0始まりで番号を再計算していると、結合境界の最初の頂点に0が割り当てられることもあります。

頂点色を含む点群OBJでも基本的な考え方は同じです。頂点行に座標と色成分が並んでいても、その頂点を

p

や

f

から参照する番号は1始まりです。色成分の有無によって頂点番号の開始位置が変わることはありません。

点群OBJを確認するときは、「座標行に0があるか」ではなく、「参照行が0番の頂点を要求していないか」を区別することが重要です。

頂点番号0が混入する主な原因

頂点番号0が混入する代表的な原因は、変換処理内の番号体系とOBJ形式の番号体系が一致していないことです。内部データを配列として保持する処理では、最初の頂点を要素0として扱うことがあります。その配列番号を1加算せずにOBJへ出力すると、最初の頂点が0番として書き出されます。

たとえば、内部で3頂点を

0、1、2

と管理している場合、OBJへ書き出す際には

1、2、3

へ変換する必要があります。この加算処理が抜けると、

f 0 1 2

のような不正な面参照が生成されます。座標行が3行存在していても、参照行と番号体系が一致していないため、正常には読み込めません。

別の原因として、複数ファイルの統合時に使う頂点数の加算ミスがあります。前半のデータに1000頂点あり、後半のデータを追加する場合、後半の頂点1は統合後の頂点1001として参照する必要があります。加算値を999や0として処理すると、参照先がずれたり、0が発生したりします。

不要点を削除した後に、参照番号を再構築していないケースもあります。たとえば最初の頂点を除外したにもかかわらず、面や点の参照情報が元の番号のまま残ると、存在しない頂点を指す行ができます。削除後の再番号付け処理で、最初の有効頂点を0にしてしまうこともあります。

表計算データやテキストデータからOBJを組み立てるときに、行番号をそのまま頂点番号として使った場合も注意が必要です。データ行の管理番号が0から始まっていれば、出力される参照番号も0から始まります。見出し行を差し引く処理や、空行を除外する処理によって、途中から番号がずれることもあります。

さらに、面の記述には頂点番号だけでなく、テクスチャ座標番号や法線番号が組み合わされることがあります。

f 1/1/1 2/2/2 3/3/3

のような記述では、スラッシュで区切られた各値に役割があります。

f 1/0/1

のような値がある場合、頂点番号は1でも、テクスチャ座標番号が0になっています。この0も読み込みエラーの原因になる可能性があります。

エラー表示に「頂点番号0」と書かれていても、実際には複合参照のどの部分が問題なのかを確認する必要があります。行全体の構造を見ずに数値だけを置換すると、別の参照関係を壊してしまいます。

修正手順1:エラーが発生している行を特定する

最初の手順は、頂点番号0が使われている行を特定することです。ファイル全体に含まれる文字の0を検索するだけでは、座標値や色成分まで大量に検出されてしまいます。そのため、行頭の命令と数値の位置を意識して確認します。

まず、OBJファイルをテキストとして開き、

p 0

、

l 0

、

f 0

のように、参照行の先頭付近に0が現れるパターンを探します。ただし、0が行の途中にある場合や、複合参照内にある場合もあります。

f 1 0 2

や

f 1/1/1 2/0/2 3/3/3

のような記述も確認対象です。

検索するときは、数字の一部として含まれる0と、独立した番号としての0を区別します。たとえば頂点10、100、101には数字の0が含まれますが、これらは頂点番号0ではありません。前後が空白、スラッシュ、行末などで区切られた0を探す必要があります。

アップロード時のエラーに行番号が表示される場合は、その行を優先して確認します。ただし、表示された行より前の記述が原因で解析位置がずれている場合もあります。該当行だけでなく、その直前にある数行も確認すると原因を見つけやすくなります。

ファイルが大きく、手作業での確認が難しい場合は、元データを複製したうえで分割して調査します。前半と後半に分けてアップロードし、どちらでエラーが起きるかを確認する方法です。エラーが起きる側をさらに分けると、問題行の範囲を絞り込めます。

ただし、OBJを単純に途中で分割すると、後半側の参照番号が成立しなくなることがあります。調査用に分割する場合は、頂点定義と、その頂点を参照する行を一緒に扱う必要があります。面を含むOBJでは、任意の位置でファイルを切るだけでは正しい検証になりません。

問題行を見つけたら、すぐに修正せず、まずその行が

p

、

l

、

f

のどれであるかを記録します。複合参照であれば、0が頂点番号、テクスチャ座標番号、法線番号のどこにあるかも確認します。この分類が、次の手順で安全に修正するための基礎になります。

修正手順2:頂点定義と参照行の対応を確認する

問題行を特定した後は、ファイルに何個の頂点が定義されているかを確認します。OBJでは、一般に行頭が

v

の行が頂点座標です。

vt

はテクスチャ座標、

vn

は法線を表すため、単純に文字

v

で始まる行をすべて頂点として数えないようにします。

頂点定義が100行ある場合、有効な正の頂点番号の範囲は通常1から100です。参照行に0があれば範囲外であり、101以上があっても同様に範囲外です。頂点番号0だけを直しても、ほかに範囲外参照が残っていればアップロードは成功しません。

次に、参照行がどの番号体系で作られているかを確認します。たとえば最初の面が

f 0 1 2

、次が

f 0 2 3

、その後も連続して番号が使われているなら、ファイル全体が0始まりで出力されている可能性があります。この場合は、頂点参照番号を一律で1加算する修正が候補になります。

一方、ほとんどの行が1始まりで、1行だけ

f 0 125 126

となっている場合は、全体を1加算してはいけません。特定の面生成処理だけが誤った値を出している可能性があるため、その行の参照先を元データから確認する必要があります。

点要素の

p

行についても同様です。

p 0 1 2 3

と記述されており、すべての頂点を順番に点として指定しているのであれば、

p 1 2 3 4

へ直すことが考えられます。しかし、頂点定義が3行しかなければ、単純に1加算すると頂点4が範囲外になります。この場合、出力側が頂点数を誤っているか、参照行に余分な番号が含まれている可能性があります。

面参照にスラッシュが含まれる場合は、頂点、テクスチャ座標、法線の定義数をそれぞれ確認します。

f 1/1/1

の最初の1は頂点番号、2番目はテクスチャ座標番号、3番目は法線番号です。どの種類の番号を修正するかは、対応する定義行の数と開始番号を見て判断します。

頂点番号だけが0始まりで、テクスチャ座標番号と法線番号は1始まりというファイルもあり得ます。その場合、スラッシュで区切られたすべての数字を一律に加算すると、正常だった情報までずれてしまいます。複合参照では、各位置を別々の項目として扱うことが重要です。

修正手順3:0始まりの番号を1始まりへ変換する

ファイル全体の頂点参照が0始まりであることを確認できたら、参照番号を1始まりへ変換します。基本的な考え方は、頂点を参照している正の番号へ1を加えることです。

内部番号が

0、1、2

なら、OBJ上では

1、2、3

にします。

f 0 1 2

は

f 1 2 3

となり、

p 0 1 2

も

p 1 2 3

となります。ただし、これは参照番号の並び全体が0始まりである場合に限った修正です。

座標を定義する

v

行の数値には加算しません。

v 0.000 12.500 3.200

の先頭の0はX座標です。これを1へ変更すると、点の位置が1単位移動してしまいます。頂点番号は

v

行に直接書かれているのではなく、ファイル内での登場順によって決まります。

頂点色を含む

v

行にも同じ注意が必要です。座標の後ろに色成分が記録されている場合、0は色の最小値などとして使われている可能性があります。色成分を1へ置換すれば、表示色が変化します。頂点番号の修正対象は、参照命令の引数だけです。

複合参照では、修正対象を位置ごとに分けます。たとえば

f 0/0/0 1/1/1 2/2/2

があり、頂点、テクスチャ座標、法線のすべてが0始まりで出力されていることを確認できた場合は、

f 1/1/1 2/2/2 3/3/3

へ変換します。

一方、

f 0/1/1 1/2/2 2/3/3

のように、頂点番号だけが0始まりで、ほかは1始まりであれば、修正後は

f 1/1/1 2/2/2 3/3/3

となります。各数字へ無条件に1を加えるのではなく、スラッシュの前にある頂点番号だけを変換します。

一括変換を行う場合は、必ず元ファイルを保存しておきます。上書き後に参照関係のずれが見つかると、元の番号体系を復元するのが難しくなるためです。修正版は別名で保存し、変換前後のファイルを比較できる状態にします。

変換後は、最小の参照番号が1になっていることだけでなく、最大の参照番号が頂点定義数を超えていないことも確認します。すべての番号へ1を加えた結果、最大番号が頂点数より1大きくなった場合は、元の参照行に余分な番号が含まれていたか、頂点定義が不足している可能性があります。

修正手順4:範囲外参照と負の番号を点検する

頂点番号0を修正した後は、ほかの不正な参照がないかを確認します。アップロード処理は最初に見つけたエラーだけを表示することがあるため、0を直すと次に別の範囲外番号が検出される場合があります。

正の頂点番号は、定義済みの頂点数の範囲内でなければなりません。頂点が5000個なら、参照できる正の番号は通常1から5000です。5001以上の番号があれば、存在しない頂点を指しています。

この範囲外参照は、点の削除や間引きの後に起きやすい問題です。元の点群に5000点あり、1000点を削除した結果、頂点定義が4000行になっていても、参照行が元の番号を保持していれば4001以上の番号が残ります。頂点を削除するときは、参照番号も再構築する必要があります。

負の頂点番号が含まれている場合は、その意図を確認します。OBJ形式では負の番号による相対参照が使われることがありますが、アップロード先によっては対応状況が異なる可能性があります。互換性を高めたい場合は、負の番号を対応する正の絶対番号へ変換する方法があります。

負の番号を正の番号へ変換する際は、ファイル全体の最終頂点数だけを基準にしてはいけません。負の番号は、その参照行より前に定義されている頂点を基準として解釈されます。ファイルの途中で頂点定義と面定義が交互に現れる構成では、各参照行の位置までに何個の頂点が定義されているかを数える必要があります。

たとえば、ある

f

行までに100個の頂点が定義されている場合、一般的には

-1

が頂点100、

-2

が頂点99、

-3

が頂点98に対応します。すべての頂点がファイル冒頭にまとめて定義されている場合は計算しやすいものの、途中に追加の

v

行がある構成では変換を慎重に行います。

また、

-0

のような表現が出力されている場合も確認が必要です。数値処理上は0と同じように扱われることがあり、有効な相対参照にはなりません。符号が付いていても、参照先として成立するとは限りません。

テクスチャ座標番号や法線番号についても、それぞれの定義数に収まっているかを確認します。頂点番号が正常でも、存在しない

vt

や

vn

を参照していると、読み込みに失敗したり、一部の面が欠落したりすることがあります。

点群として利用するだけで、テクスチャ座標や法線が不要な場合は、元データを複製したうえで、不要な複合参照を整理した検証用ファイルを作る方法もあります。ただし、面の外観や陰影に必要な情報を削除すると表示結果が変わるため、用途を確認してから行います。

修正手順5:小さな検証用OBJで再アップロードする

大容量の点群OBJを修正した直後に、そのまま全量アップロードすると、結果が分かるまで時間がかかることがあります。また、アップロードが失敗した場合に、頂点番号の修正が不十分なのか、容量や通信など別の問題なのかを区別しにくくなります。

そこで、同じ記述形式を保った小さな検証用OBJを作成します。数個から数十個程度の頂点を残し、それらを参照する

p

、

l

、

f

行だけを含めます。頂点色、法線、テクスチャ座標を使用している場合は、実データと同じ構造を少量だけ残します。

検証用ファイルでは、最初の頂点番号が1であること、最大番号が頂点数以内であること、0番参照がないことを確認します。面を含む場合は、各面が少なくとも必要な数の頂点を参照しているかも確認します。

小さなファイルが正常にアップロードできた場合、OBJの基本構造と番号体系は受け入れられている可能性が高いと考えられます。次に頂点数を増やしたファイルを試し、どの段階で問題が再発するかを確認します。

小さなファイルでも同じエラーが出る場合は、頂点番号以外の書式を確認します。空白やタブの扱い、行末の不要文字、数値以外の文字列、行頭命令の誤記、文字コードなどが影響している可能性があります。

検証用OBJを作る際は、元ファイルの先頭部分だけを切り出せばよいとは限りません。先頭の頂点定義だけを残し、後半の面参照を残してしまうと、存在しない頂点番号が発生します。残した頂点だけを参照する要素を選び、定義と参照を一組として抽出します。

点群が

v

行と

p

行から構成されている場合は、残した頂点数に合わせて

p

行を書き直します。たとえば10個の頂点を残したなら、参照番号は1から10の範囲に収めます。

検証用ファイルが成功したら、同じ変換規則を全量データへ適用します。全量版では、頂点数、点要素数、線要素数、面要素数が想定と一致しているかを確認してからアップロードします。

頂点番号を一括修正するときの注意点

大規模な点群OBJでは、参照行が数万行から数百万行に及ぶことがあります。この規模を手作業で直すのは現実的ではないため、テキスト処理や変換処理を使って一括修正することになります。

一括修正で最も重要なのは、行の種類を判定してから数値を変更することです。

v

行、

vt

行、

vn

行、コメント行、マテリアル関連の行などには、頂点参照以外の数値が含まれます。これらを修正対象に含めると、座標、色、法線、設定値などが変化します。

点要素だけを修正する場合は

p

行、線要素は

l

行、面要素は

f

行を対象にします。ただし、

l

行には頂点番号とテクスチャ座標番号が組み合わされる構成があり、

f

行にはスラッシュを使った複合参照があります。単純に空白で分割して数字へ1を加えるだけでは不十分な場合があります。

ファイル内に複数のオブジェクトやグループが含まれていても、頂点番号がグループごとに1へ戻るとは限りません。OBJでは、ファイル内で定義された頂点を通して参照する構成が一般的です。グループの切り替わりを見て番号を0や1へ戻すと、後半の要素が前半の頂点を参照したり、範囲外になったりします。

複数のOBJを統合する場合は、追加前に存在する頂点数をオフセットとして参照番号へ加えます。1つ目のOBJに3000頂点あるなら、2つ目のOBJの頂点1は統合後の頂点3001になります。2つ目の参照番号が0始まりの場合は、まず1始まりへ直し、その後に既存頂点数を加える考え方が分かりやすくなります。

変換後の検証では、番号の最小値と最大値だけでなく、各参照行の構文も確認します。数字が連結されていないか、スラッシュが重複していないか、行末に不要な区切りが付いていないかを点検します。

一括処理の前後でファイル容量が大幅に変わった場合も注意が必要です。番号が1桁増えることでわずかに容量が増えることはありますが、極端な増減があれば、改行の重複、行の欠落、文字コードの変更などが起きている可能性があります。

修正後のOBJを保存する際は、テキストとして扱える一般的な文字コードを使用し、先頭に不要な制御文字が追加されていないかも確認します。頂点番号を正しく直しても、保存方法によって別の解析エラーが発生することがあります。

修正後もアップロードできない場合の確認事項

頂点番号0を解消しても点群OBJをアップロードできない場合は、エラー原因が複数重なっている可能性があります。OBJはテキスト形式であるため、一部の記述不備がファイル全体の解析に影響します。

最初に確認したいのは、頂点定義の書式です。一般的な頂点行は、行頭の

v

に続いてX、Y、Zの座標値を記述します。区切りや小数点の表現が読み込み側の想定と合わない場合、頂点数を正しく数えられません。その結果、参照番号が範囲内であっても、存在しない頂点として扱われることがあります。

数値欄に空欄や文字列が混入していないかも確認します。座標値が取得できなかった箇所へ、欠損を表す文字がそのまま出力されていると、頂点行として認識されない場合があります。欠損点を除外した場合は、参照番号の再構築も必要です。

面を含むデータでは、1つの面に指定された頂点数や並びも影響します。同じ頂点を重複して指定した面、必要な数の異なる頂点を持たない面、交差した頂点順序などは、読み込み側によって警告やエラーの対象になることがあります。

ファイル内で参照している付属ファイルが不足している場合もあります。外観情報を別ファイルから読み込む構成では、参照名と実際のファイル名、相対位置、文字の違いなどを確認します。ただし、付属ファイルがなくても形状だけを読み込める環境と、処理を中断する環境があるため、アップロード先の仕様に合わせた確認が必要です。

ファイル容量や頂点数の上限も考慮します。小さな検証用OBJは成功するのに全量版だけが失敗する場合、番号体系ではなく、ファイル容量、処理時間、メモリ使用量、通信の中断などが関係している可能性があります。

座標値が非常に大きい場合や、小数桁が過度に多い場合も、処理負荷や表示上の問題につながることがあります。測量座標を使用する点群では、必要な精度を保ちながら、アップロード先が扱いやすい座標系や原点位置へ調整する方法を検討します。ただし、座標を移動する場合は、後で元の位置へ戻せるように移動量を記録しておきます。

アップロード後に点群が見えないだけで、処理自体は成功しているケースもあります。点の大きさ、表示範囲、視点位置、座標原点からの距離、色や透明度などを確認します。頂点番号のエラーと表示設定の問題は分けて考える必要があります。

点群OBJの書き出し段階で再発を防ぐ方法

頂点番号0の問題は、完成したOBJを後から修正するより、書き出し段階で防ぐほうが安全です。変換処理を構築するときは、内部番号とOBJ出力番号を明確に分けます。

内部データが0始まりでも、その設計自体に問題はありません。OBJへ書き出す瞬間に、参照番号へ1を加えればよいからです。重要なのは、頂点、テクスチャ座標、法線のそれぞれについて、内部番号と出力番号の変換規則を統一することです。

書き出し処理には、最小番号が1以上であること、最大番号が定義数以内であることを確認する検査を入れます。条件を満たさない参照が見つかった場合は、ファイルを完成させる前に処理を停止し、対象の行や要素を記録できるようにします。

点の削除、間引き、範囲切り出し、重複統合などを行った後は、古い番号を使い続けないようにします。残った頂点へ新しい番号を割り当て、元番号から新番号への対応を使って

p

、

l

、

f

の参照を更新します。

複数の点群を結合するときは、結合前の頂点数を記録し、追加するデータの参照番号へ正しいオフセットを加えます。頂点だけでなく、テクスチャ座標や法線を結合する場合は、それぞれ別の定義数を基準にします。

出力後には、全量ファイルをアップロードする前に、自動検査と小規模な読み込み確認を行います。頂点番号0、範囲外番号、不正な負の番号、定義されていないテクスチャ座標や法線の参照などを事前に検出できれば、アップロード後の原因調査を減らせます。

点群取得からOBJ作成まで複数の工程がある場合は、どの工程で番号体系が変わるのかを記録します。取得データの点番号、編集時の内部番号、OBJの頂点番号は、同じ数字に見えても役割が異なる場合があります。各工程の番号の意味を分けて管理すると、0始まりと1始まりの混同を防ぎやすくなります。

定期的に同じ形式の点群OBJを作る業務では、正常にアップロードできた小規模な基準ファイルを保存しておくと便利です。新しい出力結果と基準ファイルの行構造を比較することで、番号体系や区切り方の変化を早期に確認できます。

まとめ

点群OBJの頂点番号0が使えない主な理由は、OBJ形式の正の頂点参照が1から始まるためです。内部処理で最初の要素を0番として管理していても、その番号を変換せずにOBJへ書き出すと、

p 0

や

f 0 1 2

のような不正な参照が生成されます。

修正では、最初に0が含まれる参照行を特定し、頂点定義数と参照番号の関係を確認します。ファイル全体が0始まりであることを確認できた場合は、頂点参照番号を1始まりへ変換します。その後、最大番号が頂点数を超えていないか、負の番号や複合参照に問題がないかを点検します。

修正後は、いきなり大容量のファイルをアップロードするのではなく、同じ構造を持つ小さな検証用OBJで確認することが重要です。小規模ファイルが成功すれば、番号体系と基本構文の問題を切り分けやすくなります。

また、座標行に含まれる0と、頂点参照番号として使われる0は別物です。ファイル内の0を一律に置換すると、座標、色、法線、テクスチャ情報などを壊す可能性があります。行の種類と数値の役割を判定し、参照番号だけを修正しなければなりません。

再発を防ぐには、OBJを書き出す処理の中で、0始まりの内部番号を1始まりの出力番号へ変換し、参照範囲を自動検査する仕組みを設けます。点の削除や統合後には必ず番号を再構築し、複数データの結合時には既存頂点数を正しく加算します。

点群OBJのアップロードは、番号体系だけでなく、座標の扱い、ファイル容量、点密度、色、付属情報なども結果に影響します。現場で取得した点群を扱いやすい形で整理し、共有や確認につなげたい場合は、LRTK Phoneを活用した点群取得からデータ運用までの流れもあわせて検討すると、作業工程を整理しやすくなります。

現場を3Dで残して、あとから測る。
実際の画面と動画で使い方を確認できます。

LRTK Phoneの使い方・実例を見る
資料請求導入相談
現場をスマホで3DスキャンLRTK Phone実例を見る