LRTKレフィクシア株式会社

点群OBJアップロードで頂点法線数が合わない原因と5つの修正

点群OBJで頂点法線数が合わないとは

点群から作成したOBJをアップロードした際に、頂点数と頂点法線数が一致しない、法線データが不足している、法線の参照番号が範囲外であるといったエラーが表示されることがあります。アップロード自体は完了しても、面の一部が黒く見える、照明の向きによって表面がまだらになる、稜線に不自然な筋が入る、陰影が反転したように見えるなどの問題が生じる場合もあります。

この問題を解決するには、最初に「頂点数と頂点法線数は必ず同じでなければならない」という考え方を見直す必要があります。OBJでは、形状を構成する頂点座標と、陰影計算に使う法線ベクトルを別々の要素として記録できます。同じ頂点座標に複数の法線を割り当てることも、複数の面で一つの法線を共有することも可能です。

そのため、OBJ内に記録された頂点の件数と法線の件数が異なるだけでは、必ずしもデータ不良とは判断できません。重要なのは、各面を構成する角が、存在する頂点番号と法線番号を正しく参照しているかどうかです。

たとえば、法線が100件しか記録されていないOBJで、面が101番目の法線を参照していれば、その参照は成立しません。また、一つの三角形を構成する三つの角のうち、二つだけに法線があり、残りの一つには法線がない場合も、読み込み側の実装によってはエラーになります。

点群OBJという言葉にも注意が必要です。OBJは一般に三角形や四角形などの面を記録するメッシュ形式として使われますが、点群の座標だけをOBJの頂点として保存し、面を持たないデータが作られることもあります。面を持たないOBJでは、面の陰影計算に使う法線をどのように扱うかが曖昧になりやすく、メッシュを前提としたアップロード先では正しく読み込めない可能性があります。

実務では、点群をそのままOBJへ変換したのか、点群から三角形の面を生成してOBJへ変換したのかを最初に確認することが重要です。頂点法線の問題は、単純な件数不足ではなく、点群、メッシュ、面、頂点、法線の関係が変換工程の途中で崩れた結果として発生することが多いためです。

OBJにおける頂点と頂点法線の基本

OBJはテキスト形式で記録されることが多く、頂点座標、テクスチャ座標、法線、面などが行単位で保存されます。頂点座標は一般にvで始まる行、テクスチャ座標はvtで始まる行、法線はvnで始まる行、面はfで始まる行として記述されます。

頂点座標には、三次元空間上の位置を表す数値が格納されます。法線には、主に陰影計算で使う表面方向が記録されます。面の幾何学的な表裏は頂点の並び順によって決まり、法線はその向きと整合している必要があります。法線は位置ではなく方向を表すため、頂点座標とは役割が異なります。

面の行では、面を構成する各角が、どの頂点、テクスチャ座標、法線を使用するかを番号で指定します。この仕組みにより、一つの頂点座標を複数の面で共有しながら、面の角ごとに異なる法線を割り当てられます。

立方体の角を考えると理解しやすくなります。立方体の一つの角には三つの面が接続しています。座標上の位置は一つですが、各面は異なる方向を向いています。角を鋭く表示するには、同じ位置に対して三方向の法線が必要です。この場合、形状としての頂点は一つに見えても、表示上は複数の法線が使われます。

一方、緩やかな曲面や地表面では、隣接する面の法線を平均化して滑らかに見せることがあります。複数の面の角が同じ法線を参照する構造になれば、法線数が頂点数より少なくなる可能性もあります。

したがって、頂点数と法線数を単純に比較するだけでは、OBJが正しいかどうかを判断できません。確認すべきなのは、面に書かれた参照番号が有効であること、必要な面に法線がそろっていること、法線の方向が現在の形状と一致していることです。

また、頂点法線という言葉から、各頂点に必ず一つの法線が付属すると考えられがちですが、OBJの内部構造では面の角ごとに法線が指定されます。同じ頂点番号が面によって異なる法線番号と組み合わされることもあります。この柔軟な構造をアップロード先が完全に解釈できない場合、正しいOBJであっても頂点法線数の不一致として処理される可能性があります。

原因1 面が存在しない法線番号を参照している

頂点法線数に関するエラーで、最も直接的な原因は、面に記録された法線番号と実際の法線データが対応していないことです。法線が500件しかないのに、面が501番以降の法線を参照していれば、アップロード先は必要な法線を取得できません。

