LRTKレフィクシア株式会社

点群OBJのアルファ画像で輪郭が白くなるときの5つの修正

点群OBJのアルファ画像で白い輪郭が出る理由

点群から作成したOBJをアップロードした後、透明な背景を含むテクスチャの周囲に白い線が見えることがあります。樹木、フェンス、標識、設備、植生、細い配線などを透明画像で切り抜いて表現している場合に起こりやすい現象です。正面から拡大して見たときは問題がなくても、表示を縮小したときや斜め方向から見たときに、輪郭だけが白く浮いて見えることもあります。

この白い輪郭は、OBJの形状に白い線が含まれているとは限りません。透明画像の内部に残った色情報、アルファの合成方式、UV座標の配置、半透明材質の描画方法、画像の縮小処理などが関係しています。複数の原因が同時に発生することもあるため、OBJを再出力するだけでは改善しない場合があります。

透明画像の一つひとつの画素には、一般的に赤、緑、青の色情報と透明度が記録されています。完全に透明な画素は画面に見えないため、透明部分の色は無関係に思えるかもしれません。しかし、3D表示では、画像を拡大縮小したり、斜め方向へ投影したりする際に、周囲の画素を混ぜて表示色を計算します。

たとえば、緑色の樹木を白い背景から切り抜いた画像を考えます。背景を透明にしても、透明になった画素の赤、緑、青が白色のまま残っていることがあります。樹木の輪郭付近では、緑色の画素と透明な白色の画素が補間されます。その結果、透明度は低いものの、白色を含んだ画素が生成され、暗い背景に重ねたときに白い縁として見えることがあります。

画像編集時に透明部分が市松模様で表示されていても、その内部の色情報まで消えているとは限りません。市松模様は透明であることを示しているだけであり、透明画素にどのような色が記録されているかまでは判断できない場合があります。そのため、画像単体では問題がないように見えても、点群OBJをアップロードした後に白い輪郭が現れます。

また、白い輪郭は遠距離で強くなる傾向があります。3D表示では、表示負荷を抑えるために元画像から小さな画像を生成し、表示距離に応じて使い分けることがあります。画像を縮小すると、輪郭の色と透明部分の白色が一つの画素へまとめられます。近距離では正常でも、遠距離用の画像へ切り替わると白い線が出る場合は、この縮小処理が関係している可能性があります。

白い輪郭を修正するには、透明部分を作り直すだけでなく、透明画素の色情報、画像の合成方式、UVの余白、材質設定、縮小後の画像まで段階的に確認する必要があります。

修正前に切り分けたい画像側とOBJ側の問題

修正を始める前に、白い輪郭が画像側で発生しているのか、OBJや材質の構造によって発生しているのかを切り分けます。この確認を行わずに複数の設定を同時に変更すると、どの修正が有効だったのか分からなくなり、別の不具合を増やすことがあります。

最初に、使用しているアルファ画像を不透明な背景へ重ねて確認します。白、黒、灰色、赤、青など複数の背景色を使うと、輪郭に残った不要な色を発見しやすくなります。白い背景だけで確認すると、白い縁が背景へ溶け込んで見えなくなるため、問題を見落としやすくなります。

黒い背景へ重ねた時点で白い線が確認できる場合は、元画像の半透明画素や透明画素に白色が残っている可能性があります。画像単体では正常で、3D表示時にだけ白くなる場合は、アルファの合成方式、UV座標、縮小処理、材質設定などを確認します。

次に、単純な一枚の四角い面へ同じ画像を貼り、表示結果を確認します。単純な面でも白い輪郭が出る場合は、点群から生成された複雑な形状よりも、画像またはアルファ設定に原因がある可能性が高いと判断できます。単純な面では正常で、本番のOBJでだけ白くなる場合は、重複面、細長い三角形、UVのずれ、法線の向き、材質の重複などが疑われます。

