点群OBJのアップロードでLODが必要になる理由
点群から作成したOBJをクラウドや共有システムへアップロードするとき、元データをそのまま送れば最も多くの形状情報を残せます。しかし、情報量が多いデータほど実務で扱いやすいとは限りません。高密度な点群から生成したOBJは、頂点数や面数が大きくなりやすく、アップロード時間、保存容量、表示速度、通信量などに影響します。
特に現場全体、道路、造成地、建築物、設備、法面などを広い範囲で計測したデータでは、細かな凹凸まで再現しようとすると形状が非常に複雑になります。さらに、写真から作成した画像を表面に貼り付ける場合は、OBJ本体だけでなく、マテリアル情報や複数の画像ファイルも合わせて管理しなければなりません。
このようなデータを閲覧用の環境へそのままアップロードすると、転送は完了しても表示開始まで時間がかかったり、視点を動かしたときに画面が止まったりすることがあります。利用する端末によっては、データを開くだけでメモリの使用量が増え、ほかの操作が難しくなる場合もあります。
そこで検討したいのがLODです。LODはLevel of Detailの略で、閲覧条件に応じて形状の細かさを変える考え方を指します。遠くから見るときには簡略化したモデルを使い、近づいたときには細かなモデルへ切り替えることで、見た目と処理負荷のバランスを取ります。
ただし、点群OBJをアップロードする前に、すべての案件でLODを作ればよいわけではありません。簡略化によって小さな段差や境界、設備、亀裂、突起などが失われる可能性があるためです。測定や数量計算に使用するデータまで一律に軽量化すると、作業目的を満たせなくなることがあります。
重要なのは、ファイルが大きいという理由だけでLODを作るのではなく、アップロード後の使い方、必要な精度、閲覧端末、通信環境、更新方法を整理したうえで判断することです。この記事では、点群OBJアップロード前にLODを作るべきかを判断するための5つの条件と、実際に作成するときの注意点を解説します。
点群OBJにおけるLODの基本的な考え方
点群OBJという言葉は、点群から生成したポリゴンモデルをOBJ形式で保存したデータを指す場合と、OBJ内に頂点情報を記録し、点に近い状態で扱うデータを指す場合があります。実務では、計測した点群から表面形状を作成し、三角形の面で構成されたモデルとしてOBJへ書き出すケースが多く見られます。
OBJには頂点座標、面を構成する頂点番号、テクスチャ座標、法線などを記録できます。一方で、一般的なOBJ形式そのものに、複数のLODを自動的に切り替えるための共通ルールが用意されているとは限りません。そのため、LODを用意するときは、詳細度ごとに別のOBJファイルを作成し、アップロード先の仕組みで切り替える方法が一般的です。
たとえば、元データに近い詳細モデル、中程度に簡略化した確認用モデル、大幅に軽量化した全体表示用モデルを分けて保存します。閲覧システムが自動切り替えに対応していない場合でも、用途別にファイルを選べるようにしておけば、利用者が必要な詳細度を選択できます。
LODで減らす対象は、ポリゴン数だけではありません。画像を表面に貼り付けている場合は、テクスチャ画像の解像度も表示負荷に大きく影響します。形状だけを簡略化しても、高解像度の画像を多数読み込む構成であれば、データ全体の容量やメモリ使用量はあまり減らないことがあります。
反対に、画像だけを小さくして形状を維持すると、輪郭や段差は保てますが、文字、ひび割れ、汚れ、材質の違いなどが見えにくくなります。形状と画像のどちらを優先するかは、閲覧目的によって変える必要があります。
LODを作る際には、元データを上書きしないことも重要です。簡略化は基本的に情報を削る処理であり、一度失われた形状を簡略化後のOBJから正確に復元することは困難です。高密度な元データを保管し、その複製からLODを作成することで、測定、再編集、再出力が必要になった場合にも対応できます。
判断条件1 ファイル容量がアップロードと共有の負担になっている
最初の判断条件は、OBJ一式の容量がアップロードや共有の負担になっているかどうかです。ここで確認する容量は、OBJファイル単体ではありません。マテリアル情報を記録したファイル、テクスチャ画像、補足データなど、アップロードに必要な一式の合計で考えます。
高密度な点群から生成されたOBJでは、頂点と面の情報が大量に記録されます。OBJは文字列で座標や面構成を記録することが多いため、同じ形状でも保存形式によってはファイル容量が大きくなりやすい傾向があります。頂点数が増えるほど座標行が増え、面数が増えるほど面定義の行も増加します。
アップロードに時間がかかっている場合、単に回線速度だけを原因と考えるのは早計です。アップロード前の圧縮処理、サーバー側の検査、展開、変換、プレビュー生成などに時間がかかっている可能性もあります。大容量ファイルでは、転送後の処理が終わるまで閲覧できないこともあります。
また、アップロードが途中で失敗した場合、最初から送信し直さなければならない環境では、容量が大きいほど再作業の負担が増えます。現場の通信が不安定な状況では、同じファイルを何度も送ることになり、業務時間を圧迫します。
このような場合は、LODを作成する価値があります。ただし、容量が大きいという理由だけで大幅にポリゴンを削減するのではなく、まず何が容量を占めているかを確認します。OBJ本体が大きいのか、テクスチャ画像が大きいのか、画像の枚数が多いのかによって、適切な対策は異なります。
OBJ本体が主な原因であれば、形状簡略化によって頂点数と面数を減らします。画像が主な原因であれば、画像解像度の調整、不要画像の除外、同一用途の画像統合などを検討します。両方が大きい場合は、形状用LODと画像用LODを組み合わせる必要があります。
判断に使う数値は、特定の容量だけで決めるべきではありません。アップロード先の上限、通信速度、利用者が待てる時間、更新頻度によって実用的な容量は変わります。ある環境では問題なく送れるファイルでも、現場回線や遠隔地では扱いにくいことがあります。
実際の運用では、元データを使って一度アップロード試験を行い、転送開始から閲覧可能になるまでの時間を測ります。次に、面数や画像解像度を段階的に下げたLODを作り、同じ条件で比較します。感覚ではなく、処理時間と見え方を並べて確認することで、削減しすぎを防げます。
容量の大きさによって共有が止まる、送信失敗が繰り返される、アップロード後の変換に長い時間がかかるという状態であれば、LODを作るべき可能性は高いと判断できます。
判断条件2 表示端末で操作遅延や描画停止が発生する
2つ目の判断条件は、アップロード後に使用する端末で、操作遅延や描画停止が発生するかどうかです。ファイルをアップロードできても、閲覧時に動かせなければ実務では使えません。
点群OBJを表示するときは、ファイルを読み込み、頂点、面、法線、画像などの情報を端末側で処理します。表示環境によって処理方法は異なりますが、一般に形状が複雑になるほど、描画やメモリへの負担が増えます。
特に負荷が高くなりやすいのは、広い範囲を高密度でメッシュ化したデータです。地面の細かな凹凸、植生、資材、設備、仮設物などがすべて形状化されていると、全体表示の段階でも大量の面を処理することになります。
操作遅延の有無は、ファイルが開くかどうかだけでは判断できません。視点の回転、拡大縮小、移動、断面表示、表示レイヤーの切り替えなど、実際の作業で使う操作を試す必要があります。読み込み直後は動いていても、複数回操作すると動作が不安定になる場合もあります。
また、高性能な作業用端末で問題なく表示できたとしても、すべての利用者が同じ環境を使うとは限りません。現場で使用する携帯端末、一般的な事務用端末、遠隔会議中の共有画面などでは、同じOBJでも操作感が大きく変わります。
LODを用意すると、全体を確認するときは軽量モデルを使用し、詳細確認が必要な範囲だけ高精細モデルを開く運用ができます。これにより、最初から全域の高密度形状を読み込む必要がなくなります。
ただし、単純に面数を減らすだけでは、表示速度が十分に改善しないこともあります。画像枚数が多い場合、透明表現が多い場合、細かく分割された形状が大量に含まれる場合などは、別の要因が負荷になっている可能性があります。
そのため、LOD作成前には、形状だけを表示した場合と画像を含めた場合を分けて試すと原因を切り分けやすくなります。形状だけなら軽快に動く場合は、画像側の調整が有効です。画像を外しても重い場合は、頂点数、面数、オブジェクト分割、不要形状などを見直します。
操作中に画面が頻繁に止まる、視点移動が滑らかに行えない、端末によって表示できない、読み込み後にほかの作業が難しくなる場合は、LODを作るべき明確な兆候です。
判断条件3 閲覧距離に対して細部が過剰になっている
3つ目の判断条件は、データに含まれる細部が、実際の閲覧距離に対して過剰になっていないかという点です。LODは、見えない情報や判断に使わない情報を減らし、必要な部分へ処理能力を集中させるための方法です。
たとえば、敷地全体を上空から確認する用途では、地面にある数ミリから数センチ程度の細かな凹凸をすべて表示しても、画面上では区別できないことがあります。それにもかかわらず、高密度な形状を維持すると、見た目がほとんど変わらないまま処理負荷だけが増えます。
一方、舗装面の段差、構造物の角、配管の形状、設備の取り合いなどを近距離で確認する用途では、同じ細部が重要になります。つまり、必要な詳細度は対象物そのものではなく、対象物をどの距離と縮尺で見るかによって変わります。
LODを判断するときは、データの主な閲覧範囲を想定します。現場全体を俯瞰するのか、建物単位で確認するのか、部材や設備まで拡大するのかによって、適切な段階数は異なります。
全体配置の確認が中心であれば、境界、主要構造物、地盤形状などが判別できれば十分な場合があります。施工前後の比較や出来形確認を行う場合は、比較対象となる面や端部を維持しなければなりません。亀裂や欠損の確認を目的とする場合は、形状簡略化よりも元データの維持を優先する必要があります。
実務では、一つのOBJですべての閲覧距離に対応させようとすると、全体表示には重すぎ、詳細確認には粗すぎるという中途半端な状態になりがちです。複数のLODを作れば、全体確認用、通常閲覧用、詳細確認用に役割を分けられます。
ただし、LODの段階を増やしすぎると管理が難しくなります。利用者がどのファイルを選べばよいか分からなくなり、誤ったLODで測定や確認を行う危険もあります。最初から多くの段階を作るのではなく、実際の閲覧用途に合わせて必要最小限に設定することが重要です。
閲覧画面で細部が判別できないにもかかわらず、細かな形状が大量に含まれている場合や、全体確認のためだけに高密度モデルを毎回読み込んでいる場合は、LODを作るべき条件に該当します。
判断条件4 利用者ごとに通信環境と用途が異なる
4つ目の判断条件は、同じ点群OBJを利用する人の通信環境や用途が異なるかどうかです。社内の高速回線だけで運用する場合と、現場や外出先から閲覧する場合では、求められるデータ構成が変わります。
点群OBJは、計測担当者だけで利用するとは限りません。施工担当者、設計担当者、発注者、協力会社、管理者など、複数の関係者が閲覧することがあります。それぞれが必要とする情報量は同じではありません。
計測担当者は、形状の精度やノイズの状態を確認するため、高密度なデータを必要とすることがあります。設計担当者は、構造物の位置関係や外形を確認できればよい場合があります。現場担当者は、現在位置周辺の形状を素早く確認したいことがあります。説明や報告を受ける側では、全体像が軽快に表示されることが優先される場合もあります。
このように用途が異なるにもかかわらず、全員へ同じ高密度OBJを配布すると、必要以上の通信量と操作負荷が発生します。反対に、軽量モデルだけを共有すると、詳細確認が必要な利用者が目的を達成できません。
LODを作成しておけば、閲覧用の軽量モデルと、確認用の詳細モデルを分けられます。最初は軽量モデルで全体を共有し、詳しく確認する必要がある人だけが高精細なデータを使用する運用が可能です。
通信環境の差も重要です。事務所では問題なく扱える容量でも、移動中や現場の通信では読み込みに時間がかかることがあります。通信が一時的に切れた場合、再読み込みが必要になる仕組みでは、軽量なLODがあるだけで作業の中断を減らせます。
また、共有先が増えるほど、利用端末の性能も揃わなくなります。作成者の環境だけを基準にしていると、ほかの利用者が開けない、操作できない、画像が表示されないといった問題が起こりやすくなります。
この条件では、LODを単なる軽量版として扱うのではなく、利用者別の配布データとして設計することが有効です。全体説明用、通常確認用、技術確認用など、用途をファイル名や管理情報で明確にします。
ただし、簡略化したデータを測定や合否判定に使わせないための区別も必要です。閲覧用LODには、測定用の元データではないことが分かる名称や説明を付けます。表示上の利便性と、判断に使用できる精度は分けて考えなければなりません。
複数の利用者が異なる場所や端末から閲覧し、必要な情報量にも差がある場合は、LODを作ることで共有の負担を大きく減らせます。
判断条件5 更新頻度が高くデータ管理が複雑になっている
5つ目の判断条件は、点群OBJの更新頻度が高く、アップロードやデータ管理が複雑になっているかどうかです。工事の進捗確認、定期点検、地形変化の記録などでは、同じ場所を繰り返し計測し、複数時点のOBJを保存することがあります。
一回だけアップロードする場合は、多少大きなデータでも許容できるかもしれません。しかし、毎日、毎週、工程ごとに高密度OBJを追加していくと、保存容量と転送時間が積み重なります。利用者が過去データを比較するときにも、複数の大容量モデルを読み込む必要が生じます。
更新頻度が高い案件では、毎回すべての情報を最高密度で共有する必要があるかを見直します。全体の進捗確認が目的であれば、各時点の軽量LODを並べ、詳細な確認が必要な日付だけ元データを参照する運用が考えられます。
また、計測範囲の一部しか変わっていない場合でも、OBJ全体を再出力してアップロードすると、変更していない部分まで繰り返し転送することになります。アップロード先が部分更新に対応していない場合は、区域ごとにモデルを分割し、それぞれにLODを用意する方法が有効です。
ただし、区域分割には注意が必要です。境界部分が重複したり、隙間ができたり、座標がずれたりすると、複数ファイルを重ねたときに不整合が生じます。分割前に共通の座標基準と境界ルールを決めておく必要があります。
LODを作るとファイル数は増えるため、命名と版管理を行わないと、かえって管理が複雑になります。撮影日、対象範囲、詳細度、改訂番号などを一貫した順序で記録し、どれが元データでどれが閲覧用かを明確にします。
更新運用では、毎回異なる簡略化設定を使わないことも重要です。同じ場所のLODでも、時点ごとに削減率や境界保持の条件が異なると、実際には変化していない部分が変形して見えることがあります。時系列比較を行う場合は、できるだけ同じ処理条件を適用します。
高頻度で更新するデータをすべて高密度のままアップロードしており、保存、転送、検索、比較に時間がかかっている場合は、LODを作るべき条件に該当します。閲覧用LODと保存用の元データを分けることで、日常的な確認を軽くしながら、必要な情報を残せます。
LODを作らず元データを優先すべきケース
LODは便利ですが、形状を簡略化することで目的を損なう場合があります。特に測定、検査、解析、数量計算に使用するOBJでは、安易な簡略化を避ける必要があります。
たとえば、出来形の差を細かく確認する場合、面を減らすことで局所的な高低差が平均化されることがあります。小さな段差、欠損、変形、角部などが削られると、元の点群が持っていた特徴を確認できません。
体積計算や断面作成に使用する場合も注意が必要です。簡略化によって表面が内側または外側へ変化すると、算出される体積や断面形状が変わる可能性があります。見た目では違いが小さくても、広い面積にわたる誤差が積み重なると、数量へ影響することがあります。
構造物の接合部、設備の干渉、配管の位置、狭い隙間などを確認する用途では、形状の境界を維持することが重要です。全体の面数を減らす処理によって、別々だった形状がつながったり、薄い部材が消えたりする場合があります。
亀裂、剥離、欠け、細かな変状を確認するデータでは、LOD作成そのものが目的と合わないことがあります。これらは高密度な形状や高解像度画像を必要とするため、軽量化よりも対象範囲を限定する方が適しています。
アップロードする範囲が小さく、元データのままでも転送と表示に問題がない場合も、無理にLODを作る必要はありません。LOD作成には処理時間、確認作業、管理作業が必要です。軽量化による効果が小さいなら、元データをそのまま使う方が工程を減らせます。
測定用、保存用、将来の再処理用には元データを残し、LODは閲覧や共有を補助する派生データとして扱うことが基本です。元データを削除し、LODだけを正式データとして残す運用は避けた方が安全です。
点群OBJのLODを設計する実践手順
LODを作ると決めたら、最初にアップロード後の用途を明確にします。軽くすること自体を目標にすると、必要な形状まで削除しやすくなります。全体配置の確認、現場説明、遠隔共有、詳細確認など、どの操作を快適にしたいのかを先に決めます。
次に、元データの状態を記録します。OBJ本体の容量、頂点数、面数、画像枚数、画像容量、対象範囲などを確認します。LOD作成後に同じ項目を比較することで、どの程度軽量化できたかを判断できます。
その後、削減してはいけない特徴を決めます。構造物の輪郭、地盤の主要な起伏、段差、開口部、設備の外形、区域の境界など、用途に必要な形状を整理します。簡略化処理では、これらの部分を優先的に維持します。
LODの段階は、実際の利用場面に合わせて設定します。全体を素早く開くための軽量モデル、通常の確認に使う中間モデル、細部を見るための詳細モデルという構成が考えられます。ただし、必ず3段階にする必要はありません。全体用と詳細用の2段階で十分な案件もあります。
段階ごとの目標は、削減率だけで決めないことが重要です。面数を一定割合まで減らしても、対象範囲や元の密度によって見え方は異なります。主要な輪郭が残っているか、視点移動が滑らかになったか、アップロード時間が短くなったかを確認します。
形状の簡略化後は、元データと重ねて差を確認します。輪郭、角、地表面、設備の境界などに不自然なずれがないかを見ます。測定用ではないLODであっても、位置関係が大きく変わると説明資料として使いにくくなります。
最後に、アップロード先で実際に試験します。作成環境では軽快でも、アップロード後の変換や表示方式によって結果が変わることがあります。想定する端末と通信環境で読み込み、全体表示、拡大、回転、移動などを試します。
この試験結果を基に、LODの設定を固定します。同じ種類のデータを継続的に作成する場合は、案件ごとにゼロから判断するのではなく、用途別の基準として残すと作業を標準化できます。
LOD作成時に維持すべき座標と形状の情報
LODを作成するときは、形状の細かさを減らしても、座標基準を変えないことが重要です。元データとLODの原点、軸方向、単位、位置を揃えておけば、複数の詳細度を切り替えても同じ場所に表示できます。
簡略化の前後で原点が自動的に変更されると、元データとLODを重ねたときに位置がずれます。処理時に中心位置へ移動する設定や、自動的に座標を正規化する設定が有効になっていないか確認します。
単位にも注意が必要です。OBJの座標値だけでは、使用している単位が閲覧側へ確実に伝わらない場合があります。作成側とアップロード先で、メートル、ミリメートルなどの解釈が異なると、モデルの大きさが合いません。LODごとに異なる設定で出力すると、詳細度を切り替えたときに縮尺が変わって見えます。
軸方向も統一します。高さとして扱う軸や前後左右の方向が出力処理によって変わると、モデルが横倒しになったり反転したりします。元データとすべてのLODで同じ座標変換を適用します。
形状面では、外周境界、鋭い角、穴、段差などを維持する必要があります。特に外周が簡略化されすぎると、隣接する区域との間に隙間が生じます。複数ファイルを並べる運用では、区域境界の頂点を固定する方法が有効です。
薄い形状にも注意します。柵、板、配管、縁石、標識などは、簡略化によって消えたり、厚みが変わったりすることがあります。これらが用途上必要であれば、別オブジェクトとして分けるか、簡略化の対象外にします。
法線の状態も確認します。形状簡略化後に面の向きが乱れると、表示環境によっては表面が暗くなったり、一部が見えなくなったりします。見た目の問題だけでなく、表裏判定に影響することもあるため、出力前に法線方向を確認します。
テクスチャを含むOBJで注意するポイント
テクスチャ付きの点群OBJでは、形状LODと画像LODを別々に考える必要があります。面数を減らしても画像が元のままであれば、アップロード容量や読み込み時間が期待ほど減らないことがあります。
高解像度画像は、表面の文字や細かな状態を確認するには有効です。しかし、全体を遠くから見る用途では、画像の細部を表示できないため、過剰な解像度になる場合があります。全体表示用LODでは画像を縮小し、詳細用LODでは元の解像度に近い画像を使用する方法があります。
画像を縮小するときは、縦横比を変えないことが重要です。縦横比が変わると、テクスチャが伸びたり縮んだりして見えます。また、画像形式の変換や再圧縮によって色や透明部分の扱いが変わることもあります。
形状簡略化によって面の構成が変わる場合は、テクスチャ座標も適切に更新しなければなりません。形状だけを減らし、元のテクスチャ座標との対応が崩れると、画像がずれたり、細長く伸びたりします。
OBJとマテリアル情報、画像ファイルの参照関係も維持します。LODごとに同じ画像名を使うと、アップロード先や保存場所によっては別の画像を参照してしまう可能性があります。詳細度ごとに保存先を分けるか、対応が分かる名称を付けます。
画像名には、空白、特殊な記号、環境によって解釈が変わりやすい文字を避けると管理しやすくなります。OBJ、マテリアル情報、画像を移動したときに参照が切れないよう、アップロード前に一式を別の場所へコピーして表示試験を行う方法も有効です。
全体確認用のLODでは、すべての画像を残す必要がないこともあります。対象外の床面、遠景、植生などに割り当てられた画像を整理することで、見た目を大きく変えずに容量を減らせる可能性があります。
ただし、画像を削除する際には、表面が無地になったり、マテリアル参照エラーが発生したりしないよう注意します。不要な参照記述も合わせて整理し、アップロード先で警告が出ない状態にします。
アップロード前に行うLODの品質確認
LODを作成した後は、容量が減ったことだけで完了と判断せず、元データとの違いを確認します。確認は形状、表示、ファイル構成、運用の4つの視点で行います。
形状については、対象物の輪郭、主要な段差、角、開口部、薄い部材などが残っているかを確認します。全体表示だけでは見落としやすいため、複数の方向から拡大して確認します。
地面や法面では、簡略化によって不自然な平面ができていないかを見ます。細かな凹凸を減らすことは有効ですが、地形の折れや勾配変化まで消すと、現地の印象と合わなくなります。
元データとLODを重ねられる場合は、差が大きい場所を確認します。全域で完全に一致させる必要はありませんが、用途上重要な範囲で大きなずれがないことを確かめます。
表示確認では、想定する閲覧端末で実際に操作します。読み込み時間だけでなく、回転、移動、拡大縮小、表示切り替えが安定しているかを見ます。複数のLODを切り替える運用では、切り替え後に位置や縮尺が変化しないことも確認します。
ファイル構成では、OBJから参照されるマテリアル情報と画像がすべて揃っているかを確認します。作成した端末では表示できても、別の場所へ移動すると画像が消える場合があります。アップロード予定の一式だけを新しいフォルダへコピーし、その状態で開く試験が有効です。
運用面では、元データとLODを明確に区別します。軽量モデルを誤って測定や正式な数量算出に使わないよう、名称や説明を統一します。作成日、対象範囲、詳細度、処理条件が分かる状態にしておくと、後から再作成しやすくなります。
点群OBJのLOD運用で起こりやすい失敗
LOD運用でよくある失敗は、元データを残さず、軽量化したOBJだけを保存してしまうことです。後から詳細確認や再計算が必要になっても、削減された形状から元の状態を正確に復元することはできません。
次に多いのが、削減率だけで品質を判断することです。同じ面数まで減らしても、平坦な地面と複雑な設備では結果が異なります。数値上は軽くなっていても、必要な形状が失われていれば実務では使えません。
LODごとに原点や縮尺が変わる失敗もあります。作成処理の途中で座標を移動したり、単位を変えたりすると、切り替え時に位置が飛びます。すべてのLODを同じ基準で出力する必要があります。
ファイル名だけで詳細度を区別し、利用者へ用途を説明していないケースにも注意が必要です。軽量版を正式データだと思って測定すると、結果の信頼性に影響します。閲覧用、確認用、保存用などの役割を明示します。
形状だけを軽くして、画像容量を確認していないケースもあります。OBJが小さくなっても、画像一式が大きいままでは、アップロード時間や表示負荷がほとんど変わらない場合があります。
反対に、画像を過度に縮小し、表面状態が確認できなくなることもあります。形状と画像は、用途に合わせて別々に品質を評価します。
更新のたびに異なる条件でLODを作ることも、時系列比較では問題になります。簡略化処理の違いが、実際の変化のように見える可能性があります。継続案件では、使用した条件を記録し、同じ方法を再利用できる状態にします。
LODの段階を増やしすぎる失敗もあります。ファイル数が多くなるほど、アップロード漏れ、画像の参照違い、版の取り違えが起こりやすくなります。利用目的が明確でない段階は作らず、必要な詳細度だけを用意することが安全です。
まとめ
点群OBJアップロード前にLODを作るべきかは、ファイル容量だけでは判断できません。アップロードと共有の負担、表示端末での操作性、実際の閲覧距離、利用者ごとの環境、更新頻度という5つの条件を総合的に確認する必要があります。
容量が大きく送信や変換に時間がかかる場合、表示端末で操作が止まる場合、遠景では見えない細部を大量に読み込んでいる場合は、LODによる軽量化が有効です。また、複数の利用者が異なる環境でデータを閲覧する場合や、高頻度で同じ場所を更新する場合にも、用途別のLODを用意する価値があります。
一方、測定、数量計算、出来形確認、変状調査など、形状の細部が結果に影響する作業では、元データを優先します。LODは元データの代替ではなく、閲覧や共有を快適にするための派生データとして位置付けることが大切です。
LODを作成するときは、ポリゴン数だけでなく、テクスチャ画像、座標、単位、軸方向、境界、法線、ファイル参照まで確認します。元データと重ねて形状差を確認し、実際のアップロード先と閲覧端末で動作を試すことで、軽さと見え方のバランスを判断できます。
点群OBJの運用を効率化するには、最初から必要以上に高密度なデータを作らないことも重要です。計測範囲、撮影距離、利用目的を整理し、必要な部分を適切な密度で取得できれば、後工程の簡略化や修正を減らせます。現場で点群を取得し、クラウド共有やOBJ出力まで一連の流れを見直したい場合は、LRTK Phoneを活用した点群計測の方法も確認してみてください。