点群OBJアップロードでメモリ不足が起こる仕組み
点群OBJをクラウドサービスやWeb上の管理画面へアップロードするとき、ファイルの送信途中で処理が停止したり、読み込み画面が閉じたり、メモリ不足を示すエラーが表示されたりすることがあります。ファイル容量だけを見ると問題がないように見えても、実際の読み込み処理では、保存されているデータを解析して画面表示や計測に使える形式へ展開するため、ファイル容量を上回るメモリが必要になる場合があります。
OBJは、頂点座標、面を構成する頂点番号、法線、テクスチャ座標、オブジェクト名、グループ情報、マテリアル参照などをテキストとして記録できる形式です。点群として利用する場合は頂点情報が中心になりますが、作成方法によっては面情報や法線、色に関連するデータが含まれていることもあります。アップロード先では、これらの文字列を数値として解析し、内部の配列や描画用データへ変換します。
そのため、ストレージ上では数百MBのOBJであっても、解析中には元データ、変換後の頂点配列、表示用の一時データ、サムネイル生成用データなどが同時に保持されることがあります。処理内容によっては同じ頂点情報が一時的に複数箇所へ複製されるため、実際のメモリ使用量がファイル容量の数倍以上になることも珍しくありません。
テクスチャ画像を伴う場合は、さらに注意が必要です。画像ファイルは保存時に圧縮されていても、画面表示のために展開されると、幅、高さ、色数に応じた大きなメモリ領域を使用します。画像ファイルの容量が小さいからといって、読み込み時の負荷も小さいとは限りません。高解像度画像を多数参照しているOBJでは、形状データより画像データの展開がメモリ不足の主因になる可能性もあります。
また、アップロード処理は、ファイルをサーバーへ送信する工程だけではありません。送信前の検査、文字コードの確認、構文解析、頂点数の集計、座標範囲の算出、表示用データの作成、サムネイル生成などが続く場合があります。画面上では「アップロード中」と表示されていても、実際には端末側で変換処理が進んでいることがあります。
点群OBJのメモリ不足を解消するには、単純に通信環境を改善するだけでは不十分です。元データの頂点数、面数、属性、分割方法、利用端末の空きメモリ、ブラウザの状態、アップロード先の仕様を組み合わせて見直す必要があります。
事前に確認したいメモリ不足の兆候
点群OBJのアップロードが失敗したからといって、原因が必ずメモリ不足とは限りません。通信の切断、ファイル形式の不整合、利用できない文字、参照ファイルの欠落、アップロード可能容量の超過などでも似た症状が発生します。対策を始める前に、メモリ不足らしい兆候があるかを確認することが重要です。
代表的な兆候は、処理が進むにつれて端末全体の動作が重くなることです。マウス操作や画面切り替えの反応が遅くなり、別の画面まで停止する場合は、空きメモリが急激に減っている可能性があります。アップロード画面だけが一瞬でエラーになる場合より、一定時間処理した後に停止する場合のほうが、解析中のメモリ消費が影響している可能性が高くなります。
同じOBJを容量や範囲ごとに分割したところ、小さいファイルだけ正常に処理できる場合も、メモリ不足を疑う材料になります。元のファイルに構文上の問題がある場合は、分割後も同じ行を含むファイルで失敗する可能性があります。一方、どの部分も小さくすれば読み込めるのであれば、総頂点数や総データ量が処理上限へ達していた可能性があります。
再起動直後は成功しやすいのに、長時間作業した後は失敗しやすい場合も、空きメモリの不足が考えられます。複数の画面、設計資料、画像、点群ビューア、編集画面などを開いたままにすると、それぞれがメモリを使用します。ブラウザのタブを閉じただけではメモリが完全に解放されず、アプリケーション自体の再起動が必要になることもあります。
アップロード処理中に画面が再読み込みされたり、タブが強制終了したりする場合は、ブラウザ側が使用できるメモリの限界へ達している可能性があります。ただし、同様の現象は拡張機能や端末の省電力機能、セキュリティ設定によっても起こり得ます。メモリ不足と断定せず、条件を一つずつ変えて再現性を確認することが大切です。
確認するときは、元ファイルの容量だけでなく、頂点数、面数、テクスチャ画像の枚数、画像の解像度、関連ファイルの総容量、処理に使用した端末の状態を記録しておくと効果的です。成功したファイルと失敗したファイルの違いを比較すれば、次に調整すべき項目を判断しやすくなります。
方法1 頂点数と面数を適正化する
メモリ不足を解消するうえで最も効果が出やすい方法は、点群OBJに含まれる頂点数と面数を減らすことです。ファイル容量だけを圧縮するのではなく、読み込み後に保持される要素数そのものを削減する点が重要です。
点群の密度が必要以上に高い場合、見た目や計測結果にほとんど影響しないほど近接した点が大量に含まれていることがあります。対象物の大きさや必要な測定精度に対して点間隔が細かすぎると、アップロード時間や描画負荷だけが増え、実務上の利点が小さくなる可能性があります。
まず、点群を利用する目的を明確にします。構造物の概略形状を確認する用途と、細かな凹凸を調べる用途では、必要な点密度が異なります。広範囲の地形や造成状況を確認するだけであれば、数mm間隔の点を全面に保持する必要がない場合があります。一方、小さな段差や損傷を確認する場合は、対象部分の密度を残し、それ以外の範囲を軽量化する方法が適しています。
点を間引く際は、一定の割合で機械的に削除するだけでなく、空間上の間隔を基準に整理する方法が有効です。点が集中している場所では削減量を増やし、形状変化が大きい場所では点を多く残すようにすれば、データ量を抑えながら形状を維持しやすくなります。
OBJに面情報が含まれている場合は、ポリゴン数も確認します。点群として使う予定にもかかわらず、書き出し時の設定によって細かな三角形が大量に生成されていることがあります。面を必要としないアップロード先であれば、頂点だけを残したデータを用意できないか確認します。ただし、面情報を削除すると、表面表示、陰影、断面生成、体積計算などの機能へ影響する場合があります。利用目的とアップロード先の対応機能を確認したうえで判断する必要があります。
メッシュを維持する場合は、形状を単純化する処理を検討します。平坦な部分や変化の少ない部分の面数を減らし、角部や曲面など重要な部分を残すことで、見た目を大きく変えずに軽量化できる可能性があります。削減率だけを基準にするのではなく、代表寸法、境界位置、穴、段差、法面の変化などが維持されているかを確認します。
不要な点も削除します。測定対象から離れた背景、空中に浮いた孤立点、移動体、反射ノイズ、機器周辺の不要部分などが残っていると、メモリを消費するだけでなく、表示範囲や自動処理にも悪影響を与える場合があります。対象範囲を切り出してからOBJへ変換することで、必要なデータだけをアップロードできます。
軽量化後は、元データを上書きせず、別ファイルとして保存します。点数や面数を減らす処理は元に戻せない場合があるため、原本を保管し、アップロード用の派生データとして管理することが重要です。元データ、軽量化条件、作成日、対象範囲を記録しておけば、必要に応じて異なる密度で再作成できます。
方法2 OBJを範囲ごとに分割する
頂点数を減らしても一つのOBJが大きすぎる場合は、対象範囲を複数のファイルへ分割します。分割によって一回の処理で必要となるメモリを抑えられるため、アップロード時の停止や画面の強制終了を避けやすくなります。
分割するときは、単純にファイル容量が均等になるよう分けるだけでなく、実務で扱いやすい単位を選びます。工区、階、建物、道路区間、測定日、作業班、管理番号など、後から識別しやすい基準で分割すると、アップロード後の確認や共有も行いやすくなります。
広い点群を東西や南北へ機械的に分割する場合は、境界付近の情報が欠けないよう注意します。境界線の両側へ一定の重複範囲を設けると、隣接ファイルの位置関係や連続性を確認しやすくなります。ただし、重複を広くしすぎると同じ点を複数ファイルで保持するため、クラウド上の総容量が増加します。境界確認に必要な範囲だけを重複させることが重要です。
高さ方向に構造が重なる建物や設備では、平面的な分割だけでなく、高さや階層による分割が有効です。上階と下階の点が同じ平面範囲に存在する場合、平面だけで切り出すと各ファイルの点数が十分に減らないことがあります。階、設備層、屋上、地下などの単位に分けることで、一回の表示負荷を抑えられます。
分割後も共通の座標系を維持することが重要です。個別ファイルの容量を小さくするために、それぞれ異なる原点へ移動すると、アップロード後に重ね合わせる際の管理が複雑になります。アップロード先が大きな座標値に対応している場合は、共通座標を保持したまま分割します。対応状況が不明な場合は、原点移動量を明確に記録し、復元できるようにします。
OBJ内部のオブジェクトやグループを分けただけでは、ファイル全体が一括で解析されるため、メモリ使用量が十分に減らないことがあります。メモリ不足への対策としては、内部グループではなく、実際に複数のOBJファイルへ分ける必要があります。
一つの圧縮ファイルへ複数のOBJをまとめる場合も注意が必要です。アップロード先が圧縮ファイルを展開した後、含まれるOBJをすべて同時に解析する仕様であれば、メモリ削減効果が得られない可能性があります。複数ファイルを一件ずつアップロードできる場合は、順番に処理するほうが安全です。
ファイル名には、対象範囲と並び順が分かる情報を含めます。分割番号だけでは、後から内容を判断しにくくなります。現場名、工区、階、区画、測定日などを組み合わせ、同じルールで命名します。ファイル名に特殊な記号や極端に長い文字列を使うと、環境によって処理へ影響する可能性があるため、簡潔で一貫した名称が適しています。
分割方法が適切かを確認するには、最初に一部の範囲だけを書き出して試験アップロードします。小さいファイルで正常に処理できることを確認してから、同じ条件で残りを作成すると、全データを再処理する手間を減らせます。
方法3 不要な属性と関連ファイルを削減する
点群OBJのメモリ使用量は、頂点座標や面数だけで決まりません。法線、テクスチャ座標、マテリアル情報、画像、グループ、コメントなど、利用目的に不要な情報が含まれていると、解析時の負荷が増える場合があります。
OBJでは、頂点座標とは別に法線情報を保持できます。法線は表面の向きや陰影を表現するために利用されますが、単純な点表示だけを行う場合には使用されないことがあります。アップロード先が法線を必要としないのであれば、書き出し時に法線を含めない設定を選ぶことで、ファイル容量と解析対象を減らせる可能性があります。
テクスチャ座標も同様です。画像を表面へ貼り付けない用途であれば、テクスチャ座標やマテリアル参照が不要になる場合があります。OBJから参照されるマテリアルファイルや画像が大量にあると、アップロード時に関連ファイルの確認や画像展開が発生し、メモリ消費が増加します。
特に高解像度の画像には注意が必要です。画像は保存容量が小さくても、表示用に展開すると大きなメモリを使用する場合があります。点群の位置や形状を確認することが目的で、細かな色や模様が不要であれば、画像の解像度を下げる、画像枚数を減らす、画像を使用しない点群表示用データを別に作るといった方法が考えられます。
ただし、関連ファイルを手作業で削除するだけでは、OBJ内部に参照記述が残り、読み込みエラーにつながることがあります。画像やマテリアルを外す場合は、書き出し設定で参照を無効にするか、OBJ内の参照関係を整合させる必要があります。参照先が存在しない状態でも形状だけを読み込めるサービスはありますが、すべての環境で同じ動作になるとは限りません。
頂点カラーを独自の形式で記録しているOBJにも注意します。一般的なOBJの頂点行へ追加の数値を付けて色を表すデータがありますが、読み込み側がその表現に対応していない場合があります。未対応の属性があると、単に無視される場合だけでなく、解析エラーや余分な変換処理につながる可能性もあります。アップロード先の対応範囲に合わせ、必要な属性だけを出力することが安全です。
コメント行やオブジェクト名は、通常は頂点データほど大きな割合を占めません。しかし、変換工程で同じ情報が繰り返し書き込まれていたり、一つの頂点ごとに長い識別情報が追加されていたりすると、無視できない容量になることがあります。OBJをテキストとして確認し、同じ名称やコメントが過剰に繰り返されていないかを調べます。
面情報を持つOBJでは、頂点、テクスチャ座標、法線を組み合わせた参照が複雑になるほど、読み込み時の処理量が増える可能性があります。表面の見た目よりもアップロード後の位置確認や概略計測を優先する場合は、属性を減らした軽量版を別途用意する方法が有効です。
重要なのは、すべての属性を一律に削除しないことです。色、法線、画像、グループ情報が業務上必要な場合は残す必要があります。アップロード後にどの機能を使うのかを整理し、その機能に必要な情報だけを保持することで、品質と軽量化のバランスを取りやすくなります。
方法4 アップロード環境の空きメモリを増やす
OBJ自体を軽量化しても処理に失敗する場合は、アップロードに使用する端末やブラウザの状態を見直します。同じファイルでも、利用できる空きメモリが異なれば、処理結果が変わることがあります。
まず、アップロード前に不要なアプリケーションを終了します。点群編集、画像編集、設計資料の閲覧、オンライン会議、複数のブラウザ画面などは、それぞれメモリを使用します。画面上で最小化しているだけではメモリが解放されないため、使用していないものは終了させます。
ブラウザでは、アップロードに使用する画面以外のタブを閉じます。Web上で動作する地図、動画、図面、点群ビューア、表計算、文書編集などは、表示していないタブでも処理を続ける場合があります。拡張機能が多数動作している環境では、別の利用者用設定や拡張機能を抑えた環境で試すことも切り分けに役立ちます。
長時間使用した後は、ブラウザ自体を終了して起動し直します。複数回のアップロード失敗後は、一時データが残って空きメモリが少なくなっている可能性があります。ブラウザを再起動しても改善しない場合は、端末を再起動し、ほかの作業を始める前に対象ファイルだけをアップロードします。
端末のストレージ空き容量も確認します。メモリが不足したとき、端末がストレージ領域を一時的に利用する仕組みがありますが、空き容量が極端に少ないと正常に機能しないことがあります。また、ブラウザがアップロード前の一時ファイルやキャッシュを保存するためにも空き領域が必要です。
アップロード対象は、可能であれば端末内の安定した保存場所へコピーしてから処理します。外部記憶媒体や同期中の共有フォルダから直接選択すると、読み込み速度の低下や同期処理の競合が発生する可能性があります。ファイルを端末内へ一時保存し、同期が停止した状態でアップロードすれば、原因を切り分けやすくなります。
複数人が同じデータを扱う場合は、より多くのメモリを搭載した端末で試すことも有効です。ただし、高性能な端末へ変更するだけでは根本的な解決にならない場合があります。データ量が増え続ければ、いずれ再び限界へ達します。端末環境の改善は、OBJの軽量化や分割と組み合わせることが重要です。
ブラウザ版のアップロード機能では、一つの画面が使用できるメモリ量に制約がある場合があります。端末全体に空きメモリがあっても、特定の処理単位で上限へ達する可能性があります。この場合は、端末を変更するより、ファイルの分割や頂点数の削減が有効です。
アップロード中は、同じ画面で別の操作を連続して行わないようにします。処理中に表示条件を変更したり、同じファイルを重複して選択したりすると、複数の処理が並行してメモリを消費する可能性があります。完了表示または明確なエラーが出るまで、対象画面を維持することが安全です。
方法5 読み込み処理を段階化して再試行する
大きな点群OBJを扱うときは、すべての処理を一度に進めず、試験用データから段階的に確認します。これにより、メモリ不足とファイル不整合を切り分けながら、安全に本番データへ移行できます。
最初に、元データの一部だけを切り出した小容量のOBJを作成します。この試験ファイルには、本番データと同じ種類の頂点、面、法線、テクスチャ、座標値を含めます。単純な立方体など別の形状で試すだけでは、本番データ固有の問題を確認できません。元データの特徴を残した小さな範囲を使うことが重要です。
試験ファイルが正常にアップロードできたら、範囲や点数を少しずつ増やします。急に全体データへ戻すのではなく、複数段階で試すことで、失敗し始める規模を確認できます。これにより、頂点数、面数、画像数、ファイル容量のどれが上限に近いのかを推定しやすくなります。
同じファイルで繰り返し失敗する場合は、再試行のたびに条件を一つだけ変更します。頂点数を減らす、画像を外す、分割する、端末を再起動するなどを同時に実施すると、どの変更が有効だったのか分からなくなります。変更前後の条件と結果を記録し、再現性を確認します。
アップロードが完了した後も、すぐに成功と判断しないことが大切です。表示用データの変換やサムネイル生成が後から行われる場合があります。ファイル一覧へ登録されたものの、開くと画面が停止する場合は、送信には成功していても表示処理でメモリ不足が起きている可能性があります。
その場合は、表示時の初期設定も確認します。アップロード直後から全点を一括表示する仕様では、端末側の負荷が高くなります。点の表示密度を抑えられる機能や、範囲を限定して開ける機能がある場合は、初期表示を軽くします。ただし、利用できる設定はアップロード先によって異なります。
複数ファイルを処理するときは、一件ずつ完了を確認してから次へ進みます。並列アップロードは作業時間を短縮できる場合がありますが、端末側で複数の解析処理が同時に動くと、メモリ不足が起こりやすくなります。特に大容量OBJでは、処理件数より安定性を優先するほうが結果的に手戻りを減らせます。
失敗後に同じファイルを再送するときは、重複した未完了データが残っていないか確認します。アップロード先によっては、一覧に表示されていなくても一時データが残る場合があります。連続して送信を繰り返すと、処理待ちが増えたり、同じ名称のデータが複数作成されたりする可能性があります。
段階化の目的は、単に小さいファイルへ分けることではありません。どの条件なら安定して処理できるかを把握し、次回以降も再現できる手順を作ることです。成功したファイルの頂点数、面数、属性、容量、処理時間を記録しておけば、同じ環境で扱える目安を設定できます。
方法6 運用に合わせてデータ作成基準を決める
メモリ不足を根本的に減らすには、アップロード直前の対処だけでなく、点群の取得、編集、書き出し、共有までを含めた作成基準を決める必要があります。毎回異なる密度や設定でOBJが作られると、担当者ごとに結果が変わり、失敗原因の特定が難しくなります。
最初に、点群OBJを何のためにアップロードするのかを分類します。現場状況の閲覧、関係者への共有、距離確認、断面確認、数量算出、施工前後の比較、記録保存では、必要な点密度や属性が異なります。すべての用途を一つの高密度OBJで賄おうとすると、データが過剰になりやすくなります。
閲覧用、計測用、保存用などの用途別にデータを分ける方法が有効です。閲覧用は軽量化して素早く表示できるようにし、詳細な計測が必要な範囲だけ高密度版を用意します。原本は別の安全な場所に保管し、クラウドへは業務上必要な派生データだけをアップロードします。
一ファイル当たりの目安も決めます。ファイル容量だけではなく、頂点数、面数、画像枚数、対象範囲を基準にします。過去に安定して処理できた実績から、安全側の上限を設定し、それを超える場合は自動的に分割や軽量化を行う運用にすると、担当者の判断に依存しにくくなります。
点密度の基準は、対象物の最小確認寸法から決めます。確認したい形状より極端に細かな点間隔を設定しても、画面解像度や現場での判断精度を超えていれば、実務上の効果が小さい場合があります。必要な精度を満たす範囲で点数を抑えることが、メモリ不足の防止につながります。
不要範囲を除去する基準も統一します。取得範囲の外周、空中の孤立点、移動体、反射ノイズ、対象外の建物や地形をどこまで削除するかを決めます。担当者によって切り出し範囲が異なると、同じ現場でもデータ量に大きな差が生じます。
書き出し設定については、座標系、単位、法線の有無、テクスチャの有無、画像解像度、面の有無、文字コード、ファイル名のルールなどを記録します。正常に処理できた設定を標準化すれば、未対応属性の混入や関連ファイルの不足を減らせます。
作成後の検査項目も定めます。OBJが開けるか、頂点数や面数が想定範囲か、座標値が異常に大きくないか、参照ファイルがそろっているか、不要な画像が含まれていないか、対象範囲が適切かをアップロード前に確認します。
運用基準には、失敗時の対応順も含めます。最初に端末を再起動し、次に試験ファイルを送信し、その後に属性削減、分割、頂点削減を行うなど、組織内で順序を統一します。担当者が毎回異なる方法を試すより、記録された手順に沿って切り分けるほうが早く原因へ到達できます。
アップロード後のデータ管理も重要です。分割したファイルの名称や位置関係が分からなくなると、再結合や比較が難しくなります。元データとの対応、作成条件、分割範囲、座標の扱い、更新日を記録し、同じ規則で管理します。
一度決めた基準を固定し続けるのではなく、端末環境、アップロード先の仕様、点群取得方法、利用目的の変化に合わせて見直します。失敗した事例だけでなく、正常に処理できたデータの条件も蓄積すれば、現場ごとの適切なデータ量を判断しやすくなります。
点群OBJを軽量化するときの注意点
メモリ不足を避けるためにデータを減らしすぎると、点群本来の利用目的を満たせなくなる可能性があります。軽量化では、容量の削減だけでなく、必要な精度、形状、座標、色、境界が維持されているかを確認する必要があります。
点を間引いた後は、重要な角部や段差が丸くなっていないかを確認します。配管、縁石、構造物の端部、掘削境界、法肩、法尻などは、点の削減によって位置を判断しにくくなる場合があります。全体を同じ割合で削減するのではなく、重要範囲を残す方法が適しています。
メッシュを単純化した場合は、小さな穴が閉じたり、薄い部材が消えたりすることがあります。見た目では問題がなくても、断面や体積を計算すると結果が変わる可能性があります。軽量版を計測へ使用する場合は、元データとの比較を行い、許容できる差かを確認します。
座標値の丸めにも注意が必要です。OBJの小数桁を減らすとファイル容量を抑えられる場合がありますが、必要以上に桁を削ると位置精度が低下します。対象範囲、座標単位、必要精度によって適切な桁数は異なります。ファイルを小さくする目的だけで一律に小数桁を削除しないようにします。
座標原点を移動して数値を小さくする方法は、読み込みの安定性に寄与する場合がありますが、元の座標へ戻すための情報が必要です。移動量を記録しないままアップロードすると、他の測量成果や設計データと重ねられなくなるおそれがあります。
分割時には、境界で点が欠落していないかを確認します。切り出し条件によって、境界線上の点がどちらのファイルにも含まれない場合があります。隣接範囲を重ねて確認するか、切り出し後の全体範囲を元データと比較します。
テクスチャ画像を縮小すると、標識、ひび割れ、文字、設備番号などが読めなくなる可能性があります。形状確認用の軽量版と、画像確認用の詳細版を分けることで、目的に応じた品質を維持できます。
軽量化後は、ファイル容量だけでなく、実際のアップロード、表示、移動、拡大縮小、計測まで確認します。アップロードに成功しても、画面操作が極端に重ければ、実務で使える状態とはいえません。利用者が通常行う操作を試し、安定して扱えるかを評価します。
メモリ不足を切り分ける実務フロー
点群OBJのアップロードに失敗したときは、原因を推測して無作為に設定を変更するのではなく、再現条件を整理して順番に切り分けます。
最初に、同じアップロード先へ小さなOBJを送信し、基本的な機能が利用できるかを確認します。小さいファイルも失敗する場合は、メモリ不足より、通信、権限、利用環境、サービス側の状態、ファイル選択方法などを確認する必要があります。
小さいOBJが成功する場合は、元データの一部を切り出した試験ファイルを作ります。この試験ファイルが成功すれば、元データ全体の規模が影響している可能性があります。失敗する場合は、特定の構文、属性、座標、関連ファイルに原因があるかもしれません。
次に、テクスチャやマテリアルを外した形状のみのOBJを試します。これで成功すれば、画像の解像度、画像枚数、参照関係が負荷やエラーに関係している可能性があります。変化がなければ、頂点数や面数を減らして比較します。
頂点数を半分程度にしたファイル、対象範囲を半分に分けたファイル、属性を減らしたファイルを別々に作成し、結果を記録します。複数の変更を一度に加えず、どの要素が処理結果へ影響したかを判断できる状態にします。
端末側では、不要なアプリケーションを終了し、ブラウザと端末を再起動してから同じファイルを試します。再起動後だけ成功する場合は、空きメモリの不足や長時間利用による一時的な負荷が関係している可能性があります。
別の端末で同じOBJを試せる場合は、結果を比較します。どの端末でも同じ規模で失敗するなら、ファイル側またはアップロード先の処理上限が考えられます。特定の端末だけ失敗するなら、その端末の空きメモリ、ストレージ、ブラウザ設定、同時実行中の処理を確認します。
最終的には、成功した条件を基準として、分割単位や軽量化率を決めます。一度だけ成功した条件ではなく、複数回安定して処理できる余裕のある基準を採用します。処理上限の直前までデータを詰め込むと、端末の状態や関連画像の違いによって再び失敗する可能性があります。
まとめ
点群OBJアップロード時のメモリ不足は、ファイル容量だけを見ても判断できません。OBJを解析すると、頂点、面、法線、テクスチャ座標、画像などが内部データへ展開され、元ファイルより大きなメモリを使用する場合があります。送信が完了しても、変換や表示処理の段階で停止することもあります。
対策の基本は、頂点数と面数の適正化、範囲ごとの分割、不要な属性や関連ファイルの削減、アップロード環境の整理、段階的な試験、データ作成基準の統一です。これらを順番に実施すれば、メモリ不足とファイル不整合を切り分けながら、安定したアップロード条件を見つけやすくなります。
特に重要なのは、元データを残したままアップロード用の軽量版を作ることです。閲覧用、共有用、計測用、保存用を分ければ、すべての用途へ過剰な高密度データを使用せずに済みます。軽量化後は、位置、形状、境界、色、計測結果が利用目的を満たしているかを確認してください。
今後も点群OBJを継続的に扱う場合は、取得段階から対象範囲と点密度を意識し、アップロード後の利用方法まで含めて運用を設計することが大切です。現場での点群取得から確認、共有までの流れを効率化したい場合は、LRTK Phoneを活用した運用も次の選択肢として検討できます。