表示距離による変化も重要です。近距離から遠距離まで少しずつ視点を離し、白い輪郭がいつ現れるかを確認します。常に同じ太さで白く見える場合は、元画像の輪郭処理に問題がある可能性があります。一定の距離を超えたときに急に白くなる場合は、縮小画像への切り替えが関係している可能性があります。

正面と斜め方向でも比較します。正面では正常で、面を傾けると白い線が現れる場合は、画像の補間範囲が広がり、透明部分の色を拾っている可能性があります。UVの余白不足や画像端の処理も確認対象です。

視点を動かしたときに白い線がちらついたり、位置が細かく変化したりする場合は、単純なアルファ画像の問題ではなく、ほぼ同じ位置に複数の面が重なっている可能性があります。点群から自動生成したメッシュでは、重複面や近接面が残ることがあるため、画像修正だけで解決しない場合があります。

修正前には、元画像、単純な検証用OBJ、本番OBJ、近距離表示、遠距離表示をそれぞれ確認し、どの条件で白い輪郭が出るのかを記録します。原因の範囲を絞ってから一項目ずつ修正すると、点群OBJアップロード後の確認作業を効率化できます。

修正1 透明部分に残った白色を輪郭色で埋める

最初に試したい修正は、完全に透明な部分に残っている白色を取り除き、切り抜いた対象物の輪郭に近い色で埋めることです。白い輪郭の原因として特に多いのが、透明度はゼロであっても、色情報には白が残っている状態です。

樹木を白い背景から切り抜いた場合、見た目では背景が透明でも、透明部分の色情報には元の白背景が残ることがあります。3D表示で輪郭付近の画素が補間されると、緑色と透明な白色が混ざり、白っぽい緑色が生成されます。これが暗い背景や点群の濃い色と重なると、白い縁として目立ちます。

修正するときは、透明部分を単に黒色で塗りつぶすのではなく、対象物の輪郭色を外側へ延長します。樹木であれば緑や茶色、金属部材であれば灰色、赤い標識であれば赤や暗い赤など、輪郭に接している色を透明領域へ広げます。透明度はゼロのままで構いません。透明画素は直接見えませんが、補間や縮小の際には色情報が利用されるため、輪郭色を延長しておくことに意味があります。

延長する範囲は一画素だけでは不足することがあります。画像が遠距離表示用に何段階も縮小される場合、輪郭から離れた画素まで平均計算へ含まれる可能性があるためです。画像の大きさや利用方法によりますが、対象物の外側へ数画素以上の同系色を持たせると、白い色の混入を抑えやすくなります。

ただし、輪郭全体を一色で埋める方法は適切でない場合があります。樹木や機械設備のように、場所によって輪郭色が異なる画像では、上部、下部、左右で近い色を外側へ延長する必要があります。画像全体の代表色で透明部分を塗ると、白い縁は消えても、輪郭に別の色のにじみが生じる可能性があります。

細い枝、金網、ケーブル、文字などを含む画像では、輪郭が複雑です。透明部分に色を広げる際に、隣接する別の部分の色が混ざると、細部が太く見えたり、色の濁りが発生したりします。元の輪郭に近い位置の色を使い、必要以上に広い範囲を一律に処理しないことが重要です。

半透明の影や煙のような表現では、完全透明部分だけでなく、透明度が低い画素に背景色が混ざっていないかを確認します。白い背景から切り抜いた際に、半透明部分のRGB自体が白っぽくなっていると、完全透明部分を修正しても白い縁が残ります。この場合は、背景色の影響を除いた色へ調整し直す必要があります。

画像を修正した後は、黒、白、灰色など複数の背景へ重ねて再確認します。黒背景で白い線がなくなっていても、白背景で暗い線が出る場合は、透明部分の色が暗すぎる可能性があります。どの背景でも対象物の色から自然につながって見える状態を目指します。

