点群OBJのスムージング設定が反映されない状態とは
点群から作成したOBJをアップロードした際、編集画面では滑らかに見えていた表面が、アップロード後には角張って見えることがあります。曲面に細かな三角形の境界が現れたり、平らな面の一部だけ陰影が乱れたり、同じデータでも表示環境によって見え方が変わったりする症状です。点群 OBJ アップロードの実務では、形状そのものが壊れていなくても、スムージング設定や法線情報の扱いによって品質が低く見えることがあります。
ここでいうスムージングは、頂点位置を移動して形状を丸める処理だけを意味するものではありません。OBJで扱われるスムージングは、主に隣り合う面の法線をどのように扱い、光の当たり方を滑らかに見せるかに関係します。ポリゴン数や頂点位置が同じでも、面または頂点に対応する法線の持ち方が違えば見た目は変わります。
OBJには、幾何頂点を表すv、線を表すl、面を表すf、法線を表すvn、スムージンググループを表すsなどの記述があります。ただし、すべてのソフトウェアが各記述を同じように解釈するわけではありません。元のWavefront系の仕様では、明示的な頂点法線がある場合にスムージング情報より優先される扱いが示されており、読み込み側の実装差も考慮する必要があります。([Paul Bourke][1])
また、点群OBJという呼び方には複数の状態が含まれます。測定点だけをOBJの頂点として保存したもの、点を線で結んだもの、点群から三角形メッシュを生成したもの、さらにテクスチャや材質を付けたものなどです。一般的なスムーズシェーディングが作用するのは、主に面を持つメッシュです。点だけで構成されたOBJにスムーズ表示を設定しても、面の陰影補間が存在しないため、メッシュと同じ変化は期待できません。
スムージングが反映されないときは、設定を繰り返す前に、OBJにどの情報が含まれているか、アップロード先が何を読み込むか、途中の変換で何が変更されるかを順番に確認します。原因を切り分けずに再書き出しを続けると、ファイル容量だけが増えたり、法線の再計算によって見え方がさらに変わったりすることがあります。
この記事では、点群から作成したOBJをアップロードした後にスムージングが反映されない代表的な原因を五つに整理し、実務で確認しやすい順序で解説します。特定のソフトウェアやサービスの動作を断定せず、一般的なOBJの構造と変換処理を前提にしているため、実際の利用環境では読み込み仕様もあわせて確認してください。
原因1：OBJが点や線だけで構成されている
最初に確認したいのは、対象のOBJにポリゴン面が含まれているかどうかです。OBJは三次元形状を保存できる形式ですが、必ずしも面を持つとは限りません。頂点を示す情報だけを並べたOBJや、頂点同士を線として結んだOBJも作成できます。こうしたデータでは、面の表裏や面法線を使った陰影補間が存在しないため、メッシュ向けのスムージングを設定しても表示結果は変わりません。OBJで点、線、面、法線を別々に記述できることは仕様上も確認できます。([Paul Bourke][1])
点群からOBJへ変換する工程では、点をそのまま頂点として保存する方式と、近傍点から三角形を生成してメッシュ化する方式があります。画面上で点が密に表示されていると表面のように見えるため、OBJにも面があると考えがちですが、実際には頂点だけが記録されている場合があります。点のサイズや描画方法によって見え方が変わるため、外観だけでは判断しにくい点に注意が必要です。
OBJの内容を確認するときは、頂点を示すv行だけでなく、面を示すf行が含まれているかを確認します。面情報がなければ、一般的なスムーズシェーディングの対象にはなりません。アップロード先が点群表示に対応している場合でも、点の描画方式とメッシュの陰影処理は別機能として実装されることがあり、メッシュ用の設定が点表示へ適用されるとは限りません。
この原因に該当する場合、必要なのはスムージング設定の変更ではなく、目的に合ったデータ構造への変換です。表面を滑らかに見せたいのであれば、点群から面を生成し、三角形メッシュとして書き出します。ただし、単純にすべての点を結べばよいわけではありません。点密度が不均一な領域や遮蔽部分では、実際には存在しない面が張られる可能性があります。計測対象の形状、点間隔、欠損範囲、ノイズ量を確認しながら面生成条件を決めることが重要です。
一方、目的が点群そのものの確認であれば、無理にメッシュ化する必要はありません。点サイズ、表示密度、色、距離に応じた間引きなど、点群向けの表示設定を調整した方が適切な場合があります。メッシュ化すると、補間によって元の計測点にはない表面が作られるため、測定結果の確認という目的から外れないように注意します。
点群 OBJ アップロード後に表面が角張って見えると感じたときは、まず角張った面があるのか、点の集合が粗く見えているのかを分けて考えます。前者は法線やスムージングの問題である可能性がありますが、後者は点密度や点表示の問題です。この区別を最初に行うだけで、不要な設定変更を減らせます。
原因2：スムージンググループが正しく書き出されていない
OBJでは、面を滑らかに扱うための指定としてスムージンググループが使われることがあります。一般的な記述ではs 1などでグループを指定し、s offで無効化します。ただし、この指定は頂点法線そのものではなく、法線を生成または解釈する際の手掛かりとして扱われることがあります。明示的な頂点法線が面から参照されている場合は、そちらが優先される実装もあるため、スムージンググループだけで表示結果が保証されるわけではありません。([Paul Bourke][1])
編集画面でスムーズ表示になっていても、その状態がOBJへ自動的に保存されるとは限りません。画面表示だけを滑らかにしている場合、書き出し処理でスムージンググループや頂点法線が出力されず、アップロード先で面ごとの陰影として表示されることがあります。逆に、すべての面を一つのグループとして扱うと、本来は角を残したい境界まで滑らかになり、稜線がぼやけることがあります。
特に注意したいのは、書き出し元と読み込み先でスムージンググループの解釈が一致しない場合です。OBJにs指定が含まれていても、読み込み先がその情報を利用せず独自に法線を生成する場合があります。また、スムージンググループと頂点法線の両方があるときの優先順位も、アプリケーションや変換処理によって異なることがあります。したがって、OBJ内に指定があることと、表示に反映されることは分けて確認する必要があります。
確認するときは、書き出し設定で法線、スムーズ境界、面のグループ化に関する項目が有効かを見ます。たとえばBlenderのOBJ書き出し機能には、面法線と頂点法線を書き出す設定があります。名称や選択肢は利用環境によって異なるため、設定名だけで判断せず、出力されたOBJにvnやsが含まれているかを確認すると確実です。([Blender Documentation][2])
設定項目が複数ある場合は、一度にすべてを変えず、基準となる小さなテストモデルで差を確認します。テストモデルには、平面、緩やかな曲面、明確な直角部分を含めると効果的です。平面では不要な陰影の波がないか、曲面ではポリゴン境界が目立たないか、直角部分では稜線が保たれるかを確認できます。
スムージンググループは形状を修正する機能ではありません。三角形の配置が粗い場合や、点群のノイズで表面が波打っている場合、陰影を滑らかにしても輪郭や頂点位置は変わりません。輪郭線に段差が見える場合はメッシュの解像度や形状処理を見直し、表面内の陰影だけが角張って見える場合にスムージンググループや法線を確認します。
原因3：頂点法線が欠落または再計算されている
スムージングの見た目を大きく左右するのが頂点法線です。法線は、面または頂点がどの方向を向いているかを示す情報で、照明計算や陰影表現に使われます。OBJにはvnとして法線を記録し、面の各要素から法線番号を参照できます。曲面上の各頂点に適切な法線が割り当てられていれば、ポリゴン自体が三角形の集合でも、面同士が滑らかにつながっているように見せられます。([Paul Bourke][1])
書き出し時に頂点法線が含まれていない場合、アップロード先は面形状から法線を生成することがあります。この計算方法が書き出し元と異なると、元の画面とは違う陰影になります。隣接面の角度が一定値を超えた境界を硬いエッジとして扱う方法、隣接面を平均する方法、面積や角度で重み付けする方法などがあり、同じ頂点座標でも結果は一致しないことがあります。
頂点法線がOBJに含まれていても、変換処理で無視または再計算されることがあります。メッシュの軽量化、頂点の統合、三角形化、属性の再構成などによって、元の法線と面の対応関係が変わるためです。その場合、処理側は整合性を保つために法線を生成し直すことがあり、書き出し前に調整した境界が失われる可能性があります。
反対に、不正確な法線がそのまま保持されることで問題が起きる場合もあります。点群から生成したメッシュでは、局所的な面の向きが不揃いになり、隣り合う法線が急に反転していることがあります。編集画面では両面表示などで目立たなくても、アップロード後に片面表示や別の照明条件が使われると、黒い斑点や不自然な陰影として現れることがあります。
頂点法線を確認するときは、法線の有無だけでなく、向きと連続性も見ます。曲面に沿って少しずつ方向が変化しているか、局所的に逆向きの法線がないか、直角部分で意図せず平均化されていないかが重要です。表面全体を一律に再計算すると改善することがありますが、構造物や機械部品のように明確な角を持つ形状では、必要な稜線まで丸く見える可能性があります。
実務では、まず面の向きをそろえ、その後に滑らかにしたい領域と角を残したい領域を分け、最後に頂点法線を生成する順序が安定します。面の向きが混在したまま法線を平均すると、不自然な方向になることがあります。法線再計算を行う場合は、角度条件だけに頼らず、部材境界や意図する形状も考慮します。
点群 OBJ アップロードで陰影が変わる場合、書き出し前後の頂点数と面数が同じでも、法線情報だけが変わっていることがあります。形状の数値だけでは判定できないため、可能であれば法線を可視化し、単一色の材質で照明を当てて確認します。テクスチャがあると陰影の乱れが隠れることがあるため、診断時には模様のない表示が適しています。
原因4：頂点分割や不整合な面が滑らかな陰影を妨げている
スムージングは、隣り合う面が共有する位置や法線の関係を利用して行われます。そのため、見た目ではつながっている面でも、内部的に頂点や法線が分かれていると滑らかにつながらないことがあります。点群から生成したメッシュでは、同じ位置に複数の頂点が存在したり、面ごとに独立した頂点が作られたりすることがあり、これがポリゴン境界を目立たせる原因になります。
頂点分割は必ずしも不具合ではありません。鋭い角を表現するため、異なる法線を割り当てるため、またはUVの継ぎ目を保持するために、同じ位置が変換先で複数の描画頂点へ展開されることがあります。OBJでは位置、テクスチャ座標、法線を別々の番号で参照できますが、描画用データへ変換するときに、その組み合わせごとに頂点を分ける実装があります。材質境界が常に幾何頂点の分割を必要とするわけではないため、材質切り替えと頂点分割を同一視しないことが重要です。([Paul Bourke][1])
問題になるのは、滑らかにしたい曲面まで不要に分割されている場合です。各面が別々の位置頂点または法線を持つと、隣接関係を使った法線平均が行われず、面ごとの陰影が残ることがあります。位置が同じでも法線番号が異なれば、見た目の境界は硬くなる可能性があります。
点群メッシュでは、重複頂点以外にも、ゼロ面積に近い三角形、極端に細長い三角形、重なり面、局所的な面反転、穴の周囲の不連続、非多様体の辺などが、法線再計算や後段の変換処理を不安定にすることがあります。自己交差が直ちに法線を壊すとは限りませんが、修復、軽量化、三角形化の結果を予測しにくくするため、診断対象には含めます。
頂点の統合を行う場合は、許容距離の設定に注意が必要です。距離を大きくしすぎると、本来は離れている薄い部材の表裏や、近接した配管、狭い隙間の頂点まで統合され、形状が壊れます。逆に小さすぎると、数値上わずかにずれた重複頂点が残ります。点群の座標精度、対象物の最小寸法、メッシュの平均辺長を基準に、必要最小限の範囲で統合します。
面の向きも重要です。隣り合う三角形で頂点の並び順が逆になると、幾何学的な面法線は反対方向を向きます。両面表示では形状が存在するように見えても、照明計算や法線生成では不連続が生じます。点群からの自動面生成では、閉じていない形状や薄い構造物の周辺で表裏判定が難しく、局所的な反転が残ることがあります。アップロード前に面方向を確認し、意図しない反転を修正します。
また、UVの継ぎ目や硬いエッジでは、位置が連続していても異なる法線が割り当てられることがあります。アップロード先が位置、法線、テクスチャ座標の組み合わせを一つの描画頂点として展開する場合、いずれかが異なるだけで内部頂点が分かれます。その結果、編集環境と変換後で境界の見え方が変わることがあります。
対策は、すべての頂点を一律に統合することではありません。曲面として連続させたい領域だけを統合し、角を残したい稜線、開口部、部材境界、必要なUVの継ぎ目は維持します。そのうえで不要な面を除去し、面方向を統一し、法線を再生成します。形状修復と法線再計算を分けて実施すると、どの処理が表示へ影響したかを確認しやすくなります。
原因5：アップロード後の変換処理で設定が変わっている
OBJをアップロードすると、表示環境によってはファイルをそのまま描画せず、内部形式へ変換します。表示速度を上げるための三角形化、頂点属性の再構成、面の並べ替え、座標変換、法線の再計算、不要属性の削除などが行われる場合があります。この工程でスムージンググループや頂点法線が変更されると、書き出し元とアップロード後の見た目が一致しません。
四角形や多角形を含むOBJでは、読み込み時に三角形へ分割されることがあります。どの対角線で分割するかによって三角形の向きが変わり、特にねじれた多角形では陰影が変化します。書き出し前の環境とアップロード先で三角形化の方法が異なると、同じ外形でも表面に斜めの陰影が現れることがあります。これを避けるには、アップロード前に三角形化し、その状態で法線を確認してから書き出します。
軽量化処理も影響します。面数削減では頂点位置や辺の構成が変わるため、元の法線をそのまま利用できないことがあります。処理後に法線が再計算されると、細かな曲面や角部の印象が変わります。点群由来のメッシュは小さな凹凸が多いため、軽量化を強くかけると、面数は減っても陰影の連続性や輪郭の再現性が低下することがあります。
アップロード先にスムース角度や自動法線の設定がある場合、OBJ内の情報よりもその設定が優先されることがあります。角度が小さすぎると曲面の途中に硬い境界が増え、角度が大きすぎると直角部分まで丸く見えます。適切な値は対象形状と読み込み仕様によって異なるため、万能な数値はありません。地形のような連続曲面と、建物や設備のように明確な稜線を持つ形状では、適した基準が異なります。
キャッシュも確認対象です。同じファイル名や同じ識別情報で再アップロードした場合、表示側に以前の変換結果やプレビューが残り、新しい法線設定が反映されていないように見えることがあります。ただし、キャッシュの有無や更新条件はサービスごとに異なります。ファイル名や版番号を変え、頂点数、面数、ファイル容量も記録して比較すると、古いデータを見ているのか、変換で設定が変わったのかを分けやすくなります。
OBJ本体がMTLやテクスチャを参照している場合、関連ファイルの欠落や参照名の不一致によって、既定材質で表示されることがあります。これはスムージンググループや頂点法線そのものが失われたことを意味しませんが、光沢、拡散反射、透明度、テクスチャの有無が変わることで、面の境界が強調される可能性があります。材質の読み込み失敗を、法線の消失と断定しないことが重要です。OBJとMTLが別ファイルで参照される構造は仕様資料でも確認できます。([The Library of Congress][3])
アップロード後の変換が原因かどうかを確認するには、同じOBJを複数の閲覧環境で開きます。書き出し直後のローカル表示では正常で、特定のアップロード先だけで崩れる場合は、その環境の変換処理や表示設定の影響を疑います。反対に、どの環境でも同じように角張る場合は、OBJ自体の法線、スムージンググループ、頂点構造を優先して確認します。
点群OBJアップロード前に行う確認手順
スムージングが反映されない問題は、確認順序を固定すると効率よく切り分けられます。最初に、対象OBJが点、線、面のどれを含むかを確認します。面がなければ、面の陰影を滑らかにする設定は作用しません。表面表現が必要ならメッシュ生成へ進み、点群表示が目的なら点の描画設定を調整します。
次に、メッシュの基本状態を確認します。面の向きがそろっているか、重複面がないか、極端に細い三角形が集中していないか、穴や非多様体部分がないかを見ます。この段階で形状が不安定な場合、法線を再計算しても安定した結果にならないことがあります。まず形状を修復し、その後に法線処理を行います。
三番目に、滑らかにしたい境界と角を残したい境界を決めます。すべてを滑らかにする設定は簡単ですが、構造物の稜線や部材境界までぼやける可能性があります。地形や盛土のように連続性を重視する領域と、壁、床、柱、配管の接合部のように角度を保ちたい領域を分けて扱います。
四番目に、頂点法線を生成または再計算します。面方向が統一された状態で行い、必要に応じて角度条件や境界条件を設定します。法線を生成した後は、単一色で斜め方向から光を当て、曲面の途中に筋がないか、平面に波打つ陰影がないか、角が意図どおり残っているかを確認します。
五番目に、OBJの書き出し設定を確認します。頂点法線、スムージング情報、面、材質参照など、必要な属性が含まれているかを確認します。用途に不要な情報を増やすと頂点分割や変換条件が複雑になる場合があるため、最終用途に必要な属性を明確にします。
六番目に、アップロード前のOBJを別の閲覧環境で開きます。書き出し元だけで確認すると、そのソフトウェアが内部情報を補って表示している可能性があります。別環境でも同じ見た目なら、必要な情報がOBJに含まれている可能性が高まります。別環境で崩れるなら、書き出し設定やOBJ構造を再確認します。
最後に、アップロード後の変換結果を比較します。版を識別できるファイル名を使い、同じ視点と照明条件で確認します。視点や光源が違うと、同じ法線でも印象が変わります。比較用の画像を残す場合は、正面、斜め、逆光に近い方向など複数の条件をそろえると、陰影の不連続を発見しやすくなります。
症状から原因を切り分ける方法
ポリゴンの三角形が一枚ずつはっきり見える場合は、頂点法線がない、スムージンググループが無効、平面法線が割り当てられている、または頂点や法線が面ごとに分割されている可能性があります。まずOBJ内のvnと面からの法線参照を確認し、次にs指定と共有頂点の状態を確認します。
曲面の一部だけに線状の境界が出る場合は、頂点または法線の分割、UVの継ぎ目、硬いエッジ、スムース角度の判定が考えられます。線が規則的に続くなら属性境界、局所的で不規則なら重複頂点や不整合面を疑います。境界の両側で法線方向を表示すると、連続しているかどうかを判断しやすくなります。
黒い面や急に暗くなる斑点がある場合は、面法線の反転、ゼロ面積に近い面、重なり面、異常な頂点法線の影響が考えられます。両面表示では形状が見えても、照明計算では逆向きの面が暗くなることがあります。面方向を確認した後に法線を再計算し、症状が変わるかを確認します。
平らなはずの面に波状の陰影が出る場合は、平面上の頂点法線が周囲の曲面や細かな凹凸の影響を受けている可能性があります。点群から生成したメッシュでは、計測ノイズによる微小な凹凸が残り、法線平均によって広い範囲へ陰影が広がることがあります。形状を過度に平滑化せず、平面として扱う範囲を分けて法線をそろえる方法が有効です。
書き出し元では正常で、アップロード後だけ崩れる場合は、変換時の法線再計算、三角形化、軽量化、キャッシュを優先して確認します。アップロード前に三角形化したテストデータと、元の多角形を含むデータを比較すると、三角形化の影響を判断できます。法線ありと法線なしの二種類を作り、アップロード先の挙動を比較する方法も有効です。
形状の輪郭そのものが角張っている場合は、スムージングだけでは解決しません。陰影補間は輪郭となる頂点位置を変えないため、外周ではポリゴン形状がそのまま見えます。この場合は、面数、三角形の配置、曲面近似の精度を見直します。見た目だけを滑らかにしたいのか、実際の形状精度を高めたいのかを分けて判断することが重要です。
スムージングを安定させる書き出し設定
安定したOBJを書き出すには、最終利用環境で必要となる情報を明確にします。単なる形状確認であれば、頂点、面、適切な法線が中心です。テクスチャ表示が必要なら、テクスチャ座標、材質参照、画像ファイルの関係も維持します。書き出し設定によって位置、法線、UVの組み合わせが変わり、変換後の頂点数が増えることがあるため注意します。
ポリゴンは、必要に応じてアップロード前に三角形化します。OBJは三角形以外の多角形も表現できますが、最終表示で三角形へ変換される環境は多くあります。事前に三角形化しておけば、対角線の選び方を固定でき、書き出し前後で法線の結果を比較しやすくなります。ただし、三角形化後に法線を再確認しなければ、変換前の見た目と一致しないことがあります。
頂点法線は、必要に応じて書き出し対象へ含めます。ただし、アップロード先が必ず保持するとは限らないため、法線を含む版と、読み込み先で再計算させる版を小規模データで比較すると安全です。どちらが安定するかは、変換処理の仕様とメッシュ状態によって異なります。
スムージンググループを利用する場合は、滑らかにしたい面が同じグループとして出力されているかを確認します。角を残したい境界ではグループを分けるか、異なる法線を割り当てます。すべてを一つのグループにまとめる方法は地形のような連続面では有効なことがありますが、人工構造物では不自然な丸みを生みやすいため注意が必要です。
座標値の大きさや単位も間接的に影響します。OBJには標準化された単位指定がないため、書き出し元と読み込み先で単位の前提が異なると縮尺が変わる可能性があります。また、非常に大きな座標値のまま細かな形状を扱うと、表示環境の数値精度によって頂点位置や法線計算に影響が出ることがあります。必要に応じてローカル原点へ移動し、単位と原点移動量を記録します。OBJの座標に標準単位がない点は形式解説でも確認できます。([The Library of Congress][3])
ファイル名は、版を識別できるようにします。同じ名前で上書きを続けると、キャッシュや作業者の取り違えにより、変更が反映されていないように見えることがあります。日付、版番号、処理内容などを簡潔に含め、法線再計算前後や軽量化前後を区別できるようにします。
書き出し後は、OBJ本体だけでなく関連ファイルも一式で確認します。MTLやテクスチャ画像が必要な場合、参照名の大文字と小文字、拡張子、相対位置が一致しているかを見ます。材質の欠落はスムージング設定そのものを変えませんが、光沢や陰影の強さが変わり、角張りが強調されることがあります。
点群OBJの品質を保つ運用ルール
スムージング問題を再発させないためには、個別の設定だけでなく、作業工程を標準化することが重要です。点群取得、ノイズ除去、メッシュ生成、形状修復、法線生成、軽量化、書き出し、アップロードという順序を明確にし、各工程の目的を分けます。複数の処理を一度に行うと、どこで表示が変わったか追跡しにくくなります。
元の点群、初期メッシュ、修復後メッシュ、軽量化後メッシュ、アップロード用OBJを別々に保存します。最終ファイルだけを残す運用では、問題が出たときに原因を比較できません。特に法線は見た目に影響する一方、頂点数や面数だけでは変更を把握しにくいため、法線生成条件も記録します。
確認用の基準視点を決めることも有効です。曲面、平面、稜線、穴、薄い部材など、問題が出やすい場所をあらかじめ選び、毎回同じ方向から比較します。照明条件も固定し、テクスチャありと単一色の両方で確認します。単一色表示では法線の乱れを発見しやすく、テクスチャ表示では実際の利用時の印象を確認できます。
軽量化率だけで品質を管理しないことも重要です。同じ面数まで減らしても、曲率の高い部分を残す方法と一律に減らす方法では見た目が異なります。点群OBJでは、広い平面よりも曲面、稜線、開口部の周辺へ面を多く残す方が、少ない面数でも形状と陰影を保ちやすくなる場合があります。
アップロード先の仕様が更新される可能性も考慮します。内部変換や表示機能が変わると、以前と同じOBJでも見え方が変化することがあります。重要な案件では、基準となる小さなOBJを保存しておき、環境更新後に同じ手順で比較すると、表示側の変化を発見しやすくなります。
複数担当者で作業する場合は、スムージング済みという表現だけで引き継がないようにします。スムージンググループを設定したのか、頂点法線を再計算したのか、頂点位置を動かす形状平滑化を行ったのかで意味が異なります。処理内容、角度条件、頂点統合の許容距離、三角形化の有無、軽量化の有無を記録すると、再現性が高まります。
LRTK Phoneで取得したデータを扱う際の考え方
LRTK Phoneを使って現場の点群データを取得し、クラウドで保存、閲覧、編集、共有する場合も、スムージングは表示品質と計測情報を分けて考える必要があります。公式情報では、LRTK Phoneによる絶対座標付き点群の取得と、クラウド上での座標、距離、面積、体積の計測、データ共有が案内されています。(LRTK Phone公式製品情報)
滑らかな陰影は形状を見やすくしますが、計測精度を高める処理ではありません。表面がきれいに見えることと、寸法や位置が正しいことを同一視しないことが重要です。点群をOBJメッシュへ変換する場合は、取得データ、メッシュ生成条件、法線処理の影響を分けて管理します。
現場データでは、植生、反射面、細い部材、遮蔽物、移動体などによってノイズや欠損が生じることがあります。これらを含んだままメッシュ化すると、補間によって誤った面が自然に見えてしまう場合があります。まず点群の状態を確認し、不要点を除き、必要な範囲だけをメッシュ化してから法線を整えます。
土量確認や出来形確認など、数値評価が中心の用途では、頂点位置を変更する形状平滑化を強くかけすぎないようにします。頂点位置が変われば、局所的な高さや端部形状、体積計算の結果に影響する可能性があります。陰影だけを整える法線処理と、頂点座標を移動する形状処理を明確に区別し、目的に応じて使い分けます。
共有用OBJを作成する際は、閲覧しやすい軽量版と、計測情報を保った確認版を分ける方法が有効です。軽量版では表示速度を優先し、確認版では必要な点密度や形状精度を維持します。どちらも同じ名称で管理すると取り違えやすいため、用途、処理内容、版番号を明記します。
LRTK Phoneから得た点群を点群 OBJ アップロードへつなげる場合、取得、処理、書き出し、表示の各段階で何が変わるかを記録しておくと、スムージングの問題だけでなく、座標、縮尺、色、材質、ファイル容量に関する問題も切り分けやすくなります。見た目の調整と計測データの保全を両立させることが重要です。
まとめ
点群OBJのスムージング設定が反映されない主な原因は、OBJに面が含まれていないこと、スムージンググループや頂点法線が適切に書き出されていないこと、頂点法線が欠落または再計算されていること、頂点や法線の分割と不整合な面が残っていること、アップロード後の変換処理で設定が変わっていることの五つです。
最初に点、線、面の構成を確認し、次に面方向や重複頂点などの形状状態を整えます。その後、滑らかにする領域と角を残す領域を分け、頂点法線とスムージング情報を設定します。書き出し後は別の閲覧環境で確認し、アップロード後の変換結果と比較することで、問題がOBJ側にあるのか、表示環境側にあるのかを判断しやすくなります。
スムージングは、粗い形状を自動的に高精度化する機能ではありません。陰影を滑らかにする処理、頂点位置を平滑化する処理、点群から面を生成する処理は、それぞれ目的と影響が異なります。見た目だけを改善したいのか、形状自体を整えたいのか、計測情報を保ちたいのかを明確にしてから処理を選ぶことが大切です。
点群 OBJ アップロードを安定させるには、法線やスムージングだけを個別に調整するのではなく、点群取得からメッシュ生成、修復、軽量化、書き出し、アップロードまでを一つの工程として管理します。LRTK Phoneで取得した点群を利用する場合も、取得時のデータ、メッシュ化後の形状、表示用の法線を分けて管理することで、見た目と計測情報の両方を保ちやすくなります。