点群から作成したOBJデータを3D表示環境へアップロードしたものの、透明に設定したはずの面が不透明のまま表示されることがあります。設計面と現況データを重ねたいとき、地形の内部にある構造物を確認したいとき、切土・盛土の差を見比べたいときには、透過表示が使えないだけでも確認作業の効率が下がります。
特に、現場で即土量を確認したい実務担当者にとって、表示不具合の原因調査に長い時間をかけることは避けたいところです。ただし、OBJの透過はOBJファイルだけで完結するとは限りません。材質情報を記録するMTLファイル、面ごとの材質割り当て、透過用の画像、アップロード時のファイル構成、表示側の描画仕様など、複数の要素が関係します。
また、点群をOBJとして出力したデータには、点要素を含むものと、点群から三角形などの面を生成したメッシュがあります。どちらもOBJという拡張子で扱われることがありますが、透過設定の反映方法は同じとは限りません。OBJは点と面の両方を表現できますが、材質交換の中心は一般に面を持つモデルであり、点要素や点ごとの色・透明度の対応範囲は表示環境によって異なります。([NVIDIA Docs][1])
本記事では、点群OBJをアップロードした後に透過しない代表的な4つの原因を整理し、MTLの不透明度、OBJとMTLの参照、画像のアルファ情報、表示環境を確認する順番を解説します。原因を一つずつ切り分けることで、再出力や再アップロードを何度も繰り返す無駄を減らせます。
点群OBJの透過表示が必要になる場面
点群OBJの透過表示は、単に見た目を整えるためだけの機能ではありません。複数の三次元データを重ねて比較するとき、手前の面が不透明だと、奥にある対象物や差分が隠れます。土工、造成、掘削、盛土、構造物施工などの現場では、現況地形と計画形状を同じ空間に配置する場面が多く、透過表示は位置関係を視覚的に確認する手段の一つになります。
例えば、現況点群または現況メッシュの上に計画面を重ね、切土となる範囲と盛土となる範囲を確認する場合を考えます。計画面が完全に不透明だと、現況地形がその下に隠れ、両者の高低差を直感的に把握しにくくなります。計画面を適度に透過させれば、現況の起伏を残したまま計画形状を確認しやすくなり、施工範囲の説明や関係者との認識合わせに役立ちます。
掘削後の出来形を確認する場合にも透過表示は有効です。設計された掘削面と、現場で取得した点群から作成した面を重ねることで、掘り過ぎや掘り残しが疑われる場所を視覚的に探せます。このとき、一方の面を透過させると、二つの形状が近い場所と離れている場所を見分けやすくなります。ただし、透過表示は視覚確認であり、差分量や合否を単独で確定するものではありません。
構造物を含むデータでは、外側の地形や仮設面を透過させ、内部の配管、基礎、埋設物、支持部材などを確認する使い方もあります。透明度を調整できれば、全体の位置関係を維持しながら、必要な対象を見やすくできます。
一方で、透明度を示す数値を設定すれば必ず反映されるとは限りません。OBJには主に形状や要素の情報が保存され、材質は外部のMTLファイルへ記録されることがあります。画像の場所ごとに透過を変える場合は、画像のアルファチャンネルまたは透過用のマップが必要です。さらに、アップロード先が該当する材質記述や透過描画に対応している必要があります。
そのため、透過しないときは、表示画面の透明度設定だけを何度も変更するのではなく、形状、材質、画像、参照関係、アップロード、描画という流れ全体を確認することが重要です。どの段階で透過情報が失われたかを切り分ければ、修正対象を絞り込めます。
原因1｜MTLファイルに透明度が正しく記録されていない
点群OBJが透過しない最初の原因は、MTLファイルに不透明度または透過度が正しく記録されていないことです。OBJには頂点座標、テクスチャ座標、法線、点や面などの要素が記録されますが、色、反射特性、画像参照、面材質の不透明度などはMTLへ分けて保存されるのが一般的です。
MTLで特に確認したいのが、dとTrです。dはdissolveと呼ばれる値で、標準的な解釈ではd 1.0が完全不透明、d 0.0が完全透明です。一方、互換実装で使われることがあるTrは逆向きに解釈され、Tr 0.0が完全不透明、Tr 1.0が完全透明となる例があります。両方が書かれている場合や、出力側と読込側で対応が異なる場合は、同じ材質でも表示結果が一致しないことがあります。([The Library of Congress][2])
このため、単に「アルファ値が0か1か」だけを見て判断してはいけません。MTLのd、Tr、画像のアルファ、表示画面の不透明度は、名称と数値の向きが同じとは限りません。最初に、どの項目を編集しているのかを確認する必要があります。
MTLを開いたときにdやTrなどの透明度に関係する記述が見当たらない場合、表示側は不透明な初期材質として処理することがあります。出力前の画面で透明度を下げていても、その設定がMTLへ書き出されていなければ、アップロード先には伝わりません。編集画面上の見た目と、書き出されたファイルの内容は分けて確認します。
また、透明度の値が記録されていても、透明にしたい面とは別の材質へ設定されていることがあります。一つのOBJに複数の材質が含まれている場合、地形面、側面、底面、計画面などへ異なる材質名が割り当てられます。目的の面に別の材質が指定されていれば、MTL内の数値を変更しても表示は変わりません。
確認時には、OBJ内のusemtlで指定されている材質名と、MTL内のnewmtlで定義されている材質名が一致しているかを見ます。大文字と小文字、空白、記号の違いは、読み込み環境によって参照失敗の原因になります。材質を変更した後に古いMTLを残していると、OBJは新しい材質名を参照しているのに、MTLには古い材質しかない状態になることもあります。
透過しない原因を素早く判断するには、同じ単純な面に対して、d 1.0の材質とd 0.5の材質を割り当てた小さなテストデータを作る方法が有効です。二つのデータでMTLの内容と表示結果を比較すれば、dが読み込まれているか、値の変更が反映されているかを確認できます。Trを使う場合も、dと混在させず、別の試験データで確認する方が安全です。
MTLを直接変更する場合は、元ファイルを残してから作業します。数値の意味を確認せずに0や1へ変更すると、完全に消えて見えなくなることがあります。まずはd 0.5などの中間値で確認し、表示結果を見ながら調整すると、方向の取り違えを避けやすくなります。
原因2｜OBJとMTLの参照関係がアップロード後に切れている
二つ目の原因は、OBJとMTLの参照関係がアップロード後に切れていることです。MTLに正しい不透明度が記録されていても、OBJがそのMTLを読み込めなければ透過は反映されません。この場合、形状だけは正常に表示されることがあるため、材質も読み込まれているように見えて原因を見落としやすくなります。
OBJ内では、mtllibが外部MTLファイルを参照し、usemtlが後続の面などへ材質名を割り当てます。MTL側ではnewmtlが材質を定義します。したがって、mtllibのファイル名、usemtlの材質名、newmtlの材質名が対応していなければなりません。OBJとMTLの参照関係は外部ファイルと名称に依存するため、アップロード時の欠落や名称変更が不具合につながります。([NVIDIA Docs][1])
よくあるのは、OBJだけを選択してアップロードし、同じ場所に保存されていたMTLや画像を含めていないケースです。出力時には一つのモデルに見えても、保存先にはOBJ、MTL、画像の複数ファイルが作られていることがあります。アップロード先が複数ファイルまたは圧縮ファイルを受け付ける場合は、その仕様に従って関連ファイルをまとめます。
圧縮ファイルでアップロードする方式では、圧縮前のフォルダー構成も確認します。OBJから参照されるMTLや、MTLから参照される画像が別階層にあり、記録された相対パスと一致しなければ読み込まれないことがあります。アップロード後の自動展開や内部変換で階層が変わる環境もあるため、原因調査中はOBJ、MTL、画像を同じフォルダー直下へ置いた最小構成が分かりやすい方法です。
ファイル名の変更にも注意が必要です。書き出し後にMTLの名前だけを変更すると、OBJ内のmtllibと一致しなくなります。日本語、空白、長い記号列を含む名前を利用できる環境もありますが、変換処理や別のOSを経由すると扱いが変わることがあります。切り分け段階では、半角英数字とアンダースコア程度にそろえた短い名称が安全です。
大文字と小文字の違いも見逃せません。手元では区別されずに読み込めても、アップロード先では別のファイルとして扱われる場合があります。OBJがmaterial.mtlを参照しているのに、実際のファイル名がMaterial.mtlであれば、環境によっては参照に失敗します。
MTL内で画像を参照している場合は、OBJからMTL、MTLから画像という二段階の参照になります。OBJとMTLが正しく関連付いていても、画像が見つからなければ、画像に含まれる色や透過情報は使用されません。材質色は合っているのに画像の透明部分だけ反映されない場合は、MTL内の画像参照と実ファイル名を確認します。
アップロード後のログや警告を確認できる場合は、MTLが見つからない、画像を読み込めない、未対応の材質記述があるといった表示がないかを見ます。画面上では形状が表示されていても、内部では関連ファイルの読み込みに失敗していることがあります。
切り分けには、OBJ、MTL、画像を一つのフォルダー直下に置き、名称を半角英数字へ統一した最小構成を作る方法が適しています。ファイル名を出力後に変更せず、アップロード先が指定する方法でまとめて登録します。この状態で透過すれば、元のデータでは参照経路、名称、階層のいずれかに問題があった可能性が高いと判断できます。
原因3｜透過画像のアルファチャンネルが失われている
三つ目の原因は、材質に使用している画像のアルファチャンネルが失われていることです。アルファチャンネルは、画像の各画素がどの程度不透明かを示す情報です。PNGの仕様では、アルファが0なら完全透明、最大値なら完全不透明です。8ビットのアルファであれば0から255、16ビットであれば0から65535の範囲を取ります。([W3C][3])
画像全体を一律に半透明にする場合は、MTLのdや表示側の不透明度だけで対応できることがあります。一方、格子の隙間、境界外、切り抜き部分など、画像の場所によって透明度を変える場合は、色画像のアルファチャンネルを利用する方式か、MTLのmap_dなどで別の透過用画像を参照する方式が必要です。
透過画像を作成したつもりでも、保存形式を変更した段階で透明情報が失われることがあります。アルファチャンネルを保持できない形式へ変換すると、透明だった場所が白、黒、灰色などの背景色で塗りつぶされる場合があります。PNGなどアルファを保持できる形式でも、保存設定や画像処理の途中で背景と合成されれば、透明部分は残りません。
アップロード前の画像を通常の画像表示画面で開いたとき、透明部分が白く見えるだけではアルファの有無を断定できません。表示ソフトが透明部分を白い背景上で表示している可能性があるためです。画像編集機能や画像情報の確認機能を使い、アルファチャンネルまたは透過情報が実際に存在するかを確認します。
画像にアルファチャンネルが残っていても、表示環境が色画像のアルファを自動利用するとは限りません。MTLのmap_Kdは主に拡散色の画像を指定する記述で、透過用のmap_dとは役割が異なります。ある読込環境ではmap_Kd画像のアルファを利用しても、別の環境ではmap_dの指定や表示側の透明化設定が必要になることがあります。MTLの記述と表示環境の対応範囲を分けて確認する必要があります。
透過用画像を別ファイルとして使う場合は、白黒や明度で不透明度を表すことがあります。一般的には白側を不透明、黒側を透明として扱いますが、読み込み設定や画像のチャンネル指定によって期待と異なる結果になる場合があります。本来残したい部分が消え、消したい背景だけが表示されるときは、画像の反転、参照チャンネル、読込側の仕様を確認します。
また、表示画面に「50」と入力した値が50パーセントを意味するのか、0から255のうちの50を意味するのか、または0から1の入力欄へ誤って50を入れているのかは、画面仕様によって異なります。MTLのd、PNGのアルファ、表示画面のパーセント表記を同じ数値体系として扱わないことが重要です。
点群から作成した色付きメッシュでは、写真から生成された画像が複数枚に分かれていることがあります。そのうち一枚だけ画像名、保存形式、透過設定が異なると、一部の面だけ不透明になることがあります。全体ではなく区画ごとに表示結果が違う場合は、複数の材質と画像が使われていないかを確認します。
画像編集時に透明部分を背景と合成してしまう操作にも注意が必要です。見た目が同じでも、透明部分として保存されている状態と、白や黒を塗った状態は異なります。書き出し前には、背景レイヤーを非表示にした状態で保存されているか、画像の平坦化によって透明情報が失われていないかを確認します。
原因を切り分けるためには、複雑な画像の代わりに、透明部分と不透明部分が明確に分かれた小さな試験画像を使用すると効果的です。画像の左半分を完全不透明、右半分を完全透明にしたものを単純な面へ割り当てます。この画像でも全面が不透明なら、アルファが保存されていないか、表示側が画像のアルファを利用していない可能性があります。左右が正しく分かれれば、元画像の保存方法、map_dの参照、材質割り当てのいずれかへ確認範囲を絞れます。
原因4｜表示環境が材質の透過処理に対応していない
四つ目の原因は、アップロード先の表示環境が、OBJやMTLに含まれる透過指定へ対応していない、または別の設定を必要としていることです。ファイルに正しい不透明度が記録されていても、表示側がその項目を読み取らなければ不透明になります。
OBJとMTLは広く利用されている形式ですが、すべての表示環境が同じ項目を同じ方法で解釈するわけではありません。形状、色、画像には対応していても、d、Tr、map_d、色画像のアルファのうち一部だけに対応する場合があります。MTLには現在の交換ソフトで必ずしも広く対応されていない項目もあり、読込側が未対応の記述を無視する可能性があります。([The Library of Congress][2])
特に、点を主体としたデータと、三角形の面を主体としたデータでは描画方式が異なります。一般的な面材質の透明度がメッシュには反映されても、点要素へ同じように反映されるとは限りません。アップロード後に点群レイヤーとして扱われる場合は、MTLではなく、表示画面の点群不透明度、レイヤー透明度、点サイズなどが優先されることがあります。
この場合、MTLを編集し続けても解決しません。OBJから読み込まれたデータが、点群、点要素、メッシュのどれとして登録されているかを確認し、表示画面に対象形式専用の不透明度設定がないかを見ます。汎用的な3Dライブラリでも、面用材質と点用材質は別に用意され、透明度やアルファマップの処理が個別に設定されます。([Three.js][4])
半透明にはなるものの、奥側が不自然に欠ける場合や、見る角度によって面の前後関係が変わる場合は、アルファ値そのものではなく、透明面の描画順序、深度処理、裏面除外などが影響している可能性があります。半透明の面が多数重なると、どの面を先に描くかによって見え方が変わります。
地形面のように厚みのない面では、表側と裏側を区別して描画する設定も関係します。表側から見えるのに反対側から消える場合、透過不良ではなく、裏面が描画対象から除外されている可能性があります。視点を反対側へ移したときだけ消えるのであれば、面の向きと両面表示の設定を確認します。
表示速度を優先する環境では、連続的な半透明ではなく、一定のしきい値を境に表示と非表示を切り替えるアルファテストが使われることがあります。この場合、透明度を少し変更しただけで急に消えたり、細い部分が欠けたりします。表示側にブレンド、マスク、カットアウトなどの選択肢がある場合は、目的に合った方式かを確認します。
アップロード時にデータが内部形式へ自動変換される場合も注意が必要です。OBJを表示用形式へ変換する過程で、材質名、透過指定、画像参照が簡略化されることがあります。手元では透過しているのにアップロード後だけ不透明になる場合は、アップロード先の変換仕様や対応形式を確認します。
原因を確認するには、同じOBJ、MTL、画像の組み合わせを、別の閲覧環境でも開いて結果を比較します。別環境では透過し、アップロード先だけ不透明なら、表示環境または変換処理の影響が疑われます。どちらでも透過しない場合は、MTL、材質割り当て、画像、参照関係など、元データ側の設定を優先して確認します。
アルファ値を確認する具体的な手順
透過不良を効率よく解決するには、設定を無作為に変更するのではなく、確認する順番を決めることが重要です。最初に、元の作成環境で対象が本当に透過しているかを確認します。編集画面上で透明に見えていなければ、書き出しやアップロード以前の設定を見直します。
次に、対象データが点なのか面なのかを確認します。OBJ内にfで始まる面要素があり、usemtlで材質が割り当てられているなら、MTLの面材質が関係する可能性があります。vとpを中心とする点要素で、面がない場合は、表示側の点群または点材質の設定を確認する方が先です。
その後、出力されたファイルの構成を確認します。OBJだけでなく、同じ保存場所にMTLや画像が作成されているかを見ます。作成日時や版番号を比較すると、今回の出力で更新されたファイルか、以前の出力が残っているだけなのかを判断しやすくなります。
MTLが存在する場合は、d、Tr、map_dなどを確認します。dを使う場合は、1.0が完全不透明、0.0が完全透明です。Trを使う場合は逆向きに扱われる例があるため、読込先の対応を確認します。dとTrが同じ材質に併記されている場合は、どちらが優先されるかが環境によって異なる可能性があるため、試験用データでは一方に統一します。
OBJ内では、mtllibのファイル名、usemtlの材質名、MTL内のnewmtlの材質名を順番に照合します。大文字と小文字を含めて一致しているかを確認し、出力後に名称だけ変更していないかを見ます。
画像を使用している場合は、アルファチャンネルが含まれているか、透過を保持できる形式で保存されているか、背景と統合されていないかを確認します。map_dがある場合は、指定された画像が実際に存在し、参照パスとファイル名が一致しているかを見ます。
アップロード時には、OBJ、MTL、画像を一つのデータセットとして扱います。アップロード先が個別ファイル、フォルダー、圧縮ファイルのどれを受け付けるかを確認し、その仕様に従います。原因調査中は同じ階層へまとめ、短い半角英数字の名称へそろえると参照不良を切り分けやすくなります。
アップロード後は、まず色や画像が読み込まれているかを確認します。元の色や画像が反映されていなければ、透明度以前にMTLまたは画像参照が失敗している可能性があります。色は正しいのに透明度だけ反映されない場合は、d、Tr、map_d、画像アルファ、表示側の透明化設定へ確認対象を絞れます。
最後に、表示画面にレイヤー不透明度、材質不透明度、点群透明度、ブレンド方式、両面表示などの設定がないかを確認します。アップロードされた材質値より表示側の設定が優先される場合があります。画面側が不透明に固定されていれば、元データの値を変更しても反映されません。
OBJを再出力するときに確認したい設定
原因が出力設定にあると判断した場合は、同じ操作を繰り返すのではなく、再出力前に材質と関連ファイルの設定を整理します。まず、透明にしたい対象へ専用の材質を割り当てます。複数の面が同じ材質を共有していると、一部だけ透明にしたい場合に設定を分けられません。
例えば、現況地形、計画面、構造物、境界面に同じ材質が割り当てられている状態で不透明度を変更すると、すべてが同時に透過する可能性があります。現場で比較したい対象ごとに材質を分けておけば、アップロード後の表示調整もしやすくなります。
次に、材質情報を外部ファイルへ書き出す設定が有効かを確認します。OBJだけを書き出す設定では、MTLや画像参照が含まれない場合があります。MTLを同時に出力し、画像も関連ファイルとして保存する設定を選びます。
透明度の書き出しに対応しているかも確認が必要です。編集画面で材質を透明にできても、OBJ出力機能がd、Tr、map_dなどへ変換しない場合があります。出力後のMTLを開き、材質の不透明度を変えたときに該当する値が実際に変化しているかを確かめます。
画像を使用する場合は、元画像のアルファ情報を維持できる設定を選びます。画像変換や容量削減を有効にすると、透明画像がアルファを持たない画像へ変換されたり、背景と合成されたりすることがあります。自動変換を行う場合は、変換後の画像にも透過情報が残っているかを確認します。
座標値が大きい現場データでは、表示原点から遠いことによる数値精度の影響で、面のちらつきや重なりが目立つ場合があります。これはアルファ値の欠落とは別の問題ですが、透過不良に見えることがあります。表示用に原点を移動する場合は、元の測量座標との変換量を記録し、数量計算用データと混同しないようにします。
再出力時には、いきなり現場全体を出力せず、小さな範囲で試験する方法が有効です。地形の一部、計画面の一部、単純な四角形などを使い、材質を一つだけ設定します。試験データで透過が成功した後に同じ設定を現場全体へ適用すれば、確認時間を短縮できます。
ファイル名と材質名も簡潔にします。日本語や空白を使用できる環境はありますが、原因調査中は互換性を優先し、短い半角英数字とアンダースコアへ統一した方が切り分けやすくなります。透過が確認できた後も、OBJ内の参照名と実ファイル名が一致する状態を保ちます。
出力後には、OBJ、MTL、画像を一つの作業単位として保存します。OBJだけを上書きし、MTLや画像が古いまま残ると、組み合わせが不整合になります。フォルダー名に出力日や版番号を付け、異なる出力結果を混在させないことが大切です。
点群OBJとメッシュOBJで異なる透過の考え方
点群OBJの透過問題を考えるときは、データが点として描画されているのか、面として描画されているのかを区別する必要があります。名称に点群と付いていても、実際には点群から生成したメッシュである場合があります。
OBJは点要素と面要素を記録できます。点要素はp、面要素はfで表されますが、アップロード先が点要素を点群として扱うか、点の色や透明度をどこまで解釈するかは一様ではありません。面を持つOBJではusemtlによる材質割り当てを利用しやすい一方、点だけのOBJでは表示側の点材質やレイヤー設定が必要になることがあります。([NVIDIA Docs][1])
点データでは、一つひとつの頂点を小さな点として表示します。点の色を頂点情報として書き出す実装もありますが、OBJの交換互換性はソフトウェアによって異なり、点ごとのアルファまで同じように受け渡せるとは限りません。点の色が表示できても、MTLのdが点群全体へ反映されない場合があります。
また、点群表示では点の密度と点サイズによって見た目の透明感が変わります。点が疎であれば隙間から奥が見えるため、透明に見えることがあります。しかし、これはアルファブレンドによる透過とは異なります。点を大きくすると隙間が埋まり、不透明な面のように見えるため、透明度を変更していなくても見え方が変わります。
点群レイヤーの不透明度を下げる機能がある場合は、OBJのMTLよりも表示側の設定を使う方が適切なことがあります。点群全体を均一に薄く表示し、計画面や測定点を前面に出す使い方に向いています。
一方、メッシュOBJでは、三角形などの面に材質を割り当てます。MTLのd、Tr、map_dや画像のアルファが反映される可能性が高いのは一般にこちらです。ただし、面が細かく分割され、透明な面が大量に重なると、描画順序や深度処理による乱れが起こりやすくなります。
地形メッシュは一枚の面に見えても、実際には多数の三角形で構成されています。表面、底面、外周の側面を含む閉じた形状では、透明にしたときに奥側の面まで重なって表示されます。その結果、不透明度を下げたのに全体が濃く見えることがあります。
一枚の半透明面を通して見る場合よりも、手前の側面、地形表面、奥の側面という複数の面が重なる場合の方が、合成後の色は濃くなります。値が間違っているとは限らないため、不要な底面や側面を除いた試験データで確認すると判断しやすくなります。
現況地形と計画面を比較する目的であれば、両方を同じ半透明にするより、一方を不透明に近い表示、もう一方を薄い半透明にする方が位置関係を把握しやすい場合があります。さらに、境界線や特徴点を別表示にすると、面が重なる場所でも形状を見失いにくくなります。
土量確認では、透過表示はあくまで視覚的な確認手段です。透明に見えていることだけで、切土量や盛土量が正しいと判断してはいけません。二つのデータが同じ座標系、同じ高さ基準、同じ単位で配置され、比較範囲と基準面が適切に設定されていることを確認したうえで差分計算を行います。
現場で即土量の確認を止めないデータ管理
現場で即土量を確認する運用では、透過表示の修正に時間を取られないよう、データ作成からアップロードまでの手順を定型化することが重要です。担当者ごとに出力方法やファイル名が異なると、同じ不具合が繰り返し発生します。
まず、現況点群、現況メッシュ、計画面、比較結果を用途ごとに分けて管理します。すべてを一つのOBJへまとめると、材質設定や表示切り替えが複雑になります。用途ごとに分けておけば、計画面だけを透過させる、現況だけを非表示にする、差分結果だけを共有するといった操作がしやすくなります。
ファイル構成も固定します。一つのOBJに対して、対応するMTLと画像を同じフォルダーへ保存し、フォルダーまたはアップロード先が指定する圧縮単位で受け渡します。OBJだけを個別に移動する運用では、関連ファイルの欠落が起こりやすくなります。
版管理では、上書きを避けることが大切です。現場では、朝の計測結果、施工途中の計測結果、作業後の計測結果など、同じ範囲のデータが複数作成されます。すべて同じファイル名で保存すると、どのMTLや画像がどのOBJに対応しているか分からなくなります。
計測日、対象範囲、現況か計画か、版番号などをフォルダー名へ含めます。OBJとMTLの内部参照を壊さないため、出力後のファイル名変更は避け、必要な管理情報は上位フォルダー名で補う方法も有効です。
アップロード前の確認項目も固定します。元の画面で透過しているか、MTLが作成されているか、dまたはTrの値が意図どおりか、画像のアルファが残っているか、参照名が一致しているか、座標系と単位が正しいかを毎回確認します。確認結果を簡単な記録として残せば、不具合が発生したときにどの段階まで正常だったかを追跡できます。
現場での説明に使用するデータは、編集用データとは別に軽量化しておくと安定する場合があります。点数や面数が多すぎると、透明面の描画負荷が高まり、表示の遅れやちらつきが起こることがあります。数量計算用の原データを保存しつつ、確認用には必要な範囲だけを切り出したデータを用意します。
ただし、軽量化によって地形の凹凸、法肩、法尻、掘削底などの形状が変わると、土量確認に影響します。表示用の軽量データと、計算に使用する原データを明確に区別し、軽量データだけで最終数量を確定しない運用が必要です。
透過表示が直らない場合に備え、代替の確認方法も決めておきます。対象レイヤーを交互に表示する方法、色を明確に分ける方法、高さ差を色分けする方法、断面で比較する方法などがあります。透過が使えないだけで現場判断が停止しないよう、複数の確認手段を用意しておくことが実務上は重要です。
断面比較は、透過表示より差を明確に把握できる場合があります。現況面と計画面を同じ断面上に表示すれば、切土と盛土の方向や高さの差を確認できます。平面上では見分けにくい小さな高低差も、断面では発見しやすくなります。
数量を確定する前には、基準面、対象範囲、除外範囲、欠測部分、ノイズ除去の状態を確認します。透過表示が正常でも、計算範囲に不要な地物や作業車両が含まれていれば、土量へ影響する可能性があります。見た目の確認と数量計算の条件確認を分けて実施することが大切です。
まとめ｜アルファ値だけでなくファイル構成まで確認する
点群OBJをアップロードした後に透過しない場合、原因は一つのアルファ値だけとは限りません。MTLに不透明度が正しく記録されていない、OBJとMTLの参照が切れている、画像のアルファチャンネルまたは透過用マップが失われている、表示環境が該当する透過処理に対応していないという四つの原因を順番に確認します。
最初に、対象データが点として描画されているのか、点群から作成したメッシュとして描画されているのかを確認します。点要素ではMTLの面材質が期待どおりに使われず、表示画面の点群またはレイヤー不透明度が必要になる場合があります。メッシュであれば、MTLの材質と画像の透過情報を確認します。
次に、MTLのdとTrを区別します。dは1.0が完全不透明、0.0が完全透明です。Trは逆向きに扱われる実装があるため、項目名を見ずに数値だけで判断してはいけません。完全不透明と半透明の小さな試験データを出力し、読込先で比較する方法が安全です。
OBJ、MTL、画像は一つのデータセットとして管理します。OBJだけを移動したり、MTLだけを名称変更したりすると、形状は表示されても材質が失われることがあります。mtllib、usemtl、newmtl、画像参照の名称を照合し、同じ階層へ置いた小さなテストデータで確認すると、参照不良を切り分けやすくなります。
画像の一部を透明にしたい場合は、画像にアルファチャンネルが残っているか、またはmap_dなどの透過用画像が正しく参照されているかを確認します。保存形式の変更、背景との統合、自動画像変換などによって透明情報が失われることがあります。色画像のアルファを使う方式なのか、透過用画像を別に使う方式なのかも確認が必要です。
手元では透過するのにアップロード後だけ不透明になる場合は、表示環境や内部変換の影響が考えられます。アップロード先が対応するMTL記述、点群とメッシュの扱い、レイヤー側の不透明度、透明面の描画方式を確認します。
現場で即土量を確認するためには、透過表示の復旧だけでなく、座標系、高さ基準、単位、比較範囲、基準面、ノイズ除去の状態までそろえることが重要です。透過は現況と計画を見比べる有効な手段ですが、数量の正しさを単独で保証するものではありません。
点群の取得、三次元化、現況確認、計画面との比較、数量把握までを現場中心で進めることで、事務所との往復やデータ変換の待ち時間を減らせます。現場計測から点群確認、土量把握までの流れを短くしたい場合は、次の選択肢としてLRTK Phoneをご確認ください。