この問題は、メッシュの一部を削除した後や、複数のOBJを結合した後に起こりやすくなります。通常の編集環境では、頂点や法線を削除すると面の参照番号も更新されます。しかし、異なる形式を何度も経由した場合、独自の変換処理を使用した場合、ファイル内容を直接加工した場合などには、古い番号が残る可能性があります。

複数のOBJを単純に一つのファイルへ連結する処理も危険です。二つ目のOBJにある面の頂点番号と法線番号は、一つ目のOBJに含まれる頂点数や法線数を考慮して増加させなければなりません。各ファイルの行をそのままつなげると、二つ目の面が一つ目の頂点や法線を誤って参照することがあります。

頂点番号だけを補正し、法線番号を補正していないケースもあります。この状態では形状の位置は正しく見えても、陰影だけが崩れます。アップロード先によっては表示を続行せず、法線参照の不整合として処理を停止します。

同じ面の中で法線参照の形式が混在している場合も問題です。三角形の一つ目と二つ目の角には法線番号があるものの、三つ目には頂点番号しか記録されていない状態では、その面全体の法線を一貫して扱えません。読み込み時に自動補完されることもありますが、すべての環境で同じ結果になるとは限りません。

テクスチャ座標を持たないOBJで法線を指定するときは、頂点番号と法線番号の間に空欄を示す区切りが入ることがあります。この記述が崩れると、法線番号がテクスチャ座標番号として解釈されたり、必要な要素が不足していると判断されたりします。

この原因に対して、単純に法線行を追加して件数だけを増やす方法は適切ではありません。追加した法線が面の正しい方向を表していなければ、アップロードに成功しても陰影が不自然になります。面がどの法線を必要としているかを確認し、参照番号と法線方向をまとめて修正する必要があります。

原因2 頂点共有と法線分割の考え方が合っていない

OBJを書き出した環境とアップロード先で、頂点と法線の扱い方が異なることも、頂点法線数が合わない原因になります。

OBJでは、同じ頂点番号に対して複数の法線番号を組み合わせることができます。鋭い角では面ごとに法線を分け、滑らかな曲面では周囲の面で法線を共有するという表現が可能です。しかし、アップロード先によっては、一つの頂点番号には一つの法線番号だけが対応するという単純な内部構造へ展開することを前提としている場合があります。

この場合、OBJの記述としては成立していても、アップロード側の変換処理が頂点座標と法線の組み合わせを正しく展開できず、件数不一致や参照不整合として扱うことがあります。特に、別形式からOBJへ変換したデータや、複数の属性を持つ複雑なメッシュでは、この差が表面化しやすくなります。

建物や構造物の角では、同じ位置に複数の法線が必要です。角を構成する面の法線を平均化すると、本来は鋭い稜線が丸く見えてしまいます。そのため、書き出し側は同じ座標を共有しながら複数の法線を設定するか、同じ位置に複数の頂点を作成します。

地表面や法面のように連続性を重視する形状では、隣接面の法線を平均化して滑らかに表示するほうが自然です。しかし、点群由来の細かな凹凸が多いと、法線の平均化範囲が細かく分断され、大量の法線が生成されることがあります。

材質の境界やテクスチャ座標の切れ目も、頂点分割に影響します。座標が同じでも、異なるテクスチャ位置や異なる法線を持つ場合、内部処理では別の頂点として展開されることがあります。編集画面に表示される頂点数と、書き出し後に実際に使われる頂点数が異なることも珍しくありません。

頂点共有と法線分割の考え方が一致していない場合は、頂点数や法線数を個別に調整するのではなく、アップロード先が理解しやすい構造へ変換する必要があります。異なる法線を使う場所では頂点を分け、一つの展開後頂点に一つの法線を対応させる方法が有効です。

原因3 メッシュ編集後に古い法線情報が残っている

点群からメッシュを生成した直後は正常でも、切り取り、穴埋め、結合、簡略化、頂点移動などを行った後に法線エラーが発生することがあります。これは、現在の形状と、過去に計算された法線が一致していないためです。

法線は周囲の面の向きや接続状態から計算されます。面を削除したり、頂点の位置を変更したりすれば、本来は法線も更新しなければなりません。しかし、編集内容や書き出し方法によっては、形状だけが変更され、法線情報が以前の状態で残ることがあります。

