点群データをOBJ形式で書き出し、クラウドや業務システムへアップロードした際に、「頂点数0」「頂点がありません」「有効な形状を検出できません」と表示されることがあります。ファイル容量が大きく、テキストとして開くと座標らしい数値が並んでいるにもかかわらず、読み込み結果では点が一つも存在しないと判定されるケースです。
この現象が起きたとき、点群データそのものが消失しているとは限りません。OBJ内に座標が残っていても、行頭の識別子、空白、数値の形式、文字コード、改行、点要素の記述などが読み込み側の想定と一致していなければ、頂点として認識されない場合があります。別形式から変換したOBJ、複数ファイルを結合したOBJ、表計算やテキスト処理を経由したOBJでは、見た目では分かりにくい構文上の問題が混入しやすいため注意が必要です。
OBJは三次元形状の交換に広く使われる行指向のテキスト形式です。ただし、OBJが定義できる点、線、面などの要素のうち、どこまでを読み込めるかは入力機能によって異なります。頂点を定義する v 行だけで点群として表示できる環境もあれば、p 行などで頂点を点要素として参照する必要がある環境もあります。面モデル専用の入力機能では、頂点だけのOBJを有効な表示対象として扱わないこともあります。
そのため、点群 OBJ アップロードの失敗を調べる際は、ファイルの有無や容量だけではなく、OBJ本体に有効な頂点行があるか、数値として解釈できるか、解析が途中で停止していないか、入力先が点群または点要素へ対応しているかを順番に切り分けることが重要です。
本記事では、点群OBJで「頂点数0」になるときに確認したい構文上の5項目を整理します。さらに、少量の確認用ファイルを使う方法、大容量データを安全に調べる手順、再出力時の注意点まで、実務で再現しやすい流れに沿って解説します。
点群OBJで「頂点数0」と表示される理由
OBJは、三次元形状に関する情報をキーワードで始まる行として記述するテキスト形式です。代表的な記述には、頂点位置を表す v、テクスチャ座標を表す vt、法線を表す vn、点要素を表す p、線要素を表す l、面要素を表す f などがあります。
点群をOBJへ保存する場合、各点のX座標、Y座標、Z座標を v 行として並べる方法が使われます。基本的な頂点行は、v 12.345 67.890 4.321 のような形です。標準的な頂点位置の記述ではX、Y、Zが必須で、必要に応じて同次座標の重みを表す w を4番目の値として付加できます。読み込み側は、行頭のキーワードと、その後ろに続く数値を解釈しながらファイルを処理します。
したがって、テキスト内に数百万組の座標値が存在していても、それらが有効な v 行として記述されていなければ、OBJの位置頂点とは認識されません。たとえば、座標が 12.345,67.890,4.321 のように並んでいるだけの場合、座標一覧としては意味があっても、そのままではOBJの頂点構文ではありません。
「頂点数0」という表示が何を数えているかは、読み込み機能によって異なります。ファイル内で定義された v 行を数える機能もあれば、点、線、面などの要素から参照され、実際の処理対象となった頂点だけを数える機能もあります。構文エラーや容量制限などで解析が中断されたときに、処理結果を0として返す実装もあり得ます。
そのため、頂点数0が表示されたからといって、直ちに「座標が一つも書き出されていない」と判断するのは早計です。まずはOBJをテキストとして確認し、行頭が v になっている座標行が存在するかを調べます。その後、座標値の形式、文字コードと改行、ファイル全体の構造、点要素の必要性という順番で確認すると、原因を絞り込みやすくなります。
頂点は読み込まれているものの、画面上に表示されないだけのケースもあります。大きな座標値をそのまま保持している場合や、単位の解釈が合っていない場合、点群が初期表示範囲から遠く離れた場所に配置されたり、極端に大きくまたは小さく表示されたりすることがあります。この場合は、頂点数が0なのか、頂点数は存在するのに形が見えないのかを分けて確認する必要があります。
構文チェック1 行頭のvと区切り文字を確認する
最初に確認するのは、各座標行が半角小文字の v をキーワードとして始まっているかどうかです。OBJの頂点位置は、通常、v と、その後ろに続く空白、X座標、Y座標、Z座標によって記述されます。
基本形は v X Y Z です。たとえば、v 100.000 200.000 15.000 という行であれば、X座標が100.000、Y座標が200.000、Z座標が15.000の頂点として解釈されます。
行頭が大文字の V になっている場合、vertex という独自の語になっている場合、座標だけが記録されている場合は、一般的なOBJの頂点行として認識されません。OBJのキーワードは似た文字で置き換えず、仕様に沿った半角小文字で記述します。
見落としやすいのが、v の前に余計な文字が付いている状態です。行番号、カンマ、引用符、全角空白、不可視の制御文字などが先頭に入ると、単純な解析処理では行のキーワードを正しく認識できない場合があります。
たとえば、座標行が "v 100.000 200.000 15.000" のように引用符で囲まれている場合、人が見れば頂点行に見えますが、OBJの記述としては引用符を含む別の文字列です。また、表形式の処理を経由したことで、1,v 100.000 200.000 15.000 のように連番が追加されている場合も、そのままではOBJの頂点構文になりません。
コメント記号にも注意が必要です。OBJでは、行頭の # で始まる行はコメントとして扱われます。# v 100.000 200.000 15.000 と書かれている場合、v と座標値が含まれていても、その行は頂点定義として処理されません。一括編集や確認作業の際に、誤って座標行をコメント化していないか確認します。
区切りには一般的な半角の空白文字を使います。複数の半角スペースやタブを空白として処理できる読み込み機能は多いものの、全角スペース、改行されない特殊な空白、文書編集機能が挿入する不可視文字などは互換性の問題になり得ます。
特に、ウェブページや文書から座標行をコピーした場合は、見た目が通常の空白に近い特殊文字が混入することがあります。目視だけで判断しにくいため、検証用ファイルでは既存の区切りを削除し、v と各座標値の間を通常の半角スペースで入力し直すと切り分けやすくなります。
行頭に半角空白やタブが入っている場合も確認します。先頭の空白を読み飛ばす実装は多いものの、1文字目からキーワードを判定する簡易的な処理では見逃される可能性があります。互換性を重視するなら、検証用OBJの頂点行は行頭の v から開始させます。
v と vt、vn の違いも重要です。vt はテクスチャ座標、vn は法線を表すため、三次元空間上の位置を定義する v の代わりにはなりません。ファイル内に vt や vn が大量に記録されていても、位置頂点を表す v 行がなければ、位置頂点数は0です。
テキスト検索を使う際は、単に文字 v を検索するのではなく、行頭のキーワードが v である行を対象にします。単純な文字検索では、vt、vn、コメント、名称に含まれる文字まで結果に含まれ、頂点行があるように見えることがあります。
確認用として数行を抜き出す場合は、次のように単純な構造へそろえます。
v 0.000 0.000 0.000
v 1.000 0.000 0.000
v 0.000 1.000 0.000
この最小構成でも頂点数0になる場合は、区切り文字以外の原因を調べます。一方、この最小構成が読み込める場合は、元ファイル内の特殊な空白、引用符、コメント化、独自の行頭文字などが原因である可能性が高まります。
構文チェック2 座標値の数と数値表記を確認する
行頭の v が正しくても、その後ろの値を数値として解釈できなければ、有効な頂点にはなりません。標準的な頂点位置の構文は v x y z [w] で、X、Y、Zの3値が必須です。4番目の w は任意で、省略時は通常1として扱われます。
まず、各 v 行に必要な座標値がそろっているかを確認します。v 10.0 20.0 のように値が2つしかない場合は、Z座標が不足しています。v 10.0 20.0 30.0 1.0 のように4値ある場合は、4番目が標準仕様の w である可能性があるため、単純に不要列と判断して削除しないようにします。
一方、X、Y、Zの後ろへRGBなどを付ける頂点カラーの記述は、元のOBJ仕様に含まれる標準構文ではなく、後から広まった拡張的な慣例です。一般的な例では、v 10.0 20.0 30.0 1.0 0.5 0.25 のようにRGBを0から1の範囲で追加しますが、対応可否や値の範囲は読み込み機能によって異なります。
そのため、色付き点群で頂点数0になる場合は、検証用コピーで色成分を除き、v X Y Z だけにして読み込みを試します。この検証で読み込めるようになった場合、座標そのものではなく、頂点カラー拡張の解釈が原因である可能性があります。
ただし、本番データから追加属性を削除する前に、その属性が後工程で必要か確認します。原因切り分け用の変更と、正式データに対する変更を分けることが重要です。また、4番目の値が w なのか、独自属性の一部なのかは出力元の仕様を確認して判断します。
小数点の表記にも注意します。座標値の小数部分には、一般的に半角のピリオドを使います。表計算処理や地域設定の影響で、123,456 のようにカンマが小数点として使われていると、OBJの数値として正しく解釈されない場合があります。
桁区切りのカンマも避けます。1,234.567 は人には読みやすい表記ですが、解析側がカンマを数値の一部として認めず、変換に失敗する可能性があります。OBJの座標値は 1234.567 のように、桁区切りを入れずに記述します。
マイナス記号、小数点、数字が全角になっていないかも確認します。日本語入力を経由した編集では、半角の - ではなく、見た目が似た全角記号や別のUnicode文字が混入することがあります。－12.500 のような値は、人が読めても一般的な数値変換で失敗する場合があります。
欠測値や計算不能値も確認対象です。座標の一部に NaN、Inf、Infinity、null などが記録されている場合、その行を通常の有限な三次元座標として扱えないことがあります。
不正な値が一行だけなら、その行を飛ばして処理を続ける読み込み機能もあります。一方、最初の不正行で解析を中止したり、ファイル全体を無効としたりする実装もあります。ファイル冒頭の数行が正常だからといって、全体が正常とは限りません。中間や末尾にも形式の違う値がないかを確認します。
座標値に単位記号や項目名が付いている場合も、そのままでは一般的なOBJの数値として解釈されません。v 10.0m 20.0m 5.0m や v X=10.0 Y=20.0 Z=5.0 のような記述は、人には意味が分かりやすくても、OBJの頂点構文ではありません。
座標一覧からOBJへ変換する際に、列見出しが残っていないかも確認します。ファイル先頭に X Y Z や 点番号 X座標 Y座標 Z座標 といった行がある場合、それはOBJの有効な頂点行ではありません。不明なキーワードを無視する読み込み機能もありますが、厳格な検査ではエラーになる可能性があります。
指数表記も確認対象です。浮動小数点として指数表記を受け付ける処理は多いものの、簡易的な読み込み機能では通常の小数表記しか想定していない場合があります。互換性を優先する検証用ファイルでは、読み込み先が対応する形式へそろえます。
ただし、大きな座標値を単純に小数表記へ変更するだけでは、表示上の問題が解決しないことがあります。大きな座標を扱う場合、読み込み側の数値精度や表示原点との関係によって、点群が見えにくくなることがあります。頂点数が本当に0なのか、頂点はあるものの表示範囲外にあるのかを確認します。
座標値の単位も重要です。OBJの数値だけでは、メートルとミリメートルのどちらであるかを一意に判断できません。出力側と入力側の単位が異なると、点群が1000倍に拡大または縮小されたように見える可能性があります。ただし、単位の違いは通常、頂点を0にする構文エラーではなく、縮尺や表示範囲の問題として現れます。
数値表記を調べる際は、正常な行だけでなく、形式の異なる行を探すことが大切です。複数の計測データを結合した場合、前半は座標3列、後半は座標と色を含む6列というように、ファイル内で列数が変化することがあります。出力工程を統一し、同じ種類の頂点行は同じ構成へそろえます。
構文チェック3 文字コードと改行を確認する
行頭の v と座標値に問題が見当たらない場合は、文字コードと改行を確認します。OBJはテキストとして保存されますが、読み込み側がすべての文字コード、BOM、改行形式、Unicode文字へ対応しているとは限りません。
特に確認したいのが、ファイル先頭に付加されるBOMです。BOMは文字コードの識別に使われる情報ですが、単純な読み込み処理では、最初のキーワードの前に想定外のバイトがあると判断される場合があります。
画面上では最初の行が v 0.000 0.000 0.000 と表示されていても、内部的には v の前に不可視の情報が付いていることがあります。最初の行だけが無視される実装もあれば、先頭行の解析失敗を理由にファイル全体を拒否する実装もあるため、アップロード先の対応文字コードを確認します。
文字コードを変更する際は、元ファイルへ直接上書きせず、複製した検証用ファイルで試します。文字コードの変更と同時に改行や不可視文字まで変化することがあるため、修正前後を比較できる状態にしておきます。
OBJ内に日本語のコメント、オブジェクト名、グループ名、材質名などが含まれている場合は、文字コードの不一致が起きやすくなります。頂点行が半角英数字だけで構成されていても、その前にある名称行で読み込みが止まり、後続の頂点へ到達しない実装も考えられます。
切り分け時には、日本語や特殊記号を含む行を除き、半角英数字だけの頂点行で確認用OBJを作成します。このファイルが読み込めれば、座標ではなく名称、コメント、材質参照などの文字列が影響している可能性があります。
改行が正しく残っているかも確認します。OBJは基本的にキーワードごとの行で構成されます。仕様上は行末のバックスラッシュを使って長い記述を継続できる場合がありますが、通常の頂点行を分割する必要はありません。意図しない改行や改行欠落がない状態へそろえるほうが安全です。
複数の頂点行から改行が失われ、v 0.0 0.0 0.0v 1.0 0.0 0.0 のように連結されると、最初のZ座標の後ろに次の v が続き、通常の数値として解釈できません。改行の代わりに想定外の制御文字が入っている場合も同様です。
逆に、一つの頂点行が途中で改行され、行継続の記号もない場合も頂点として認識されません。v 10.0 20.0 の次の行に 30.0 だけが記録されている場合、最初の行は値が不足し、次の行はキーワードを持たない不明な行になります。
ファイル転送、文字列の連結、一定文字数での自動折り返し、文書編集機能への貼り付けなどによって、意図しない改行が入ることがあります。画面上の折り返し表示と、実際の改行は別物であるため、行番号や不可視文字を確認できる環境で調べると判断しやすくなります。
複数の改行形式がファイル内で混在している場合も注意が必要です。多くの読み込み機能は一般的な改行へ対応していますが、変換や結合を繰り返したファイルでは、前半と後半で改行形式が異なることがあります。特定の位置から急に頂点を読めなくなる場合は、結合部分を確認します。
NUL文字などの不可視の制御文字が混入している場合も、解析が停止する可能性があります。異なる形式のデータを誤って連結した場合や、保存・転送が途中で失敗した場合に、通常のテキストには含まれにくい文字が入ることがあります。
OBJは平文で確認できる形式であるため、途中から判読不能な文字が続く、座標行の間に異常な記号が入る、ファイルの一部だけ表示できないといった状態では、データ破損や別形式の混入を疑います。
大容量OBJを一般的な文書編集機能で開き、そのまま上書き保存することも避けます。保存時に文字コードや改行が変わるだけでなく、自動整形、行末空白の削除、タブ変換などが行われる場合があります。確認は原本の複製に対して行い、変更前後の容量や行数も比較します。
構文チェック4 ファイル先頭・途中・末尾の不正記述を確認する
OBJの座標行が正しくても、ファイル先頭や途中に不正な記述があると、読み込み側が頂点行へ到達する前または途中で処理を停止する場合があります。そのため、座標行だけでなく、ファイル全体の構造を確認することが必要です。
最初に、ファイル先頭へ別形式の見出しが追加されていないかを確認します。変換処理によって、作成日時、ファイル名、点数、座標系、列名、処理条件などが通常の文字列として書き込まれることがあります。
不明なキーワードを無視して読み進める読み込み機能もありますが、未知の記述を形式不正として扱う機能もあります。検証用OBJでは、独自の説明行を除き、最初の有効な行を v または必要な標準キーワードから始めると切り分けやすくなります。
拡張子だけがOBJになっており、中身は別形式というケースもあります。ファイルを開いたときに、X,Y,Z という見出しとカンマ区切りの座標が並んでいる場合、それは座標一覧として利用できても、OBJの構文ではありません。
拡張子を .obj に変更しただけでは、内容はOBJへ変換されません。各座標行を v X Y Z の形式に変換し、先頭の見出し、点番号、独自属性などをOBJとして解釈可能な形へ処理する必要があります。
構造化された別形式のテキストや圧縮データを、拡張子だけ変更している場合も同様です。テキストとして開いた際に大量の記号や判読不能な文字が表示されるなら、OBJとして正しく書き出されていない可能性があります。
ファイルの途中に処理ログやエラー文が混入していないかも確認します。変換処理が途中で失敗し、そのエラーメッセージが出力ファイルへ書き込まれる場合があります。ファイル容量が0ではないため、座標データが生成されたように見えても、実際にはログや不完全なデータしか入っていないことがあります。
複数のOBJを単純に連結した場合も注意が必要です。後半のファイルに含まれるヘッダー、名称、材質参照、コメントなどが結合位置へそのまま挿入されます。標準キーワードであっても、記述順序や参照番号が結合後の状態に合わなければ、意図した形状になりません。
OBJ内のオブジェクト名、グループ名、材質関連の記述が常に問題になるわけではありません。ただし、名称に制御文字や意図しない改行が含まれている場合、文字列処理の実装によっては解析へ影響する可能性があります。
点群だけを読み込ませるための切り分けでは、名称、材質、テクスチャ座標、法線などを一度除き、v 行だけの最小構成を作ります。読み込みに成功したら、必要な記述を一種類ずつ戻し、どの情報を加えた時点で失敗するかを確認します。
ファイル末尾が不自然に途切れていないかも重要です。保存処理、コピー、圧縮、アップロード準備などが途中で停止すると、最後の頂点行が未完成の状態になることがあります。
途中までの正常な頂点を読み込める処理もありますが、ファイル全体を事前検査する処理では、末尾の不完全な行を理由に読み込みが拒否される場合があります。最後の行が v 10.0 20.0 で終わっているなど、値が不足していないかを確認します。
容量不足や保存先の制限によって、ファイルが途中までしか書き込まれていない場合もあります。以前に正常出力した同程度の点数のOBJと比べて、ファイル容量や頂点行数が極端に少なくないかを確認します。
反対に、想定より極端に大きい場合は、同じ点群が複数回記録されている、追加属性が大量に付いている、複数ファイルが重複して連結されている可能性があります。容量だけで構文の正否は判断できませんが、出力異常を発見する手掛かりになります。
圧縮ファイルでアップロードする場合は、圧縮前のOBJだけでなく、圧縮後に展開した内容も確認します。同名の空ファイルや過去の出力ファイルが含まれていると、意図したOBJではないファイルが解析対象になる可能性があります。
フォルダ階層やファイル名の扱いによって、OBJ本体が見つからず、関連ファイルだけが処理されることもあります。圧縮後のデータを別の場所へ展開し、対象OBJの容量、更新日時、先頭行、末尾行を確認すると安全です。
構文チェック5 点群として参照される要素を確認する
OBJ内に正しい v 行があっても、読み込み機能が頂点だけのOBJを点群として扱わない場合があります。構文上は座標が定義されていても、点、線、面などの要素から参照されていないため、「有効な形状なし」や頂点数0に相当する結果が表示されるケースです。
OBJでは、v 行が頂点の位置を定義します。一方、点を表す要素には p、線には l、面には f が使われます。点群OBJの出力方法には、v 行だけを並べる方法と、v 行に加えて各頂点を p 行から参照する方法があります。
どちらを受け付けるかは、読み込み側の目的や実装によって異なります。点群向けの読み込み機能であれば、v 行だけでも各頂点を点として表示する場合があります。一方、一般的な三次元形状の読み込み機能では、p、l、f などで参照されていない頂点を描画対象にしない場合があります。
この違いを調べるには、同じ数点の座標を使って二種類の確認用OBJを作ります。一つは v 行だけのファイル、もう一つは v 行と、それらを参照する p 行を含むファイルです。
たとえば、3点を定義した後に p 1 2 3 と記述すれば、1番から3番までの頂点を点要素として参照できます。v 行だけのファイルでは頂点数0になり、p 行を加えたファイルでは点が表示される場合、読み込み側が点要素の定義を必要としている可能性があります。
ただし、p 行の対応状況も環境によって異なります。本番ファイルを一括変換する前に、少量データで検証します。点群用ではなく面モデル用の入力機能を使っている場合、f 行がないOBJを有効な三次元形状として扱わない可能性もあります。この場合は、点群に対応した入力方法を選ぶことが基本です。
連続する頂点番号を機械的に結び、面を作れば読み込めるようになるとは限りません。点群の並び順は、必ずしも隣接関係を表していないからです。取得順に三点ずつ結んだだけでは、本来存在しない三角形が生成され、形状、面積、体積、距離などの判断を誤る可能性があります。
点群を面へ変換する必要がある場合は、点の位置関係、密度、欠損、重複、法線などを考慮した適切な処理が必要です。頂点数0の回避だけを目的に、根拠のない面を追加するのは避けます。
p、l、f に記録される頂点番号も確認します。OBJでは、頂点の記述順に基づく1始まりの番号で参照する方法が基本です。負の相対インデックスを使える仕様もありますが、すべての読み込み機能が同じように対応するとは限りません。
たとえば、v 行が100行しかないのに、点要素や面要素が101番以降の頂点を参照している場合、範囲外の参照になります。無効な参照を飛ばして処理する機能もありますが、解析全体を停止する機能もあります。
複数のOBJを結合するときは、後半の参照番号に注意します。二つ目のOBJにある p や f の正の番号は、通常、そのファイル内の頂点を1番から数えたものです。単純に一つ目のファイルの後ろへ連結すると、後半の参照が一つ目の頂点を指してしまう場合があります。
正しく結合するには、前半に存在する頂点数を考慮し、後半の正の参照番号を調整する必要があります。頂点行だけを結合する場合には参照番号の問題が発生しないこともありますが、点、線、面の要素を含むOBJでは重要です。
また、vt や vn だけが出力され、位置頂点の v が欠落していないかを確認します。テクスチャ座標や法線は、三次元位置そのものではありません。出力設定の誤りによって、付加情報だけが残り、座標本体が出力されていない場合があります。
関連ファイルを同梱しているだけで、頂点が補われるとは限りません。OBJ本体に v 行がなく、別の独自ファイルに座標が保存されている場合、アップロード先がその構成へ対応していなければ頂点を取得できません。解析対象となるOBJ本体に、必要な位置情報が記録されているかを確認します。
少量の確認用OBJで原因を切り分ける
頂点数0の原因を効率的に調べるには、元の大容量OBJを直接修正するのではなく、数点から数十点の確認用OBJを作成します。問題の範囲を小さくすることで、構文、属性、文字コード、点要素の違いを比較しやすくなります。
最初の確認用ファイルには、半角小文字の v、一般的な半角スペース、X、Y、Zの数値だけを記録します。コメント、名称、材質、色、テクスチャ座標、法線、面などは含めません。
座標は原点付近の単純な値にします。たとえば、0から1程度の範囲に数点を配置すれば、大きな座標値や表示原点による問題を避けられます。このファイルが読み込めれば、アップロード機能が基本的な頂点構文へ対応している可能性が高いと判断できます。
最小ファイルでも頂点数0になる場合は、文字コード、改行、点要素の必要性、入力画面の種類、拡張子と内容の不一致などを確認します。v 行だけで失敗する場合は、同じ頂点へ p 行を加えた確認用ファイルを試します。
最小ファイルが読み込めた場合は、元ファイルに含まれる情報を一種類ずつ追加します。まず座標値を実データに近づけ、次に必要なら w、色などの追加成分を加え、さらに名称や材質関連の記述を戻します。
一度に複数の変更を加えると、どの変更が成功または失敗につながったのか分からなくなります。一回の検証では一つの条件だけを変更し、結果を記録します。
反対に、失敗する元ファイルから情報を少しずつ除く方法も有効です。ただし、大容量ファイルで削除と保存を繰り返すと、処理時間が長くなり、保存途中の停止や容量不足による新たな破損を招く可能性があります。
元ファイルから先頭の数十点だけを抜き出し、同じヘッダーや属性を含む小型版を作ると、元の構造を保ちながら調査できます。先頭部分では成功し、中間部分を抜き出したファイルで失敗する場合は、途中から形式が変化している可能性があります。
調査では、先頭、中間、末尾の三つの範囲から、それぞれ少量の頂点行を抜き出す方法が役立ちます。先頭だけが正常で、末尾側に不正値や列数の違いがある場合、ファイル全体を先頭だけ見ても発見できません。
確認用OBJには、元ファイルと区別できる名前を付けます。ただし、極端に長い名前や特殊記号を含む名前は、アップロード時の別の問題につながる可能性があります。半角英数字と一般的な区切り記号を中心に、短く分かりやすい名前にします。
検証結果として、ファイル名、容量、頂点行数、文字コード、改行形式、追加列の有無、p 行の有無、アップロード結果を記録します。同じ出力工程で再び問題が起きたとき、正常な条件と比較しやすくなります。
大容量の点群OBJを安全に調査する手順
点群OBJは、点数によっては非常に大きなテキストファイルになります。一般的な文書編集機能で全体を開くと、動作が停止したり、メモリ不足になったりすることがあります。調査中の上書き保存によって、元データを損傷する可能性もあります。
最初に原本を複製し、元ファイルを変更しない状態で保管します。調査や置換は必ずコピーに対して行います。元データが一つしかない状態で文字コード変換や一括置換を実行すると、修正内容が誤っていた場合に戻せなくなります。
次に、ファイル容量が想定と一致しているかを確認します。同じ点数や同じ計測範囲の正常なOBJがある場合は、容量を比較します。極端に小さい場合は、頂点が十分に書き出されていない可能性があります。
容量が大きいからといって正常とは限りません。重複した点、不要な属性、処理ログ、複数ファイルの連結などによって、容量だけが増えている場合があります。容量は原因を推定する手掛かりとして使い、内容の確認と組み合わせます。
ファイル全体を一度に開けない場合は、先頭部分、末尾部分、中間部分を分けて確認します。先頭では、BOM、ヘッダー、最初の v 行、区切り文字を見ます。末尾では、最後の頂点行が完結しているか、エラー文や不自然な文字がないかを見ます。
中間部分は、一定間隔で複数箇所を確認します。複数データを結合した位置や、処理条件が変わった位置で、列数や数値形式が変化する可能性があります。途中から v 行がなくなっていないか、全角記号や欠測値が増えていないかを調べます。
行数を数えられる処理環境がある場合は、各行を空白で分割し、最初のトークンが厳密に v である行数を確認します。文字列として単に v を数える方法では、タブ区切りの有効行を見落としたり、行頭の異常を区別できなかったりします。
アップロード結果の頂点数と v 行数が大きく異なる場合は、途中で解析が停止している、無効な数値を含む行が除外されている、点要素から参照されていない、入力側が独自の条件で間引いているなどの可能性があります。
不正な数値を探す際は、NaN、Inf、null、カンマ、全角マイナス、単位記号などを調べます。自動処理で各行のトークン数と数値変換を検査できる場合は、想定した形式と異なる行を抽出すると効率的です。
ただし、一括置換には注意が必要です。カンマをすべて削除する処理では、小数点として使われたカンマと桁区切りとして使われたカンマを区別できません。置換によって 12,345 が 12345 になった場合、それが12.345を意味していたのか、12345を意味していたのか判断できなくなります。
修正後は、ファイル全体をすぐにアップロードするのではなく、同じ修正を適用した少量の確認用OBJで試します。確認用データが読み込めた後に、本番コピーへ修正を適用します。
アップロードの失敗と解析の失敗も区別します。ファイル送信中に通信が切れた場合、OBJの構文を変更しても解決しません。アップロード完了後に「頂点数0」と表示される場合は、構文や対応形式を優先して確認します。
圧縮してアップロードする場合は、圧縮前後で展開後のOBJの容量やハッシュが一致するかを確認できると確実です。少なくとも、圧縮ファイルから別の場所へ展開し、OBJが0バイトになっていないか、名前が変わっていないか、意図しない階層へ入っていないかを見ます。
OBJを再出力するときに確認したい条件
手作業で構文を修正できても、点数が多い場合は、出力元から適切な設定でOBJを作り直すほうが安全です。再出力では、単に拡張子としてOBJを選ぶだけでなく、どの要素を書き出す設定になっているかを確認します。
処理環境によっては、面を持つ三次元モデルを主対象としてOBJを出力し、点群の頂点だけを想定していない場合があります。点群をメッシュ化していない状態で面モデル用の出力機能を使うと、期待した v 行や p 行が生成されないことがあります。
出力対象として、点群、頂点、点要素、面モデルなどの選択肢がある場合は、目的に合ったものを選びます。点群 OBJ アップロードを行うなら、少なくとも位置頂点がOBJ本体へ記録されることを確認します。入力先が p 行を必要とする場合は、点要素も出力できるかを確認します。
色を含める設定も互換性に影響します。頂点行の後ろへRGB値を追加する方式は広く使われる拡張ですが、元のOBJ仕様に含まれる標準の頂点構文ではありません。まず座標だけのOBJで読み込みを確認し、その後、アップロード先が対応する色表現と値域で色付きデータを試します。
法線やテクスチャ座標を出力しても、位置頂点の代わりにはなりません。vn や vt が大量に存在しているのに v がない場合は、出力対象の設定を見直します。
座標の桁数も確認します。小数桁を減らしすぎると、点群の位置精度が失われます。一方、必要以上に長い小数桁を出力しても、元の計測精度が高まるわけではなく、ファイル容量が増える可能性があります。
必要な精度、座標単位、後工程の計測方法に合わせて、適切な桁数を選びます。読み込み側が扱える数値範囲や内部精度にも注意します。
座標系と原点の扱いも重要です。大きな座標値をそのままOBJへ記録すると、読み込み側によっては表示や計算の精度へ影響する場合があります。ローカル座標へ移動して出力する場合は、元の位置へ戻すための移動量や座標変換条件を記録します。
座標を原点付近へ移動すると表示できるようになる場合があります。ただし、その結果だけで元ファイルが構文不正だったと判断してはいけません。頂点数0ではなく、頂点は読み込まれていたものの遠方に配置されていた可能性があります。
単位設定も確認します。出力側がメートル、読み込み側がミリメートルとして扱うと、点群の大きさが大幅に変わります。単位の不一致は通常、頂点数0ではなく縮尺の問題として現れますが、表示範囲を外れることで点がないように見える場合があります。
再出力後は、ファイルが作成されたことだけで完了と判断せず、先頭、中間、末尾を確認します。先頭の頂点行が v X Y Z または意図した v X Y Z W の形になっているか、途中で列数や数値形式が変わっていないか、末尾が途切れていないかを見ます。
同じ設定で少量の点群を出力し、アップロード先で頂点数が正しく表示されることを確認してから、大容量データを書き出すと手戻りを減らせます。
点群 OBJ アップロード前の最終確認
点群 OBJ アップロード前には、構文、データ内容、ファイル状態、入力方法を一連の流れで確認します。
最初に、対象ファイルが実際にテキスト形式のOBJであることを確認します。拡張子だけを変更した座標一覧、圧縮データ、別形式の点群ファイルは、内容をOBJ構文へ変換しない限りOBJとして解析できません。
次に、OBJ本体にキーワードが v となる頂点行が存在するかを確認します。vt や vn だけでは、三次元空間上の位置頂点にはなりません。
各頂点行には、X、Y、Zとして解釈できる数値を記録します。4番目の値がある場合は、標準の w なのか、出力元独自の属性なのかを確認します。全角数字、全角マイナス、単位記号、項目名、引用符、桁区切りのカンマなどが混入していないかも見ます。
座標値の後ろに色や属性を追加している場合は、アップロード先がその構文と値域へ対応しているかを確認します。不明な場合は、座標3列だけの確認用OBJで先に試します。
文字コードと改行も確認します。BOM、特殊な空白、NUL文字、行途中の改行、改行の欠落がないかを見ます。ファイル内に日本語や特殊記号を含む名称がある場合は、それらを除いた最小構成でも検証します。
ファイル先頭に独自の見出し、作成日時、列名、処理ログなどが通常の文字列として入っていないかを確認します。末尾が途中で切れていないこと、ファイル途中にエラー文や異なる形式のデータが混入していないことも重要です。
頂点行だけで読み込めない場合は、アップロード先が点要素の p 行を必要としていないかを確認します。ただし、点群を読み込ませるためだけに根拠のない面を作成することは避けます。
大容量ファイルをアップロードする前に、数点から数百点の確認用OBJでテストします。確認用データでも頂点数0になる場合は、構文、文字コード、点要素、入力機能の対応範囲を優先して調べます。
確認用データでは成功し、本番データだけが失敗する場合は、ファイル途中の不正行、列数の混在、欠測値、容量、転送状態、処理時間などを確認します。
頂点数は表示されるものの点群が見えない場合は、座標値、単位、原点、表示範囲を調べます。頂点数0と、頂点が存在するのに画面上で見えない状態は、別の問題として切り分けます。
正常に読み込めた確認用OBJは、基準ファイルとして保管すると便利です。問題が発生したOBJと比較することで、行頭、列数、文字コード、追加属性、点要素などの違いを確認できます。
まとめ
点群OBJで「頂点数0」と表示されるときは、ファイル容量だけでデータの有無を判断せず、OBJ内部の構文を順番に確認することが重要です。
第一に、座標行のキーワードが半角小文字の v になり、X、Y、Zの値が一般的な空白で区切られているかを確認します。v の前に引用符、コメント記号、行番号、不可視文字などが付いていると、頂点として認識されない場合があります。
第二に、座標値の数と数値表記を確認します。標準的な頂点位置は v x y z [w] で、X、Y、Zが必須、w は任意です。色などを後ろへ追加する形式は拡張的な慣例であり、読み込み側の対応確認が必要です。全角記号、カンマ、単位、欠測値なども数値変換の失敗につながります。
第三に、文字コード、BOM、改行、不可視文字を確認します。見た目では正常でも、行頭や数値の間に特殊な文字が含まれていることがあります。複数の頂点行が連結されている場合や、一つの頂点行が行継続なしで途中分割されている場合も正常に解析できません。
第四に、ファイルの先頭、途中、末尾を確認します。独自の見出し、処理ログ、エラー文、別形式のデータ、未完成の末尾行があると、頂点の解析前または解析途中で処理が停止する場合があります。
第五に、読み込み側が頂点だけのOBJを点群として扱えるかを確認します。環境によっては、頂点を参照する p 行が必要な場合があります。少量の v 行だけのファイルと、点要素を加えたファイルを比較すれば、対応条件を切り分けやすくなります。
調査では、大容量の原本を直接編集せず、数点から数十点の最小OBJを作る方法が有効です。最小構成から情報を一種類ずつ追加すれば、どの記述が読み込み失敗の原因になっているかを特定しやすくなります。
点群の取得、OBJの書き出し、構文確認、圧縮、アップロードまでを一つの工程として管理し、正常に読み込めた設定を記録しておけば、同じエラーの再発を抑えやすくなります。現場で取得した点群を確認し、共有や計測へつなげる運用を整える際は、LRTK Phoneによる点群データの取得と活用も検討できます。