元画像と修正版を同じファイル名で保存すると、アップロード先に以前の画像が残り、修正結果を確認できない場合があります。検証時には画像名を変更し、MTLの参照先も新しい名前へ合わせると、修正版が確実に読み込まれているかを判断しやすくなります。

修正2 アルファの合成方式を表示環境に合わせる

透明画像の色情報と透明度を扱う方法には、大きく分けて、元の色をそのまま保持する方式と、あらかじめ色へ透明度を掛けて保持する方式があります。作成時、変換時、表示時でこの前提が一致していないと、白い輪郭や黒い輪郭、半透明部分の色抜けが発生します。

元の色をそのまま保持する方式では、透明度が低い画素でも、RGBには対象物本来の色が記録されます。表示時に透明度を使って背景と合成します。一方、あらかじめ透明度を色へ反映する方式では、透明度が低い画素ほどRGBも暗くなった状態で保存または処理されます。

元の色を保持した画像を、すでに透明度が色へ反映されている画像として扱うと、輪郭の色が明るくなりすぎる場合があります。特に元画像の透明部分に白色が残っていると、白い縁が強調されます。反対に、透明度を反映済みの画像を通常の色として扱うと、透明度が重複して適用され、輪郭が暗くなったり、半透明部分が消えたりすることがあります。

この問題は、画像を目で見ただけでは判断しにくい点に注意が必要です。元画像の作成工程、画像の書き出し設定、中間変換、アップロード先の読み込み処理が、それぞれ異なる前提を持っている可能性があります。

まず、画像を書き出す際のアルファ関連設定を確認します。次に、画像の形式や解像度を変換している場合は、その工程でアルファの扱いが変更されていないかを確認します。最後に、アップロード先の材質設定に、透明画像の合成方式や乗算処理に関する項目がある場合は、画像側の前提と一致させます。

表示環境の仕様を確認できない場合は、同じ元画像から処理方法の異なる二つの検証用画像を作り、単純な面へ適用して比較します。どちらの画像を使っているか分からなくならないように、画像名とMTL名を明確に分けます。

比較するときは、白い輪郭の有無だけでなく、半透明部分の濃さや本体の色も確認します。白い縁が消えていても、葉先、金網、薄い影などが不自然に暗くなっている場合は、合成方式が正しくない可能性があります。輪郭が自然で、本体の色と透明度も元画像に近い状態を選びます。

透明画素の白色とアルファ方式の不一致は、同時に発生することがあります。そのため、合成方式だけを変更しても白い縁が完全には消えない場合があります。先に透明部分のRGBを輪郭色で整え、その後にアルファ方式を確認すると切り分けやすくなります。

MTLには、材質全体の透明度や透明画像の参照が記述されることがあります。しかし、同じ記述でも表示環境によって解釈が異なる場合があります。MTLに値が記載されているから必ず同じ見え方になるとは限りません。最終的には、点群OBJを実際のアップロード先で表示し、利用する条件で確認することが必要です。

修正3 UV境界の余白を広げて色の混入を防ぐ

アルファ画像の透明部分を修正しても白い輪郭が残る場合は、UV座標の周囲に十分な余白があるかを確認します。UV境界のすぐ外側に白色や無関係な色があると、画像補間や縮小処理によって、その色が表示領域へ混ざることがあります。

3D表示では、UV座標が指す一つの画素だけを表示するとは限りません。滑らかな見た目を作るため、周辺の複数画素を参照して表示色を決めることがあります。面を斜め方向から見た場合や、遠距離から小さく表示した場合は、さらに広い範囲の画素が計算へ含まれます。

切り抜いた対象物の輪郭ぎりぎりにUV境界が配置され、その外側が透明な白色になっていると、輪郭色と白色が混ざります。修正するときは、対象物の外側に輪郭色を延長した領域を作り、UV境界をその内側へ収めます。

一枚の画像に複数の部材や画像領域をまとめている場合は、領域同士の間隔も重要です。緑色の領域と白色の領域が近接していると、縮小時に白色が緑色側へ混ざる可能性があります。反対に、暗い領域が明るい部材へ混ざると、黒い縁として現れます。