メッシュの簡略化では、複数の頂点や面を統合しながらデータ量を削減します。簡略化後に法線を再計算しないと、削除された頂点に対応する古い法線が残ったり、新しく構成された面に必要な法線が不足したりします。

複数のメッシュを結合した場合も注意が必要です。一方のメッシュは滑らかな法線を使用し、もう一方は面ごとに独立した法線を使用している場合、結合後のデータに複数の法線規則が混在します。結合処理が参照番号を正しく再構成できなければ、存在しない法線番号や未使用の法線が残ります。

面の表裏を反転した後も法線を更新しなければ、面の頂点順序と法線方向が逆になります。見た目としては、表面の陰影が不自然になったり、片面表示の環境で期待した側が表示されなかったりします。アップロード側が面の向きと法線方向の整合性を検査する場合は、警告や読み込みエラーになる可能性もあります。

座標変換にも注意が必要です。全方向を同じ倍率で拡大または縮小するだけであれば、法線方向への影響は限定的です。しかし、軸ごとに異なる倍率を適用した場合や、左右反転を含む変換を行った場合は、法線を適切に変換し直す必要があります。

古い法線情報が残っているかどうかは、件数だけでは判断できません。頂点数と法線数が見かけ上合っていても、法線が現在の面に対して正しくない可能性があります。形状編集を終えた段階で既存法線を整理し、現在の面構成から再計算することが基本です。

原因4 不正な面によって法線を計算できない

法線は、面を構成する頂点の位置から計算されます。そのため、メッシュに不正な面が含まれていると、正常な法線を生成できません。

代表的なのは、面積がほとんどない縮退面です。三角形を構成する三つの頂点のうち二つ以上が同じ位置にある場合や、三つの頂点がほぼ一直線上に並ぶ場合、安定した面方向を求められません。計算された法線の長さがほぼゼロになり、正規化できない値が生成されることがあります。

点群から自動的にメッシュを生成すると、点の密度差や計測ノイズによって、極端に細長い三角形が作られることがあります。見た目では面が存在しているように見えても、数値的には不安定であり、法線の方向が周囲と大きく異なる場合があります。

同じ場所に面が重複している状態も問題です。同じ頂点で構成された面が二重に存在すると、同じ位置に重複する面と法線参照が存在し得ます。重複面の向きが逆であれば、正反対方向の陰影情報が重なります。その結果、表示時にちらついたり、表面が黒く見えたりすることがあります。

辺の接続関係が不自然なメッシュでも、法線の平均化が困難になります。一つの辺を過剰な数の面が共有している場合、どちら側が内側でどちら側が外側なのかを一意に判断できないことがあります。面同士が交差している場合や、内部に不要な面が入り込んでいる場合も同様です。

頂点が重複しているものの結合されていない状態では、隣接して見える面が内部では別々の領域として扱われます。この場合、境界をまたいだ法線の平均化が行われず、メッシュの途中に不自然な線が現れます。

反対に、鋭い角を維持するために意図的に分けた頂点を統合すると、必要な法線の境界が失われます。同じ座標にある頂点をすべて自動統合すればよいわけではありません。形状上の接続と、表示上の境界を区別して修復する必要があります。

不正な面が残った状態で法線を再計算しても、形式上の法線数が増えるだけで、根本的な問題は解決しません。法線修正の前に、重複面、縮退面、交差面、孤立面、意図しない穴などを確認することが重要です。

原因5 書き出し側とアップロード側の解釈が異なる

OBJは広く使われる形式ですが、すべての書き出し環境と読み込み環境が同じ範囲に対応しているわけではありません。基本的な頂点や面は読み込めても、法線の参照方法や面の構成によって互換性問題が起こることがあります。

ある読み込み環境では、法線を持たない面があっても自動的に再計算されます。別の環境では、法線付きの面と法線なしの面が混在しているだけでエラーになる場合があります。

複数の頂点を持つ多角形も解釈差の原因です。OBJでは三角形や四角形だけでなく、それ以上の頂点を持つ面も記述できます。しかし、アップロード先では内部的に三角形へ分割して処理することが一般的です。

多角形が完全な平面でなければ、どの対角線で三角形化するかによって、生成される三角形の形状や陰影が変わります。書き出し側が計算した法線と、アップロード側が三角形化した後の面が一致せず、不自然な陰影や法線不足として扱われることがあります。

