点群OBJが0バイトになる状態とは
現場で取得した点群をOBJ形式で保存し、土量計算や三次元形状の確認に使おうとしたところ、ファイル名は存在するのに容量が0バイトと表示されることがあります。0バイトとは、ファイルを置くための名前や保存場所だけが作られ、頂点座標や面情報などの実データが一切書き込まれていない状態です。
OBJは、三次元形状を構成する頂点、面、法線などの情報を文字として記録する形式です。点群を頂点情報として書き出す場合も、点群から生成した三角形メッシュを書き出す場合も、正常に保存されていれば何らかのデータが記録されます。計測範囲が小さくても、正常なOBJが完全な0バイトになることは通常ありません。
そのため、容量が0バイトであれば、点群の内容が少ないのではなく、保存処理が開始されなかった、書き込みの途中で止まった、または転送先へ内容が届かなかった可能性を考える必要があります。ファイル名が見えているため保存できたように感じますが、ファイルの作成と中身の記録は同時に完了するとは限りません。
現場で即土量を確認したい実務担当者にとって、OBJが0バイトになる問題は軽視できません。施工前後の地形を比較できず、掘削量や盛土量の確認が止まるだけでなく、関係者への共有や施工判断にも影響するためです。しかし、0バイトのOBJが見つかったからといって、計測した点群そのものが失われたとは限りません。
点群の元データとOBJは、別の段階で保存されている場合があります。計測プロジェクトや元の点群が正常に残っていれば、再計測をしなくてもOBJを書き出し直せる可能性があります。また、端末内のOBJは正常で、アップロード先だけが0バイトになっている場合には、再書き出しさえ不要で、正常なファイルを再アップロードすれば復旧できます。
重要なのは、空のOBJを見つけた時点で再計測を決めるのではなく、計測、元データ保存、OBJ書き出し、コピー、アップロードという流れを一段ずつ確認することです。どの工程まで正常だったかを切り分ければ、必要以上の手戻りを避けられます。
原因1 書き出し処理が完了する前に中断している
点群OBJが0バイトになる代表的な原因の一つが、書き出し処理の中断です。OBJの保存操作を行うと、最初に保存先へファイル名が作成され、その後に頂点や面などの情報が順番に書き込まれることがあります。この途中で処理が止まると、ファイル名だけが残り、容量は0バイトになります。
点群からOBJを生成する作業は、単なるファイルの複製ではありません。元点群の読み込み、対象範囲の抽出、不要点の処理、座標情報の整理、点の並べ替え、メッシュの生成、面の向きの計算など、複数の処理が行われる場合があります。計測範囲が広く、点密度が高いほど、書き出しに必要な時間や端末の負荷も増えます。
現場では、保存ボタンを押してファイル名が表示されると、処理が終わったと判断してしまいがちです。しかし、画面上にファイル名が現れた時点では、まだ中身を書き込んでいる途中かもしれません。その状態で画面を閉じたり、別の作業へ切り替えたりすると、処理が中断される可能性があります。
端末を休止状態にする、電源を切る、作業画面を終了する、別の大きな処理を開始するといった操作も影響します。電池残量が少なくなり、省電力のために処理が制限される場合や、端末の温度上昇によって処理能力が一時的に下がる場合もあります。
書き出し中に処理が止まったかどうかは、完了通知、処理履歴、ファイルの更新時刻、容量などを組み合わせて確認します。完了表示がなかった、進行表示が途中で消えた、書き出し直後から容量が0バイトだったという場合は、中断の可能性が高いと判断できます。
対策としては、書き出しを開始したら完了が確認できるまで画面を閉じず、端末を安定した状態に保つことが基本です。処理完了後には、保存先を開き、OBJが0バイトではないことを確認します。さらに、可能であればファイルを一度読み込み、必要な範囲が表示されることまで確認すると安心です。
再書き出しを行う場合は、0バイトのOBJへそのまま上書きするより、別名で保存した方が状況を追いやすくなります。同じ名前で何度も保存すると、どの処理が成功したのか分からなくなることがあるためです。計測日、対象範囲、書き出し回数などを含めた名前を付けると、失敗ファイルと正常ファイルを区別できます。
原因2 保存先の容量や書き込み権限に問題がある
二つ目の原因は、OBJを保存する場所の空き容量や書き込み権限です。保存操作が始まっても、必要な容量を確保できなければ、空のファイルだけが作られて処理が終了することがあります。
点群OBJを書き出す際に必要なのは、完成したOBJを保存する容量だけではありません。変換処理の途中で一時ファイルを作成する場合や、点群を一度展開してから書き込む場合には、完成ファイルより多くの作業領域が必要になることがあります。そのため、保存後のOBJが収まりそうな空き容量が表示されていても、処理途中で不足する可能性があります。
特に高密度の点群や広い現場を一括で出力する場合は注意が必要です。点群をそのまま頂点として保存するのか、面を生成して保存するのかによっても必要な容量は変わります。色や法線などの属性を含めれば、ファイル容量や処理負荷はさらに増えることがあります。
空き容量が不足していると考えられる場合は、不要な一時ファイルを整理し、十分な余裕を確保してから再度書き出します。ただし、容量を確保するために、元点群や計測プロジェクトを誤って削除してはいけません。不要かどうか判断できないデータは消さず、別の保存先へ退避させるなど、原本を保全することが優先です。
保存先の書き込み権限も確認します。保存場所によっては、ファイルの閲覧はできても、新しい内容を書き込めないことがあります。管理上の制限がある共有フォルダや、一時的に読み取り専用になっている保存領域では、ファイル名だけが作られ、中身を保存できない場合があります。
外部の記憶媒体へ直接書き出す運用でも注意が必要です。接続が不安定だったり、保存処理中に認識が切れたりすると、0バイトのファイルが残ることがあります。点群のような大容量データは書き込み時間が長くなるため、わずかな接続不良でも影響を受けやすくなります。
現場での安定性を高めるには、まず端末内の書き込み可能な場所へOBJを保存し、正常に開けることを確認してから、共有先や外部保存先へコピーする方法が適しています。保存と転送を分ければ、どちらの工程で0バイトになったのかを判断しやすくなります。
権限の問題かどうかを確かめるときは、同じ保存先へ小さな確認用ファイルを書き込めるかを確認します。小さなファイルも保存できないなら、OBJの内容より保存先の設定を疑うべきです。小さなファイルは保存できるのにOBJだけ失敗する場合は、容量、ファイル上限、処理時間などの影響を確認します。
原因3 点群のデータ量や出力条件が処理能力を超えている
三つ目の原因は、元点群のデータ量やOBJの出力条件が、端末や処理環境の能力を超えていることです。非常に多くの点を一度に書き出そうとすると、必要なメモリや作業領域を確保できず、処理が始まらない、または途中で停止することがあります。
点群の容量は、計測した面積だけでは決まりません。同じ範囲でも、計測距離、点密度、重複計測の量、不要点の数、色情報の有無などによって大きく変わります。狭い範囲であっても、同じ場所を何度も計測して大量の重複点が含まれていれば、書き出し負荷が高くなることがあります。
点群から三角形の面を生成してOBJにする場合は、単純に点を保存するよりも処理が複雑になります。近接する点をどのように結ぶかを判断し、面の向きや重複を整理する必要があるためです。地表面だけでなく、重機、資材、植生、作業員、周辺構造物などが点群に含まれていると、意図しない面が大量に生成される可能性もあります。
現場で即土量を確認する目的であれば、すべての計測点を一つのOBJへ詰め込む必要があるとは限りません。土量計算に必要な施工範囲を切り出し、対象外の点を除いてから書き出すことで、処理を安定させられます。
たとえば、掘削部分の土量を求めたい場合、遠方の道路、建物、樹木、空中のノイズなどは計算に不要です。対象範囲を明確にし、必要な地表面を残すことで、OBJの容量を抑えられます。ただし、切り出し範囲を狭くしすぎると、法肩や法尻など、体積計算の境界に必要な点まで削除してしまうことがあります。
点密度を調整する場合も同様です。点を減らせば処理は軽くなりますが、段差、法面の折れ、局所的な凹凸、掘削底の不陸などが失われると、土量結果に影響します。単に容量を小さくすることを目的とせず、計算に必要な形状を表現できる範囲で調整する必要があります。
出力条件の互換性も確認します。元点群が持っているすべての属性をOBJへ同じように保存できるとは限りません。座標、色、法線、分類情報などの組み合わせによっては、書き出し処理が正常に進まないことがあります。最初は標準的な条件で小さな範囲を書き出し、成功した後に必要な条件を追加する方が、原因を特定しやすくなります。
条件を見直す際は、複数の設定を一度に変えないことが大切です。範囲、点密度、属性、面生成条件、保存先を同時に変更すると、どの変更によって成功したのか分からなくなります。まず対象範囲だけを小さくする、次に点密度を見直すというように、一項目ずつ確認します。
元点群が正常かどうかも確認します。計測プロジェクトを開いた際に一部が表示されない、読み込みが完了しない、座標が極端に離れている、異常な点が大量にある場合は、OBJ変換の前段階に問題がある可能性があります。再書き出しを繰り返す前に、元点群を表示できるか、必要範囲を確認できるかを見ます。
原因4 通信切断によってアップロードが完了していない
四つ目の原因は、OBJ自体は正常に作成できているものの、アップロードや同期の途中で通信が切れたことです。端末内のOBJには正常な容量があるのに、共有先や別の端末で確認すると0バイトになっている場合は、転送工程の問題を疑います。
大容量ファイルを送信する際、共有先では最初にファイル名だけが作られ、その後に内容が順番に転送される場合があります。通信が途中で切断されると、共有先にはファイル名だけが残り、容量が0バイトになることがあります。
現場では、地下、山間部、構造物の陰、移動中の車内など、通信が安定しにくい環境があります。送信開始の表示が出ていても、完了まで通信が維持されなければ、正常なファイルは共有されません。また、送信中に通信方法が切り替わったり、端末が休止状態になったりすると、アップロードが中断されることがあります。
画面上に送信済みと表示された場合でも、共有先への反映が終わっているとは限りません。送信側では処理を受け付けた状態を示し、実際の転送が続いていることもあります。そのため、アップロード後は共有先で容量を確認し、可能であれば実際に開く必要があります。
切り分けの方法は、端末内のOBJと共有先のOBJを比較することです。ファイル名だけでなく、容量と更新時刻も確認します。端末内のOBJに十分な容量があり、共有先だけが0バイトなら、元点群の再計測やOBJの再書き出しは不要である可能性が高いと判断できます。
この場合は、端末内の正常なOBJを安定した通信環境で再アップロードします。0バイトのファイルへ同じ名前で上書きするよりも、別名で送る方が確認しやすくなります。同じ名前の空ファイルが残っていると、古い情報が表示されたり、どちらが最新か分からなくなったりするためです。
再アップロードが完了したら、共有先の容量が端末内のファイルとおおむね一致しているか確認します。続いて、受信側でファイルを読み込み、必要な範囲を表示できるかを確かめます。容量が反映されただけでは、転送が完全に成功したとは断定できません。
通信が不安定な現場では、計測と土量確認を端末内で完了させ、データ共有は通信の安定した場所へ移動してから行う方法も有効です。現場での施工判断と大容量データの共有を分ければ、アップロードの失敗によって土量確認まで止まる事態を防げます。
原因5 コピーや圧縮などの途中で空ファイルが残っている
五つ目の原因は、OBJを書き出した後に行うコピー、移動、圧縮、展開、名称変更などの整理作業です。元のOBJが正常でも、別の保存先へ移す途中で処理が止まれば、移動先に0バイトのファイルが残ることがあります。
コピー処理では、移動先に空のファイルを作成してから、元ファイルの内容を順番に書き込む場合があります。途中で保存先の接続が切れたり、空き容量が不足したり、操作が取り消されたりすると、空ファイルだけが残ります。
この問題を防ぐためには、重要なOBJをいきなり移動するのではなく、最初はコピーとして扱うことが有効です。移動では、処理の途中で元ファイルの位置が変わり、失敗後にどこへ正常なデータが残ったのか分かりにくくなることがあります。コピーであれば、移動先の確認が終わるまで元ファイルを保持できます。
コピー後は、元ファイルとコピー先の容量を比較します。ファイル名が同じでも、容量が異なっていれば処理は完了していません。更新時刻だけでは正常性を判断できないため、必ず容量を確認します。
圧縮処理でも0バイトが発生する可能性があります。OBJの容量を小さくして共有しようとした際、圧縮が完了する前に送信を始めたり、処理中に端末の容量が不足したりすると、不完全な圧縮ファイルが作られることがあります。受信側で展開した結果、OBJが0バイトになる場合もあります。
圧縮後は、圧縮ファイルの容量を確認し、一度展開して中身を確認してから共有する方が安全です。共有先で展開したOBJが0バイトなら、送信時の問題だけでなく、圧縮前または展開時の問題も考えられます。元のOBJが残っていれば、元ファイルから圧縮し直すことができます。
ファイル名の変更も慎重に行います。名称変更だけでファイルの中身が消えることは通常ありませんが、変更と同時に別フォルダへ移動する操作や、同名ファイルを置き換える操作が含まれていると、コピー失敗の影響を受けることがあります。
拡張子を誤って変更した場合は、0バイトではなく、読み込み側が形式を判別できない状態になります。拡張子の問題と中身の消失は分けて確認します。容量が0バイトなら保存やコピーの失敗を疑い、容量があるのに開けないなら拡張子やデータ内容を確認します。
ファイル名には、計測日、施工区分、対象範囲、版番号などを含めると管理しやすくなります。ただし、長すぎる名前や複雑な記号は避けます。書き出し直したファイルや再アップロードしたファイルを明確に区別できる、簡潔な命名規則を決めることが重要です。
0バイトを発見した直後に確認する順番
OBJが0バイトになっていることを発見したら、最初に元点群の状態を確認します。空のOBJを何度も開こうとしたり、同じファイルへ上書きしたりする前に、計測プロジェクトや元データが正常に残っているかを確かめます。
元点群を開き、対象範囲が表示されるかを確認します。計測した地表面、法面、掘削底、盛土面など、土量計算に必要な形状が残っていれば、再計測を避けられる可能性があります。点群の一部が欠けている、読み込みが完了しない、対象範囲が表示されない場合は、OBJより前の保存工程に問題があるかもしれません。
元点群が正常なら、次にOBJが最初に書き出された場所を確認します。端末内のOBJが0バイトなのか、端末内では正常でコピー先だけが0バイトなのか、共有先だけが0バイトなのかを区別します。
端末内のOBJが正常であれば、再書き出しは不要です。コピー先または共有先への転送をやり直します。端末内のOBJが0バイトでも元点群が正常なら、OBJの再書き出しを行います。元点群も正常に開けない場合は、計測時の保存状況やバックアップを確認し、必要に応じて再計測を検討します。
原因を調べている途中では、元点群を直接編集しない方が安全です。不要点の削除、座標変換、点密度の変更などを元データへ直接行うと、当初の状態へ戻せなくなることがあります。作業用の複製を作れる場合は、複製したデータで再書き出しを試します。
0バイトのOBJも、原因を確認するまでは削除しない方がよいでしょう。中身はありませんが、作成時刻、保存場所、ファイル名などが原因特定の手掛かりになります。成功ファイルが確定した後に、失敗ファイルを整理します。
操作の流れを時系列で整理することも有効です。計測後にどこへ保存したか、どの条件でOBJを書き出したか、いつコピーしたか、どの通信環境で送信したかを確認します。担当者が複数いる場合は、誰がどの工程を行ったかも記録します。
たとえば、現場で書き出し、その場で共有先へ送信し、事務所で0バイトに気付いた場合は、現場端末に正常なOBJが残っているかを最初に確認します。残っていれば再送信で済みます。端末内も0バイトなら元点群から再書き出しを行います。この順番を守ることで、不要な再計測を避けられます。
元データを守りながらOBJを書き出し直す方法
OBJの再書き出しを行う際は、元点群の保全を最優先にします。計測直後の原本はそのまま残し、可能であれば複製した作業データを使います。これにより、範囲切り出しや点密度調整に失敗しても、元の計測状態からやり直せます。
最初の再書き出しでは、対象範囲を小さくします。現場全体ではなく、一部の施工範囲を選び、標準的な条件でOBJを作成します。小さな範囲で正常なOBJが作成できれば、書き出し機能や保存先は利用できていると考えられます。
小範囲でも0バイトになる場合は、保存先の空き容量、書き込み権限、端末の状態、元点群の読み込み状況を見直します。保存先を変更し、端末内の安定した領域へ出力することも有効です。
小範囲の出力に成功したら、土量計算に必要な範囲へ少しずつ広げます。一度に現場全体へ戻すのではなく、処理可能なデータ量を確認しながら進めます。範囲を広げた段階で失敗するなら、データ量が原因である可能性が高くなります。
不要点の除去も検討します。施工範囲外の構造物、遠方の地形、空中のノイズ、移動物などを除けば、OBJの容量と処理負荷を抑えられます。ただし、土量計算の境界となる地形まで削除しないよう注意が必要です。
点密度を調整するときは、現場の形状を損なわない範囲で行います。平坦な地表面では点を整理しやすい一方、法面の折れ、段差、掘削底の凹凸などは一定の密度が必要です。土量計算に必要な面が適切に表現されることを確認しながら調整します。
書き出し中は他の大きな処理を避け、完了表示が出るまで操作を中断しません。端末の電池残量や温度にも注意し、安定した状態で実行します。書き出し後はすぐに容量を確認し、0バイトでないことを確かめます。
再書き出ししたOBJは、失敗したファイルとは別名で保存します。正常性が確認できるまでは、古いファイルへ上書きしません。複数回試す場合は、版番号や作成時刻を名前に含めると整理しやすくなります。
容量があることを確認した後は、OBJを実際に読み込みます。対象範囲が表示され、極端に離れた座標へ配置されていないか、必要な面が欠けていないか、異常な形状が発生していないかを確認します。正常に表示できて初めて、再書き出しが完了したと判断します。
正常なOBJかどうかを確認するポイント
OBJの正常性は、容量が0バイトではないという一点だけでは判断できません。途中まで書き込まれた不完全なファイルにも容量はあります。正常かどうかを確かめるには、容量、更新時刻、読み込み結果、形状の内容を順に確認します。
最初にファイル容量を見ます。0バイトであれば、その時点で中身がないと判断できます。0バイトでなくても、同じような範囲を過去に出力したファイルと比べて極端に小さい場合は、処理が途中で止まっている可能性があります。
ただし、OBJの容量は出力条件によって変わるため、一律の正常値を決めることはできません。点密度、対象範囲、面の有無、属性の数が異なれば、容量も異なります。絶対的な数値ではなく、同じ現場、同じ範囲、同じ条件で作成したファイルとの比較が有効です。
次に更新時刻を確認します。再書き出ししたつもりでも、古いファイルを見ている場合があります。作成した時刻と更新時刻が作業内容に合っているかを見ます。ただし、更新時刻が新しくても、0バイトの空ファイルが新しく作られただけという可能性があるため、容量確認と組み合わせます。
その後、OBJを読み込みます。ファイルを開けるか、対象範囲が表示されるか、視点を移動したときに形状を確認できるかを見ます。読み込み時にエラーが出る場合は、書き出しが途中で終わった、内容が破損している、または形式として解釈できない可能性があります。
表示された形状が現場の計測範囲と一致しているかも重要です。容量があり、読み込みにも成功していても、必要な施工範囲が含まれていなければ土量計算には使えません。切り出し範囲を誤っていないか、法肩や法尻などの境界が残っているかを確認します。
座標と単位も確認します。読み込んだ形状が非常に遠い位置へ配置されると、画面上では何も表示されていないように見えることがあります。これは0バイトとは異なる問題です。容量があるのに見えない場合は、全体表示、座標の基準、単位の設定などを確認します。
点群からメッシュを生成している場合は、面の欠落や異常な接続にも注意します。地表面に大きな穴がある、遠く離れた点同士が面で結ばれている、重機や植生が地表として扱われている場合は、OBJ自体は開けても土量計算へ適さないことがあります。
正常性の確認では、単に開けることではなく、目的に使えることが基準になります。現場で即土量を求めるなら、計算対象となる地表面が正しく含まれ、施工前後または設計面との比較が行える状態であることが必要です。
OBJを安全に再アップロードする手順
再アップロードは、端末内のOBJが正常であることを確認してから行います。容量が0バイトではないこと、必要な範囲が表示されること、最新の書き出し結果であることを確認します。
同じフォルダに複数のOBJがある場合は、送信対象を明確にします。過去の正常ファイル、今回の修正版、0バイトの失敗ファイルが混在していると、誤ったファイルを送信する可能性があります。送信前にファイル名、更新時刻、容量を照合します。
アップロード先に同名の0バイトファイルがある場合は、別名で送信する方法が安全です。同名で上書きすると、共有先で古い情報が残ったり、同期処理が正常に更新されなかったりすることがあります。新しい版であることが分かる名前を付けて送信します。
通信環境は安定した場所を選びます。大容量のOBJは送信に時間がかかるため、途中で通信が不安定になる場所は避けます。送信中は端末を移動させたり、通信方法を切り替えたり、休止状態にしたりしないようにします。
送信開始後は、完了表示が出るまで待ちます。進行表示が止まった場合は、同じファイルを何度も送信する前に、共有先へどのような状態で作成されているかを確認します。再送信を繰り返すと、同名または類似名の空ファイルが増え、管理が難しくなるためです。
送信完了後は、共有先でファイル容量を確認します。端末内の元ファイルと完全に同じ表示にならない場合もありますが、0バイトではなく、明らかに内容が転送されていることを確認します。
続いて、共有先からOBJを読み込みます。送信側で正常でも、共有先でファイルが完全に保存されていない可能性があるためです。対象範囲が表示され、形状に大きな欠落がないことを確かめます。
関係者へ共有する場合は、正常性を確認したファイルを正式版として明確にします。0バイトの旧ファイルが残っているなら、誤使用を避けるため、失敗が分かる場所へ移動するか、正常版の確認後に削除します。
再アップロードの記録も残します。誰が、いつ、どのファイルを、どこへ送信したかが分かれば、後から容量や内容の違いが見つかった際に原因を追いやすくなります。現場と事務所で担当者が異なる場合は、受信側の確認結果も共有します。
現場で即土量の作業を止めない運用方法
点群OBJが0バイトになる可能性を完全になくすことは難しくても、発見を早め、復旧時間を短くすることはできます。そのためには、計測、元データ保存、OBJ書き出し、共有を一つの作業としてまとめず、それぞれに完了条件を設けます。
計測工程の完了条件は、対象範囲が点群として取得され、画面上で確認できることです。保存工程の完了条件は、一度作業画面を離れても元データを再び開けることです。OBJ書き出し工程の完了条件は、ファイル容量が0バイトではなく、実際に読み込めることです。共有工程の完了条件は、受信側でも容量と形状を確認できることです。
各工程を分ければ、不具合が発生した位置をすぐに判断できます。受信側のOBJだけが0バイトならアップロード工程、端末内のOBJも0バイトなら書き出し工程、元点群も開けないなら保存工程を確認できます。
現場で即土量を求める場合、OBJの作成そのものが最終目的ではありません。目的は、施工前後の面や設計面を比較し、掘削量や盛土量を把握して施工判断へつなげることです。OBJはデータを受け渡すための形式の一つであり、元点群が正常なら、現場側で先に土量を確認できる場合があります。
そのため、現場での確認作業と、大容量OBJの共有作業を分ける運用が有効です。通信が不安定な現場では、計測後に元点群と土量結果を確認し、OBJは端末内へ確実に保存します。アップロードは通信の安定した場所へ移動してから行います。
ファイルの保存場所も分けます。計測直後の原本を置く場所、範囲切り出しや点数調整を行う作業場所、共有確認済みの成果物を置く場所を分ければ、誤って原本を編集したり、0バイトのファイルを正式版として共有したりするリスクを減らせます。
原本は直接編集せず、作業用の複製からOBJを作成します。失敗したOBJは、正常版が確定するまで別に保管します。共有済みの場所には、受信側で開けることを確認したファイルだけを置きます。
同じ種類の現場で繰り返し計測する場合は、OBJの書き出し時間や容量の傾向を記録すると異常を見つけやすくなります。いつもより極端に早く処理が終わり、容量が非常に小さい場合は、正常に書き込まれていない可能性があります。反対に、同じ範囲なのに処理時間や容量が大きく増えた場合は、不要点や重複点が増えている可能性があります。
担当者間で手順を統一することも重要です。書き出し完了前に画面を閉じない、容量を確認してからコピーする、受信側で開けるまで共有完了としないという基本を共通化します。特定の担当者だけが復旧方法を知っている状態では、不在時に作業が止まります。
現場を離れる前の確認も欠かせません。再訪が難しい場所では、元点群が開けること、OBJが0バイトではないこと、必要範囲を表示できることを確認します。アップロードを現地で完了できない場合でも、端末内に正常なデータが残っていれば、後から共有できます。
0バイトと混同しやすい別の不具合
OBJが読み込めない場合でも、必ずしも容量が0バイトとは限りません。原因を正しく判断するためには、0バイトと別の不具合を区別する必要があります。
代表的なのは、容量があるのに画面上へ形状が表示されない状態です。この場合、座標の基準が異なり、形状が表示範囲から遠く離れている可能性があります。全体表示を行う、座標値を確認する、読み込み側の基準を見直すと表示されることがあります。
単位の違いによって、形状が極端に小さく、または大きく表示される場合もあります。ファイルには内容があるため0バイトではありませんが、適切な大きさで見えず、空のように感じることがあります。
OBJの書き出しが途中で終了した場合は、0バイトではなく一定の容量を持つ不完全なファイルが残ることがあります。読み込み時にエラーが出る、途中までしか表示されない、面の一部が欠けるといった症状が現れます。容量だけで正常と判断せず、実際の読み込み確認が必要です。
点群からメッシュを作成する際に面生成がうまくいかなかった場合、OBJを開けても地表面が穴だらけになることがあります。これは保存失敗ではなく、点群の密度、不要点、面生成条件などの問題です。土量計算へ使う前に、対象面が連続しているかを確認します。
関連する補助ファイルが不足している場合もあります。形状は表示できても、色や材質が反映されないことがあります。OBJ本体が0バイトでなければ、形状データそのものは残っている可能性があります。見た目が異なることと、中身が空であることを混同しないようにします。
拡張子が誤っている場合も、読み込み側がOBJとして認識できないことがあります。容量を確認し、中身があるなら、名称や拡張子の扱いを見直します。拡張子を直すだけで読み込める場合もありますが、実データが0バイトなら名称を変えても復旧しません。
読み込み側の処理能力が不足している場合は、OBJが正常でも表示までに時間がかかることがあります。大容量のファイルを開いた直後に画面が変化しないからといって、すぐに空ファイルと判断せず、容量や処理状態を確認します。
このように、最初にファイル容量を見ることで、保存失敗と表示上の問題を大きく切り分けられます。0バイトなら保存や転送工程を確認し、容量があるなら座標、単位、データ破損、面生成、読み込み条件などを調べます。
まとめ
点群OBJが0バイトになる主な原因は、書き出し完了前の中断、保存先の容量不足や権限不良、点群のデータ量や出力条件の過大、通信切断によるアップロード失敗、コピーや圧縮などの整理工程での中断です。
0バイトを発見したら、すぐに再計測するのではなく、元点群、端末内のOBJ、コピー先、共有先の順に確認します。元点群が正常ならOBJを書き出し直せる可能性があり、端末内のOBJが正常なら再アップロードだけで復旧できる可能性があります。
再書き出しでは原本を保全し、小さな範囲と標準的な条件から試します。保存先には端末内の安定した領域を選び、完了表示を確認した後に容量と内容を確かめます。成功したOBJは失敗ファイルと別名で保存し、実際に読み込んで必要な形状が表示されることまで確認します。
再アップロードでは、安定した通信環境を使い、0バイトの同名ファイルを避けて別名で送信します。送信側の完了表示だけで判断せず、共有先で容量、更新時刻、読み込み結果を確認することが大切です。
現場で即土量を確認する運用では、計測、保存、書き出し、共有の各工程に完了条件を設けると、0バイトが発生しても原因を素早く切り分けられます。ファイル名が作成されたことを完了とせず、元点群が開けること、OBJに内容があること、共有先でも利用できることまで確認します。
点群取得から土量把握、OBJの保存と共有までを現場で一連の作業として進めるには、元データを残しながら各工程を確認できる環境が重要です。LRTK Phoneを活用して現場計測と点群管理の流れを整えることで、OBJが0バイトになった場合にも再計測と再書き出しを切り分けやすくなり、現場で即土量を確認する作業の手戻りを抑えられます。