点群OBJで頂点色が反映されない主な理由
点群データをOBJ形式で書き出し、クラウドやWeb上のビューアへアップロードしたとき、座標は読み込まれているのに頂点ごとの色が反映されないことがあります。点群全体が白色や灰色になったり、意図しない単色で描画されたりする場合は、OBJファイル内のRGB記述だけでなく、読み込み側の対応仕様や表示設定も確認する必要があります。
最初に押さえておきたいのは、OBJの原仕様で定義された幾何頂点の基本形が、v x y zまたは省略可能なwを含むv x y z wであることです。頂点座標の後ろへRGB値を追加するv x y z r g bは、原仕様に含まれる正式な頂点色構文ではなく、複数のソフトウェアで採用されてきた拡張的な慣例です。そのため、同じOBJ対応ソフトウェアでも、頂点色まで解釈できるとは限りません。The Library of Congress
頂点色を含める慣例では、例えば赤い頂点をv 10.0 20.0 30.0 1.0 0.0 0.0のように記述します。広く紹介されている方式では、RGBの各成分を0から1の範囲で表します。0から255の整数を扱える実装もありますが、OBJ頂点色の共通仕様として保証されているわけではありません。アップロード先がどの範囲を受け付けるかは、サービスの仕様書または小さな試験ファイルで確認する必要があります。The Library of Congress
また、点群として扱いたいOBJがv行だけで構成されている場合にも注意が必要です。v行は頂点を定義しますが、原仕様には点要素を表すp行もあります。ビューアによってはv行だけでも点として描画しますが、頂点が定義されているだけでは表示対象の要素がないと判断する実装もあります。点群OBJの対応可否を確認するときは、面を表すf行の有無だけでなく、p行を使った点要素に対応しているか、v行のみを点群として扱う独自仕様があるかを確認します。The Library of Congress
頂点色が表示されない問題を解決するには、RGB値の有無だけを見るのではなく、読み込み側の頂点色対応、頂点行の構造、RGB値の範囲、座標と色の対応関係、アップロード後の表示設定という五つの観点から順番に切り分けることが重要です。
RGB記述チェック1｜読み込み側が頂点色に対応しているか
最初に確認するのは、点群OBJをアップロードする環境が、OBJの頂点色拡張を解釈できるかどうかです。ここを確認せずに数値や列構造を何度も修正しても、読み込み側が座標だけを取得する仕様であれば表示結果は変わりません。
OBJ形式への対応が案内されていても、OBJ内のすべての要素や拡張に対応しているとは限りません。座標と面だけを読み込む処理、テクスチャ座標や法線まで読み込む処理、MTLによる材質やテクスチャを利用できる処理、頂点座標の後ろに追加されたRGB値を解釈できる処理など、対応範囲には差があります。OBJの原仕様に頂点色が含まれていないため、頂点色の互換性は特に実装差が出やすい部分です。The Library of Congress
読み込み処理によっては、v行の先頭にある三つの座標値だけを取得し、後ろのRGB値を無視します。別の処理では、四つ目の値を原仕様のwとして解釈する可能性があります。さらに、頂点色拡張を認識する処理でも、0から1のRGBだけを受け付ける場合や、点要素ではなく面を持つメッシュに限って頂点色を表示する場合があります。
対応状況を調べるには、少数の頂点だけを含む試験用OBJを作成すると効率的です。数百万点の実データを毎回アップロードすると、処理時間が長くなり、結果も確認しにくくなります。赤、緑、青、白、黒など違いが明確な数点を離れた座標に配置し、それぞれへ0から1のRGB値を割り当てます。
試験時は、v行だけの版、p行で各頂点を点要素として参照する版、必要に応じて小さな三角形面を持つ版を分けて作ると、どの構造が受け付けられるかを確認できます。各点が異なる色で表示されれば、読み込み側は少なくともその記述方法と数値範囲を解釈できると判断できます。
すべての点が同じ色になる場合は、頂点色が無視されている可能性があります。ただし、単色表示や高さ別表示など別の表示属性が選択されている可能性もあるため、ファイル側だけを原因と決めつけないことが大切です。
試験用OBJでは頂点色が表示されるのに、本番の点群だけ色が反映されない場合は、本番ファイルの列構造、数値範囲、不正値、点要素の記述、ファイル容量などを確認します。この切り分けにより、サービス側の仕様とデータ側の問題を混同せずに調査できます。
アップロード後に内部形式へ変換される環境では、入口のファイル形式だけで判断しないことも重要です。OBJを受け付けていても、内部変換で座標だけが保持され、頂点色が表示用データへ引き継がれない場合があります。これはサービスごとの実装によるため、元OBJを別の対応ビューアで確認し、アップロード前後で結果を比較します。
まず小さな基準ファイルで読み込み側の対応範囲を確かめ、問題がOBJの記述にあるのか、アップロード先の仕様にあるのかを明確にすることが第一歩です。
RGB記述チェック2｜頂点行の列数と並び順が正しいか
読み込み側が頂点色へ対応していることを確認したら、OBJ内の頂点行を調べます。頂点色拡張として広く使われる並びは、v x y z r g bです。ただし、原仕様の頂点行には省略可能なwがあるため、四つ目以降の値をどのように解釈するかは読み込み側に依存します。頂点色対応が明記されていない環境へ、独自にv x y z w r g bのような混合形式を渡すと、列の意味が一致しない可能性があります。The Library of Congress
変換元の形式によっては、座標とRGBの間に反射強度、分類値、点番号、信頼度などの属性が含まれています。それらをそのままv行へ追加しても、OBJ側が属性名を持たないため、読み込み側は各列の意味を判別できません。OBJへ変換するときは、アップロード先が想定する列だけを、決められた順番で出力します。
RGBの並び順にも注意します。頂点色の一般的な慣例は赤、緑、青の順です。一方、変換元の画像処理ライブラリや点群データでは、内部的に青、緑、赤の順で保持していることがあります。元データの配列順を確認せずに書き出すと、赤と青が入れ替わります。
赤と青の入れ替わりを確認するには、元データ内で明確に赤い地点を一つ選び、その地点に対応するOBJの色成分を確認します。元の赤成分がOBJの最後の列へ入っている場合は、BGRからRGBへの並べ替えが必要な可能性があります。
頂点行ごとの列数が統一されているかも重要です。ある行がv x y z r g bで、別の行がv x y zだけになっていると、色を持つ頂点と持たない頂点が混在します。読み込み処理によっては、色のない点へ既定色を割り当てますが、異なる列数を不正として扱う実装もあります。
変換中にRGBの一部が欠損すると、列数が不足することもあります。空欄を区切りとして保持しない処理では、後続値が前へ詰まり、本来の色成分とは異なる位置に入ります。欠損値がある場合は、該当点を座標と色の両方から除外するか、決めた既定色で補うかを統一し、最終的な頂点行の列数をそろえます。
区切り文字も確認します。OBJは行単位のテキスト形式で、値は通常、ASCIIの空白類で区切られます。全角空白、カンマ区切り、見えにくい特殊空白が混ざると、読み込み側が正しく分割できないことがあります。10.0,20.0,30.0のような記述は、OBJの一般的な頂点記述とは異なります。
大容量の点群OBJでは、すべての行を目視することは現実的ではありません。先頭付近だけでなく、ファイルの中間と末尾からもv行を抜き出し、数値の個数と形式を確認します。複数ファイルの結合や分割で問題が起きた場合、先頭は正常でも途中から構造が変わっていることがあります。
自動検査できる場合は、v行ごとの数値数を集計します。座標だけの三値、座標とRGBの六値、その他の個数がそれぞれ何行あるかを調べると、列数の混在を発見しやすくなります。ただし、六値だから必ずRGBとして正しいとは限りません。読み込み側が頂点色拡張として認識することまで確認する必要があります。
p行を使用する場合は、参照している頂点番号が存在するかも確認します。OBJの要素は先に定義された頂点を番号で参照します。範囲外の番号や、分割後に更新されていない番号があると、点要素の一部が欠ける可能性があります。The Library of Congress
RGB記述チェック3｜RGB値の範囲と数値形式が合っているか
三つ目の確認項目は、RGB値の範囲です。OBJの頂点色拡張として広く説明されている方式では、赤、緑、青の各成分を0から1の値で記録します。黒は0 0 0、白は1 1 1、赤は1 0 0、中間の灰色は0.5 0.5 0.5です。The Library of Congress
0から255の整数を出力するソフトウェアや、それを受け付ける読み込み処理もありますが、すべてのOBJ対応環境で共通に使えるとは限りません。0から255の値をそのまま渡したとき、上限へ丸める、255で正規化する、色列を無効とする、頂点行を不正と判断するなど、結果は実装によって変わります。
そのため、点群全体が白く見えるからといって、必ず0から255を0から1として解釈したとは断定できません。全体が黒く見える場合も同様です。RGB範囲の不一致は代表的な候補ですが、頂点色の無視、材質や照明、単色表示など別の原因も並行して確認します。
数値範囲を見分けるときは、先頭数行だけで判断しないことが大切です。黒い点では、どちらの方式でも0 0 0になります。RGB全体の最小値と最大値を集計し、最大値が1付近なのか255付近なのか、範囲外の値が混じっていないかを調べます。
0から255の値を0から1へ変換する場合は、各成分を255で割ります。例えば128 64 32は、おおよそ0.502 0.251 0.125となります。変換後は、アップロード先が必要とする小数精度を保ちます。小数点以下を削りすぎると、0と1に近い値へ丸められ、色の階調が大きく失われます。
小数値を整数として保存する設定にも注意が必要です。0から1のRGB値を小数点以下なしで出力すると、多くの色成分が0または1になり、極端な色だけが残ります。変換処理では、座標列とRGB列に別々の数値書式を指定できるか確認します。
小数点記号はピリオドを使用します。地域設定の影響で0.5が0,5として出力されると、OBJの一般的な数値表現として正しく解釈されない可能性があります。座標値とRGB値の両方で同じ問題が起こり得ます。
指数表記については、浮動小数点として受け付ける処理もありますが、すべてのアップロード先で互換性が保証されるわけではありません。RGB列に1e-05などが含まれているときに問題が起きる場合は、通常の小数表記へ変換した試験版を作り、結果を比較します。
RGB値にNaN、Inf、欠損を示す文字列、負の値、1を超える値が含まれていないかも確認します。読み込み側が値を丸めるとは限らず、該当行を無視したり、色属性全体を破棄したりする可能性があります。異常値を補正するときは、発生理由を確認し、正常範囲へ機械的に押し込むだけでよいかを判断します。
RGB値を修正するときは、元ファイルを直接上書きせず、別名で保存します。0から1へ正規化した版、元の値を維持した版、異常値を除外した版を分けて試験すると、どの変更が結果へ影響したかを追跡しやすくなります。
RGB記述チェック4｜頂点座標と色情報が対応しているか
四つ目の確認項目は、頂点座標とRGB値の対応関係です。頂点色拡張では、一つのv行に一つの座標と一組のRGBを記述します。RGB値の件数が座標数と一致していても、並び順がずれていれば正しい色にはなりません。
元データからOBJを作成する段階で、座標とRGBを同じレコードとして扱っていれば、行全体を並べ替える限り対応関係は維持されます。問題になるのは、座標列とRGB列を別々に並べ替え、後から行番号だけで再結合した場合です。
例えば、座標だけをX座標の小さい順に並べ替え、RGBを元の順番のまま結合すると、各点へ別地点の色が割り当てられます。この状態では色自体は表示されるため、単純なRGB有無チェックでは発見できません。地面に空の色が混ざったり、壁面に樹木の色が付いたりして、細かな斑点状に見えることがあります。
ノイズ除去も対応ずれの原因になります。座標データから一部の点を削除したとき、同じ点に対応するRGBを削除しなければ、削除位置以降の色がずれます。点群の途中から色が乱れる場合は、座標とRGBに同一の選択マスクが適用されているかを確認します。
ダウンサンプリングで点数を減らす場合も、選択した点と同じRGBを残す必要があります。ボクセル内の代表点を新たに計算する方式では、元の一頂点を残すだけでなく、色を平均する、中央値を取る、代表点の色を採用するなどの方法があります。どの方法を使うにしても、座標生成と色生成を同じ処理単位で実行します。
複数の点群ファイルを結合する場合は、座標とRGBを同じ順序で連結します。結合前の各ファイルについて、頂点数、RGBの有無、RGB範囲、列順を確認し、結合後の合計と一致するかを検証します。
変換前後の頂点数も比較します。元データよりOBJのv行が少ない場合は、変換途中で点が除外されています。意図した除外であっても、RGB側に同じ処理が適用されていることを確認します。OBJのv行が増えている場合は、重複出力や複数ファイルの重複結合がないかを確認します。
p行を使う点群OBJでは、v行の並びを変えた後にp行の頂点番号を更新しているかも重要です。座標とRGBが同じv行に残っていても、p行が古い番号を参照すると、意図した点が表示されません。
対応関係を確認するには、特徴的な地点を数点選んで追跡します。明るい標識、白い壁、濃い地面など、周囲と色が明確に異なる場所を選び、元データの座標とRGBを記録します。OBJ内の同じ座標に同じRGBが付いているかを確認すれば、並べ替えや削除によるずれを発見しやすくなります。
RGB値の最小値と最大値が正常であるにもかかわらず色が細かく乱れている場合は、数値範囲よりも座標とRGBの対応ずれを重点的に確認します。
RGB記述チェック5｜アップロード後の表示設定が正しいか
OBJファイル内のRGB記述が読み込み側の想定と合っていても、アップロード後の表示設定によって頂点色が見えないことがあります。ファイルを修正する前に、ビューアでどの属性が色として使用されているかを確認します。
点群の表示方法には、RGBによる頂点色だけでなく、高さ、反射強度、分類、距離、法線方向、単色などがあります。アップロード直後の初期設定が高さ別表示になっている場合、RGB情報が保持されていても、画面には高さに応じた色が表示されます。
表示属性を頂点色またはRGBへ切り替えたときに元の色が現れるのであれば、ファイル記述または内部変換は少なくとも頂点色を保持しています。この場合は、初期表示設定を見直します。
単色表示も確認します。点群全体へ指定色を割り当てる設定が有効になっていると、頂点ごとのRGBは画面へ反映されません。色選択欄やシェーダー設定で一色が指定されている場合は、頂点色を使用する設定へ変更します。
面を持つOBJでは、頂点色、材質色、テクスチャ、照明の合成方法がレンダラーによって異なります。頂点色と材質色を乗算する実装では、材質色が暗いと頂点色も暗く見えます。別の実装では、テクスチャや材質が頂点色より優先されます。確認時は、可能であればテクスチャや複雑な材質を一時的に無効にし、頂点色だけを表示して比較します。
照明や陰影処理にも注意します。点表示ではRGBをそのまま描画しても、面表示では法線、光源、陰影の影響を受けることがあります。RGBが正しいのに全体が暗い場合は、照明の影響を受けにくい表示モードやエミッション相当の表示へ切り替えて比較します。
透明度についても、実装ごとの確認が必要です。原仕様のv行に頂点アルファは定義されておらず、RGBの後ろに追加された値を透明度として扱うかどうかは拡張仕様によります。追加列があるだけで透明度と断定せず、アップロード先がRGBAを受け付けるか、値の意味と範囲が明記されているかを確認します。
点サイズも表示結果へ影響します。点が小さすぎると背景色の割合が大きくなり、色が薄く見えることがあります。点サイズを一時的に大きくし、背景色を変えると、頂点色の有無を判断しやすくなります。
大容量データでは、アップロード後に内部変換や階層化が行われることがあります。処理途中のプレビューと完了後の表示が異なるサービスもありますが、これは共通のOBJ仕様ではなくサービス固有の動作です。処理状態、属性一覧、変換ログを確認できる場合は、RGB属性が保持されているかを調べます。
修正済みOBJを再アップロードしたのに表示結果が変わらない場合は、同名ファイルのキャッシュや既存データの再利用も候補になります。ただし、これもサービス固有の挙動です。修正条件が分かる別名でアップロードし、旧版と新版を並べて比較します。
アップロード後の属性一覧にRGBや頂点色が存在しなければ、読み込みまたは内部変換の段階で色情報が利用されなかった可能性があります。属性が存在するのに色が表示されなければ、表示属性、材質、照明、透明度、点サイズを重点的に確認します。
点群OBJをアップロードする前の確認手順
点群OBJの頂点色トラブルを効率よく解決するには、元データ、OBJ変換、アップロード、表示設定を一度に変更しないことが重要です。複数の条件を同時に変えると、どの修正が有効だったのか分からなくなります。
最初に元の点群データを確認します。座標だけでなく、各点にRGB値が存在するかを調べます。元データに色情報がなければ、OBJの記述を変更しても撮影時の色は復元できません。
元データについては、点数、RGB値の最小値と最大値、欠損値、NaNやInfの数を確認します。最大値が1付近であれば0から1、255付近であれば0から255で保持されている可能性がありますが、最終的には出力設定とデータ型を確認します。
次にOBJへ変換した直後のファイルを確認します。vで始まる行に座標とRGBが記録されているか、列数が統一されているか、原仕様のwと頂点色拡張が混在していないかを調べます。先頭だけでなく、中間と末尾の行も確認します。
点群としてp行を出力する場合は、p行の参照番号が有効かを確認します。v行のみを点群としてアップロードする場合は、その構造がアップロード先で明示的にサポートされているかを確認します。
変換処理が途中で停止した場合、先頭部分は正常でも末尾が欠けていることがあります。ファイル末尾の行が途中で切れていないか、最後まで正常な改行単位で出力されているかを確認します。
その後、数点だけを含む試験用OBJを作成します。赤、緑、青だけでなく、0.5 0.25 0.75のような中間値も含めると、RGB範囲や階調を確認しやすくなります。必要に応じてv行のみ、p行あり、面ありの三種類を作ります。
試験用OBJが正しく表示されれば、読み込み側の頂点色対応と基本的なRGB形式を確認できます。本番データだけ失敗する場合は、ファイル容量、不正行、列数のばらつき、RGB欠損、参照番号の不整合などを調べます。
大容量による問題が疑われる場合は、本番データを点数の異なる複数の試験ファイルへ分けます。少ない点数では成功し、一定規模を超えると失敗する場合は、サービスの容量上限、処理時間、内部変換の制約が関係している可能性があります。
ファイルを分割するときは、頂点行の途中で切らないようにします。p行やf行を含む場合は、単純に行を分割するだけでは参照番号が不正になるため、各分割ファイル内で参照先を再構成します。
アップロード後は、最初に頂点色表示へ切り替えます。その後、材質、テクスチャ、照明、透明度、点サイズを一項目ずつ確認します。変更内容と結果を記録しておけば、再現条件を整理できます。
修正したOBJは元ファイルと別名で保存します。ファイル名にはRGB範囲、点数、p行の有無、修正内容などを含めると、どの条件で作成したデータなのかを判断しやすくなります。
症状別に見る頂点色トラブルの切り分け方
点群全体が白く表示される場合は、0から255のRGB値を0から1として扱った可能性があります。ただし、値が上限へ丸められたとは限らず、頂点色が無視され、既定色の白が使われている場合もあります。材質色、単色表示、明るさ設定も確認します。
点群全体が黒く表示される場合は、0から1のRGB値を0から255相当として扱った可能性があります。また、0から1の小数を整数として保存し、多くの値が0へ丸められていないかも調べます。照明不足や暗い材質色も候補です。
赤と青が入れ替わっている場合は、RGBとBGRの列順を確認します。変換元ライブラリの配列順と、OBJへ出力する順番が一致しているかを調べます。
一部の点だけ白や灰色になる場合は、そのv行にRGB値が存在するか、列数が他の行と同じかを確認します。複数データを結合した際に、RGBを持たないファイルが混在していないかも確認します。
点群の途中から色が乱れる場合は、座標だけが削除されたり、RGBだけが欠損したりして、対応関係がずれた可能性があります。色が乱れ始める付近の行番号と、直前に実行したフィルタリングや結合処理を確認します。
全体が細かい斑点状になる場合は、座標とRGBを別々に並べ替えていないかを確認します。RGB値の範囲が正常でも、別地点へ割り当てられると不自然な色分布になります。
色が薄い場合は、透明度、背景色、点サイズ、色空間変換、照明を確認します。白い背景に小さい点や半透明表示を重ねると、頂点色が正しくても淡く見えることがあります。
アップロード前は色が見えるのに、アップロード後だけ単色になる場合は、アップロード先が頂点色拡張を解釈していないか、内部変換でRGB属性を保持していない可能性があります。少数点の基準OBJでも同じ結果になるかを確認し、容量の問題と仕様の問題を切り分けます。
アップロード直後と処理完了後で表示が異なる場合は、サービス固有のプレビュー処理や内部変換が関係している可能性があります。処理完了の表示、変換ログ、属性一覧を確認します。
色は表示されるものの元データより暗い場合は、照明、材質色、陰影、ガンマや色空間の扱いが影響している可能性があります。RGB値だけを変更する前に、照明の影響を受けにくい表示で比較します。
点群の一部が消え、同じ範囲の色も見えない場合は、RGBではなく座標、p行の参照、表示範囲の問題かもしれません。極端な座標、不正な数値、範囲外の参照番号によって、頂点または点要素が読み込まれていない可能性があります。
RGB情報を維持するための変換と管理のポイント
頂点色の問題を繰り返さないためには、OBJへの変換条件を統一することが重要です。担当者や作業時期によってRGB範囲や列構造が変わると、同じアップロード手順でも結果が安定しません。
まず、社内で使用する頂点行の形式を決めます。アップロード先が頂点色拡張に対応していることを確認した上で、v x y z r g bを使用するのか、別形式を使うのかを明文化します。原仕様のwを同時に使う必要がある場合は、頂点色と競合しない別形式を検討します。
RGB値の範囲も統一します。一般的な頂点色拡張に合わせる場合は0から1へ正規化します。アップロード先が0から255を明示的に受け付ける場合だけ、その条件を記録して使用します。範囲を推測で決めず、基準ファイルで確認します。
小数点以下の桁数も一定にします。必要以上に長い小数はファイル容量を増やしますが、短くしすぎると色の階調が失われます。頂点色として必要な精度とファイル容量のバランスを考えて設定します。
元データは必ず保存します。OBJへの変換で削除された属性や欠損した色情報を、OBJだけから復元できるとは限りません。座標、RGB、点の識別情報、分類、反射強度などを持つ元データを残しておけば、別の条件で再変換できます。
変換条件も記録します。入力ファイル、出力日時、使用した変換ツールとバージョン、RGB範囲、点数削減の有無、座標変換、欠損値の処理、列順、p行の生成方法などを残します。
アップロード用に点数を削減する場合は、座標とRGBを同じレコードまたは同じ選択マスクで扱います。座標だけを抽出した後からRGBを結合する方法は、対応ずれの原因になります。
複数の点群を結合する場合は、結合前にRGB形式を統一します。一つのファイルが0から1、別のファイルが0から255では、結合後の表示が不均一になります。列数、列順、数値範囲、欠損処理、点要素の作り方をそろえてから結合します。
アップロード前の検査項目を定型化することも有効です。頂点数、v行の数値数、RGBの最小値と最大値、NaNやInf、欠損値、ファイル末尾、p行の参照範囲などを毎回確認します。
少数点の基準ファイルを用意しておくと、アップロード先の設定変更や処理更新があった場合にも、頂点色対応をすぐに確認できます。同じ基準ファイルを定期的に利用すれば、データ側の変化と表示環境側の変化を区別できます。
頂点色を確実に保持する必要があり、アップロード先がOBJの拡張へ対応していない場合は、頂点属性を明示的に定義できるPLYなど、別形式の利用を検討します。形式を変更するときも、アップロード先が色付き点群としてその形式を受け付けるかを事前に確認します。PLYは頂点のプロパティをヘッダーで定義できるため、RGBなどの属性構造をOBJより明示しやすい形式です。The Library of Congress
OBJは内容を直接確認しやすい反面、大容量になると手作業での検査が難しくなります。列数や範囲、欠損値、参照番号は自動検査し、人は異常値の原因と表示結果の判断へ集中する運用が効率的です。
まとめ
点群OBJの頂点色が反映されない場合は、OBJ内にRGB値が存在するかだけでなく、その記述がアップロード先の実装で解釈されるかを確認する必要があります。
最初のチェックは、アップロード先がOBJの頂点色拡張と点群表示に対応しているかどうかです。OBJの原仕様では幾何頂点はv x y zまたはv x y z wで定義され、頂点座標の後ろへRGBを追加する方式は後から広まった慣例です。OBJ対応と記載されていても、頂点色まで利用できるとは限りません。The Library of Congress
二つ目のチェックは、頂点行の列数と並び順です。座標の後ろに赤、緑、青が正しい順序で並んでいるか、元データの補助属性や原仕様のwが混在していないか、行ごとの列数が統一されているかを確認します。
三つ目のチェックは、RGB値の範囲と数値形式です。頂点色拡張として広く使われるのは0から1ですが、0から255を扱う実装もあります。範囲外の値がどのように処理されるかは実装次第なので、仕様書または基準ファイルで確認します。
四つ目のチェックは、頂点座標とRGB値の対応関係です。ノイズ除去、並べ替え、ダウンサンプリング、ファイル結合などで座標と色を別々に処理すると、色が別の地点へ割り当てられます。
五つ目のチェックは、アップロード後の表示設定です。高さ別表示、単色表示、材質、テクスチャ、照明、透明度、点サイズなどによって、保持されている頂点色が見えないことがあります。
原因を調べるときは、少数点の試験用OBJを作成し、v行のみ、p行あり、必要に応じて面ありの条件を比較します。その後、元データ、OBJ変換、アップロード、表示設定の順に、一つずつ条件を切り分けます。
点群 OBJ アップロードを安定させるには、RGBの数値範囲、頂点行の列構造、点要素の記述、変換条件、検査項目を統一することが重要です。元データを残し、修正後のファイルを別名で管理すれば、色が失われた工程を追跡しやすくなります。
現場で取得した色付き点群を確認し、計測からデータ活用までの作業を効率化する方法を検討する際は、LRTK Phoneの活用もあわせてご確認ください。