参照番号の表現にも差があります。OBJでは、ファイルの先頭から数える正の番号だけでなく、現在位置からさかのぼる形式の負の番号が使われることもあります。書式として有効でも、すべてのアップロード先が同じように対応しているとは限りません。

点群から生成した高密度メッシュでは、頂点、面、法線の件数が非常に大きくなります。アップロード側の処理上限や利用可能なメモリを超えると、読み込み処理が途中で停止し、結果として後半の面や法線の参照エラーとして報告される可能性があります。

数値表記やファイルの記録方法も影響します。法線の成分に数値として解釈できない文字が含まれている場合、極端に大きい値がある場合、有限な値として扱えない記述がある場合は、その法線行が無効になることがあります。

書き出した環境で再表示できることだけでは、アップロード互換性を保証できません。同じ環境は、自ら生成した記述を柔軟に解釈できる場合があります。実際に保存したOBJを新規に開き直し、可能であれば別の汎用的な閲覧環境でも確認することが大切です。

修正1 面と法線の参照番号を検証する

最初に行う修正は、面が参照している法線番号が有効かどうかを確認することです。いきなり法線をすべて再計算するよりも、参照関係を先に調べることで、原因を正確に切り分けられます。

まず、OBJ内にあるvn行の件数を確認します。この件数が、正の番号で参照できる法線番号の上限になります。次に、f行に含まれる法線番号を確認し、最大番号が法線件数を超えていないかを調べます。負の番号が使われている場合は、その面が記述された位置を基準に、直前までに定義された法線を正しく参照しているかを別途確認します。

法線番号がゼロになっている箇所や、数値が欠けている箇所も確認します。一つの面の中で法線を持つ角と持たない角が混在している場合は、面全体の記述を統一します。

法線を使用する方針であれば、面を構成するすべての角に有効な法線番号を設定します。法線を使用せずアップロード先で再計算する方針であれば、一部だけに法線参照を残さず、対象となる面から法線参照を整理します。

複数のOBJを結合している場合は、頂点番号、テクスチャ座標番号、法線番号がそれぞれ正しく補正されているかを確認します。頂点番号だけが更新され、法線番号が元のままになっていると、形状は見えても陰影が崩れます。

使われていない法線が大量に残っている場合も整理の対象です。未参照の法線があるだけで必ずエラーになるわけではありませんが、不要なデータが多いと検証が難しくなります。現在の面から一度も参照されていない法線は、必要性を確認したうえで削除します。

大規模なOBJを手作業で確認するのは現実的ではありません。範囲外の法線番号、法線参照を持たない面、同一面内の記述形式の混在、未参照法線などを機械的に検査できる処理を用いると効率的です。

修正時は元のOBJを上書きせず、必ず別名で保存します。面の参照番号を直接変更すると、法線だけでなく頂点やテクスチャ座標の番号まで誤って変更する可能性があるためです。

修正2 既存の法線を削除して再計算する

参照番号に明確な異常がない場合や、メッシュ編集後に問題が発生した場合は、既存の法線を整理し、現在の形状から再計算します。

再計算の前には、面の表裏をそろえる必要があります。一般に、面を構成する頂点の並び順によって面の向きが決まります。隣接する面の頂点順序がそろっていないと、法線が外側と内側へ交互に向くことがあります。

閉じた立体では、通常は法線が外側を向くように面の向きを統一します。地形のような開いたメッシュでは、利用目的に応じて表示したい側へ法線をそろえます。地表面の上側を表示するのであれば、周囲の面と整合する上向きの方向を基準にします。

面の向きをそろえた後、既存の法線を削除または無効化し、現在の面構成から新しい法線を計算します。このとき、すべての面を独立して表示するのか、隣接する面を滑らかにつなぐのかを決めます。

面単位で法線を作成すると、各三角形の境界が明確になります。建物の角や段差を表現するには有効ですが、地表面や曲面では細かな三角形が目立ち、全体が角張って見えます。

隣接面の法線を平均化すると、地形や曲面を滑らかに表示できます。ただし、構造物の稜線や段差まで平均化すると、本来は鋭い部分が丸く見えます。角度差や指定した境界を基準に、平均化する領域と分ける領域を決めることが重要です。

点群由来のメッシュでは、微細なノイズによって面の向きがばらついていることがあります。ノイズが多いまま法線を計算すると、本来は滑らかな領域に細かな明暗が発生します。必要に応じて、極端な凹凸や小さな孤立領域を整理してから法線を再計算します。