画像容量を抑えるためにUV領域を隙間なく配置すると、近距離では問題がなくても、遠距離で色のにじみが発生しやすくなります。軽量化だけを優先せず、縮小後も領域同士が混ざらない余白を確保します。

画像の端へUV領域を配置している場合も注意します。表示側の境界処理によっては、画像端の外側を参照したり、反対側の色を繰り返して使用したりすることがあります。対象物の輪郭を画像端へ直接接触させず、端まで同系色の余白を設けると安定しやすくなります。

UV座標がわずかに想定範囲から外れている場合も、白い線の原因になります。点群から自動生成したメッシュでは、小さな三角形や細長い面が大量に作られ、UV境界が複雑になることがあります。わずかなずれでも、多数の面で同じ問題が発生すると、白い線や点の集まりとして目立ちます。

UVを確認するときは、対象物の形とUVの輪郭が一致しているかだけでなく、補間用の色が外側に残っているかを確認します。透明画像の輪郭とUV境界を完全に同じ位置へ合わせるのではなく、輪郭色を延長した部分の内側にUVを配置します。

複数の領域が過密な場合は、画像を分割して材質を分ける方法もあります。一枚の画像に詰め込みすぎなければ、隣接領域からの色の混入を減らせます。ただし、画像数や材質数を増やしすぎると、アップロード処理や表示処理の負荷が高くなる可能性があります。白い輪郭を防ぎながら、管理可能なファイル数に収めることが大切です。

点群OBJアップロード用に画像を縮小する場合は、縮小前のUV余白も考慮します。元画像で十分に見える余白でも、画像サイズを半分や四分の一へ縮小すると、実際の画素数としては不足する場合があります。最終的に使用する解像度で、余白が確保されているかを確認します。

修正4 半透明描画とアルファ判定を使い分ける

アルファ画像の表示方法には、透明度を連続的に使って背景と合成する方法と、一定の透明度を境に表示と非表示を切り替える方法があります。白い輪郭の原因や対象物の性質に応じて、この二つを使い分けると改善できる場合があります。

半透明描画では、透明度が低い輪郭画素も表示されるため、葉、網、髪のような細かな形状を滑らかに見せやすくなります。一方で、背景との合成結果や面の描画順序に影響されやすく、白い輪郭、色の濁り、面の重なりなどが起こることがあります。

輪郭を明確に切り分けられる標識、設備記号、板状部材などでは、一定の透明度以下を完全に非表示にする方法が有効です。透明度の低い白っぽい画素を描画しないため、白い縁が目立ちにくくなります。

ただし、透明度のしきい値を高くしすぎると、細い枝、金網、文字の細線などが消えます。低すぎると白い半透明画素が残ります。対象物の細部を確認しながら、輪郭が不自然に欠けない範囲で調整します。

樹木やフェンスなど、透明と不透明の境界が複雑な画像では、一つの設定だけですべての細部をきれいに表示することが難しい場合があります。輪郭の大きな部分はアルファ判定で表示し、繊細な部分には半透明を使うなど、画像や材質を分けて処理する方法も考えられます。ただし、材質数が増えすぎると管理が複雑になるため、本当に必要な場合に限定します。

半透明を維持する場合は、面の描画順序も確認します。透明な面が複数重なると、どの面を先に合成するかによって見え方が変わります。点群から生成したメッシュでは、小さな面が複雑に交差し、正しい奥行き順に並べにくいことがあります。その結果、輪郭が部分的に白くなったり、奥の面が手前に見えたりする場合があります。

両面表示も白い輪郭を強める原因になります。一枚の面を表側と裏側の両方から描画すると、同じアルファ画像がほぼ同じ位置で二回合成される場合があります。透明度の低い白い輪郭でも、重ねて描画されることで目立ちやすくなります。

