点群OBJが透明になる仕組みを理解する
点群OBJをアップロードした後、地形や構造物が薄く透けて見える、裏側の形状が見える、一部だけ穴が空いたように表示されるといった現象が起こることがあります。書き出し元では正常でも、アップロード先で透明になる場合は、座標や形状だけでなく、材質、テクスチャ画像、変換処理、閲覧画面の表示方法まで含めて確認する必要があります。
OBJは、頂点座標、テクスチャ座標、頂点法線、面、線、点などをテキストで記録できる形式です。OBJから参照されるMTLには、材質名、色、反射特性、透明度、画像参照などを記述できます。OBJのmtllibがMTLファイルを指定し、usemtlが後続の形状へ適用する材質名を指定する仕組みです。DIRS
ただし、「点群OBJ」という呼び方で扱われるデータには、頂点だけを点として表示するものと、点群から生成した三角形などの面を含むものがあります。面を含むOBJの透明表示はMTLや面の向きが関係しやすく、頂点中心のOBJでは点の描画サイズ、合成方法、密度、閲覧側の点表示設定が関係することがあります。最初に、対象データが点だけなのか、面を持つメッシュなのかを確認しておくと切り分けがしやすくなります。
透明度に関係する代表的な記述は、MTLのdとmap_dです。dは材質のdissolve、すなわち不透明度に相当する係数で、仕様資料ではd 1.0が完全に不透明、d 0.0が完全に透明とされています。The Library of Congress
一方、Trは多くのソフトウェアやライブラリで透明度を表す代替記述として扱われますが、対応方法は読み込み側によって同一とは限りません。代表的な実装ではTrを1 - Trとして不透明度へ変換し、dはそのまま不透明度として読み取っています。GitHub
テクスチャ画像のαチャンネルも表示へ影響することがあります。ただし、色用画像を指定するmap_Kdのαチャンネルを透明度として利用するかどうかは、OBJとMTLの基本記述だけで一律に決まるわけではありません。アップロード先の変換処理やレンダラーが画像のαを利用する場合に限って、透明表示の原因になります。
また、透明に見える現象のすべてがα値によるものではありません。面の頂点順序が反転して裏面として除外される、重複面がちらつく、断面表示や透過表示が有効になっている、点の密度が低く背景が見えるといった場合にも、利用者には透明になったように見えます。
原因を短時間で特定するには、透明になる範囲と視点による変化を観察します。全体が均一に薄くなるのか、特定の材質だけ変化するのか、画像の模様に沿って抜けるのか、視点を反対側へ回したときだけ面が消えるのかによって、優先して確認する項目が変わります。
ここからは、点群OBJアップロード後に透明になる代表的な6つの原因と、確認時の注意点を解説します。
原因1｜MTLのd値が低く設定されている
点群OBJ全体や特定の部材が半透明になるときは、まずMTLファイルのdを確認します。dは材質の不透明度に相当する係数であり、一般的なMTLの扱いではd 1.0が不透明、d 0.0に近づくほど透明になります。
たとえば、d 0.5が設定されていれば、その材質は半透明として処理される可能性があります。ただし、最終的な見え方は、透明度用画像、色用画像のα、アップロード後の変換、描画順序などにも左右されます。
書き出し元で透明度を変更した記憶がなくても、材質を複製したときに以前の設定が残ったり、別形式からOBJへ変換したときに不透明度が引き継がれたりすることがあります。元画面で背景と重なって見えていたため、半透明に気づかなかったケースも考えられます。
全体が薄く透けている場合は、MTL内のdを検索し、1.0未満の値がないか確認します。材質が複数ある場合は、地面、壁面、設備、仮設物などの用途ごとに定義を確認します。
MTLでは、newmtlで材質定義が始まり、次のnewmtlまでが同じ材質の記述として扱われます。透明な部分だけを調べる場合は、OBJ内のusemtlで割り当てられている材質名を確認し、MTL内の対応するnewmtlを探します。
不透明にしたい材質でd 0.3などが設定されている場合は、原本を残したうえで検証用の複製ファイルを作り、d 1.0へ変更して表示を比較します。元データを直接上書きすると、修正前の条件へ戻せなくなるため、検証用データを分けて管理する方が安全です。
一方、ガラスや確認用の半透明面など、意図的な透明材質が含まれている場合は、一律にd 1.0へ変更してはいけません。透明にする材質と、不透明にしたい地形や構造物の材質を分けて修正します。
同じ材質定義の中にdが複数回ある場合は、どの値を採用するかが読み込み実装や記述順に左右されるおそれがあります。重複した透明度記述は整理し、意図する値を一つに絞る方が検証しやすくなります。
値の書式も確認します。通常は半角数字と小数点で記述します。全角数字、不要な記号、改行の欠落、別命令との連結があると、正しく解析されない可能性があります。
d 1.0へ変更しても透明表示が直らない場合は、Tr、map_d、色用画像のαチャンネル、閲覧側の表示設定など、別の要因が同時に働いていないかを確認します。
原因2｜Tr値の解釈がアップロード先と合っていない
MTLファイルには、透明度に関連する記述としてTrが含まれることがあります。多くの実装では、Tr 0.0を不透明、Tr 1.0を透明として扱い、dとは反対方向の値として解釈します。
ただし、Trはすべての読み込み環境で同じように処理されるとは限りません。MTL自体には実装差があり、古い機能や独自の拡張記述を無視する読み込み側もあります。MTLの互換性は完全ではなく、同じファイルでもソフトウェアによって材質の再現結果が異なることがあります。The Library of Congress
問題になりやすいのは、同じ材質にdとTrが併記され、その値が矛盾しているケースです。たとえば、d 1.0とTr 1.0が同時にあると、一方は不透明、もう一方は透明を示す組み合わせになります。
代表的な読み込み実装では、記述を読み取った順に同じ内部の不透明度へ格納することがあります。その場合、後に書かれた値が結果へ影響しやすくなりますが、すべてのアップロード先で同じとは限りません。したがって、「必ずdが優先される」「必ずTrが優先される」とは断定できません。
透明表現が不要な材質では、アップロード先の対応仕様を確認し、透明度の指定を一つに整理する方法が安全です。仕様が公開されていない場合は、原本を複製し、d 1.0だけを残した検証用データと、元データを比較します。
形状、UV、画像を変えず、透明度の記述だけを変更すれば、dやTrの影響を切り分けやすくなります。複数の項目を同時に変えると、どの変更が有効だったのか判断しにくくなります。
Trが意図せず出力される背景には、別形式からの変換、古い材質設定の引き継ぎ、複数ソフトウェア間の受け渡しなどがあります。変換を繰り返したデータでは、同じ意味を持つ記述が重複して残ることがあります。
一部だけ透明になる場合は、その部分へ割り当てられたusemtlをOBJ内で確認し、同名のnewmtlにTrが含まれていないか調べます。
手作業で修正するときは、命令名の大文字と小文字を不用意に変更せず、元の記述を保ちながら値だけを変えます。読み込み側によっては、仕様外の表記や大文字小文字の違いを受け入れる場合と受け入れない場合があります。
Trを削除または修正した後は、OBJのmtllibが修正済みのMTLを参照しているか確認します。別名の旧MTLを参照していれば、修正内容は反映されません。
原因3｜テクスチャ画像にαチャンネルが含まれている
MTLのdやTrに問題がなくても、アップロード先が色用テクスチャのαチャンネルを利用する実装であれば、画像側の透明度によって材質が透けることがあります。
αチャンネルは、画像の各画素に透明度を持たせる情報です。画像が通常の写真のように見えていても、内部に透明度が含まれている場合があります。画像表示ソフトが透明部分の背後へ白や黒を自動表示していると、見た目だけでは判断しにくいことがあります。
特に注意したいのは、画像全体に中間のα値が設定されているケースです。画像編集時にレイヤーの不透明度を下げた状態で書き出すと、すべての画素が半透明になることがあります。アップロード先がそのαを採用すれば、内部の面や背景が透けて見えます。
背景除去を行った画像にも注意が必要です。輪郭を切り抜く処理では、境界を滑らかに見せるために半透明画素が生成されることがあります。その結果、外周だけが薄く見えたり、遠距離表示で輪郭がぼやけたりする場合があります。
テクスチャ画像を確認するときは、透明部分を市松模様などで表示できる画像編集機能を使います。画像全体、外周、影、黒い部分、余白などに透明度が入っていないかを点検します。
ただし、map_Kdで指定した画像のαを無視する読み込み側もあります。画像にαチャンネルがあるだけで、必ず透明になるわけではありません。原因候補と判断するには、αなし画像へ差し替えた検証用データと比較する必要があります。
不透明なテクスチャとして使用する場合は、画像を不透明な背景へ統合し、αチャンネルを持たない形式または設定で書き出す方法があります。背景色によって輪郭に縁が出ることがあるため、実際の用途に合わせて確認します。
画像形式やファイル名を変更した場合は、MTL内のmap_Kdも更新します。画像だけを変更し、MTLが旧ファイルを参照したままだと、テクスチャが見つからず、透明度とは別の表示不具合につながります。
一部のレンダラーは、画像に透明画素が含まれる材質を透明描画の対象として扱います。透明描画では面の並べ替えや深度処理が不透明描画と異なることがあり、複雑なメッシュでは前後関係が不自然に見える場合があります。ただし、どの条件で透明材質へ分類されるかはアップロード先の実装によって異なります。
画像の色が薄いことと、透明であることは分けて考えます。明るい灰色や低彩度の画像は白っぽく見えますが、背景や奥側の面が見えていなければ透明とは限りません。背景色や視点を変え、実際に背後が透けているか確認します。
原因4｜map_dで透明度用画像が指定されている
MTLでは、透明度を画像で制御するためにmap_dを使用できます。元のMTL仕様では、map_dは材質のdissolveへ結び付くスカラーテクスチャとして説明されており、現在の代表的な読み込みライブラリでも透明度用テクスチャとして扱われています。Paul Bourke+1
d 1.0に設定されていても、map_dが参照されていれば、画素ごとの不透明度が変化する可能性があります。そのため、数値だけを修正しても透明表示が直らない場合は、map_dの有無を確認します。
意図せずmap_dが残る例として、透明材質を複製して地形用の材質を作った場合があります。色やmap_Kdだけを差し替え、透明度用画像の参照を削除し忘れると、新しい材質にも透明処理が残ります。
map_dが色用画像を誤って参照している場合にも問題が起こります。色用画像の明暗が不透明度へ使われると、影、文字、模様などに沿って表面が抜けることがあります。
一般的な扱いでは、map_dの明るい値ほど不透明側、暗い値ほど透明側として利用されます。ただし、利用するチャンネル、画像処理、反転設定、アップロード先の実装によって結果が変わる可能性があるため、実データで確認します。
透明表現を使用しない材質では、検証用ファイルからmap_dを外し、再アップロードして比較します。表示が不透明になれば、透明度用画像またはその参照が原因候補です。
map_dの参照先が存在しない場合の挙動は、読み込み側によって異なります。画像を無視して数値だけで描画する場合、警告や変換エラーになる場合、代替材質が使われる場合などがあり、「参照切れなら必ず不透明になる」とは限りません。
ファイル名の大文字と小文字、空白、記号、全角文字にも注意します。OSやアップロード先によってファイル名照合の厳密さが異なるため、手元では読み込めても、別環境では参照が切れることがあります。
OBJ、MTL、色用画像、透明度用画像は、できるだけ単純な階層で管理します。相対パスが深くなるほど、圧縮やアップロード時のフォルダ構成変更で参照が切れやすくなります。
透明度用画像を使う必要がある場合は、色用画像とは明確に区別できる名前を付けます。類似した名称を避けると、差し替えや整理の際の取り違えを減らせます。
原因5｜材質名や参照ファイルの対応が崩れている
OBJでは、usemtlによって後続の面や要素へ適用する材質を指定し、MTLではnewmtlによって材質を定義します。材質名が一致していないと、意図した定義を正しく参照できません。
材質が見つからない場合の挙動はアップロード先によって異なります。既定材質へ置き換える、材質を無視する、警告を出す、変換を中断するなどの可能性があります。したがって、材質名の不一致だけで必ず半透明になるとはいえませんが、元データと異なる見え方になる原因にはなります。
材質名を照合するときは、大文字と小文字、数字、記号、空白、全角と半角まで確認します。見た目が似ていても、文字列が一致しなければ別の材質として扱われる可能性があります。
材質名の末尾に見えにくい空白が付いているケースもあります。手作業で名称を変更した場合や、別形式から変換した場合は、先頭や末尾の不要な空白、制御文字、特殊記号が含まれていないか確認します。
一部だけ透明になる場合は、透明な面の直前にあるusemtlを調べます。その材質名と同じnewmtlをMTL内で確認し、d、Tr、map_d、map_Kdを点検します。
複数のMTLに同じ材質名が存在する場合も注意が必要です。読み込み側が材質名を一つの一覧へ統合する実装では、同名定義が衝突したり、先に読んだ定義または後に読んだ定義へ置き換わったりする可能性があります。すべての環境で衝突するとは限りませんが、用途や透明度が異なる材質には固有の名前を付ける方が安全です。
材質名を変更するときは、MTLのnewmtlだけでなく、OBJ内のusemtlも同じ名前へ変更します。片方だけを修正すると参照が切れます。
OBJのmtllibも重要です。mtllibには参照するMTLのファイル名が記載されます。修正したMTLをアップロードしても、OBJが旧版や別名のMTLを指定していれば変更は反映されません。
作業フォルダに旧版のMTLや同名画像が残っていると、誤ったファイルをアップロードする可能性があります。修正後は、アップロード用の新しいフォルダを作り、必要なOBJ、MTL、画像だけを入れると確認しやすくなります。
圧縮してアップロードする場合は、圧縮ファイル内の階層にも注意します。OBJとMTL、MTLと画像の位置関係が変わると、相対パスが一致しなくなることがあります。圧縮後のファイルを別の場所へ展開し、参照関係を再確認すると安全です。
原因6｜法線や表示設定の問題が透明に見えている
材質や画像に透明度が設定されていなくても、面の向き、重複面、表示設定によって透明に見えることがあります。α値を修正しても改善しない場合は、透明度以外の原因を確認します。
OBJの面の向きは、主にf行に記載された頂点の並び順によって決まります。頂点法線を表すvnは陰影計算に使われますが、一般的な背面除去で表裏を判定する基準は面の頂点順序とレンダラー側の規約です。頂点法線だけを反転すれば必ず背面表示が直るとは限りません。
アップロード先が裏面を描画しない設定の場合、裏側から見た面は表示されません。手前の面が消えると奥の面や背景が見えるため、半透明になったように感じられます。
視点を反対側へ回したときに面が現れる場合は、dや画像αよりも、面の頂点順序、面の向き、両面表示の設定を確認します。どの方向から見ても均一に薄く透ける場合は、透明度の問題である可能性が高くなります。
点群から面を生成したデータでは、複雑な凹凸、欠損部、薄い部材の周囲で面の向きが混在することがあります。面の一部だけが角度によって消える場合は、法線表示機能や面方向の検査機能を使って確認します。
重複した面も表示を不安定にする原因です。ほぼ同じ位置に複数の面が重なると、深度判定が安定せず、ちらつきや縞模様が発生します。これは半透明ではありませんが、視点移動時に薄く見えたり表面が欠けたりすることがあります。
閲覧画面の表示モードも確認します。透過表示、内部確認、断面表示、選択中の強調、比較表示などが有効だと、ファイル自体が不透明でも半透明に見える場合があります。
特定の利用者や端末だけで透明になる場合は、ブラウザやアプリに保存された表示設定、一時データ、GPUやドライバーとの組み合わせが影響している可能性があります。別の閲覧環境で同じデータを表示し、差を確認します。
OBJが面を持たず、点を中心に構成されている場合は、点の描画サイズ、点の丸め処理、距離による間引き、透明合成、背景色を確認します。点の密度が低い場所では、点の隙間から背景が見えるため、透明に見えることがあります。
OBJの頂点行へRGB値を追加する頂点カラー表現は、広く使われる拡張ですが、基本的なOBJ仕様の一部としてすべての読み込み側が同じように扱うとは限りません。色成分を無視する、別の属性として処理する、読み込みに失敗するなどの実装差があります。頂点行の追加値を「必ずα値として解釈する」とは考えず、アップロード先の対応仕様を確認します。
透明度の問題か形状の問題かを切り分けるには、材質と画像を外した小さな検証用OBJを作成します。単純な不透明材質で正常に表示されるなら、元のMTLや画像が原因候補です。材質を外しても面が消えるなら、頂点順序、重複面、表示設定を中心に確認します。
全体が透明になる場合の確認手順
OBJ全体が均一に薄く透ける場合は、共通して使われている材質、画像、閲覧設定に原因がある可能性が高くなります。
最初に、閲覧画面の表示モードを確認します。透過表示や内部確認が有効であれば解除し、同じ視点で再表示します。表示設定を変えても直らない場合は、ファイル側の確認へ進みます。
次に、対象OBJが面を持つメッシュか、頂点中心の点データかを確認します。面を持つ場合はMTLと面の向き、点中心の場合は点の描画設定や密度を優先して調べます。
OBJ冒頭付近のmtllibを確認し、実際に参照されるMTLを特定します。編集したつもりのMTLではなく、OBJに記載されたファイル名とアップロード対象が一致していることを確認します。
MTL内では、すべてのdを検索します。主要な材質がd 1.0になっているか、1.0未満の値が混在していないかを調べます。
続いてTrを検索し、透明側の値が設定されていないか確認します。dとTrが併記されている場合は、値が矛盾していないかを見ます。
その後、map_dを検索します。全体に共通する材質で透明度用画像が指定されている場合は、画像の内容、パス、利用チャンネルを確認します。
色用テクスチャのαチャンネルも点検します。ただし、アップロード先がmap_Kdのαを利用するか不明な場合は、αなし画像へ差し替えた検証用データで比較します。
これらに問題がなければ、アップロード後の変換処理や表示側の材質分類を疑います。テクスチャを外し、材質を一つにし、d 1.0だけを設定した最小構成を作ります。
最小構成が不透明に表示されれば、元のMTLまたは画像に原因があると判断しやすくなります。最小構成も透明なら、点表示設定、面の向き、閲覧モード、変換処理の対応仕様を確認します。
一部分だけ透明になる場合の確認手順
特定の部材、工区、面だけが透明になる場合は、材質単位または面方向単位で調査します。
まず、透明部分の境界を確認します。形状や部材の区切りと一致する場合は、その部分だけ別の材質が割り当てられている可能性があります。画像の模様と一致する場合は、map_dまたは画像αの影響が考えられます。
OBJ内で透明部分の面を特定できる場合は、その直前にあるusemtlを確認します。そこで指定された材質名をMTL内のnewmtlから探します。
対象材質のd、Tr、map_d、map_Kdを確認し、正常な材質と比較します。透明な材質だけに存在する記述があれば、検証用コピーで一つずつ外して確認します。
透明部分が視点によって現れたり消えたりする場合は、材質よりも面の頂点順序や裏面除去を確認します。同じ材質でも、面の向きが混在していれば一部だけ消えることがあります。
輪郭や細い部分だけ薄い場合は、テクスチャ画像の半透明画素を確認します。背景除去や画像縮小によって、境界へ中間のα値が作られる場合があります。
一部だけを修正するときは、正常な材質まで一括変更しないことが重要です。対象材質を複製し、検証用の名称へ変更してから試すと、修正範囲を限定できます。
OBJとMTLをテキストで点検する方法
OBJとMTLはテキストとして確認できますが、元データを直接編集するのは避けます。最初にファイル一式を複製し、検証用フォルダで作業します。
OBJでは、冒頭付近のmtllibを確認します。指定されたMTLが同じアップロード単位に含まれているか、ファイル名と相対パスが一致しているかを調べます。
次にusemtlを検索し、何種類の材質が使われているかを確認します。透明部分だけを調べる場合は、該当する面の前にある材質名を特定します。
MTLではnewmtlを検索し、対象材質の定義範囲を確認します。あるnewmtlから次のnewmtlまでが、一つの材質定義に対応します。
その範囲にあるd、Tr、map_d、map_Kdを確認します。透明表現が不要であれば、透明度に関する記述が残っていないかを調べます。
ファイル名を変更するときは、参照元も更新します。MTL名を変更した場合はOBJのmtllibを、画像名を変更した場合はMTLのmap_Kdやmap_dを修正します。
改行や文字コードを不用意に変更しないことも重要です。行が連結されると、複数の命令が一つの文字列として読まれ、透明度以外の読み込みエラーが発生する可能性があります。
修正内容は一度に一つだけ変更します。d、Tr、map_d、画像αを同時に変えると、どの修正が有効だったのか分からなくなります。
大規模なOBJを手作業で編集する場合は、行数が多く、誤置換の影響も大きくなります。検索と置換を行う前にバックアップを作り、対象の材質名と定義範囲を確認します。
テクスチャ画像を修正するときの注意点
テクスチャ画像を修正する場合は、透明度だけでなく、画像名、形式、寸法、色空間、参照先も確認します。
透明表現が不要であれば、画像を不透明な状態へ統合します。外周や影の部分に透明画素が残っていないかを確認し、必要に応じてαチャンネルを削除します。
画像形式を変更した場合は、MTLの参照先も変更します。画像だけを差し替えても、MTLが旧ファイルを参照していれば修正は反映されません。
画像の縦横比は維持します。縦横比を変えるとUVに対する模様の位置が変わり、透明部分が意図しない場所へ移動する可能性があります。
画像を縮小すると、透明部分と不透明部分の境界に中間値が生成されることがあります。透明表現が不要な場合は、縮小後のαチャンネルを再確認します。
複数の画像を使用しているデータでは、透明になる材質が参照している画像から調べます。すべての画像を一度に変更すると、原因を特定しにくくなります。
画像名には、半角英数字を中心とした分かりやすい名称を使うと管理しやすくなります。空白や複雑な記号を避けることで、環境差による参照エラーの可能性を減らせます。
αなし画像へ変換した後も透明に見える場合は、画像ではなくd、Tr、map_d、面の向き、表示設定を確認します。画像変更だけで原因が解消するとは限りません。
再アップロードしても直らない場合の確認事項
MTLや画像を修正して再アップロードしても表示が変わらない場合は、修正済みのファイルが実際に反映されているかを確認します。
同じファイル名で上書きを繰り返すと、閲覧画面、配信経路、変換処理の一時データに旧結果が残る場合があります。検証時は、OBJ、MTL、画像、圧縮ファイルに版番号を付け、別データとしてアップロードします。
アップロード完了と変換完了が別に管理されている場合は、変換状態を確認してから表示を比較します。処理途中では旧表示や一時的な結果が残る可能性があります。
別の閲覧環境で確認する方法も有効です。特定の端末やブラウザだけで透明になる場合は、表示設定、キャッシュ、GPU処理などの影響が考えられます。
修正したMTLをアップロードしたつもりでも、OBJのmtllibが古いMTLを指定していることがあります。アップロード用フォルダ内のOBJを開き、参照先を再確認します。
圧縮ファイルを使う場合は、圧縮前と展開後の階層を比較します。OBJからMTL、MTLから画像へ相対パスで到達できる構成になっているかを確認します。
それでも原因が分からない場合は、最小構成の検証データを作ります。テクスチャを外し、材質を一つにし、d 1.0だけを設定します。
最小構成が正常なら、元の設定を一つずつ戻します。Tr、map_d、map_Kd、画像αのいずれかを戻した時点で透明になれば、その項目が原因候補です。
最小構成でも透明になる場合は、面の頂点順序、重複面、点の描画設定、アップロード後の変換仕様、閲覧画面のモードを中心に確認します。
透明表示を防ぐアップロード前の運用
点群OBJの透明表示を防ぐには、書き出し後の確認を担当者の経験だけに任せず、一定の手順として運用することが重要です。
まず、透明にする材質と不透明にする材質を明確に分けます。同じ材質名を使い回すと、後から透明度の違いを判断しにくくなります。
不透明材質では、d、Tr、map_dに矛盾がないかを確認します。透明表現が不要な場合は、不要な透明度設定を残さないようにします。
テクスチャ画像については、αチャンネルが必要かどうかを判断します。不要であれば削除し、必要であれば透明になる範囲とアップロード先の対応を確認します。
OBJのusemtlとMTLのnewmtl、OBJのmtllibとMTLのファイル名、MTLの画像参照と実際の画像名を照合します。
アップロード用フォルダには、使用するファイルだけを入れます。旧版、同名画像、未使用のMTLが混在すると、どのファイルが参照されたか分かりにくくなります。
修正履歴も残します。dを変更した、Trを削除した、map_dを外した、画像のαを削除した、材質名を整理したといった変更を記録すると、再発時に原因を追いやすくなります。
元の点群データ、編集用データ、アップロード用データは分けて保管します。アップロード用データで問題が起きても、原本が残っていれば別条件で書き出し直せます。
アップロード後は、正面だけでなく、背面、斜め、内部が見える角度からも確認します。背景色を変えると、色が薄いだけなのか、実際に背後が透けているのかを判断しやすくなります。
小規模な検証用OBJを用意しておく方法も有効です。不透明材質、意図的な半透明材質、map_d付き材質、画像α付き材質を分けた簡単なデータがあれば、アップロード先がどの記述へ対応しているかを確認できます。
まとめ｜α値と材質参照を順番に確認する
点群OBJアップロード後に透明になる場合は、最初にデータが点中心か面を持つメッシュかを確認し、透明になる範囲と視点による変化を観察します。全体が均一に透けるのか、特定部分だけ透明になるのか、画像の模様に沿って抜けるのか、角度によって面が消えるのかによって、確認すべき原因が変わります。
MTLでは、まずdを確認します。不透明にしたい材質では、一般的にd 1.0が基準です。次にTrを確認し、dと反対方向の値が併記されていないかを調べます。Trの対応や優先関係はアップロード先によって異なるため、仕様確認または検証用データでの比較が必要です。
テクスチャ画像にαチャンネルが含まれている場合は、アップロード先がそのαを採用する実装であれば表面が透ける可能性があります。透明表現が不要であれば、αなし画像へ差し替えて比較します。
map_dが指定されている場合は、透明度用画像の内容と参照先を確認します。色用画像が誤ってmap_dへ指定されると、模様に沿って透明になることがあります。
一部分だけ透明になる場合は、OBJのusemtlとMTLのnewmtlを照合します。材質名の不一致、同名材質の重複、旧MTLの参照、画像パスのずれによって、意図した材質が再現されない可能性があります。
視点によって面が消える場合は、α値だけでなく、面の頂点順序と裏面除去を確認します。頂点法線は陰影に関係しますが、面の表裏判定と同じものではありません。
再アップロード後も表示が変わらない場合は、旧変換結果や一時データが残っていないかを確認し、版番号を変えたデータで比較します。材質と画像を外した最小構成から設定を一つずつ戻すと、原因を特定しやすくなります。
現場で取得した点群を安定して共有するには、取得時の原本を保管し、編集用とアップロード用のデータを分ける運用が重要です。点群の取得から確認、共有までの工程を整理したい場合は、LRTK Phoneを起点として、現場データを一貫して管理できる流れを検討するとよいでしょう。