点群をOBJ形式でアップロードしたとき、形状や座標は読み込まれているのに、現地の色だけが白、灰色、黒、単色に変わることがあります。この現象は、点群の座標が破損したことを直ちに意味するものではありません。OBJ内に色情報がない場合だけでなく、色の書き方を読み込み側が解釈できない場合や、アップロード後の変換工程で色属性が引き継がれない場合にも発生します。
最初に押さえたいのは、元来のOBJ仕様が頂点ごとのRGBを標準項目として定義していない点です。標準的な頂点行は座標と任意のW成分を扱いますが、実務では座標の後ろへRGBを追加する拡張記述が広く使われています。現在のソフトウェアにも、この拡張を「xyzrgb」として出力する実装がありますが、すべてのOBJ読み込み環境が同じ記述を受け付けるわけではありません。([The Library of Congress][1])
そのため、「OBJをアップロードできること」と「OBJ内の頂点色を表示できること」は別に確認する必要があります。本記事では、「点群 OBJ アップロード」で頂点色が消えるときに確認したい4つの原因を整理します。RGB列の有無、値域、列構成、点要素、アップロード後の属性変換を順番に確認し、色を保った状態で点群を受け渡すための実務的な検証方法を解説します。
点群OBJの頂点色とRGB記述の基礎
OBJは、頂点座標、点、線、面、法線、テクスチャ座標、材質参照などをテキストで記録できる形式です。頂点座標は、行頭にvを付けた行で表します。基本的な頂点行は次の形です。
v X座標 Y座標 Z座標
たとえば、ある頂点の座標がX方向に1.25、Y方向に2.50、Z方向に3.75であれば、次のように記述します。
v 1.25 2.50 3.75
元来のOBJ仕様では、座標の後ろに任意のW成分を置けます。
v X座標 Y座標 Z座標 W
WはRGBではありません。したがって、vの後ろに4つの数値がある場合、4番目を赤成分と決めつけるのは危険です。ファイルを生成したソフトウェアや変換処理の仕様を確認し、Wなのか、独自属性なのかを判断する必要があります。
一方、頂点色を1ファイルへ格納する実務上の拡張として、座標の後ろに赤、緑、青を追加する書き方があります。
v X座標 Y座標 Z座標 R G B
実際の行は次のような形です。
v 1.25 2.50 3.75 0.80 0.40 0.20
このxyzrgb形式は複数の実装で利用されていますが、元来のOBJ仕様に含まれる必須記述ではありません。読み込み側が座標以外の値を頂点色として認識しなければ、先頭のXYZだけを採用し、後半のRGBを無視することがあります。反対に、Wを含む独自形式を想定する実装へxyzrgbを渡すと、列の意味がずれて解釈される可能性があります。([Blender Documentation][2])
点群としてOBJを扱うときは、v行だけでなく、点要素を示すp行にも注意します。OBJ仕様には、登録済みの頂点番号を点要素として参照するp記述があります。たとえば、最初の3頂点を点として指定する場合は、次のように記述できます。
p 1 2 3
一部の表示環境は、p行やf行に参照されていないv行も点として描画します。しかし、その挙動をすべての読み込み環境に期待することはできません。OBJ仕様上は点要素pが存在するため、点群を確実に受け渡したい場合は、アップロード先がv行だけのファイルを点として扱うのか、p行を必要とするのかを確認します。([The Library of Congress][1])
したがって、点群OBJの頂点色を確認するときは、「v行にRGBらしい数値があるか」だけでは不十分です。標準のXYZまたはXYZWなのか、xyzrgb拡張なのか、点を示すp行があるのか、読み込み先がその組み合わせに対応しているのかまで確認する必要があります。
原因1｜アップロード先が頂点色の拡張記述に対応していない
頂点色が消える代表的な原因は、アップロード先がOBJの頂点色拡張を認識しないことです。ファイル内にRGB値が残っていても、読み込み処理が標準的なXYZまたはXYZWだけを取得する設計であれば、色は表示されません。
OBJ対応という表示だけでは、頂点色対応まで判断できません。面、点、法線、テクスチャ座標、MTL、テクスチャ画像、xyzrgb拡張は、同じOBJ関連機能でも別々に実装されることがあります。ある環境では色付きで表示され、別の環境では白や単色になることがあるのは、この実装差が理由の一つです。元来のOBJ仕様に頂点色が含まれず、後から複数の方式が使われるようになったため、読み書きの互換性は製品名やバージョンだけでなく、実際の入出力条件で検証する必要があります。([The Library of Congress][1])
まず、元のOBJをテキストとして確認し、v行に座標以外の数値があるか調べます。次のようにvの後ろへ6つの数値が並んでいれば、後半3値がRGBとして出力されたxyzrgb形式の可能性があります。
v 100.125 200.250 15.375 0.521 0.486 0.455
次のように3値しかなければ、少なくともその行には頂点色がありません。
v 100.125 200.250 15.375
ただし、6値だから必ずRGBとは限りません。独自拡張や前処理で別の属性を追加している可能性もあるため、出力元の仕様を優先します。RGBであることが明記されていないときは、複数行を比較し、後半3値の分布と元データの色変化が対応しているかを確認します。
アップロード先の対応可否を確かめるには、少数点の検証用OBJを使います。赤、緑、青に相当する色を持つ点を用意し、v行のRGBだけでなく、p行で点として参照した状態でも試します。小規模なファイルで座標は表示されるのにすべて同じ色になる場合は、通信容量よりも頂点色の解釈や表示モードを優先して疑えます。
頂点色に非対応の環境へ同じファイルを何度アップロードしても、通常は結果が変わりません。ファイル名や圧縮方法だけを変更するのではなく、読み込み先が受け付ける色表現を確認します。頂点色を保持できる別形式への変換が必要な場合もありますが、変換前後で座標、点数、色、座標系が維持されていることを必ず検証します。
また、アップロード先がxyzrgbへ対応していても、画面側で頂点色を使わない材質が選択されていることがあります。読み込み機能と表示設定を分け、RGB属性が内部に存在するのか、存在するが表示されていないのかを切り分けます。
原因2｜RGB値の範囲が読み込み側の想定と異なる
OBJ内にRGBらしい3値があり、アップロード先も頂点色拡張を扱える場合は、次に値の範囲を確認します。頂点色の追加記述は標準仕様ではないため、値域もOBJファイルだけから一律に決められません。0から1までの小数を使う実装がある一方、取得・変換工程によっては0から255相当の値が出力されることがあります。重要なのは、出力側と読み込み側が同じ値域を想定しているかです。
0から1の形式では、白は1 1 1、黒は0 0 0です。
v 5.100 8.200 2.300 0.250 0.500 0.750
0から255相当の形式では、次のような値が見られます。
v 5.100 8.200 2.300 64 128 191
出力側が0から255相当で記録し、読み込み側が0から1を想定している場合、1を超えた値の処理は実装によって異なります。上限へ切り詰める実装なら、複数成分が最大値となって白や明るい単色に見える可能性があります。エラーとして行を無視する実装や、別の規則で正規化する実装も考えられるため、表示結果だけで処理内容を断定しないことが重要です。
反対に、出力側が0から1で、読み込み側が0から255の整数を想定している場合、小数の丸めや型変換によって色が極端に暗くなる可能性があります。ただし、読み込み側が自動的に値域を判定する場合もあります。白くなった、黒くなったという結果だけで値域不一致と決めつけず、仕様書、ログ、検証ファイルを使って確認します。
値域の調査では、先頭数行だけでなく、ファイルの中間と末尾も確認します。後半3値が全行で0から1以内に収まり、元の景色に対応して変化しているなら、正規化RGBの可能性が高まります。10、120、240のような値が継続して現れるなら、0から255相当の記録を疑います。負の値、極端に大きい値、NaN、空欄がある場合は、不正値として色属性または頂点行全体が除外される可能性があります。
0から255相当の値を0から1へ変換する場合は、各成分を255で割ります。128 64 32は、おおよそ0.502 0.251 0.125です。0から1を0から255相当へ変換する場合は各成分を255倍します。ただし、変換はアップロード先の仕様を確認してから行います。誤った推測で変換すると、正常だった色を二重に正規化したり、階調を失ったりするおそれがあります。
アルファ値にも注意が必要ですが、v X Y Z R G B AをOBJ頂点色の共通仕様として扱うことはできません。7値以上の頂点行を認識する実装があっても、アルファを無視する実装や、列全体を別形式として扱う実装があります。実際に、OBJ頂点色のアルファが読み込み時に無視される実装例もあります。したがって、Aが0なら必ず透明になるとは断定せず、出力元と読み込み先の双方が同じ拡張を明示的に扱う場合に限って評価します。([Blender Projects][3])
色が白、黒、極端に濃い、極端に薄い場合は、RGB値域、クランプ、丸め、色空間、表示材質の影響を順番に確認します。値域だけに原因を限定せず、同じ座標と色を持つ小規模ファイルで条件を一つずつ変えると、切り分けやすくなります。
原因3｜頂点行の列数や点要素が正しく解釈されていない
3つ目の原因は、v行の列数、列順、点要素の参照方法が読み込み側の想定と一致していないことです。RGB値が妥当でも、各列の意味を読み込み側が別のものとして解釈すれば、色は表示されません。
標準的な頂点行としてまず想定されるのは、XYZの3値、またはXYZWの4値です。
v X Y Z
v X Y Z W
頂点色拡張として広く見られるのは、XYZRGBの6値です。
v X Y Z R G B
一方、実装によってはXYZWRGBのようにWを挟む方式が使われることがあります。xyzrgbとxyzwrgbは列の位置が異なるため、同じOBJ頂点色として自動的に互換になるとは限りません。読み込み側がxyzrgbを想定しているのにxyzwrgbを渡すと、Wを赤として読み、本来の青が余分な値になるなどのずれが起こり得ます。こうした方式は標準OBJの統一仕様ではなく、出力元と読み込み先の個別仕様として扱う必要があります。([Blender Projects][4])
列の欠損も問題になります。たとえば、1行目はRGBを含むのに、2行目は青成分が不足しています。
v 1.0 2.0 3.0 0.4 0.5 0.6
v 1.1 2.1 3.1 0.4 0.5
読み込み側は、不足した行だけを除外する場合もあれば、頂点色属性全体を無効と判断する場合もあります。数百万行のうち数行だけ不正でも影響する可能性があるため、冒頭だけでなく、すべてのv行のトークン数を集計します。
座標だけの行とRGB付きの行が混在するケースにも注意します。
v 1.0 2.0 3.0 0.4 0.5 0.6
v 1.1 2.1 3.1
この状態で色なし頂点へ何色を割り当てるかは、読み込み側によって異なります。白や既定材質色を使う場合、点群の一部だけ色が抜けたように見えます。ファイル全体で同一形式に統一できるか、色なし点を別管理すべきかを検討します。
数値の区切り文字も確認します。一般的なOBJでは、キーワードと各値を空白で分けます。次のようなカンマ区切りは、空白分割を前提とする読み込み処理では正しい数値列として扱われない可能性があります。
v 1.25,2.50,3.75,0.80,0.40,0.20
小数点にカンマを使った数値、全角空白、タブと制御文字の混在、NaN、無限大、不要な記号も確認対象です。座標が読めている場合でも、後半の色列だけに不正文字が含まれていれば、RGBだけが欠落する可能性があります。
点群OBJではp行の有無と参照番号も確認します。v行に頂点を定義しただけのファイルを点として表示するかどうかは読み込み環境に依存します。p行がある場合は、参照番号が1から始まるOBJの頂点番号と一致しているか、範囲外参照がないかを確認します。p行がなく、アップロード先が未参照頂点を描画しない場合は、色以前に点要素として採用されないことがあります。元来のOBJ仕様には点要素pが定義されているため、点群用途では頂点定義と点要素の両方を確認するのが安全です。([The Library of Congress][1])
RGBの並び順も確認します。出力元がRGBではなくBGRなどの独自順序を採用している場合、赤い対象が青く見えるなど、色相が大きく変わります。ただし、見た目だけで順序を断定せず、明確な色を持つ検証点と仕様書で確認します。
列数の検証では、v行ごとの数値数、p行の参照数、RGB値域、不正文字数を集計します。Wやアルファを含む独自形式を推測で削除せず、元データの意味と出力仕様を確認してから変換します。
原因4｜アップロード後の変換処理で色情報が削除される
4つ目の原因は、アップロードしたOBJがそのまま表示されず、サーバー側や表示側で別の内部形式へ変換される過程でRGB属性が削除されることです。
大容量の点群を扱う環境では、アップロード後に分割、軽量化、階層化、座標変換、メッシュ化、点数削減、属性選別などが行われることがあります。変換処理がXYZだけを対象として新しい頂点を作る場合、元のv行にあったRGBが出力先へ引き継がれません。
この現象では、手元の確認環境では色付きで表示できるのに、アップロード後だけ白や単色になることがあります。元ファイルが正常で、同じファイルを別の読み込み環境では色付きで開けるなら、アップロード先の変換工程または表示設定に原因がある可能性が高まります。
点群を面モデルへ変換する処理にも注意します。頂点色を持つ点から面を生成しても、変換先がMTLの材質やテクスチャだけを採用する設計なら、元のRGBが失われる可能性があります。反対に、面モデルを点表示用の内部形式へ変換するときに、テクスチャ座標や材質情報が削除されることもあります。
軽量化処理では、複数点を代表点へまとめる際の色の扱いを確認します。座標だけを平均化して色を計算しなければ、新しい点にRGBが付かない可能性があります。近傍色の平均を使う場合でも、境界部分の色が混ざり、全体が薄く見えることがあります。点数削減後の座標だけでなく、RGB属性の保持方法も検証します。
座標系変換そのものは主に位置を扱う処理ですが、変換ツールが新しいOBJを書き出す際にRGB列を再出力しなければ、色は失われます。元データから色が消えたのではなく、変換後ファイルへコピーされていない状態です。変換前後でv行の列数とRGB分布を比較すると確認できます。
圧縮ファイルを使う場合は、OBJ、MTL、テクスチャ画像など、元の表示方式に必要なファイルが揃っているかも確認します。ただし、色がv行のxyzrgbとして直接保存されている場合、RGBのためだけに外部画像を必要とするわけではありません。関連ファイル不足で白くなる場合は、頂点色ではなくMTLやテクスチャによる色付けだった可能性があります。
変換前後のファイルを取得できる場合は、同じ座標付近のv行を比較します。変換前が6値、変換後が3値なら、RGBが工程内で省略されたと判断できます。変換後ファイルを確認できない場合は、少数点の検証データ、処理ログ、属性一覧、表示モードを利用して切り分けます。
内部データの容量が元OBJより小さいだけでは、RGB削除と断定できません。圧縮、数値精度、点数削減、バイナリ化でも容量は変わります。容量差は補助情報に留め、属性の有無を直接確認できる方法を優先します。
OBJファイル内のRGB記述を確認する方法
頂点色が消えたときは、最初に書き出し直後のOBJへRGBが含まれているか確認します。ここを確認せずにアップロード設定だけを変更すると、書き出し時点で色が失われていた問題を見落とします。
OBJはテキスト形式なので、内容を確認できます。ただし、大規模な点群OBJを一般的な編集画面で全件読み込むと、動作が重くなることがあります。その場合は、先頭、中間、末尾の行を抽出する方法や、v行のトークン数だけを集計する方法を使います。
確認対象は、行頭がvと半角空白で始まる頂点行です。vnは法線、vtはテクスチャ座標、vpはパラメータ空間頂点なので、単純にvの文字だけで検索すると取り違える可能性があります。
vの後ろに3値があればXYZ、4値なら標準上はXYZWの候補、6値ならxyzrgb拡張の候補です。7値以上は、W、RGB、アルファ、その他属性のどれを含むかをOBJだけで決められません。出力元の仕様を確認します。
次に、後半3値の範囲と分布を確認します。0から1以内か、0から255相当か、全頂点で同一か、場所に応じて変化するかを見ます。すべての頂点が次のように1 1 1で終わる場合、xyzrgbとして解釈する環境では白に相当します。
v 12.10 8.50 3.20 1 1 1
すべて0 0 0なら、同じ解釈では黒に相当します。
v 12.10 8.50 3.20 0 0 0
ただし、4番目以降をRGBとして扱う根拠がないファイルでは、この判断を適用できません。列数だけでなく、出力仕様と元データを照合します。
先頭数行だけでなく、ファイル全体の列数を集計します。6値行と3値行が混在している場合、色付き点と色なし点が混在している可能性があります。不足行が特定範囲へ集中しているなら、色付け処理の対象外、撮影画像不足、変換途中の欠損などを調べます。
p行も確認します。点要素が定義されている場合は、v行の頂点数を超える参照、0番参照、数値以外の参照がないかを調べます。p行がない場合は、アップロード先が未参照のv行を点として描画する仕様か確認します。
RGBの順序を確認するには、元データで明確な色を持つ場所と座標を対応させます。赤い対象付近で最初の色成分が高く、残りが低ければRGB順の可能性が高まります。対応付けが難しい場合は、赤、緑、青、白、黒を意図的に設定した少数点の検証ファイルを作ります。
文字コードや改行も確認対象ですが、XYZが正常に読み込まれているのにRGBだけが消える場合は、まず頂点色拡張への対応、列数、値域、点要素、表示モードを優先します。問題の可能性が高い順に確認すると、不要な再変換を減らせます。
頂点色とMTL・テクスチャ画像の違い
点群OBJの色を確認するときは、頂点色、MTLの材質色、テクスチャ画像を区別します。画面上では同じように色付きで見えても、色の保存場所と読み込み方法が異なります。
頂点色は、各頂点へRGBを関連付ける方法です。OBJで使われるxyzrgb拡張では、v行の座標後ろにRGBを追加します。点ごとに色を保持しやすい一方、元来のOBJ仕様ではなく、読み込み側の対応が必要です。
MTLは、OBJからmtllibで参照する材質ライブラリです。OBJ内のusemtlで、後続の要素へ材質名を関連付けます。元来のOBJでは、色やテクスチャなどの外観情報をMTLで扱う仕組みが用意されていますが、MTLや独自キーワードへの対応には実装差があります。([The Library of Congress][1])
テクスチャ画像は、vtで定義したテクスチャ座標とMTL内の画像参照を組み合わせ、主に面へ画像を対応させる方法です。OBJ、MTL、画像、参照パスのいずれかが不足すると、形状だけが白く表示される可能性があります。
点だけで構成されたデータでは、面へ貼るテクスチャと、各点が持つ頂点色を同じようには扱えません。p要素へ材質を適用できるか、点表示で材質色を使うかは読み込み側の実装に依存します。点群の色を点ごとに保持したい場合は、xyzrgbなどの頂点属性を保持できる組み合わせか、点群向けの別形式を検討します。
元の確認画面で色が見えていても、OBJへ頂点色として保存されているとは限りません。確認画面が元の点群データ、撮影画像、内部キャッシュ、別の属性を使って表示している場合、OBJ書き出し後にはRGBが含まれていないことがあります。
反対に、OBJ内にRGBがあっても、表示環境がMTLやテクスチャだけを色として使う場合は頂点色が見えません。複数の色方式が同時に含まれるときは、頂点色、材質色、テクスチャのどれが優先されるかも確認します。
点群を点のまま共有するのか、面を生成したモデルとして共有するのかによって、適した色の保持方法は変わります。受け渡し前に表示形態と色方式を決め、送信側と受信側で同じ条件を確認します。
点群OBJアップロード前に行う事前検証
頂点色の消失を防ぐには、本番データをアップロードする前に、小さな検証用OBJで動作を確認します。数百万点を含むデータで試行を繰り返すと、処理時間が長くなり、原因の切り分けも難しくなります。
検証用ファイルには、座標が異なる少数の頂点を用意し、明確なRGB値を設定します。0から1のxyzrgbを検証する例は次のとおりです。
v 0 0 0 1 0 0
v 1 0 0 0 1 0
v 2 0 0 0 0 1
v 3 0 0 1 1 1
v 4 0 0 0 0 0
p 1 2 3 4 5
p行を含めることで、v行だけを自動描画しない読み込み環境でも、点要素として認識されるかを確認できます。アップロード後に5点が赤、緑、青、白、黒として見えれば、その環境が少なくともこの列順、値域、点要素を解釈できる可能性があります。
次に、出力元が0から255相当を使うことが確認できている場合に限り、同じ構成で値域を変えたファイルを試します。
v 0 1 0 255 0 0
v 1 1 0 0 255 0
v 2 1 0 0 0 255
p 1 2 3
両方のファイルを比較すると、値域の扱いを判断しやすくなります。ただし、仕様が分からないまま本番データを0から255へ変更することは避けます。検証ファイルは、本番ファイルを生成する処理と同じ列順、区切り、改行、点要素で作ります。
XYZRGBとXYZWRGBを混在させず、必要なら別々の検証ファイルを作ります。アルファ付きとされる7値形式も、出力元と読み込み先が対応を明記している場合だけ独立して試します。条件を一つずつ変えれば、どの差が表示結果へ影響したかを判断できます。
検証点は同じ座標へ重ねず、X方向またはY方向へ一定間隔で配置します。点が重なると、どの色が表示されているか判別しにくくなります。点サイズと背景色も固定し、比較条件をそろえます。
本番データについては、アップロード前にv行数、6値行数、3値行数、4値行数、その他列数の行数、p行の参照範囲、RGB値域外の件数、不正数値の件数を確認します。頂点数とRGB付き行数が一致していても、p行が一部頂点しか参照していない場合は、表示対象の点数が一致しない可能性があります。
ファイルを圧縮してアップロードする場合は、圧縮前と展開後のOBJが同一かを確認します。通常の圧縮でテキスト内容が変わることは想定しにくいものの、圧縮前後に自動変換やファイル整理が入る運用では、OBJが再生成されることがあります。
ファイル名やフォルダ名は、MTLやテクスチャ画像の参照に影響する場合があります。しかし、頂点色がv行へ直接記録されているなら、ファイル名変更だけでRGB列が復元する可能性は高くありません。問題の色方式に合わせて確認順を決めます。
頂点色が消えたときの切り分け手順
点群OBJをアップロードして色が消えた場合は、書き出し、保存、アップロード、内部変換、表示の各工程を順番に確認します。複数工程を同時に疑うより、各段階の結果を比較した方が原因を特定しやすくなります。
最初に、書き出し直後のOBJへRGB候補があるか確認します。v行がXYZだけなら、その行に頂点色はありません。XYZWの4値なら、4番目をRGBと解釈せず、Wまたは独自属性として出力仕様を確認します。XYZRGBの6値なら、頂点色拡張の候補として値域と分布を調べます。
次に、すべてのv行の列数を集計します。3値、4値、6値、7値以上が混在していないか、不足行や数値以外の文字がないかを確認します。RGB候補が全行で同じ値になっていないかも見ます。
点群としての要素も確認します。p行があるなら参照番号が有効か、すべての表示対象頂点を参照しているかを調べます。p行がない場合は、アップロード先が未参照頂点を点として扱うか確認します。
元ファイルに問題がなければ、同じOBJを別の確認環境で表示します。別環境で色が出れば、元OBJに頂点色が保持されており、アップロード先の対応形式、内部変換、表示設定のいずれかに原因がある可能性が高まります。複数環境で色が出ない場合は、RGB記述、値域、点要素、材質設定を再確認します。
続いて、少数点の検証ファイルをアップロードします。小規模ファイルでも色が出ないなら、データ容量よりも拡張記述への非対応や表示設定を疑います。小規模ファイルでは表示され、本番ファイルだけ色が消える場合は、途中の不正行、列混在、点数上限、軽量化、属性削除を調べます。
アップロード後の表示モードも確認します。頂点色ではなく、高さ、分類、反射値、単色、材質色などが選ばれていると、RGB属性が存在しても元の色は見えません。点サイズが小さすぎる場合や、黒い点を暗い背景へ表示している場合も、色が消えたように見えることがあります。
表示設定を変えても色が出ず、元OBJは別環境で正常なら、内部変換を確認します。頂点属性を保持する設定、点群として処理する設定、色属性を含める設定があるかを調べます。変換後の属性一覧を確認できる場合は、RGBまたはColor属性が残っているかを直接確認します。
再アップロードでは、一度に複数条件を変更しません。RGB値域、列順、Wの有無、p行、圧縮方法、表示モードを同時に変えると、どの修正が有効だったか分からなくなります。一つの条件だけを変えた検証ファイルと結果を記録します。
点群の色を維持するための運用ルール
頂点色の消失を繰り返さないためには、OBJを書き出す担当者とアップロードする担当者の間で、データ条件を共有します。「OBJで渡す」という合意だけでは不十分です。点群としての要素、頂点色の拡張形式、RGB値域、Wやアルファの有無、表示モードまで決めます。
まず、頂点行の標準形を決めます。たとえば、v X Y Z R G Bとし、RGBは0から1の小数で統一する、といったルールです。ただし、受け渡し先が別形式を必要とする場合は、その仕様へ合わせます。Wを使う場合は、xyzrgbと混同しないよう、列の意味を文書化します。
点群をOBJの点要素として渡す場合は、p行を含めるか、v行だけを受信側が点として扱えることを事前に確認します。p行を使うなら、頂点番号が1から始まること、参照範囲がv行数を超えないことを検査します。
数値の区切りは半角空白、小数点はピリオドへ統一します。座標とRGBの桁数を検査しやすい形式へそろえる方法はありますが、不要な丸めで座標精度や色の階調を損なわないようにします。
RGBがない点の扱いも決めます。色なし点を残す、除外する、未取得を示す特定値へ置く、近傍から補間するなどの方法がありますが、補間すると実際には色を取得していない領域まで撮影済みのように見える可能性があります。色の欠損と推定色を区別できる運用が安全です。
アップロード先ごとに検証済み条件を記録します。同じOBJでも、xyzrgb、p要素、MTL、テクスチャへの対応は異なります。使用した列構成、RGB値域、点数、p行、変換設定、表示モード、検証日を残せば、環境更新後の再確認にも使えます。
元データ、書き出し直後のOBJ、アップロード用に加工したOBJを分けて保存します。加工後だけを残すと、RGBがどの工程で消えたか追跡できません。工程名や作成日をファイル名へ含め、上書きを避けます。
点群の一部を切り出した検証データも保管します。アップロード環境の更新、変換処理の変更、表示機能の更新があったとき、同じファイルで頂点色と点要素の対応状況を再確認できます。
点群の色は、地面、構造物、植生、資材などを目視で判別するための重要な情報です。ただし、頂点色は照明、影、反射、撮影条件、色補正の影響を受けます。色が保持されていることと、現物の色を測定値として厳密に再現していることは分けて評価します。
現地で点群を取得してからアップロードや共有まで行う運用では、最終画面だけでなく、取得、色付け、OBJ書き出し、加工、転送、内部変換、表示の流れを確認します。LRTK Phoneを利用する場合も、書き出したOBJをどの環境へ渡すのか、頂点色、点要素、座標情報が受け渡し先でどのように扱われるのかを小規模データで事前に検証すると、手戻りを抑えやすくなります。
まとめ
点群OBJをアップロードしたあとに頂点色が消える原因は、主に4つに整理できます。アップロード先がxyzrgbなどの頂点色拡張へ対応していないこと、RGB値域が出力側と読み込み側で一致していないこと、v行の列構成やp行の点要素が正しく解釈されていないこと、アップロード後の変換工程でRGB属性が削除されることです。
元来のOBJ仕様では、頂点行はXYZと任意のW成分を扱い、頂点ごとのRGBは標準項目ではありません。実務で使われるv X Y Z R G Bは拡張記述であり、ソフトウェアごとの対応確認が必要です。また、点群をOBJで表す場合は、未参照のv行を自動的に点表示する実装だけに依存せず、点要素pの扱いも確認します。
まず書き出し直後のOBJを調べ、v行の列数、RGB候補の値域、列の混在、不正値、p行の参照を確認します。元ファイルが正常なら、赤、緑、青などを設定した少数点の検証OBJを使い、アップロード先の頂点色対応、点要素、表示モード、内部変換を順番に切り分けます。
OBJへRGBらしい数値が書かれていることと、アップロード後に頂点色が表示されることは同じではありません。出力側と読み込み側が、同じ拡張形式、値域、列構成、点要素、表示条件を採用して初めて、点の位置と色を安定して受け渡せます。
本番データを受け渡す前に、小規模な検証用OBJで結果を確認し、検証済み条件を運用ルールとして残すことが、頂点色の消失を防ぐ現実的な対策です。現場での点群取得からデータ確認、共有までの作業を一連の流れとして整理する場合は、LRTK Phoneを含む取得環境と受け渡し先の組み合わせを実データで検証し、色と座標の両方が維持されることを確認します。