片側からしか見ない面であれば、不要な裏面表示を避けます。両側から見る必要がある場合は、両面材質を使う方法と、表裏の面を明示的に分ける方法で結果が異なる可能性があります。実際の表示環境で、輪郭、明るさ、描画順序を比較します。

白い縁がオブジェクト同士の交差部分だけに出る場合は、画像自体よりも半透明面の重なりが原因かもしれません。対象物を一つだけ表示した場合と、複数を重ねた場合を比較すると、原因を切り分けやすくなります。

煙、薄い布、影など、連続的な透明度が必要な表現では、単純なアルファ判定へ変更すると不自然になります。白い輪郭を隠すためだけに半透明をすべて切り捨てるのではなく、対象物に必要な表現を維持したまま、透明画素の色や合成方式を先に整えることが重要です。

修正5 縮小画像と圧縮後の輪郭を確認する

元画像では白い線がないのに、点群OBJをアップロードした後や遠距離表示でだけ白くなる場合は、画像の縮小処理や圧縮が関係している可能性があります。

高解像度の画像をそのまま常に表示すると処理負荷が高くなるため、表示環境では複数段階の縮小画像が使われることがあります。遠距離では小さな画像を使い、近距離では大きな画像を使うことで、表示負荷を抑えます。

縮小画像を作るときは、複数の画素をまとめて一つの画素へ変換します。対象物の輪郭色と、透明度ゼロの白色が同じ範囲へ含まれると、白っぽい半透明画素が生成されます。近距離では元画像が使われるため問題がなくても、遠距離用の画像へ切り替わると白い縁が現れます。

この問題を防ぐには、縮小前の元画像で透明部分のRGBを輪郭色へ変更しておくことが重要です。元画像の透明部分に白色が残っている限り、アップロード先で自動縮小された際に白色が混ざる可能性があります。

自分で画像を縮小する場合は、透明度を考慮した縮小方法を使用します。RGBと透明度を単純に別々で平均すると、完全透明な白色も色の計算へ含まれます。透明度の影響を考慮して色を計算し、縮小後も輪郭色が自然につながるようにします。

大きな画像を一度に極端に縮小すると、細い枝、金網、文字、配線などの情報が失われやすくなります。輪郭が一画素未満になると、本体色と透明部分が強く混ざります。実際の表示サイズに合った解像度を用意し、必要以上に高解像度の画像をアップロード先で大幅縮小させないことも対策になります。

ただし、画像を高解像度にすれば必ず改善するわけではありません。高解像度画像が表示環境で自動的に小さく変換される場合、変換方法によっては白い輪郭が再発します。元画像の解像度だけでなく、最終的な表示サイズと縮小後の品質を確認します。

画像の圧縮でも、輪郭付近の色や透明度が変化することがあります。細かな色や透明度が一定の単位でまとめられると、輪郭に不要な色が現れたり、透明度が段階的になったりします。元画像では滑らかな輪郭でも、アップロード後に白い点や階段状の線が見える場合があります。

圧縮の影響を切り分けるには、同じ元画像から保存方法や解像度の異なる検証版を作ります。変更点を一つだけにし、同じOBJと材質設定で比較します。複数の条件を一度に変えると、どの処理が白い輪郭へ影響したのか判断できません。

色の変換も確認対象です。画像の書き出し、中間変換、アップロード後の読み込みで色の解釈が変わると、輪郭の明るさが本体と合わなくなることがあります。画像全体の色がわずかに変化しているだけでも、透明度の低い輪郭では差が目立つ場合があります。

検証時には、元画像を等倍で見るだけでなく、実際の表示に近い大きさまで縮小して確認します。黒、白、灰色など複数の背景へ重ね、輪郭の数画素に白色や暗色が発生していないかを確認します。

OBJとMTLと画像の参照関係を確認する

画像を修正したのに表示が変わらない場合は、OBJ、MTL、アルファ画像の参照関係を確認します。修正版の画像が実際に読み込まれていなければ、どれだけ画像を直しても白い輪郭は残ります。