計算後は、法線ベクトルが有効な値になっているかも確認します。長さがほぼゼロの法線や、数値として扱えない成分がある場合は、対応する面に縮退や重複がないかを調べます。

法線を再計算したら、編集画面の状態だけで判断せず、OBJへ書き出した後にファイルを閉じ、新規に読み込み直します。編集画面では正常に見えていても、書き出し設定で法線が保存されていないことがあるためです。

修正3 頂点分割とスムージングを整理する

法線を再計算しても頂点法線数のエラーが残る場合は、アップロード先の内部形式が頂点と法線の一対一対応を求めている可能性があります。この場合は、異なる法線を使う場所で頂点を分割します。

同じ頂点番号が複数の法線番号と組み合わされている場合、法線の組み合わせごとに頂点を複製します。複製した頂点の座標は同じですが、別の頂点番号を割り当て、それぞれ一つの法線番号に対応させます。

この処理により、頂点番号と法線番号の関係を単純化できます。OBJの柔軟な参照方式に十分対応していないアップロード先でも、読み込める可能性が高まります。

頂点を分割する代表的な場所は、建物や構造物の鋭い角、段差の境界、法線方向が急激に変わる稜線です。これらの場所で頂点を共有したまま法線を平均化すると、角が丸く見えます。

一方、地表面や緩やかな曲面では、不要な頂点分割を避ける必要があります。面ごとにすべての頂点を分けると、頂点数が大幅に増え、ファイル容量、アップロード時間、表示負荷が増大します。

点群から生成した高密度メッシュでは、すでに多くの頂点が含まれています。法線のためにすべての面を独立させると、同じ座標が面の数だけ複製されることがあります。形状に必要な境界だけを残し、滑らかにつなげる領域は共有することが重要です。

スムージングの設定も統一します。複数のメッシュを結合した場合、それぞれが異なる法線計算方法を持っていることがあります。結合後にいったん法線の設定を整理し、全体を同じ基準で再計算したうえで、必要な稜線だけを分離すると安定します。

頂点分割後に重複頂点の統合を実行する場合は注意が必要です。同じ座標という理由だけで統合すると、法線を分けるために作成した頂点が再び一つに戻ります。座標だけでなく、法線や面の境界も考慮して統合する必要があります。

一対一構造へ変換した後は、面の各角が対応する頂点番号と法線番号を参照しているかを確認します。頂点数と法線数が同じでも、組み合わせがずれていれば正しい陰影にはなりません。

修正4 重複面や縮退面を修復する

法線を安定して計算するには、元になるメッシュの品質を整える必要があります。法線の件数だけを合わせても、不正な面が残っていれば同じ問題が再発します。

最初に確認したいのは、意図しない重複頂点です。同じ位置に複数の頂点が存在し、それぞれが別の面に接続していると、見た目では面が連続していても、内部では分離しています。この状態では境界をまたいだ法線の平均化が行われず、線状の陰影が発生します。

ただし、鋭い角を維持するために意図的に分けられた頂点もあります。距離が近い頂点を無条件に統合するのではなく、周囲の面、法線、境界の意味を確認してから処理します。

次に、同じ場所に存在する重複面を確認します。同じ頂点番号で構成された面が複数ある場合は、不要な面を削除します。頂点の並び順だけが逆になっている重複面では、反対向きの面が重なっている可能性があります。

縮退面も除去または再構成します。二つの頂点が同じ位置にある三角形、三つの頂点がほぼ一直線上にある三角形、面積が極端に小さい面は、正常な法線を計算できません。

極端に細長い三角形も確認します。必ずしもすべてが不正とは限りませんが、点群のノイズによって偶然作られた細長い面は、周囲と大きく異なる法線を持つことがあります。表示上不要であれば、面の再構成や簡略化を検討します。

面の交差や内部面も法線処理を不安定にします。閉じた立体の内部に不要な面が残っていると、内側と外側の判定が難しくなります。地表面のような開いたメッシュでは外周が存在すること自体は問題ではありませんが、メッシュ中央に意図しない穴や切れ目がないかを確認します。

孤立した小さな面や小領域も整理します。点群計測では、移動物体、反射、遠方の誤計測などによって、本体から離れた小片が生成されることがあります。これらが不要であれば、法線計算前に削除します。

形状を修復した後は、面の向きを改めてそろえます。穴埋めや面の再構成によって追加された面だけが逆向きになることがあるためです。その後、現在のメッシュ全体から法線を再計算します。

