点群から生成したOBJモデルをアップロードし直したにもかかわらず、画面には更新前の形状や色が表示されることがあります。元データを修正し、OBJファイルを再出力し、アップロード完了まで確認したのに結果が変わらないと、変換処理やモデル自体に問題があるように見えます。しかし、実際にはブラウザ、配信サーバー、ファイルURL、関連ファイルのいずれかに古いデータが残っているケースが少なくありません。
特に、同じファイル名でOBJを上書きする運用では、アップロード先のファイルが更新されていても、閲覧側が以前に取得したデータを再利用することがあります。また、OBJだけを差し替え、マテリアル情報やテクスチャ画像を更新していない場合には、形状は新しくても外観だけが古い状態になることもあります。
点群 OBJ アップロード後の表示不具合を短時間で解決するには、むやみに再変換や再アップロードを繰り返すのではなく、どの段階に古いモデルが残っているかを順番に切り分けることが重要です。本記事では、古いモデルが表示される代表的な4原因と、キャッシュを解消するための確認手順、再発を防ぐファイル管理方法を実務担当者向けに解説します。
点群OBJアップロード後に古いモデルが出る現象とは
点群OBJアップロード後に古いモデルが表示される現象は、アップロード処理の失敗だけで発生するものではありません。保存先には新しいファイルが存在していても、閲覧端末が以前のファイルを保持していれば、画面上では更新前のモデルが表示されます。
OBJは、一般に頂点座標、面情報、法線、テクスチャ座標などを記録できる3次元モデル形式です。点群から表面形状を生成したモデルをOBJとして出力することもあれば、点を頂点情報として扱うこともあります。モデルの外観には、OBJ本体だけでなく、マテリアル情報を記録したファイルやテクスチャ画像が関係する場合があります。
このため、「古いモデルが出る」という表現には複数の状態が含まれます。形状そのものが更新前である場合、形状は更新されているものの色や模様だけが古い場合、モデルの一部分だけが以前の状態に見える場合、複数モデルのうち一つだけが差し替わっていない場合などです。
最初に確認したいのは、本当にOBJ本体が古いのか、それとも表示に利用される関連データだけが古いのかという点です。ここを区別せずに再アップロードを続けると、原因が残ったまま同じ操作を繰り返すことになります。
点群 OBJ アップロードの作業では、変換元データ、出力ファイル、アップロード先、配信経路、閲覧画面という複数の段階を通ります。古いモデルが表示される場合は、この経路のどこかで以前のデータが再利用されていると考えると切り分けやすくなります。
原因1｜ブラウザに以前のOBJデータが保存されている
最も確認しやすい原因は、閲覧に使用しているブラウザのキャッシュです。ブラウザには、一度取得したファイルを端末内に一時保存し、次回の表示を速くする仕組みがあります。画像や文書だけでなく、設定によってはOBJ、マテリアル情報、テクスチャ画像、表示用スクリプトなども再利用されます。
アップロード前後でOBJのURLが同じ場合、ブラウザは「すでに取得済みのファイル」と判断し、新しいファイルを取得せずに端末内のデータを使用することがあります。アップロード先で正しく上書きされていても、閲覧画面には古い形状が表示されるため、アップロードが失敗したように見えます。
この問題の特徴は、閲覧環境によって表示結果が異なることです。作業に使用した端末では古いモデルが表示される一方、別の端末や別の閲覧環境では新しいモデルが表示される場合、ブラウザ側に古いデータが残っている可能性が高いと考えられます。
通常の再読み込みだけでは、キャッシュされたファイルが引き続き使われることがあります。そのため、再読み込みを何度繰り返しても表示が変わらないケースがあります。確認時には、キャッシュを使用しない再読み込み、閲覧履歴や一時ファイルの削除、保存情報を引き継がない閲覧モード、別端末での表示確認などを使い分けます。
ただし、最初から端末内の保存情報をすべて削除する必要はありません。業務で利用している他の画面のログイン状態や設定まで失われることがあるため、まずは対象ページだけをキャッシュなしで再読み込みし、それでも変わらない場合に対象範囲を広げる方法が効率的です。
テクスチャ画像だけが古い場合も、ブラウザキャッシュが関係している可能性があります。OBJ本体は更新後の形状になっているのに、表面の色や撮影画像が以前のままであれば、OBJではなく画像ファイルが再利用されていることがあります。この場合は、OBJだけを再取得させても外観は変わりません。
原因2｜配信サーバーや中継キャッシュに古いデータが残っている
閲覧端末のキャッシュを解消しても古いモデルが表示される場合は、サーバー側や配信経路に古いファイルが残っている可能性があります。
3次元モデルの閲覧システムでは、保存場所から直接OBJを読み込むとは限りません。表示を高速化するため、利用者に近い配信拠点や中継サーバーにファイルを一時保存する構成が使われることがあります。保存先のOBJが更新されても、中継側のデータが更新されるまで、以前のモデルが返される場合があります。
この状態では、閲覧端末を変えても古いモデルが表示されやすくなります。複数の担当者が異なる端末から確認しても同じ古い形状が出る場合は、個々のブラウザよりもサーバー側のキャッシュを疑います。
配信経路にキャッシュがある場合、元ファイルの上書きと表示への反映に時間差が生じることがあります。アップロード完了画面が表示された直後に閲覧すると古いモデルが出て、しばらくしてから新しいモデルに切り替わる場合は、この時間差が関係している可能性があります。
一方、一定時間待っても更新されない場合は、キャッシュの有効期間が長く設定されている、更新通知が配信側へ伝わっていない、別の保存場所を参照しているなどの確認が必要です。管理機能にキャッシュ削除や配信更新の操作が用意されている場合は、OBJ本体だけでなく、関連するマテリアル情報や画像も対象になっているか確認します。
サーバー側のキャッシュ問題は、アップロードを繰り返しても改善しないことがあります。同じURLに同じ名前で上書きし続けると、中継側から見れば取得対象が変わっていないためです。再アップロードの回数を増やすより、ファイルURLを変更して新しいデータとして認識させるほうが有効な場合があります。
また、アップロード先と公開先が分かれている構成では、保存領域には新しいOBJがあるものの、公開領域には古いOBJが残っていることがあります。管理画面でアップロード済みと表示されても、実際の閲覧画面が同じ保存先を参照しているとは限りません。公開処理、変換処理、配信反映処理が別になっている場合は、それぞれの完了状態を確認する必要があります。
原因3｜同じファイル名とURLで上書きしている
点群OBJアップロード後も古いモデルが出る場面では、同一ファイル名での上書きが大きな要因になります。
たとえば、修正前と修正後のモデルをどちらも「model.obj」のような固定名で保存し、同じ場所へアップロードすると、閲覧側から見た参照先は変わりません。ファイルの中身は更新されていても、URLが同じため、ブラウザや中継キャッシュが以前のデータを再利用しやすくなります。
固定名での上書きは、操作手順が単純になる一方で、新旧判定を難しくします。表示中のファイルが最新版なのか、前回版なのかをファイル名から判断できません。アップロード日時だけで管理していると、端末の時刻差、処理完了時刻、再変換時刻などが混在し、確認に時間がかかります。
対策として有効なのは、OBJのファイル名や参照URLに版を識別できる情報を持たせることです。作成日、更新番号、出力番号、承認段階などを加え、修正ごとに異なる名前を使用します。たとえば、初回出力と修正版で別のファイル名にすれば、閲覧側は新しいURLからデータを取得するため、古いキャッシュが再利用されにくくなります。
ファイル名を変更できない仕組みでは、参照URLに更新用の識別値を加える方法があります。OBJ本体の保存名が同じでも、閲覧側が異なるURLとして認識できれば、新しい取得要求を発生させられる場合があります。
ただし、識別値を付けても、表示システム内部でURLが固定化されている場合や、入力した値が読み込み時に除去される場合には効果が限定されます。変更後は、実際に閲覧画面が新しい参照先を使用しているか確認することが重要です。
ファイル名の変更はキャッシュ解消だけでなく、履歴管理にも役立ちます。どの点群から作成したOBJなのか、どの修正が反映されているのか、いつ公開したモデルなのかを追跡しやすくなります。上書き運用を続けるより、版ごとにファイルを分け、確認完了後に公開対象を切り替える方法のほうが安全です。
原因4｜OBJと関連ファイルの更新状態が一致していない
OBJモデルは、OBJファイルだけで表示が完結するとは限りません。色や材質、画像を使用するモデルでは、マテリアル情報を記録するファイルやテクスチャ画像を一緒に読み込みます。OBJ本体だけを更新し、関連ファイルを以前のまま残すと、新旧データが混在します。
この原因は、形状と見た目のどちらが古いかによって判断しやすくなります。点の位置、面の形、欠損部分、切り取り範囲などが修正版になっているのに、表面の画像だけが古ければ、OBJ本体は更新されている可能性があります。反対に、色は変わっているのに形状が以前のままであれば、画像だけが更新され、OBJが差し替わっていない可能性があります。
OBJ内には、参照するマテリアル情報のファイル名が記録されることがあります。また、マテリアル情報には、使用するテクスチャ画像のファイル名や相対的な保存場所が記録される場合があります。修正後のデータを書き出した際にファイル名やフォルダー構成が変わると、アップロード先で正しく関連付けられないことがあります。
たとえば、新しいOBJと新しい画像をアップロードしても、マテリアル情報が古い画像名を参照していれば、以前の画像が表示される可能性があります。逆に、OBJが古いマテリアル情報を指定したままであれば、新しくアップロードした関連ファイルが利用されません。
点群からOBJを再生成する際は、OBJだけを単独で差し替えるのではなく、同時に出力された一式を確認することが重要です。OBJ、マテリアル情報、テクスチャ画像の更新日時、ファイル名、保存場所、参照記述が一致しているかを確認します。
関連ファイルにもブラウザやサーバーのキャッシュが適用されます。そのため、OBJの名前だけを変更し、テクスチャ画像の名前を固定したままにすると、形状は新しくても画像だけ古いという状態が起こり得ます。確実に更新したい場合は、関連ファイルにも版を識別できる名前を付けます。
最初に新旧モデルの違いを特定する
キャッシュを削除する前に、表示されているモデルのどの部分が古いのかを明確にします。違いが分からないまま操作すると、更新されたかどうかを客観的に判定できません。
確認しやすいのは、修正箇所を一つ決めて比較する方法です。点群の不要部分を除去した場所、追加した範囲、切り取り境界、穴埋めした面、座標を補正した箇所、色調を変更した範囲など、旧版と新版の差が明確な場所を選びます。
モデル全体の印象だけで判断すると、視点、陰影、描画品質、表示距離によって見え方が変わります。特定の構造物の有無や、境界形状の違いなど、再現性のある判定基準を用意することが重要です。
修正版に確認用の特徴を一時的に加える方法もあります。公開前の検証用モデルで、目立たない位置に小さな形状変更を加えたり、確認対象の範囲を限定したりすれば、表示中のデータが新版かどうかを判定しやすくなります。ただし、本番公開時には検証用の変更を除去し、最終データで再確認します。
ファイル容量も補助的な判断材料になります。大きく編集したにもかかわらず、アップロード先のOBJ容量が修正前と完全に同じである場合は、誤ったファイルを選択した可能性があります。ただし、容量が同じでも中身が異なる場合があるため、容量だけで更新の成否を断定してはいけません。
出力時刻、ファイル容量、頂点数、面数、関連ファイル数などを記録しておくと、アップロード対象の取り違えを発見しやすくなります。特に、似た名前のOBJが複数ある作業フォルダーでは、更新済みと思っていたファイルが実際には前回版だったというケースがあります。
アップロード先のファイルが更新されたか確認する
次に、アップロード操作が保存先へ正しく反映されたかを確認します。画面上に「完了」と表示されても、その表示がファイル転送の完了を意味するのか、受付の完了を意味するのか、変換や公開まで含むのかは仕組みによって異なります。
アップロード後に追加処理が行われる場合は、その処理が完了するまで旧モデルが表示されることがあります。大容量の点群やOBJでは、受信後に検査、展開、最適化、変換、公開準備などが行われる場合があります。転送が終わった直後に表示確認すると、公開側には前回版が残っている可能性があります。
管理画面で確認できる場合は、アップロード日時、処理状態、ファイル容量、公開状態を確認します。更新時刻が変わっていない場合は、上書き処理が実行されていない、別フォルダーへ保存された、同名ファイルの置換が許可されていないなどの可能性があります。
アップロード対象の選択ミスにも注意が必要です。作業用、確認用、軽量化用、公開用など複数のOBJが存在すると、旧版を再度アップロードすることがあります。ローカル側でファイルを開き、修正箇所が反映されていることを確認してからアップロードすると、切り分けが容易になります。
圧縮した状態でアップロードする運用では、圧縮ファイルの作成日時と内部ファイルの更新日時が一致しているか確認します。OBJを修正した後、以前に作成した圧縮ファイルを選択すると、アップロード操作自体は正常でも中身は旧版です。
また、ファイルの置換ではなく追加登録として処理される仕組みでは、新しいモデルが別データとして保存され、閲覧画面は以前の登録を参照し続けることがあります。この場合は、アップロードよりも公開対象や表示対象の切り替えが必要です。
ブラウザ側のキャッシュを解消する
アップロード先の更新を確認できたら、閲覧側のキャッシュを段階的に解消します。最初に行うのは、対象画面をキャッシュなしで再読み込みする操作です。通常の再読み込みよりも、新しいファイルを取得しやすくなります。
それでも変わらない場合は、対象画面を閉じて開き直します。3次元表示画面では、ページを表示している間、OBJデータが端末のメモリー上に保持されることがあります。ページ内の更新操作だけでは、読み込み済みモデルが破棄されない場合があります。
次に、保存情報を引き継がない閲覧環境で同じ画面を確認します。そこで新しいモデルが表示されれば、通常環境に残っているキャッシュや保存データが原因と判断しやすくなります。
別の端末から確認する方法も有効です。ただし、同じネットワーク内に共通の中継キャッシュがある場合は、端末を変えても古いデータが表示される可能性があります。別端末でも旧版が出るときは、ブラウザだけでなくサーバー側の確認へ進みます。
キャッシュ削除後は、修正した場所を基準に新旧を判定します。単にモデルが表示されたことだけで更新完了と判断してはいけません。視点を同じ位置に合わせ、形状、範囲、色、画像、配置を確認します。
なお、キャッシュ削除によって表示が改善しても、根本的な運用が同名上書きのままであれば再発する可能性があります。緊急対応としてキャッシュを消した後、ファイル名や公開方法も見直すことが重要です。
URLやファイル名にバージョン情報を付ける
古いモデルの再表示を防ぐ方法として、ファイル名やURLの版管理は効果的です。更新のたびに異なる参照先を使用すれば、閲覧側は新しいデータとして取得しやすくなります。
版情報には、作成日だけでなく、更新回数や承認状態を含めると管理しやすくなります。同じ日に複数回修正する現場では、日付だけでは区別できません。連番や時刻、作業段階を組み合わせ、重複しない名前を使用します。
ファイル名は、担当者だけが理解できる略称に偏らせないことも重要です。案件、対象範囲、データ種別、版を一定の順序で記載すると、別の担当者でも判別できます。ファイル名が長くなりすぎる場合は、必要項目を絞り、管理台帳と対応させます。
OBJの名前を変更する際は、マテリアル情報内の参照関係にも注意します。OBJの名前だけを変更しても、内部で指定されている関連ファイル名が旧版のままでは、新旧データが混在する可能性があります。
公開URLを変更した後は、閲覧画面や埋め込み先が新しいURLを参照しているか確認します。新しいOBJを保存しただけでは、利用者が見る画面は切り替わりません。検証用URLで表示を確認し、問題がなければ公開先を新版へ切り替える流れが安全です。
版管理を行うと、問題発生時に以前の正常なモデルへ戻しやすくなります。常に同じファイルを上書きすると、更新後に不具合が見つかっても旧版を復元できないことがあります。キャッシュ対策と復旧性の両面から、版ごとの保存が有効です。
サーバー側のキャッシュ設定を見直す
複数端末で同じ旧モデルが表示される場合は、配信側の設定を確認します。管理担当者と閲覧担当者が異なる場合は、表示結果だけでなく、対象URL、アップロード時刻、確認時刻、旧版と新版の判別箇所を共有します。
配信側では、ファイルをどの程度の期間保存する設定になっているか、新しいファイルの取得確認が行われるか、手動でキャッシュを更新できるかを確認します。OBJ本体だけでなく、マテリアル情報や画像にも個別の設定が適用されている場合があります。
更新頻度の高い作業中データと、確定後に長期間変更しない公開データでは、適切なキャッシュ方針が異なります。作業中のOBJに長期間のキャッシュを適用すると、更新確認が難しくなります。一方、確定した大容量モデルを毎回取得すると、表示開始までの時間や通信量が増える可能性があります。
そのため、検証段階では短い更新間隔や版付きURLを使用し、公開確定後は固定版として扱う方法が考えられます。運用段階に応じて設定を分けることで、更新性と表示効率を両立しやすくなります。
サーバーが返す更新情報と実際のファイル内容が一致していない場合もあります。内容を上書きしたのに更新日時や識別情報が変わらないと、閲覧側が新しい取得を行わないことがあります。管理できる環境では、ファイル更新時に識別情報も更新される構成になっているか確認します。
キャッシュ削除を実行する場合は、対象範囲を明確にします。OBJだけを対象にしても、古いテクスチャ画像が残れば見た目は更新されません。反対に、必要以上に広い範囲を削除すると、他のモデルの読み込み速度へ影響することがあります。案件、モデル、版、関連ファイルを特定して実行することが重要です。
OBJ・マテリアル・テクスチャを一式で確認する
点群OBJアップロードでは、出力フォルダー内のファイル構成をアップロード前に確認します。OBJ本体だけを見ていると、関連ファイルの漏れや参照ずれを見逃します。
まず、ローカル環境で修正版のOBJを開き、形状と外観が意図どおりであることを確認します。ローカルでも旧形状が表示される場合、キャッシュではなく、出力元や選択したファイルに問題があります。
次に、OBJが参照するマテリアル情報のファイル名を確認します。ファイル名の大文字と小文字、拡張子、保存場所が一致している必要があります。閲覧環境によっては、大文字と小文字の違いを別ファイルとして扱うため、ローカルでは表示できてもアップロード先では読み込めないことがあります。
マテリアル情報から参照される画像についても、名前と保存場所を確認します。画像を再生成した場合は、同名上書きよりも版付きの名前に変更し、参照先も合わせて更新したほうが新旧を判定しやすくなります。
アップロード時にフォルダー構成が変わる場合は、相対的な参照関係が維持されるか確認します。OBJ、マテリアル情報、画像を別々の場所へ配置すると、参照先が見つからず、色が表示されない、以前の画像が代わりに利用されるなどの問題につながります。
一式を圧縮して登録する方式では、最上位のフォルダー階層にも注意します。圧縮ファイル内に不要な親フォルダーが追加されると、想定した場所から関連ファイルを読み込めない場合があります。以前の登録が残っていると、新しい関連ファイルが見つからない際に旧データが表示され、更新失敗と誤認することもあります。
再アップロードを繰り返しても直らない場合の切り分け
同じOBJを何度アップロードしても古いモデルが表示される場合は、作業をいったん止め、確認点を整理します。再アップロードの回数が増えるほど、どの版がどこに保存されたか分かりにくくなるためです。
最初に、ローカル上の修正版を開き、判別箇所が更新されているか確認します。ここで旧版が表示されるなら、アップロード工程ではなく、OBJの生成工程やファイル選択を見直します。
ローカルでは新版、アップロード先では旧版という場合は、アップロード後のファイル情報を確認します。容量や更新時刻が変わっていなければ、転送、保存、上書きのいずれかが完了していない可能性があります。
保存先では新版なのに閲覧画面が旧版であれば、キャッシュか参照先の問題です。新しいファイル名でアップロードし、新しいURLを直接指定して表示できるか確認します。新しいURLでは新版が出るなら、固定URLに残るキャッシュや公開設定が原因と判断できます。
新しいURLでも旧版が表示される場合は、閲覧画面が指定したURLを使用していない可能性があります。登録情報、モデル識別子、公開対象、埋め込み設定などが以前のモデルを参照していないか確認します。
形状は新版、色だけ旧版であれば、テクスチャ画像のURLを変更して確認します。反対に、色は新版、形状が旧版なら、OBJ本体の参照先を確認します。このように、形状と外観を分けて調べることで、対象ファイルを絞り込めます。
複数の担当者が作業する場合は、「アップロードした」という報告だけでなく、アップロードしたファイル名、版、容量、時刻、公開先、確認結果を共有します。作成担当者と公開担当者が別の場合、修正版を受け取ったつもりで旧版を登録することがあります。
古いモデルの再表示を防ぐ運用ルール
キャッシュ問題は、一度解消しても同じ運用を続けると再発します。再発防止には、ファイル作成から公開確認までの流れを標準化することが重要です。
基本となるのは、同一ファイル名での無制限な上書きを避けることです。作業版、確認版、公開版を区別し、修正のたびに版番号を更新します。公開中のモデルを直接上書きするのではなく、新版を別の参照先へ登録し、確認後に公開対象を切り替えると安全です。
次に、OBJと関連ファイルを一つの単位として管理します。OBJだけに版番号を付け、画像は固定名のままにすると、モデル内で異なる版が混在します。出力一式に共通の版情報を付け、どの組み合わせが正しいか分かる状態にします。
アップロード前後の確認項目も固定します。アップロード前は、ローカル表示、修正箇所、頂点数、面数、容量、関連ファイルを確認します。アップロード後は、保存先の更新、処理完了、キャッシュなしでの表示、新旧判定箇所、別環境での確認を行います。
公開完了の判断基準も明確にします。アップロード操作が終わっただけでは、利用者が新版を閲覧できるとは限りません。実際の公開画面で修正箇所を確認し、必要に応じて別端末でも表示してから完了とします。
旧版を一定期間残しておくことも重要です。新版に問題が見つかった場合、すぐに以前の正常なモデルへ戻せます。旧版を削除する時期と、最新版を示す方法を決めておけば、保管ファイルが増えても混乱しにくくなります。
ファイル名だけでなく、簡単な更新記録を残すとさらに管理しやすくなります。修正内容、作成者、出力日時、アップロード日時、公開確認者、対象URLを記録すれば、古いモデルが出た際にどの工程まで完了していたか追跡できます。
点群OBJアップロードを効率化するポイント
点群OBJアップロードの効率を上げるには、問題が起きてからキャッシュを削除するだけでなく、データ作成段階から公開後の確認方法までを一つの工程として設計する必要があります。
点群からOBJを生成する際は、不要な範囲を整理し、用途に合った密度や面数に調整します。データ量が大きすぎると、アップロード、サーバー処理、閲覧開始までの時間が長くなり、更新結果を確認しにくくなります。確認用には対象範囲を限定した軽量版を用意し、問題がなければ本番版を登録する方法も有効です。
修正内容が小さい場合でも、ファイル全体を同名で置き換えるのではなく、版を更新します。これにより、キャッシュ問題が起きにくくなるだけでなく、修正前後を比較しやすくなります。
閲覧確認では、モデルを開いた直後の見た目だけでなく、座標、向き、縮尺、欠損、表面画像、切り取り範囲などを確認します。キャッシュが解消されて新版が表示されても、変換設定の違いによって配置や寸法に問題が生じている可能性があります。
現場で取得したデータを扱う場合は、取得データと公開モデルの対応関係も残します。どの測定日、どの範囲、どの処理条件から作成されたOBJか分かれば、修正や再出力が必要になった際に迷いません。
LRTK Phoneを利用して現場データを取得する運用では、取得段階から案件名、計測範囲、日時、版を整理しておくと、後工程の点群処理やOBJ管理を進めやすくなります。端末側のデータ名と、変換後のOBJ名、アップロード先のモデル名を対応させることで、別のデータを誤って公開するリスクを減らせます。
アップロード後に古いモデルが表示された場合も、取得データまで戻って作業をやり直すのではなく、まず表示経路を確認します。ローカルのOBJが正しければ、ブラウザ、配信サーバー、URL、関連ファイルの順で切り分けることで、不要な再処理を避けられます。
まとめ
点群OBJアップロード後も古いモデルが表示される主な原因は、ブラウザに以前のデータが残っていること、配信サーバーや中継キャッシュが旧版を返していること、同じファイル名とURLで上書きしていること、OBJとマテリアル情報やテクスチャ画像の更新状態が一致していないことの4つです。
解決時には、まず旧版と新版を判定できる箇所を決めます。そのうえで、ローカルのOBJ、アップロード先のファイル、公開処理、ブラウザ表示の順に確認します。最初から再変換や再アップロードを繰り返すのではなく、どの段階まで新版が届いているかを確認することが重要です。
ブラウザ側だけで古いモデルが出る場合は、キャッシュなしの再読み込みや別の閲覧環境で確認します。複数端末で同じ旧版が表示される場合は、サーバー側のキャッシュや公開先の参照設定を確認します。
形状だけが古い場合はOBJ本体、色や画像だけが古い場合はマテリアル情報やテクスチャ画像を重点的に調べます。OBJと関連ファイルは別々に扱わず、同じ版の一式として管理することが大切です。
再発防止には、同名上書きに依存せず、ファイル名やURLへ版情報を付ける方法が有効です。修正版を別の参照先へ登録し、表示確認後に公開対象を切り替えれば、キャッシュの影響を受けにくくなり、問題発生時の復旧も容易になります。
点群データの取得からOBJ作成、アップロード、公開確認までを一貫して管理したい場合は、LRTK Phoneを活用した現場データ取得の流れもあわせて確認すると、データの取り違えや版管理の負担を減らしやすくなります。