OBJには、使用するMTLのファイル名が記述されることがあります。MTLには、材質名、色、透明度、画像の参照先などが記述されます。OBJからMTL、MTLから画像という参照が正しくつながっていることを確認します。

ファイル名は、大文字と小文字、全角と半角、空白、記号、拡張子まで一致させます。作業環境では同じファイルとして読み込めても、アップロード先では大文字と小文字を別の名前として扱う場合があります。

ファイル名には、管理上必要な範囲で単純な文字を使うと安全です。長すぎる名前、複雑な記号、複数の空白などは避け、OBJ、MTL、画像で統一します。

MTL内の画像参照に、作業端末内だけで有効な絶対的な保存場所が残っていないかも確認します。作業端末では画像が見えても、アップロード先には同じ保存場所が存在しません。アップロードするファイル構成に合った相対的な参照へ整えます。

画像が読み込めない場合、既定の白色や材質色で面が表示されることがあります。この状態はアルファ画像の輪郭が白い問題とは異なりますが、白い部分が表示されるため混同しやすくなります。輪郭だけが白いのか、画像全体が読み込まれていないのかを確認します。

修正版を同じファイル名で上書きした場合は、以前の画像が残って表示されている可能性も考慮します。検証中は一時的に画像名を変更し、MTLの参照名も更新します。OBJやMTLの名前も変更すれば、新しいデータ一式として確認しやすくなります。

複数の画像や材質を使用している場合は、必要なファイルがすべてアップロード対象に含まれているかを確認します。ファイルをまとめる場合は、展開後のフォルダ階層とMTLの参照先が一致している必要があります。

MTLに材質全体の透明度と透明画像の両方が指定されている場合、透明度が重複して適用される可能性があります。読み込み側によって解釈が異なることもあるため、検証用データでは不要な指定を減らし、単純な材質構成から確認します。

本番の複雑なOBJだけで検証すると、画像、MTL、UV、形状のどこに問題があるのか分かりにくくなります。一枚の面、一つの材質、一枚の画像だけで構成した検証用OBJを作り、同じアップロード手順で確認すると効率的です。

点群から作成したOBJ特有の原因を確認する

点群から自動生成したOBJには、一般的な手作業の3Dモデルとは異なる形状が含まれることがあります。大量の微小な三角形、細長い面、重複面、孤立面、裏返った面などが残り、アルファ画像の白い輪郭を強調する場合があります。

ほぼ同じ位置に二つ以上の面が重なっていると、アルファ画像が複数回描画されます。一回では目立たない白い半透明画素でも、重ねて合成されることで明るく見えます。視点を動かしたときに白い線がちらつく場合は、重複面や近接面を確認します。

面同士が非常に近い場合、どちらを手前に表示するかが安定せず、細かなちらつきが起こることがあります。このちらつきが白い輪郭と重なると、白い線が動いているように見えます。画像のRGBを修正してもちらつきが残る場合は、形状側の整理が必要です。

法線の向きが不統一な場合も、面ごとの明るさや表示方向が変わります。透明材質を両面表示していると、表向きの面と裏向きの面が重なり、輪郭が濃くなったり白くなったりすることがあります。

点群から生成されたメッシュには、非常に細長い三角形が含まれることがあります。細長い面へ狭いUV領域が割り当てられると、画像の補間範囲が広がり、透明部分や隣接領域の色を拾いやすくなります。

微小な面は、遠距離表示では画面上の一画素より小さくなります。その場合、本体色、透明部分、背景色が平均化され、白い点や線として見えることがあります。画像の解像度だけでなく、不要な微小面を整理し、表示目的に合ったメッシュ密度へ調整することが重要です。

点群から作成したOBJに孤立した面が残っている場合、その面へアルファ画像の一部が貼られ、対象物から離れた場所に白い破片が見えることがあります。白い輪郭と思っていたものが、実際には不要な小面である可能性もあります。