修正5 互換性を優先してOBJを書き出す

メッシュと法線を修復した後は、アップロード互換性を優先した条件でOBJを書き出します。編集環境内で正常に見えても、保存されたOBJの構造が複雑すぎると、アップロード先で読み込めない場合があります。

まず、法線を含める設定を確認します。法線を利用する場合は、すべての対象面に法線参照を付けて書き出します。法線を利用しない場合は、一部だけに古い参照を残さず、アップロード先で再計算できることを確認します。

次に、書き出し前に面を三角形化します。アップロード先で自動的に三角形化される場合でも、事前に面構成を確定しておけば、法線を計算した面と、アップロード後の面を一致させやすくなります。

特に、四つ以上の頂点を持つ非平面の面では、三角形化の方法によって形状と陰影が変わります。書き出し側で三角形化し、その状態で法線を再計算することで解釈差を減らせます。

参照番号は、可能な限り単純な正の番号にそろえます。現在位置からさかのぼる負の参照はOBJの書式として有効ですが、読み込み側によって対応差があるため、互換性を優先する場合は避けます。頂点、法線、面という基本的な構造で保存すると、互換性を確保しやすくなります。

検証段階では、材質やテクスチャなどの付加情報を一時的に外し、形状と法線だけのOBJを作成する方法も有効です。最小構成でアップロードに成功すれば、頂点法線以外の要素が原因である可能性を切り分けられます。

複数のオブジェクトを一つのOBJへまとめる場合は、書き出し処理によって参照番号を再構成します。個別のOBJファイルをテキストとして単純に連結する方法は避けます。

座標値が非常に大きい場合は、検証用として原点に近い位置へ移動したOBJを作成することも考えられます。大きな座標を扱える環境でも、内部の数値精度によって表示や法線計算が不安定になる可能性があるためです。

ただし、測量や施工管理で実座標を維持する必要がある場合は、元の座標を失わないようにします。検証用に移動した場合は、移動量を記録し、元座標へ戻せる状態を保ちます。

書き出し後は、保存したOBJを新規に読み込みます。頂点数、面数、法線の有無、面の表裏、陰影、孤立領域などを確認し、編集前と同じ状態で再現されるかを調べます。

点群OBJの問題を効率よく切り分ける手順

頂点法線の問題は、複数の原因が同時に発生していることがあります。すべての設定を一度に変更すると、どの修正が有効だったのか分からなくなるため、段階的に切り分けることが重要です。

最初に、OBJに面が存在するかを確認します。頂点を表す行だけがあり、面を表す行がない場合は、一般的なメッシュOBJとは異なります。アップロード先が面を持つ三次元モデルを前提としている場合、点の座標だけでは処理できない可能性があります。

面が存在する場合は、法線行の有無を確認します。法線が一件もない場合は、アップロード先が法線を自動生成できるかを確認します。法線を必須とする環境であれば、書き出し前に法線を計算する必要があります。

法線が存在する場合は、面の参照番号を確認します。範囲外の番号、ゼロ、欠落、面内の記述形式の混在がないかを調べます。ここで異常が見つかれば、参照を修正するか、法線を削除して再計算します。

参照に問題がなければ、面の品質を確認します。重複面、縮退面、逆向き面、交差面、孤立面、意図しない穴などがないかを調べます。面に問題があれば、形状を修復してから法線を再計算します。

次に、元データの一部を切り出した小規模なOBJを作成します。問題のなさそうな領域だけを三角形化し、法線を再計算してアップロードします。

小規模OBJが成功し、全体OBJが失敗する場合は、データ内の特定領域、頂点数、面数、法線数、ファイル容量などが影響している可能性があります。領域を半分ずつ分けて検証すると、問題箇所を絞り込みやすくなります。

小規模OBJでも失敗する場合は、頂点と法線を一対一にした単純な構造へ変換します。それでも失敗する場合は、法線をすべて除いたOBJと、すべての面に法線を設定したOBJをそれぞれ試し、アップロード先がどの形式を受け入れるかを確認します。

エラーメッセージに行番号や参照番号が表示される場合は、その情報を優先します。頂点法線数が合わないと表示されていても、実際には一つの面だけが範囲外の番号を参照していることがあります。

正常にアップロードできる最小条件が分かったら、テクスチャ、材質、複数オブジェクト、高密度な面などを一項目ずつ追加します。一度に戻さないことで、エラーが再発する条件を特定できます。

