点群OBJの隠しファイル混入でエラーが起こる理由
点群OBJをアップロードするとき、OBJ本体は正常に開けるのに、受付直後に拒否されたり、圧縮ファイルの展開後に処理が止まったりすることがあります。原因の一つとして確認したいのが、作業フォルダや圧縮ファイルへ意図せず混入した隠しファイルや管理用フォルダです。
隠しファイルは、フォルダの表示情報、検索情報、サムネイル用キャッシュ、拡張属性、一時保存情報などを保持するため、端末や保存先の仕組みによって自動生成されることがあります。担当者が作成した覚えがなくても、フォルダを開く、画像を一覧表示する、外部記録媒体や共有領域へ複製する、別の環境で圧縮するといった操作をきっかけに追加される場合があります。
点群OBJの成果物は、OBJだけで完結するとは限りません。OBJからMTLを参照し、MTLからテクスチャ画像を参照する構成では、OBJ、MTL、画像、画像用フォルダをまとめて受け渡します。その際、画面上では見えていなかった管理ファイルまで一緒に圧縮されることがあります。
隠しファイルが含まれていても、アップロード先が未知のファイルを無視する仕様であれば、処理に影響しないことがあります。一方、受付可能なファイル形式や階層を厳密に検査する仕組みでは、未許可のファイルが見つかった時点で圧縮ファイル全体が拒否される可能性があります。どの挙動になるかは、アップロード先の仕様や実装によって異なります。
特に注意したいのが、元ファイルとよく似た名称を持つ管理ファイルです。たとえば texture.jpg に対応する ._texture.jpg が作成されることがあります。後者は名称の末尾だけを見ると画像に見えますが、通常の画像データではなく、元ファイルに付随するメタデータを保持する補助ファイルです。拡張子だけで画像を許可する検査では通過する可能性があるため、ファイル名の先頭や実際の内容も確認する必要があります。
圧縮ファイル内の階層もエラーに関係します。OBJが最上位にあることを前提とする受付処理では、不要な親フォルダや管理用フォルダが追加され、OBJが一段深い場所へ入ると検出されない場合があります。ただし、必要な階層はサービスごとに異なるため、最上位配置を一律の正解とせず、受付仕様を優先します。
隠しファイルは原因候補の一つであり、混入していれば必ずエラーになるわけではありません。容量超過、対応していない圧縮方式、OBJ内の数値や参照番号の不整合、MTLの参照切れ、画像形式の非対応、通信の中断などでも失敗します。隠しファイルを除外した版を作り、それ以外の条件を変えずに再試行すると、原因を切り分けやすくなります。
点群OBJのアップロードを安定させるには、作業フォルダの見た目だけでなく、実際に送信する圧縮ファイルの中身を検査することが重要です。隠しファイル対策は、不要データを掃除する作業ではなく、受付仕様に合う成果物を再現可能な手順で作る品質管理と考えるとよいでしょう。
点群OBJフォルダに混入しやすい隠しファイル
点群OBJの作業フォルダには、利用環境に応じて複数の管理ファイルが混入します。代表例として、フォルダ表示情報を保存する .DS_Store、元ファイル名の先頭に ._ が付く補助ファイル、圧縮時に作られることがある __MACOSX フォルダ、画像の縮小表示に使われる Thumbs.db、フォルダ表示設定を保持する desktop.ini などがあります。
.texture.jpg のようなファイルは、対応する texture.jpg と名前が似ていますが、同じ画像の複製ではありません。画像の拡張子だけを見てアップロード対象へ残すと、画像として開けないファイルを含めることがあります。除外判定では、. で始まる名称を先に検出し、その後で拡張子の許可判定を行う順序が適しています。
__MACOSX のような管理用フォルダには、圧縮対象のファイルに対応する補助情報が格納されることがあります。アップロード先がその情報を必要としない場合は、アップロード用成果物から除外できます。ただし、保管用の元データまで削除する必要はありません。元データを残し、アップロード専用の複製から取り除く方法が安全です。
画像を一覧表示したときに生成されるキャッシュも混入しやすい項目です。点群OBJに多数のテクスチャ画像が含まれていると、画像の内容とは別にサムネイル管理用のファイルが作成されることがあります。これらは一般にOBJやMTLから参照されないため、受付仕様で求められていなければアップロード対象に含める必要はありません。
一時ファイルやロックファイルにも注意します。OBJやMTLを編集中に作られ、正常終了時には消えるものでも、処理の中断や異常終了によって残る場合があります。元ファイル名に記号が付いた名称、末尾に一時保存を示す文字列が付いた名称、容量が極端に小さいファイルなどが候補になります。
バックアップファイルは隠し属性を持たないこともありますが、意図しない混入物として同様に確認します。修正前、軽量化前、自動保存、複製などのOBJが同じフォルダに残っていると、複数OBJを許可しない受付処理ではエラーになる可能性があります。複数OBJを許可する場合でも、どれが正式な成果物か分からなくなるため整理が必要です。
不要かどうかは、名称や容量だけで断定できません。作成日時、更新日時、格納場所、OBJやMTLからの参照、社内処理での用途を合わせて確認します。小さいファイルでも独自の管理工程に必要なことがあり、ピリオドで始まるファイルでも組織内の処理で利用している可能性があります。
削除候補を見つけたら、元フォルダから直ちに消すのではなく、アップロード用の複製から退避します。退避後にOBJを別の場所で開き、形状、位置、材質、色、テクスチャが維持されていることを確認すれば、必要な関連ファイルを誤って除外するリスクを下げられます。
除外方法1 隠し項目を表示して不要ファイルを取り除く
最初の方法は、ファイル管理画面で隠し項目や保護された項目を表示し、不要なファイルを目視で確認する方法です。少数の成果物を扱う場合や、初めて発生したアップロードエラーの原因を調べる場合に向いています。
作業前に元フォルダを複製し、保管用とアップロード準備用を分けます。元データを直接編集すると、必要なMTLや画像を誤って削除した際に復旧しにくくなります。保管用は変更せず、複製したフォルダだけを整理します。
次に、利用環境の表示設定で、隠しファイル、隠し項目、保護された管理項目などを表示します。名称は環境によって異なります。通常の隠し項目を表示しても、保護された管理ファイルが別設定になっている場合があるため、表示範囲を確認します。
確認対象は、.DS_Store、._ で始まる補助ファイル、__MACOSX、Thumbs.db、desktop.ini、一時ファイル、ロックファイル、古いバックアップなどです。これらの名称に一致しても、社内の処理で利用している場合は除外条件を見直します。
不要と判断した項目は、最初から完全削除せず退避フォルダへ移動します。OBJ内の mtllib で指定されたMTL、MTL内の画像参照命令で指定されたテクスチャは残します。名称が分かりにくくても、参照されているファイルは必要な可能性があります。
退避後は、アップロード準備用フォルダを別の保存場所へ移し、そのフォルダだけでOBJを開きます。確認ソフトが元フォルダから不足ファイルを自動検索すると、参照切れに気付けないことがあります。元フォルダと切り離して確認することで、アップロード用構成だけで完結しているかを判断できます。
形状だけでなく、材質、色、画像の向き、欠落した部分がないかも確認します。頂点だけを利用する点群OBJではMTLや画像が不要なこともありますが、色やテクスチャを利用する成果では関連ファイルを残す必要があります。
整理後は、以前の圧縮ファイルを使い回さず、新しい圧縮ファイルを作成します。圧縮ファイルの中だけを編集すると、古い項目や想定外の階層が残ることがあります。整理済みフォルダから新規作成するほうが、内容を追跡しやすくなります。
圧縮後には中身を一覧表示し、さらに仮フォルダへ展開します。圧縮処理によって管理用フォルダが追加されていないか、OBJが指定された階層にあるか、退避したファイルが再混入していないかを確認します。
手作業は混入物の種類を理解しやすい反面、案件数やファイル数が増えると見落としやすくなります。最初の原因調査で得たファイル名や発生条件を記録し、後の許可リストや自動検査へ反映すると継続運用しやすくなります。
除外方法2 必要なファイルだけを新規フォルダへ複製する
2つ目は、不要なファイルを探して削除するのではなく、必要なファイルだけを空の新規フォルダへ複製する方法です。見えないファイルを持ち込まないという点では、除外方式より許可方式のほうが管理しやすい場合があります。
最初に、アップロード対象のOBJを確定します。複数のOBJを扱う仕様でなければ、修正前、確認用、軽量化前などの別版を混ぜません。正式な版を一つ決め、元データの保管場所とは別にアップロード用の空フォルダを作ります。
OBJ内に mtllib の記述がある場合は、指定されたMTLを複製します。MTL内に map_Kd などの画像参照がある場合は、実際に参照される画像も複製します。出力ソフトによっては複数の画像参照命令を使うため、特定の命令だけに決め打ちせず、利用している出力形式を確認します。
新規フォルダは、元フォルダの複製ではなく空の状態から作ります。元フォルダを丸ごと複製すると、隠しファイルや管理用フォルダまで引き継ぐ可能性があります。OBJ、MTL、画像を選択して複製し、必要な階層だけを再現します。
画像を下位フォルダへ格納している場合は、MTLに記載された相対パスと同じ位置関係を保ちます。画像をすべて最上位へ移すと、MTLが元のフォルダを探し続けて参照切れになることがあります。
ファイル名を変更する場合は、参照元の記述も同時に更新します。MTL名を変えたときはOBJ内の mtllib を、画像名や画像フォルダ名を変えたときはMTL内の該当箇所を修正します。大文字と小文字も含めて一致させると、環境差による参照切れを減らせます。
ファイル名に空白や特殊な記号があっても必ず失敗するわけではありませんが、解釈方法は読込側によって異なる場合があります。名称を簡潔な英数字へ整理する場合は、元データを残したうえで複製側だけを変更し、参照記述との整合を確認します。
複製後は、新規フォルダだけを別の場所へ移してOBJを開きます。形状、座標、色、材質、テクスチャが正しく表示されることを確認します。参照ファイルが不足している場合、形状だけは表示されても色や画像が失われることがあります。
必要ファイルだけを集める方法は、担当者間で基準を共有しやすい点が利点です。アップロード用フォルダへ入れてよい形式、OBJの数、画像フォルダの位置、命名規則を決めれば、不要ファイルの名称をすべて覚えなくても統一した成果物を作れます。
除外方法3 圧縮ファイルの作成条件を見直す
3つ目は、圧縮する対象範囲、階層、圧縮方式を見直す方法です。作業フォルダを整理しても、圧縮時の選択方法によって不要な親フォルダや管理ファイルが加わることがあります。
まず、親フォルダ全体を圧縮するのか、フォルダ内の必要項目だけを選択するのかを確認します。親フォルダ全体を選ぶと、案件管理用の別資料、管理ファイル、旧版フォルダまで含まれる可能性があります。受付仕様が求める範囲だけを選択します。
圧縮ファイルを開いた直後の階層も確認します。OBJ、MTL、画像フォルダを最上位に置く仕様もあれば、案件名のフォルダを一つ含める仕様もあります。階層を深くしすぎると検出されない場合がありますが、必要な構成はアップロード先の案内を優先します。
圧縮前にはOBJやMTLの編集を終了し、画像確認画面や変換処理も閉じます。ファイルが更新中の状態で圧縮すると、一時ファイルが残ったり、圧縮中に内容が変わったりする可能性があります。
版を更新するときは、既存の圧縮ファイルへ追加や上書きをせず、整理済みフォルダから新しく作成します。古いOBJや削除した画像が圧縮ファイル内に残ることを防ぎやすくなります。
圧縮形式、暗号化、分割、パスワードの有無も確認します。受付側が対応を明示していない特殊な圧縮条件は避け、指定された形式と一般的な設定を使用します。拡張子が同じでも、内部方式の違いで展開できない場合があります。
圧縮ファイル名は、組織内の命名規則に従いつつ、長すぎる名称、末尾の空白、扱いにくい記号を避けます。名称だけが原因と断定はできませんが、処理環境による差を減らすため、アップロード用の複製では簡潔な名称が扱いやすくなります。
作成後は、圧縮ファイルを仮フォルダへ展開します。展開した内容を隠し項目を含めて確認し、_MACOSX や . で始まるファイルなどが追加されていないか、OBJが想定した階層にあるかを調べます。
仮展開したOBJを開き、MTLと画像の参照が維持されているかも確認します。圧縮前に開けたことだけでは、受け渡し用の圧縮ファイルが正しいことの証明になりません。実際に送信するファイルを展開した状態で確認することが重要です。
容量も確認します。隠しファイルは小さいことが多いため、除外しても容量上限を下回らない場合があります。その場合は、OBJの点数や面数、重複データ、画像寸法、画像枚数、画像形式など、成果物本体の構成を見直します。
圧縮は単なる容量削減ではなく、アップロード先へ渡す構造を確定する工程です。圧縮前、圧縮後、仮展開後の三段階で検査すると、隠しファイル、階層ずれ、参照切れを発見しやすくなります。
除外方法4 自動処理で隠しファイルを除外する
4つ目は、一定の条件に一致する管理ファイルを自動検出し、アップロード用フォルダへ複製しない方法です。点群OBJを繰り返し扱う場合や、複数案件を同じ手順で処理する場合に適しています。
自動処理では、元フォルダを直接変更せず、別の出力先へアップロード用データを生成します。元データを読み取り専用の入力として扱えば、除外条件に誤りがあっても原本を守れます。
最初に、明確な除外パターンを設定します。たとえば .DS_Store、Thumbs.db、desktop.ini、_MACOSX、名称が . で始まるファイルなどです。ただし、組織内で同名の独自ファイルを利用していないことを確認してから適用します。
拡張子だけの許可判定には注意が必要です。._texture.jpg は末尾が .jpg なので、画像形式を拡張子だけで許可すると残る可能性があります。処理順は、既知の管理ファイル名や接頭辞を除外し、その後に許可拡張子を判定する形が適しています。
さらに安全性を高めるには、画像として許可するファイルを実際に画像として読み取れるか検査します。ファイル内容の識別情報や画像デコーダーで確認すれば、名称だけが画像に見える補助ファイルを検出しやすくなります。ただし、検査できる画像形式は事前に定義します。
OBJから参照されるMTLと、MTLから参照される画像を抽出し、必要なファイルだけを集める方法もあります。複数MTL、複数の画像参照命令、相対パス、大文字と小文字、空白を含む名称などを考慮し、単純な文字列分割だけに依存しない設計が必要です。
代表的な成果物で試験することも重要です。小規模な一例だけで検証せず、頂点だけのOBJ、面を含むOBJ、複数材質、画像フォルダを使う構成、複数MTLを参照する構成など、実際の運用に近いデータで確認します。
処理結果には、採用したファイル、除外したファイル、参照先が見つからないファイル、重複名称、容量、処理日時、使用した規則の版を記録します。エラーが起きたときに、どの条件で成果物を作ったか追跡できます。
圧縮後の自動検査も組み込みます。生成した圧縮ファイルを一時領域へ展開し、未許可ファイルがないか、OBJが指定階層にあるか、必要なMTLと画像が存在するかを再確認します。
導入初期から自動削除にする必要はありません。最初は候補を警告し、担当者が確認してから出力する方式にします。誤検出や不足がないことを確かめた後、自動除外、自動複製、自動圧縮へ段階的に進めます。
自動化の目的は、作業時間の短縮だけではありません。担当者ごとの判断差を減らし、同じ入力から同じ構成のアップロード用成果物を作ることにあります。規則と検査結果を残すことで、再発防止にもつながります。
除外方法5 許可リストを使ってアップロード前に検査する
5つ目は、完成した圧縮ファイルを許可リストと照合し、受付条件に合うかを最終検査する方法です。作成者や利用環境が異なっていても、アップロード直前に共通基準で確認できます。
許可リストには、受付可能な圧縮形式、OBJの数、MTLの扱い、画像形式、階層、ファイル名、個別ファイル容量、圧縮後容量などを設定します。具体的な条件はアップロード先の仕様に合わせ、推測で固定しません。
最初に圧縮ファイル内の全項目を一覧化します。最上位だけでなく、下位フォルダ、ピリオドで始まる項目、拡張子のない項目、管理用フォルダも検査します。仮展開した後に隠し項目を表示すると、画面上の一覧だけでは見つからない項目を確認できます。
検査順序も重要です。既知の管理ファイル名と ._ などの接頭辞を確認し、その後に拡張子を照合します。拡張子だけを先に見ると、._texture.jpg のような補助ファイルを画像として許可する可能性があります。
画像は拡張子だけでなく、実際に開けるか、画像寸法を取得できるかも確認します。壊れた画像や内容が画像ではないファイルを検出しやすくなります。受付先が対応する画像形式と、社内確認環境が開ける形式は必ずしも同じではないため、最終的には受付仕様を優先します。
同じ名称のファイルが複数階層にないかも確認します。大文字と小文字だけが異なる名称は、環境によって別ファイルまたは同一名として扱われる可能性があります。参照元と参照先の表記を一致させ、曖昧な重複を避けます。
OBJの数は受付条件と照合します。一つのOBJだけを想定する仕組みでは、旧版や確認用OBJが残ると処理対象を決められない場合があります。複数OBJを許可する場合も、すべてが意図した成果かを確認します。
MTLと画像は、存在することに加えて参照されていることを確認します。OBJから指定されたMTLがない、MTLから指定された画像がない、相対パスが異なるといった状態は、アップロード後の表示欠落や変換失敗につながる可能性があります。
不許可ファイルが見つかった場合は、圧縮ファイルの中だけを直接修正せず、作成元のアップロード用フォルダへ戻って除外し、新しい圧縮ファイルを作ります。混入原因を残したまま最終ファイルだけ直すと、次の版で同じ問題が再発します。
検査済みファイルは、その後に再圧縮しません。別の環境で展開して圧縮し直すと、新しい管理ファイルが追加される可能性があります。内容や圧縮方法を変更した場合は、同じ許可リストで再検査します。
許可リスト方式は、手作業で整理した成果物、自動処理で生成した成果物、外部から受領した成果物のすべてに使えます。アップロード直前の共通関門として設けることで、作成経路によるばらつきを抑えられます。
隠しファイルの削除前に確認すべき参照関係
隠しファイルに見える項目を除外する前に、OBJ、MTL、テクスチャ画像の参照関係を確認します。不要に見えるファイルでも、材質や画像表示に必要な可能性があるためです。
OBJは、頂点座標、テクスチャ座標、法線、面などを記述できるテキスト形式です。材質を使う場合は、OBJ内の mtllib でMTLを指定し、usemtl で材質名を選択します。MTLでは材質の値に加え、map_Kd などの命令で画像を参照することがあります。
OBJ内に mtllib がある場合は、指定されたMTLの名称と実ファイル名を照合します。似た名称のMTLが複数あると、不要な版を残して必要な版を除外するおそれがあります。大文字と小文字、空白、相対パスも含めて確認します。
MTL内の画像参照も同様です。画像ファイル名だけでなく、画像用フォルダとの位置関係を確認します。フォルダ名だけを変更しても参照切れになるため、名称変更時はMTL内の記述を同時に更新します。
点群として頂点だけを利用し、色や材質を使わない受付仕様では、MTLや画像が不要な場合があります。一方、頂点色、材質、テクスチャを利用する成果では関連ファイルが必要です。また、頂点だけのOBJを点群として受け付けるか、面情報を必要とするかもアップロード先によって異なります。
隠しファイルを除外した後は、OBJを開いて形状だけを見るのではなく、色、材質、テクスチャ、座標の状態を確認します。形状が表示されていても、MTLや画像が不足していることがあります。
参照されていないファイルを見つけても、直ちに削除とは判断しません。複数OBJをまとめて管理している場合や、後工程で使用する補助成果が含まれる場合があります。今回アップロードする範囲を明確にし、その範囲で必要かを判断します。
ファイル名を簡潔にする場合は、OBJ、MTL、画像をまとめて確認します。MTL名だけを変えた場合はOBJ内の指定を、画像名だけを変えた場合はMTL内の指定を修正します。変更後は元フォルダから切り離した場所で再確認します。
参照関係の確認は、隠しファイル対策に限らず、点群OBJアップロード全体の品質管理に役立ちます。不要な管理ファイルを減らしながら、表示や変換に必要な情報を維持することが正しい除外作業です。
除外後もアップロードできない場合の切り分け方
隠しファイルを除外してもエラーが続く場合は、別の原因を一つずつ確認します。複数条件を同時に変えると、どの変更が結果へ影響したか分からなくなるため、比較用の版を分けます。
最初に、アップロード方法と受付条件を確認します。圧縮ファイルを送るのか、OBJ単体を選ぶのか、関連ファイルを同時に指定するのかによって必要構成が変わります。複数OBJ、頂点だけのOBJ、MTL、画像の対応範囲も確認します。
次に圧縮形式を確認します。暗号化、パスワード、分割、特殊な方式を使用している場合は、指定された一般的な条件で作り直します。圧縮ファイルを手元で展開できても、受付側が同じ方式に対応しているとは限りません。
容量も切り分けます。隠しファイルは小さいことが多いため、除外後も上限超過が残る場合があります。圧縮後の総容量だけでなく、OBJ本体、MTL、各画像の容量、ファイル数を確認します。
OBJの内容では、数値として解釈できない座標、未定義値、無限大を表す値、極端な桁、途中で切れた行などを調べます。面情報がある場合は、頂点、テクスチャ座標、法線の参照番号が定義範囲内かを確認します。
OBJの記述自体が正しくても、アップロード先が対応していない命令や拡張表現を含む場合があります。頂点色などは実装ごとの差があるため、小さなテストデータを同じ出力条件で作り、受け付けられるかを比較します。
MTLや画像を外したOBJ単体で試す方法もあります。OBJ単体では成功し、関連ファイルを追加すると失敗する場合は、MTLの記述、画像形式、相対パス、画像破損などへ原因を絞れます。ただし、元データを変更せず比較用の複製で行います。
ファイル名の長さ、日本語、空白、特殊な記号も比較対象です。これらが必ず失敗原因になるわけではありませんが、処理環境によって扱いが異なる可能性があります。短い英数字名へ変更した版を作り、参照記述も合わせて更新します。
小規模なOBJでも失敗する場合は、容量より記述形式や受付条件を疑います。反対に、小規模版は成功して元データだけ失敗する場合は、容量、ファイル数、特定行、特定画像などの影響を確認します。
通信状態も記録します。毎回同じ進行位置で止まる場合と、停止位置が変わる場合では原因の傾向が異なります。発生時刻、表示文、処理段階、ファイル名、容量、通信環境、試した変更を残します。
比較版は、隠しファイルだけを除外した版、名称だけを変更した版、関連画像を外した版、容量を減らした版など、変更点を一つにします。成功版と失敗版の差を小さくするほど、原因を特定しやすくなります。
隠しファイルの再混入を防ぐ運用ルール
一度エラーを解消しても、同じ作業手順を続ければ管理ファイルが再混入する可能性があります。継続的に点群OBJを扱う場合は、担当者の注意だけに頼らず、フォルダ構成と検査手順を標準化します。
まず、作業用、保管用、アップロード用のフォルダを分けます。作業用では編集、画像表示、形式変換に伴って補助ファイルが作られることがあります。作業完了後に、必要な成果物だけを空のアップロード用フォルダへ複製します。
保管用には、受領時または出力時の元データを残します。アップロード用の整理中に必要なファイルを誤って除外しても、保管用から復旧できます。保管用を直接圧縮して送る運用は避けます。
アップロード用フォルダのひな型を用意し、OBJとMTLの位置、画像フォルダ、許可する形式、OBJの数、命名規則を決めます。担当者ごとの階層差を減らすことで、参照切れや圧縮範囲の誤りを防ぎやすくなります。
版番号も統一します。最新、最終、最終修正 のような曖昧な名称を重ねると、旧版を一緒に圧縮しやすくなります。案件識別、作成日、版番号などを一定の順序で付け、アップロード対象を明確にします。
圧縮前の確認項目を定型化します。OBJの数、MTLの存在、画像参照、未許可拡張子、既知の管理ファイル、._ 接頭辞、階層、容量、画像破損を同じ順番で確認します。
確認担当者とアップロード担当者が異なる場合は、整理済みフォルダではなく検査済みの圧縮ファイルを受け渡します。受領後に別の環境で再圧縮すると、管理ファイルが追加される可能性があります。変更が必要なら、作成担当へ戻して再生成し、再検査します。
共有領域へアップロード用フォルダを長期間置くことも避けます。複数環境から開くことで管理ファイルが増える場合があります。圧縮直前にアップロード用フォルダを生成し、検査後の圧縮ファイルを成果として管理する方法が分かりやすくなります。
外部から受領した圧縮ファイルは、直接アップロードせず確認用の場所へ展開します。管理ファイル、階層、拡張子、OBJの数、参照関係を検査し、自社の基準に合うアップロード用成果物を作ります。
エラー案件では、混入していた名称、作成環境、圧縮方法、除外条件、再試行結果を記録します。同じ管理ファイルが繰り返し見つかる場合は、許可リストや自動検査の規則へ追加します。
アップロード先の受付仕様や出力ソフトの構成が変わった場合は、除外条件も見直します。以前は不要だった形式が必要になる場合や、新しい画像形式が追加される場合があります。固定した禁止一覧だけでなく、現行仕様に基づく許可リストを維持します。
点群OBJアップロード前の最終確認
アップロード直前には、整理した元フォルダではなく、実際に送信する圧縮ファイルを対象に最終確認します。圧縮工程で管理用フォルダや不要な階層が追加される可能性があるためです。
圧縮ファイルを新しい仮フォルダへ展開し、全項目を隠し項目も含めて確認します。.DS_Store、._ で始まるファイル、__MACOSX、Thumbs.db、desktop.ini、一時ファイル、旧版OBJなどがないかを調べます。
展開後の階層が受付仕様と一致しているか確認します。OBJ、MTL、画像フォルダが必要な位置にあり、不要な親フォルダが重なっていないことを確認します。
OBJが複数ある場合は、それが意図した構成かを判断します。単一OBJを想定する場合は正式版だけを残し、修正前や確認用のOBJを含めません。
OBJ内の mtllib で指定されたMTLが存在するかを確認し、MTLから参照される画像がそろっているかを照合します。相対パス、大文字と小文字、空白、フォルダ名まで確認します。
画像は実際に開き、寸法や内容を確認します。._texture.jpg のように名称だけが画像に見える補助ファイルは、通常の画像として開けません。拡張子一覧だけでなく、接頭辞とファイル内容を確認します。
ファイル名やフォルダ名を変更した場合は、OBJとMTL内の参照記述も更新されていることを確認します。名称変更後に元フォルダから切り離した場所で開き、外部のファイルへ依存していないことを確かめます。
圧縮ファイル全体と個別ファイルの容量も確認します。上限に近い場合は、隠しファイルの除外だけでなく、重複点、不要な面、未使用画像、画像寸法などの見直しが必要になることがあります。
仮展開したOBJを開き、位置、形状、色、材質、テクスチャを確認します。アップロードできることだけを目標にすると、必要な関連情報の欠落を見落とす可能性があります。
最終検査後は、圧縮ファイルを展開して編集したり、別環境で再圧縮したりしません。変更が必要になった場合は、アップロード用フォルダへ戻り、新規圧縮と検査を最初から行います。
検査済みファイルには、案件識別、作成日、版番号などを含む一貫した名称を付けます。どの圧縮ファイルを実際にアップロードしたか追跡できるようにし、検査結果と対応付けて保管します。
まとめ
点群OBJのアップロードエラーは、OBJ本体の破損や容量だけでなく、作業フォルダや圧縮ファイルへ自動生成された管理ファイルが関係する場合があります。.DS_Store、._ で始まる補助ファイル、__MACOSX、Thumbs.db、desktop.ini、一時ファイル、旧版OBJなどが代表的な確認対象です。
ただし、隠しファイルが含まれていれば必ず失敗するわけではありません。未知のファイルを無視する仕組みもあれば、未許可項目が一つあるだけで拒否する仕組みもあります。実際の受付仕様を確認し、隠しファイルだけを除外した比較版で原因を切り分けます。
手作業で確認するときは、元データを直接削除せず、アップロード用の複製で作業します。不要なファイルを探すより、空の新規フォルダへ必要なOBJ、MTL、画像だけを複製する許可方式が適する場合もあります。
拡張子だけの許可リストでは、._texture.jpg のような補助ファイルを画像として残す可能性があります。既知の管理ファイル名や接頭辞を先に検査し、次に拡張子を確認し、必要に応じて実際に画像として読み取れるかを確認します。
圧縮時は、対象範囲、階層、圧縮形式、ファイル名を確認し、毎回整理済みフォルダから新しい圧縮ファイルを作ります。圧縮後は仮展開し、隠しファイルの再混入、階層ずれ、参照切れがないかを調べます。
除外後も失敗する場合は、容量、OBJの記述、参照番号、頂点だけのOBJへの対応、MTL、画像形式、相対パス、名称、通信状態を一つずつ確認します。変更点を一つにした比較版を作ると、原因を特定しやすくなります。
点群OBJを継続的に扱う場合は、作業用、保管用、アップロード用を分け、許可リストと検査記録を運用します。点群の取得から共有、確認までの流れをまとめて整理したい場合は、LRTK Phoneを活用した点群計測とクラウド上でのデータ確認・共有も選択肢になります。