OBJが面を持たず、頂点だけで構成されている場合は、通常のUVテクスチャとは異なる表示方法が使われることがあります。表示側が各点を小さな四角形として描き、その四角形に円形のアルファ画像を適用している場合、点一つひとつの周囲に白い輪郭が出ることがあります。

点の密度が高い場所では、各点の白い縁が重なり、白い霧や膜のように見えることがあります。この場合も、点の描画に使う画像の透明部分に残った色や、アルファの合成方式を確認します。

点ごとに異なる色を表示する場合は、点の色と描画用画像の色を組み合わせる方法によって結果が変わります。透明部分へ固定の白色が残っていると、どの点色にも白い縁が加わります。点色を自然に表示できるよう、描画用画像のRGBと透明度の関係を確認します。

座標値が非常に大きいOBJでは、表示精度の影響により面の境界が細かく揺れることがあります。視点を動かすたびに白い線の位置が変化する場合は、アルファ画像だけでなく、座標原点からの距離や形状の重なりも確認します。

アップロード前後の検証手順

点群OBJのアルファ画像を修正した後は、一つの画面で白い線が消えたことだけで判断せず、複数の条件で再発しないかを確認します。

最初に、修正した画像を2次元の状態で確認します。黒、白、灰色、明るい色、暗い色の背景へ重ね、輪郭が不自然に明るくなったり暗くなったりしないかを見ます。特定の背景色でだけ線が見える場合は、透明部分や半透明部分のRGBが適切でない可能性があります。

次に、一枚の単純な面へ修正版の画像を貼ります。正面から近距離で確認し、問題がなければ面を斜めにします。斜め方向で白さが増える場合は、UV余白や画像補間を見直します。

その後、表示距離を少しずつ変えます。特定の距離で白い線が突然現れる場合は、縮小画像への切り替えが疑われます。距離に応じて徐々に白さが増える場合は、画像の縮小や面の画面占有率が関係している可能性があります。

単純な面で正常であれば、本番の点群OBJへ同じ画像と材質を適用します。本番データでだけ白くなる場合は、UV、重複面、法線、微小面、材質の重複などを確認します。

検証用ファイルは、変更内容が分かる名前で管理します。透明部分を修正した画像、アルファ方式を変えた画像、UV余白を増やした画像などを分けます。同じ名前で上書きを繰り返すと、どの変更が有効だったのか分からなくなります。

修正は一項目ずつ行います。最初に透明画素のRGB、次にアルファの合成方式、その後にUV余白、描画方式、縮小処理の順で確認すると、原因を切り分けやすくなります。

視点を固定した静止状態だけでなく、回転、拡大、縮小、上下移動も行います。重複面や半透明面の描画順序が原因の場合、視点によって白い線の見え方が変わります。

背景色を変更できる表示環境では、明るい背景と暗い背景の両方で確認します。白い輪郭は暗い背景で目立ち、暗い輪郭は明るい背景で目立ちます。どちらの背景でも輪郭が自然であることが望ましい状態です。

最終確認は、実際に業務で利用する表示環境で行います。手元の確認画面とアップロード後の画面では、画像の縮小方法、透明材質の解釈、背景色などが異なる場合があります。手元で正常だから問題がないと断定せず、最終的な利用場所で確認します。

白い輪郭を再発させないデータ作成ルール

白い輪郭を毎回個別に修正するよりも、画像作成から点群OBJアップロードまでの工程に共通ルールを設けるほうが効率的です。

アルファ画像を作成するときは、白い背景から白色だけを削除する方法に依存しないようにします。単純な背景色の削除では、輪郭の半透明画素に背景色が残りやすくなります。対象物の色と透明度を分けて調整し、背景色の影響を取り除きます。

透明領域のRGBには、対象物の輪郭色を延長します。透明度がゼロだから色は不要だと考えず、縮小や補間で参照されることを前提に作成します。