頂点法線の不整合を防ぐ運用方法

頂点法線の不整合は、書き出し前の確認工程を標準化することで再発を減らせます。点群の取得からOBJアップロードまでに複数の作業者や変換工程が関わる場合は、誰がどの段階で法線を確定するかを決めておくことが重要です。

基本的には、形状編集が完了した後に最終的な法線を計算します。点群からメッシュを生成した直後に法線を作成しても、その後に切り取り、穴埋め、簡略化、結合などを行えば、再計算が必要になります。

作業途中の法線は表示確認用とし、アップロード用OBJを書き出す直前に、面の向き、接続状態、スムージングの境界を確認して再計算する運用が安全です。

書き出し前の検査項目も統一します。範囲外の法線番号、法線を持たない面、縮退面、重複面、逆向き面、孤立領域、未参照の法線などを確認します。

検出された要素をすべて機械的に削除する必要はありません。地表面には外周辺が存在しますし、鋭い稜線では同じ位置に複数の頂点が必要になることもあります。重要なのは、検出結果が意図した構造なのかを判断できることです。

アップロード先ごとに、適切な書き出し条件を記録することも有効です。ある環境では共有頂点と複数法線を扱えても、別の環境では一対一対応へ展開したデータが必要な場合があります。

編集用の高品質なデータを保持しながら、アップロード用には頂点分割や三角形化を適用した互換性重視のOBJを別途作成すると、元データを損なわずに対応できます。

ファイル名だけでなく、書き出し時の条件も記録します。三角形化の有無、法線の計算方法、スムージングの境界、頂点分割の条件、簡略化の程度、座標移動の有無などを残しておけば、同じ問題が発生したときに比較できます。

保存したOBJを新規に読み込み直す工程も標準化します。作成中の編集データではなく、実際に保存されたファイルだけを使って形状と法線を確認することで、書き出し設定の見落としを発見できます。

大規模なOBJでは、全体版と同じ設定で小規模な検証用OBJも作成しておくと便利です。全体版のアップロードが失敗したとき、小規模版が成功するかを確認することで、構造の問題と処理量の問題を分けられます。

点群を取得する段階で、不要な重複、移動物体、反射による異常点、遠方の孤立点などを減らすことも重要です。元の点群にノイズが多いほど、メッシュ生成後の重複面や細長い面が増え、法線処理が複雑になります。

後工程だけで修正しようとせず、点群取得、ノイズ処理、メッシュ生成、形状編集、法線計算、OBJ書き出し、アップロードという一連の工程を管理することが、安定した運用につながります。

まとめ

点群OBJアップロードで頂点法線数が合わないと表示されたときは、頂点数と法線数の件数差だけを見て判断しないことが重要です。OBJでは頂点と法線が別々に管理され、同じ頂点に複数の法線を割り当てることも、複数の面で一つの法線を共有することもできます。

実際に問題となるのは、面が存在しない法線番号を参照している状態、同じ面の中で法線の有無が混在している状態、編集前の古い法線が残っている状態、法線を計算できない不正な面がある状態などです。

また、OBJとして成立していても、アップロード先の内部形式が頂点座標と法線の組み合わせを一対一の頂点列へ展開する場合があります。その変換に対応できないときは、異なる法線を使う場所で頂点を分割し、単純な参照構造へ変換する必要があります。

修正は、面と法線の参照番号を検証し、既存法線を現在の形状から再計算し、頂点分割とスムージングを整理し、不正な面を修復したうえで、互換性を優先した条件で書き出す順に進めると効率的です。

書き出し後は、保存したOBJを新規に読み込み、面、頂点、法線、表裏、陰影が正常であることを確認してからアップロードします。正常に処理できる小規模なOBJを用意しておけば、大容量による問題とデータ構造の問題も切り分けやすくなります。

点群OBJの品質は、書き出し時の設定だけで決まるものではありません。点群取得時のノイズ、メッシュ生成方法、形状編集、簡略化、面の修復、法線計算までが相互に影響します。現場で取得する点群から後工程までを安定させるには、計測段階からデータの重複や欠損を確認し、用途に合った密度と範囲で記録することが大切です。

現場の点群取得とデータ確認を効率化し、OBJ作成へつなげる運用を検討している場合は、LRTK Phoneを活用した計測方法も確認してみてください。

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

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