点群から生成した三次元メッシュをOBJ形式でアップロードしたとき、角が丸く見える、平面同士の境目がぼやける、構造物の稜線が消えるといった問題が起こることがあります。元の編集画面では明確だった壁と床の境界が、アップロード後のビューアーでは連続した曲面のように見えることもあります。
この現象は、必ずしも頂点座標が変形したことを意味しません。形状は維持されていても、頂点法線の参照方法、スムージンググループの解釈、アップロード先での法線再計算などが変わると、陰影だけが滑らかにつながり、角が消えたように見えます。一方で、簡略化や再メッシュ化によって実際の稜線が失われている場合もあるため、表示上の問題と形状上の問題を分けて確認する必要があります。
「点群 OBJ アップロード」で原因を調べる際は、OBJファイルだけでなく、面情報、法線、スムージング指定、テクスチャ、アップロード先の変換処理まで順番に確認することが重要です。本記事では、スムージング境界が消える仕組みを整理し、構造物の角や地形の変化点を維持するための5つの対処法を解説します。
点群OBJのスムージング境界とは
OBJ形式では、頂点座標、テクスチャ座標、頂点法線、面などをテキストで記録できます。一般的なメッシュOBJでは、複数の頂点を参照して三角形や四角形の面を作り、その面の集合で三次元形状を表現します。
スムージングとは、隣接する面の法線を補間し、面と面の間を滑らかに見せるシェーディング処理です。円柱や緩やかな曲面では、実際には複数の多角形で構成されていても、法線が連続していれば一枚の滑らかな面のように表示できます。
一方、建物の角、擁壁の天端、縁石の稜線、箱形構造物の折れ目などでは、隣接面の法線を平均化すると、本来の鋭い境界が弱く見えます。OBJには、どの面を同じ滑らかな領域として扱うかを示すスムージンググループの指定を記述できます。
ただし、スムージンググループと頂点法線は同じ情報ではありません。スムージンググループは、法線を生成または補間するときの区分として使われます。OBJに明示的な頂点法線が含まれている場合は、各面の各頂点位置がどの法線を参照するかによって陰影が決まります。読み込み側がどちらを優先するか、また法線を再計算するかは実装によって異なります。
スムージング境界とは、実務的には「ここを越えて陰影を連続させない」という境目です。同じ位置の頂点座標を複数の面が共有していても、面ごとに異なる法線を参照できれば、座標を重複させずに角を表現できます。反対に、境界をまたいで同じ法線へ統合されると、直角部分でも丸みがあるように見えることがあります。
そのため、OBJにスムージング指定が入っているかだけでなく、法線が出力されているか、面の参照関係が維持されているか、アップロード先が再計算していないかを確認する必要があります。
境界が消えると起こる実務上の問題
スムージング境界が消えても、頂点座標が変わっていなければ数値上の形状は維持されている場合があります。しかし、三次元データを画面上で確認する業務では、陰影や輪郭も判断材料になるため、見た目の変化を軽視できません。
壁と床の境界が滑らかにつながって見えると、床面の範囲や立ち上がり位置を判別しにくくなります。法面と平場の切り替わりがぼやければ、断面を作成する位置や勾配変化点を誤認する可能性があります。構造物の角が丸く見えると、設計との差が実形状の変化なのか、表示処理によるものなのかを判断しにくくなります。
点群から生成したメッシュでは、計測ノイズ、欠測部の補間、点密度の差によって細かな面が多数作られます。そこへ広い範囲のスムージングが適用されると、段差、継ぎ目、欠損、表面の局所的な変化などが目立ちにくくなることがあります。ただし、ひび割れのようにテクスチャで見えているだけの情報は、法線を調整しても戻らないため、形状と画像を分けて評価する必要があります。
関係者へアップロード後のデータを共有する場合も注意が必要です。作成者は元データを知っているため違和感に気づきやすい一方、閲覧者は表示されたモデルだけで判断します。境界が失われたモデルを確認資料に使うと、施工状態や形状の解釈に差が生じるおそれがあります。
したがって、点群OBJのアップロードでは、ファイルが開けることだけでなく、角、折れ目、面の切り替わり、曲面の連続性が用途に合った状態で表示されているかまで確認することが重要です。
点群OBJでスムージング境界が消える主な原因
スムージング境界が消える原因は一つではありません。OBJを書き出す段階、アップロード時の変換、ビューアーでの描画という複数の工程で、法線や面構成が変化する可能性があります。
一つ目は、スムージンググループの指定が出力されていない、または読み込み側で使用されていないことです。元の編集環境では鋭いエッジが設定されていても、その情報がOBJのスムージング指定や法線として書き出されなければ、同じ見た目が維持されるとは限りません。読み込み側がフラット表示する場合もあれば、独自の角度条件で法線を再計算する場合もあります。
二つ目は、頂点法線が欠落している、無視されている、または変換時に再生成されていることです。法線が再計算される際に広い角度範囲が同じ滑らかな領域として扱われると、本来分けたい壁と床や、構造物の稜線まで陰影が連続することがあります。
三つ目は、頂点座標の共有そのものではなく、境界の両側にある面の法線参照が同一化されることです。OBJでは同じ頂点座標を使いながら、面ごとに異なる法線番号を参照できます。ところが、変換先が位置、法線、テクスチャ座標の組み合わせを正しく保持せず、位置だけを基準に一つの頂点へまとめると、境界法線が平均化されることがあります。
四つ目は、重複頂点の削除や近接頂点の統合です。互換性を確保するために意図的に分けた頂点が、アップロード時の最適化で再結合されると、ハードエッジが失われる場合があります。特に、座標が同じで法線だけが異なるデータは、単純な座標一致による結合の影響を受けやすくなります。
五つ目は、メッシュ簡略化、再三角形化、再メッシュ化です。面数を減らす処理で稜線上の頂点や辺が削除されると、陰影だけでなく実際の形状境界も変わります。外形が大きく変わっていなくても、境界付近の面の向きが変われば、法線の補間結果も変化します。
対処法1 スムージンググループを明示する
最初の対処法は、OBJを書き出す前に、滑らかに見せる領域と角を残す領域を区分し、スムージンググループを明示することです。読み込み側がこの指定に対応していれば、法線を計算するときの意図を伝えやすくなります。
同じスムージンググループに属する隣接面は、共有位置で滑らかな法線を生成する対象になります。異なるグループに属する面や、スムージングを無効にした面は、境界で法線を分ける対象になります。ただし、明示的な頂点法線がある場合の扱いはソフトウェアによって異なるため、スムージンググループだけで完全な互換性が得られるとは限りません。
設定では、モデル全体を一つのグループにしないことが重要です。曲面を構成する細かな面は同じ滑らかな領域として扱い、壁と床、壁と天井、平場と法面、構造物と地面など、形状上の意味が変わる場所でグループを分けます。
反対に、すべての面を別グループにすると、緩やかな曲面まで多面体のように角張って見えます。必要なのは、滑らかさを消すことではなく、滑らかにする範囲を用途に合わせて限定することです。
点群から自動生成したメッシュは面数が多いため、隣接面の角度差を使って境界候補を抽出する方法が現実的です。ただし、点群ノイズによる小さな角度変化まで境界にすると、平面が細かく分断されます。先に孤立点や極端な小面を整理し、構造上残すべき稜線を優先して設定します。
書き出したOBJをテキストで確認できる場合は、スムージング指定が含まれているかを確認します。ただし、記述が存在することと、アップロード先が解釈することは別問題です。汎用ビューアーへの読み戻しと、アップロード先での表示を分けて検証します。
アップロード先がスムージンググループを利用しない場合に備え、重要な境界では明示法線の分離も組み合わせると、原因の切り分けと互換性確認がしやすくなります。
対処法2 境界部分の頂点と法線を分離する
二つ目の対処法は、角を残したい境界で法線の参照を分け、必要に応じて頂点も分離することです。スムージンググループが無視される環境では、面ごとの法線を明示する方が意図を伝えやすい場合があります。
箱形形状の角では、一つの頂点座標を正面、側面、上面が共有できます。座標を共有していても、OBJの面記述で各面が別の法線を参照すれば、同じ位置に複数の向きを持たせられます。したがって、鋭い境界を作るために座標頂点を必ず複製しなければならないわけではありません。
明示法線を使う場合は、境界の両側で面の向きに対応した別の法線を参照させます。正面、側面、上面が平均化された一つの法線を参照すると、角の周辺で明暗が連続し、丸く見えやすくなります。
一部の変換処理は、OBJが持つ頂点座標、テクスチャ座標、法線の別々の索引を、内部形式の一つの頂点索引へ展開します。この変換が正しく行われれば、同じ座標でも法線が異なる角は維持されます。反対に、位置だけで頂点を統合する実装では、法線の境界が失われる可能性があります。
そのような互換性問題が疑われる場合は、境界位置の頂点を面ごとに複製し、各頂点に専用の法線を持たせる方法を試します。ただし、これは常に必要な処理ではなく、ファイル容量や頂点数を増やします。また、アップロード先が重複頂点を再結合すれば効果がなくなるため、結合条件も併せて確認します。
頂点や法線の分離は、構造物の角、部材の継ぎ目、開口部、地形のブレークラインなど、実務上の意味を持つ場所に限定します。スキャンノイズによる細かな凹凸まで分けると、表面が必要以上に粗くなります。
修正後は正面だけでなく、斜め、上方、側方から確認します。照明方向を変えたときに、境界を越えて陰影が不自然につながっていないかを見ます。可能であれば法線表示とワイヤー表示も使い、見た目だけでなく参照関係と面構成を確認します。
対処法3 法線の再計算条件を見直す
三つ目の対処法は、OBJの書き出し前またはアップロード時に行われる法線再計算の条件を見直すことです。元データで境界が正しくても、変換時に法線が一律に作り直されると、意図したハードエッジが消える場合があります。
法線は、面がどの方向を向いているかをシェーディングへ伝える情報です。頂点座標が正しくても、法線の方向や面ごとの割り当てが不適切であれば、面が膨らんで見えたり、へこんで見えたり、角が丸く見えたりします。
法線の再計算では、隣接面の角度差を基準に、滑らかにつなぐか、境界として分けるかを判断することがあります。しきい値を大きくすると、角度差の大きい面まで滑らかにつながりやすくなります。しきい値を小さくすると、わずかな角度差でも境界になり、表面が細かく角張る可能性があります。
適切な条件は対象物によって異なります。建築物や箱形構造物では、直角部や段差を確実に分ける必要があります。地形や法面では、緩やかな変化を細かな面境界として強調しすぎない方が見やすい場合があります。
点群由来のメッシュは、平面にも小さな角度変化を含みます。計測誤差、反射条件、点密度の差、穴埋め処理などが影響するためです。厳しい角度条件を一律に適用すると、一枚の壁や床まで細かな境界に分断されます。
法線再計算の前に、孤立点、重複面、面積がほとんどない面、極端に細長い面などを整理すると、計算が安定しやすくなります。ただし、平滑化しすぎると、本来残すべき段差や欠損まで失われるため、形状用途に応じて処理量を調整します。
OBJを書き出す際は、法線を含める設定になっているかを確認します。法線を出力しない場合、読み込み側が面法線や独自の条件で頂点法線を生成する可能性があります。逆に、明示法線を出力しても、アップロード先が再計算する仕様であれば元の陰影は維持されません。
法線データを点検するときは、反転、ゼロベクトル、数値異常、境界をまたぐ不適切な共有がないかを確認します。OBJの法線は必ずしも単位長で保存されるとは限らないため、長さが1でないことだけを直ちに破損と判断せず、使用するソフトウェアの正規化処理を含めて評価します。
面の向きも重要です。面を構成する頂点の並び順が周囲と逆になっていると、法線が反対方向を向くことがあります。表裏が混在したモデルでは陰影が乱れ、スムージング境界の消失に似た見え方になる場合があります。
形状の性質が異なるモデルでは、構造物、地形、曲面などの領域ごとに再計算条件を分ける方法も有効です。すべてを同じ設定で処理するより、角と曲面の両方を維持しやすくなります。
対処法4 頂点結合とメッシュ簡略化を制御する
四つ目の対処法は、重複頂点の結合、近接頂点の統合、メッシュ簡略化などの処理を見直すことです。アップロード前のOBJでは境界が残っているのに、アップロード後だけ消える場合は、変換工程で頂点属性や面構成が変えられている可能性があります。
頂点結合は、同じ位置または近い位置にある頂点をまとめ、データ量を減らす処理です。しかし、同じ座標でも法線やテクスチャ座標が異なる頂点は、描画上は別の役割を持ちます。位置だけを基準に統合すると、スムージング境界やテクスチャ境界が失われる場合があります。
結合処理を使う場合は、位置だけでなく、法線、テクスチャ座標、面の所属などの違いを保持できるかを確認します。結合距離の許容値が大きすぎると、近接している別の面や薄い部材の表裏まで一体化するおそれがあります。
メッシュ簡略化は、大容量の点群OBJを共有しやすくするうえで有効です。ただし、面数の削減率だけを基準にすると、平面内部の不要な頂点と、稜線上の重要な頂点が同じように削除される可能性があります。
境界を維持するには、折れ目、外周、開口部、ブレークラインなどを保護する設定を使います。擁壁の角、縁石の上端、道路と法面の境目、構造物の開口など、判読や計測に使う線を先に指定し、その後で平面内部や緩やかな曲面を簡略化します。
簡略化後は、容量が減ったことだけで成功と判断しません。元データと重ね合わせ、境界付近の座標差、断面形状、稜線位置を確認します。陰影だけが変わったのか、実際の頂点や面が移動したのかを分けて評価します。
再三角形化によって内部の辺の向きが変わると、同じ外形でも法線の補間結果が変化します。境界付近に極端に細長い三角形、重複面、つぶれた面が作られていないかも確認します。
アップロード先に品質設定がある場合は、まず簡略化を抑えた条件で比較します。高い削減率のデータだけを見ると、元OBJの問題なのか、アップロード時の最適化の問題なのかを切り分けにくくなります。
対処法5 アップロード先の変換処理を確認する
五つ目の対処法は、アップロード先で行われる変換処理を確認することです。OBJが正しく作られていても、サーバー側やビューアー側で内部形式へ変換される際に、法線、スムージング指定、頂点属性、面構成が変わる場合があります。
三次元データの共有サービスでは、表示を高速化するため、面の再分割、法線生成、頂点統合、階層化、圧縮、簡略化などを行うことがあります。ただし、具体的な処理はサービスごとに異なるため、名称や一般論だけで挙動を断定できません。
仕様が公開されていない場合は、小さな検証用OBJを作ると切り分けやすくなります。直角に交わる二枚の面と、緩やかにつながる曲面を同じファイルに含め、直角部には分離法線、曲面には連続法線を設定します。
アップロード後に直角部と曲面部を比較します。両方が滑らかになる場合は、境界法線が統合または再計算されている可能性があります。両方が角張る場合は、明示法線が使われず、面単位のフラット表示になっている可能性があります。ただし、結果だけで処理を確定せず、追加テストで確認します。
次に、法線を含むOBJと含まないOBJ、スムージング指定を変えたOBJ、境界頂点を複製したOBJを比較します。一度に一項目だけ変えることで、どの情報が維持され、どの情報が失われるかを把握できます。
大容量の実データだけで試すと、変換時間が長く、比較条件も増えます。問題のある境界付近を切り出した検証データで挙動を確認し、その結果を本番データの書き出し条件へ反映します。
変換後データを再取得できる場合は、頂点数、面数、法線の有無、境界付近の面構成を比較します。頂点数や面数の変化だけで処理内容を断定することはできませんが、簡略化や再構成を疑う手掛かりになります。
表示品質の設定がある場合は、各条件で境界の見え方を比較します。遠景表示や低負荷表示だけで境界が弱くなる場合は、段階的詳細度や描画側の簡略化が関係している可能性があります。
点だけのOBJと面を持つOBJを区別する
「点群OBJ」という言葉は、運用によって異なるデータを指します。点群から生成した三角形メッシュをOBJで保存している場合もあれば、OBJの点要素を使って点を表している場合、または特定のソフトウェアが頂点定義だけのファイルを独自に点群として解釈している場合もあります。
OBJの標準的な構造では、頂点は v で定義し、点として構成する場合は p 要素からその頂点を参照できます。頂点定義だけが並び、面や点要素がないファイルをどのように扱うかは読み込み側に依存します。そのため、単に v 行があることだけで、すべてのビューアーが点群として表示するとは限りません。
面を持たない点データには、隣接面が存在しないため、通常の意味でのスムージング境界はありません。点がぼやけて見える場合は、点の描画サイズ、透過、補間表示、点密度の調整、アップロード後の自動表面生成などを確認します。
アップロード先が点データから自動的に面を生成する場合、境界の見え方は生成されたメッシュの条件で決まります。壁と床の点が近く、境界付近の点が不足していると、両者を横断する三角形が作られ、角が丸くつながったように見えることがあります。
この場合は、点群の段階で壁面と床面を分離し、境界付近の点密度を確保してからメッシュを生成します。浮遊点や不要点を除去し、境界をまたぐ誤った面が作られていないかをワイヤー表示で確認します。
すでに面を持つOBJであれば、スムージンググループ、明示法線、面ごとの索引、頂点統合、簡略化を調べます。最初に f 面要素や p 点要素の有無を確認すると、検討すべき原因を絞り込みやすくなります。
点データとメッシュOBJを混同すると、スムージング設定を変更しても改善しません。アップロード前に、対象が点の集合なのか、面を持つ立体モデルなのか、アップロード先で自動的に表面化されるのかを明確にします。
テクスチャの境界消失と混同しない
スムージング境界が消えたように見えても、実際にはテクスチャ、照明、陰影の問題である場合があります。形状の境界、法線の境界、テクスチャの境界は別の情報です。
形状の境界は、頂点と面によって作られる実際の折れ目や段差です。法線の境界は、シェーディング上の面方向が切り替わる場所です。テクスチャの境界は、画像の貼り付け位置や色が切り替わる場所です。
壁と床の形状が直角でも、法線が平均化されれば陰影が滑らかにつながり、角が丸く見えます。反対に、法線が正しく分かれていても、壁と床の色が似ていたり、照明が弱かったりすると境界を判別しにくくなります。
テクスチャ座標がずれている場合は、境界付近の画像が引き伸ばされ、面の切り替わりがぼやけることがあります。画像の縮小や圧縮によって、細い目地や線が失われる場合もあります。
切り分けでは、まずテクスチャを無効にし、単色表示で形状と陰影を確認します。単色表示で角が明確になる場合は、テクスチャや色調が影響している可能性があります。単色表示でも丸く見える場合は、法線または面構成を重点的に確認します。
次に、照明を抑えた表示、フラット表示、ワイヤー表示、面ごとの色分けなどを使います。境界を横断する面が存在する場合は、法線だけを修正しても実形状は戻りません。
テクスチャの有無、照明の有無、法線表示、ワイヤー表示を一つずつ切り替えることで、形状、陰影、画像のどこに原因があるかを整理できます。
アップロード前に行う確認手順
点群OBJをアップロードする前は、元の編集データ、書き出したOBJ、アップロード後の表示という三段階を分けて確認します。工程を分けることで、どこで境界が失われたかを特定しやすくなります。
最初に、元データで実際の稜線が存在するかを確認します。ワイヤー表示を使い、角や段差に沿って適切な辺が配置されているかを見ます。境界を横断する大きな三角形や、角を丸める中間面がある場合は、法線より先に面構成を修正します。
次に、境界の両側で法線が適切に分かれているかを確認します。反転法線、ゼロベクトル、境界をまたぐ不要な共有がないかを調べます。曲面では連続し、角では切り替わる状態が用途に合っているかを見ます。
その後、スムージンググループや鋭いエッジの設定を確認します。モデル全体が一つの滑らかな領域になっていないか、構造上の境界で区分されているかを点検します。
OBJの書き出しでは、面、法線、テクスチャ座標、マテリアル参照、スムージング指定など、必要な情報が出力対象になっているかを確認します。使用するソフトウェアによって項目名や対応範囲が異なるため、書き出し結果を実ファイルで検証します。
書き出したOBJは、可能であれば別の汎用的な閲覧環境へ読み込みます。同じ編集環境へ戻すだけでは、元の内部設定が残っているように見えたり、同じ規則で再解釈されたりして、互換性問題を見落とすことがあります。
書き出したOBJの段階で境界が消えていれば、書き出し設定またはOBJ内の法線参照を確認します。別環境では正常で、アップロード後だけ消える場合は、アップロード先の変換や描画を重点的に調べます。
本番データを修正する前に、問題箇所だけを切り出した小さなOBJを作ると検証しやすくなります。法線、スムージング指定、頂点分離、簡略化を一項目ずつ変え、結果を記録します。
境界は正面だけで判断せず、側面、上面、斜め方向から確認します。照明方向や表示倍率も変え、輪郭線と陰影の両方が正しい位置で切り替わるかを見ます。
最後に、ファイル容量、頂点数、面数、法線の有無、書き出し条件、アップロード設定を記録します。修正前後の条件が残っていれば、再発時の比較と社内標準化が容易になります。
修正後も境界が戻らない場合の切り分け方
5つの対処法を試しても境界が戻らない場合は、スムージング以外の問題を疑います。元形状に稜線が存在しない場合や、境界付近の面が不正な場合は、法線だけを調整しても改善しません。
まず、頂点座標と断面から実際の角度を確認します。画面上では直角に見えても、点群から生成したモデルに複数の中間面があり、壁と床が緩やかにつながっている場合があります。この状態では、ハードエッジを付けても形状そのものの丸みは残ります。
次に、境界付近の点密度を確認します。点が少ない場所では、表面生成時に離れた点同士が結ばれ、大きな面が作られることがあります。角の両側に点が十分あるか、死角や反射条件による欠測がないかを見ます。
重複面、内部面、表裏が反転した面も確認します。同じ位置に複数の面が重なると、陰影のちらつきや不明瞭な境界が生じます。極端に細長い三角形や面積がほとんどない面も、法線計算を不安定にする要因になります。
座標値が大きく原点から遠い場合は、利用環境の数値精度が細かな表示へ影響することがあります。元座標との対応を記録したうえでローカル原点付近へ移し、表示結果を比較すると、座標精度の影響を切り分けられます。
アップロード先だけで境界が消える場合は、閲覧端末、表示品質、表示距離も確認します。遠景や低負荷表示でのみ境界が弱くなる場合は、段階的詳細度や描画時の簡略化が関係している可能性があります。
原因を特定するときは、一度に複数の設定を変えません。法線、スムージング指定、頂点分離、簡略化、テクスチャを一つずつ変更し、結果を比較します。変更項目を限定することで、形状、属性、変換、描画のどこに問題があるかを判断しやすくなります。
現場で扱いやすい点群OBJを作る考え方
点群OBJの品質は、頂点数や面数が多いほど高いとは限りません。現場で必要な境界を残しながら、不要なノイズと過剰な面を減らし、アップロード後も意図が伝わる状態にすることが重要です。
まず、データの用途を明確にします。概略形状の共有が目的なら、微細な凹凸をすべて残すより、壁、床、法面、構造物の境界を明確にした方が判読しやすくなります。微細な段差や損傷を確認する用途では、平滑化や簡略化を抑え、元点群や高密度メッシュも保存します。
境界には優先順位を付けます。構造物の外周、開口部、段差、施工範囲、地形の変化点など、計測や判断に使う境界を優先的に保護します。平面内部の不要な三角形は減らしても、重要な稜線は残すという方針が有効です。
点群からメッシュを生成するときは、計測時の点密度が境界品質に影響します。壁と床、構造物と地面、部材同士の接合部は、複数方向から取得して死角を減らします。境界の両側に点がなければ、後処理だけで正確な折れ目を復元することは難しくなります。
暗い場所、濡れた面、反射条件が不安定な面、細い部材などでは点が不足しやすいため、取得結果を現場で確認します。不足があれば追加計測し、推定による穴埋めへ依存しすぎない運用が重要です。
OBJへ変換するときは、地面、構造物、不要物などを領域分けすると、それぞれに適した法線計算や簡略化を適用できます。地形では緩やかな法線補間を使い、構造物では角度変化とブレークラインを重視するなど、同じモデル内でも条件を分けます。
ファイル容量を抑える場合は、全体を均等に削減せず、平坦な部分を優先的に簡略化します。平面は少ない面でも表現できますが、曲面や境界付近では形状を維持するための頂点密度が必要です。
共有用OBJと保存用データを分ける方法も有効です。共有用は表示速度を重視しながら重要境界を残し、保存用には元点群や高密度メッシュを保持します。共有用だけを唯一の成果にすると、簡略化で失われた情報を後から検証できません。
書き出し条件、法線計算、頂点結合、簡略化、アップロード設定、確認結果を記録すると、同じ問題の再発を防ぎやすくなります。検証済みの条件を標準化すれば、担当者や案件が変わっても境界品質をそろえやすくなります。
まとめ
点群OBJのスムージング境界が消える問題は、スムージンググループの欠落や未対応だけでなく、明示法線の再計算、法線参照の統合、重複頂点の結合、メッシュ簡略化、アップロード先の変換処理などによって発生します。
最初に確認すべきなのは、対象が点データなのか、面を持つメッシュなのかという点です。面を持たない点データには通常のスムージング境界がないため、点描画や自動表面生成を確認します。OBJでは点要素と面要素が区別されるため、ファイル内の構成と読み込み側の対応を確かめることが重要です。
面を持つOBJでは、スムージンググループを明示し、重要な境界で法線参照を分けます。頂点座標の共有だけを問題視するのではなく、面ごとの法線とテクスチャ座標を含む参照関係が変換後も保持されているかを確認します。
書き出したOBJでは正常で、アップロード後だけ境界が消える場合は、アップロード先で法線再生成、頂点統合、簡略化などが行われている可能性があります。小さな検証データを用意し、一項目ずつ条件を変えることで原因を切り分けます。
点群OBJの目的は、面数を増やすことではなく、現場で必要な形状を正しく伝えることです。曲面は滑らかに見せ、構造物の角や地形の変化点は明確に残すという使い分けが欠かせません。
境界が重要な場所は計測時から点密度を確保し、変換時には稜線を保護し、アップロード後には複数方向と複数表示条件で確認します。この流れを標準化すれば、点群OBJアップロード後の見え方を安定させ、関係者間の誤認を抑えやすくなります。
現場での点群取得から三次元データの共有までを効率化し、必要な形状をその場で確認できる運用を整えるなら、その入口となるのがLRTK Phoneです。