輪郭色を延長する幅も、作業者ごとにばらつかないようにします。画像の解像度や使用目的に応じて、最低限必要な余白を決めておくと、遠距離表示での白化を減らせます。

画像の書き出しでは、アルファの合成方式を統一します。作成担当者とアップロード担当者で前提が異ならないように、どの方式で画像を用意し、どの材質設定で読み込むかを整理します。

UVでは、対象物の輪郭ぎりぎりに境界を配置せず、色を延長した余白の内側へ収めます。一枚の画像に複数領域をまとめる場合は、領域間に十分な間隔を設けます。

画像を縮小する場合は、透明度を考慮した処理を使い、縮小後の画像を複数の背景色で確認します。元画像だけを確認して作業完了とせず、実際の表示サイズに近い状態でも輪郭を確認します。

OBJ、MTL、画像のファイル名は、単純で一貫した形式にします。参照先の大文字と小文字、拡張子、フォルダ階層を統一し、アップロード先で参照が外れにくい構成にします。

修正版の確認では、必要に応じてファイル名を変更し、以前の画像との取り違えを防ぎます。修正日や変更内容を管理用の記録へ残しておくと、再発時に過去の対処を確認できます。

点群からOBJを生成した後は、重複面、孤立面、微小面、法線の不統一を確認します。アルファ画像が正常でも、形状の重なりによって白い輪郭が強調されることがあります。

本番データへ適用する前に、一枚の面と一枚の画像で構成した検証用OBJを使うルールを設ける方法も有効です。検証用OBJで正常に表示できれば、画像と基本的な材質設定に大きな問題がないと判断しやすくなります。

点群OBJアップロード後の確認項目には、近距離、遠距離、正面、斜め、明るい背景、暗い背景を含めます。白い輪郭は一つの条件だけでは発見できないことがあるため、複数の条件を標準的な確認手順へ組み込みます。

まとめ

点群OBJのアルファ画像で輪郭が白くなる現象は、透明な背景を設定しただけでは防げない場合があります。透明度がゼロの画素にもRGBは残っており、その色が白いままだと、画像の補間や縮小時に輪郭へ混ざります。

最初の修正では、透明部分に残った白色を取り除き、対象物の輪郭色を外側へ延長します。次に、画像を作成したときのアルファ方式と、アップロード先が想定する合成方式を一致させます。

UV境界の周囲には余白を設け、対象物のすぐ外側や隣接領域の色が混ざらないようにします。複数の領域を一枚の画像へまとめる場合は、軽量化のために詰め込みすぎないことが重要です。

半透明が不要な対象では、透明度のしきい値によって表示と非表示を分ける方法も有効です。半透明を維持する場合は、面の重なり、描画順序、両面表示を確認します。

近距離では正常で、遠距離だけ白くなる場合は、縮小画像や圧縮後の輪郭を確認します。元画像の透明部分に白色が残っていると、アップロード先で自動的に画像が縮小された際に、白い半透明画素が作られる可能性があります。

画像を修正しても表示が変わらない場合は、OBJからMTL、MTLから画像への参照が正しいかを確認します。修正版のファイル名を変え、古い画像との取り違えを防ぐことも重要です。

点群から生成したOBJでは、重複面、微小面、孤立面、複雑なUV、法線の不統一が白い輪郭を強調する場合があります。画像側だけに原因を限定せず、形状、材質、表示条件を分けて検証します。

現場で取得した点群を継続的に活用するには、取得からアップロード、表示確認までの手順を統一することが大切です。LRTK Phoneによる現場計測を起点に、点群データの整理、OBJ変換、クラウド上での確認へつなげることで、表示不具合の切り分けやデータ管理を進めやすくなります。

現場を3Dで残して、あとから測る。
実際の画面と動画で使い方を確認できます。

LRTK Phoneの使い方・実例を見る
資料請求導入相談
現場をスマホで3DスキャンLRTK Phone実例を見る