点群が異常に肥大化して表示される不具合（Rikugi-en / HOUSE of HOSOO）— ADAPTIVE点サイズと平坦データの相性

[naokazuterada]

概要

一部の点群データ（HOUSE of HOSOO・Rikugi-en）で、ビューア上の点が異常に肥大化し、円盤状に重なって表示される不具合。特に植物の葉や点密度が低い領域で顕著。

（House of Hosoo / December）

この状況を再現する視点

症状

ADAPTIVE 点サイズモードにおいて、植物の葉や点密度が低い領域で点がディスク状に肥大化して重なる。地面など点密度が一様で平坦な領域では発生しにくい。

データセット	状態
HOUSE of HOSOO	❌ 不具合あり
Rikugi-en	❌ 不具合あり
joei_ji / Murinan / 風月楼 / Sessyutei 等	✅ 問題なし

---

これまでの経緯

1. ビューア側の対症療法を試行（解消せず）

• pointcloud.material.maxSize = 15（Potreeデフォルトは50）でサイズ上限をクランプ → 症状は緩和するが本質的解決にならず、見た目への影響も大きい
• 点サイズモードを ADAPTIVE → ATTENUATED（カメラ距離のみで点サイズを決定）に切替 → giant point は回避できるが見た目が大きく変わってしまう

いずれも完全な対策にはならず、現状コードは ADAPTIVE モードのまま（クランプ無し）に戻している。

2. 点群データ側の問題と判断し、提供元へ問い合わせ

当初の調査では「z方向（高さ）の範囲が x, y に対して極端に狭い」というデータ特性に起因すると判断。提供元に対し、z方向の外れ値の確認・PotreeConverter の変換パラメータ再検討・代替ツールでの変換を相談した。

3. 提供元からの回答

• 変換は PotreeConverter のデフォルト設定で実施しており、パラメータの変更箇所の調査からになる。検証効率の観点から、LASファイルをこちらに送るので寺田側で検証してほしい
• 代替ソフトでの変換は調査中
• **「z軸方向の外れ値は無さそう」**との確認結果

4. 実LASファイルを受領 → 本Issueで再調査

0101TDK_TLSLDC_M001E001.las（Rikugi-en / 1億5600万点 / 3.8GB / PDRF2）を受領し、ヘッダ解析・点分布のサンプリング・密度解析を実施。

---

今回の実LAS解析結果

① 外れ値は存在しない（提供元の確認と一致）

1億5600万点をサンプリングして全軸の分布を確認。

軸	min/max全体	上下0.1%除去後
X	-7.0 〜 431.7（438.7m）	13.4 〜 426.6（413m）
Y	34.4 〜 443.0（408.2m）	52.0 〜 438.6（387m）
Z	-7.1 〜 28.6（35.8m）	-6.4 〜 23.1（29.5m）

上下0.1%を除去してもバウンディングボックスは 438.7m → 413m とほぼ変わらない。
→ 「外れ値を除去して再変換」しても giant point は解消しないことが確定。

② spacing 3.43m は計算ミスではなく仕様どおりの値

spacing = cube一辺 / 128（PotreeConverter 2.x のデフォルト）に正確に一致（438.8 / 128 = 3.43）。
実点間距離はボクセル占有解析から約1〜2cm。3.43m はオクツリー最上位ノードの間隔であり、異常値ではない。
→ PotreeConverter 2.x をデフォルトで再変換しても完全に同じ結果（決定論的）。

③ 真の判別因子は「平坦さ（z/cube比）」

リポジトリ内の全データセットを横並び比較した結果、不具合の出る2件だけが突出して平たい。

データセット	cube一辺	spacing	実z範囲	z/cube	状態
Hosoo	116m	0.91	11.0m	9.5%	❌
Rikugi-en (新)	438.8m	3.43	39.9m	9.1%	❌
Rikugi-en (旧)	568.3m	4.44	70.1m	12.3%	(旧版)
ryogen-in	57.5m	0.45	10.0m	17.3%	✅
Murinan系	98〜118m	0.77〜0.92	33〜68m	33〜58%	✅
風月楼系	97〜143m	0.76〜1.12	29〜59m	30〜53%	✅
Sessyutei	154.6m	1.21	57.9m	37.5%	✅

• 不具合の出る2件だけが z/cube ≈ 9% と突出して平たい
• spacing の絶対値は判別因子ではない（Hosoo の 0.91 は問題のない Sessyutei 1.21 より小さい）
• z方向に薄いデータを Potree が立方体オクツリーに収めることで、ADAPTIVE モードの点サイズ算出が破綻する構図

---

結論

• 点群データに欠陥はなく、変換も誤りではない。
• 「外れ値除去 → 再変換」では直らない（②の確定事項）。提供元が同じ方向で作業しても空振りになる。
• 直すなら方向は2つ：

A. データ側で対応する場合

PotreeConverter 2.x のデフォルトでは spacing が変わらないため、より細かい spacing を強制する必要がある。

• PotreeConverter 1.x の --spacing 指定
• 変換前に z方向の薄さを考慮したダウンサンプリング 等

→ 当環境に PotreeConverter を導入して、本LASで再変換パラメータの当たりを取ることは可能（156M点・3.8GB のため変換に時間を要する）。

B. ビューア側で対応する場合

以前 ATTENUATED / maxSize を試して「見た目が変わる」と見送ったが、material.size と組み合わせて再チューニングすれば実用範囲に収まる可能性がある。実アプリ上で着地点を探れる。

推奨

まず B（ビューア側の再チューニング） で着地点を探るのが、工数・確実性ともに有利と考える（データ側は提供元の再変換待ちになり、かつ確実に直る保証がないため）。

---

補足

• 解析対象LAS: 0101TDK_TLSLDC_M001E001.las（Rikugi-en）
• 関連ファイル: app/pages/[alias].vue（pointSizeType 設定箇所 / 現状 L1616 付近）
• HOUSE of HOSOO は本Issueの解析対象外だが、同一の根本原因（z/cube ≈ 9.5%）と推定される

[naokazuterada]

調査結論と対処（ビューア側で解決）

実LASの解析・全データセット比較・ブラウザ上でのライブ検証の結果、点群データの欠陥ではなく、Potreeビューアの描画アーティファクトであることが判明し、ビューア側で対処しました。

発生メカニズム

1. ADAPTIVE点サイズモードは、各点の描画サイズを「その点が属するoctreeノードの spacing」から算出する（spacing × 1.7 をワールド空間サイズの基準にして画面投影）。
2. その spacing は boundingBox(立方体)の一辺 / 128 で決まる。庭が大きい/平たいほど cube が大きく spacing も大きくなる（Rikugi-en は spacing 3.43m）。
3. point budget が 2,000,000 で飽和しており、詳細な構図では細かいLODが読み込めず、粗いLODノード（spacing大）が画面に残り続ける。
4. その粗いノードの点が ADAPTIVE によって巨大サイズで描画され、円盤状のgiant pointsになる。

なぜ Hosoo と Rikugi-en だけか

この2つは全データセット中で bounding box が最も大きく・最も平たい（実z範囲 / cube ≈ 9%）。そのため spacing が大きく、広域で budget も枯渇しやすい。他の庭は cube が小さく spacing も小さいため目立たなかった。

確定事項

• データに欠陥はない：外れ値なし、spacing = cube/128 は PotreeConverter の仕様どおりの正常値。→ 「外れ値除去 → 再変換」では直らない（提供元へ依頼した方向は空振りになるため、再変換は不要と連絡するのが望ましい）。
• 旧ワークアラウンド pointcloud.material.maxSize = 15 は実は無効だった：このPotreeビルドの PointCloudMaterial には maxSize のプロパティアクセサが無く、代入してもシェーダーuniformに伝播しない。当時「maxSizeは効かない」と判断して ATTENUATED へ進んだのは、これが原因だった可能性が高い。

対処

app/pages/[alias].vue で、ADAPTIVE を維持したまま uniforms.maxSize.value を直接クランプ（10px）。巨大化した点だけを上限で抑え込み、giant points を解消。

pointcloud.material.uniforms.maxSize.value = 10 // px（Potreeデフォルトは50）

コミット: b1df4ec

残課題 / 今後の検討

• point budget とのトレードオフ：budgetを上げれば粗い点が減り根本的だが描画負荷・メモリと引き換え。今回は軽量な maxSize クランプを採用。性能チューニングとあわせて別途検討。
• maxSize の値（現状10px）は1行の数値で調整可能。

[naokazuterada]

📨 点群提供元への返信メッセージ（ドラフト）

先に送った調査依頼に誤りがあったため、訂正・お詫びし、「なぜ誤ったか」と「再変換は不要」を簡潔に伝える内容。

---

お世話になっております。

先日ご相談しておりました点の肥大化表示の件（HOUSE of HOSOO / Rikugi-en）、こちらで詳しく調査したところ、原因が点群データ側ではなく、ビューア（Potree）側の描画設定にあることが判明し、ビューア側の修正で解消できました。

つきましては、先にお送りした調査内容に誤りがございましたので、訂正してお詫び申し上げます。

【訂正】

• 先のメッセージで「点群データの特性（spacing と実点密度の乖離）に起因」「外れ値の除去や再変換でのご対応をご相談」とお伝えしましたが、データ側の問題ではありませんでした。
• いただいた LAS を解析した結果、z軸方向の外れ値は無く（ご確認いただいた通りです）、spacing の値も PotreeConverter の仕様どおりの正常な値でした。データに問題はございません。
• したがって、再変換やパラメータ調整は不要です。ご検証のお手間をおかけしてしまい、申し訳ございませんでした。

【なぜ誤った診断をしてしまったか】
2点の見落としが重なり、データ側の問題と早合点してしまいました。

1. これらのデータが極端に平坦で spacing が大きい、という観察自体は正しかったのですが、そこから「spacing が実点密度と乖離している＝データ/変換側の問題」と結びつけてしまいました。実際には spacing は立方体バウンディングボックスから算出される仕様どおりの正常値で、肥大化はビューアの点サイズ算出モード（ADAPTIVE）側の挙動でした。
2. 当時ビューア側の対処（点サイズ上限の設定）も試しましたが効かず、「ビューアでは直せない＝データ側の問題」と結論づけてしまいました。しかし効かなかったのはこちらの設定方法の誤り（プロパティへの代入では反映されず、シェーダーの値を直接更新する必要があった）が原因で、本来は有効な対処でした。この見落としが、誤った結論を後押ししてしまいました。

【原因と対処（簡単に）】

• ビューアの点サイズ算出モードが、点群の構造上、一部領域で点を過大に描画していたことが原因でした。
• ビューア側で点サイズの上限を制限する設定を正しく入れることで解消済みです。データの作り直しは必要ありません。

z軸外れ値のご確認や代替ソフトの調査など、お手数をおかけしました。重ねてお詫び申し上げます。
引き続きどうぞよろしくお願いいたします。

[naokazuterada]

お世話になっております。

先日ご相談しておりました点の肥大化表示の件、再度詳しく調査したところ、原因が点群データ側ではなく、ビューア側の描画設定にあることが判明し、こちらの修正で解消できました。

つきましては、先にお送りした調査内容に誤りがございましたので、訂正してお詫び申し上げます。

【訂正】

先のメッセージで「点群データの特性（spacing と実点密度の乖離）に起因」「外れ値の除去や再変換でのご対応をご相談」とお伝えしましたが、いただいた LAS を解析した結果、すでにご確認いただいていた通り、確かにz軸方向の外れ値は無く、spacing の値も PotreeConverter の仕様どおりの値でした。

【なぜ誤った診断をしてしまったか】
2点の見落としが重なり、データ側の問題と早合点してしまいました。
これらのデータが極端に平坦で spacing が大きい、という観察自体は正しかったのですが、そこから「spacing が実点密度と乖離している＝データ/変換側の問題」と結びつけてしまいました。実際には spacing は立方体バウンディングボックスから算出される仕様どおりの正常値で、肥大化はビューアの点サイズ算出モード（ADAPTIVE）側の挙動でした。
当時ビューア側の対処（点サイズ上限の設定）も試しましたが効かず、「ビューアでは直せない＝データ側の問題」と結論づけてしまいました。しかし効かなかったのはこちらの設定方法の誤り（プロパティへの代入では反映されず、シェーダーの値を直接更新する必要があった）が原因で、本来は有効な対処でした。この見落としが、誤った結論を後押ししてしまいました。

【原因と対処】

ビューアの点サイズ算出モードが、点群の構造上、一部領域で点を過大に描画していたことが原因でした。
ビューア側で点サイズの上限を制限する設定を正しく入れることで解消済みです。

z軸外れ値のご確認や代替ソフトの調査など、お手数をおかけしました。重ねてお詫び申し上げます。
引き続きどうぞよろしくお願いいたします。

[naokazuterada]

お世話になっております。

先日ご相談していた点の肥大化表示の件ですが、再調査の結果、原因は点群データ側ではなくビューア側の描画設定にあり、こちらの修正で解消できました。先にお送りした調査内容に誤りがありましたので、訂正してお詫びいたします。

【訂正】
いただいた LAS を解析したところ、ご確認いただいていた通り z軸方向の外れ値は無く、spacing も PotreeConverter
の仕様どおりの正常な値でした。いただいたデータに問題はありませんでした。

【誤りの原因】
「データが平坦で spacing が大きい」という観察自体は正しかったのですが、それをデータや変換時の問題と早合点してしまいました。実際は spacing は正常値で、肥大化はビューアの点サイズ算出モード（ADAPTIVE）側の挙動でした。当時ビューア側の対処も試したもののこちらの設定方法の誤りで効かず、「ビューアでは直せない」と誤認してしまったことも一因です。

【対処】
ビューア側で点サイズの上限を正しく設定することで、解消することができました。

外れ値のご確認や代替調査など、お手数をおかけしました。重ねてお詫び申し上げます。引き続きよろしくお願いいたします。

[naokazuterada]

補足：「可視領域が同じなら見え方も同じはず」という疑問への回答（根本原因の精密化）

疑問

ある部分データと、それを内包するより大きい平坦なデータがあり、視野内に内包部分しか写っていないとき、可視領域の元データは同一のはずなのに、見えていない周囲データの有無で見え方が変わるのは不自然ではないか。

回答：原則としてこの直感は正しい

カラクリは 「Potree は可視領域の点を“全部”描いているのではなく、LOD（詳細度）の“間引きサンプル”を描いている」 こと。

• データは octree（階層的な箱）に格納され、各ノードが「その領域の間引きサンプル」を持つ。粗いノード＝少ない点、深いノード＝細かい点。
• ADAPTIVE の点サイズは、その点が属するノードの階層（spacing）に比例する。粗いノードの点は大きく、深いノードの点は小さく描かれる。
• 画面には budget が許す深さまでのノードしか読み込まれない。

ここが核心：

小さいデータと、それを内包する大きいデータでは、同じ物理領域でも octree の階層構造が異なる（大きいデータは最上位の箱が大きく目盛りが粗い）。そのため 同じ budget の下では、大きいデータの方が“より粗い間引きサンプル”しか表示できず、「少ない・大きい点」で描かれる。

つまり 実際に描画されているサンプルが両者で同一ではない。可視領域の元データは同じでも、表示される間引き方が違うため見え方が変わる。「見えない領域のデータが魔法のように影響している」のではなく、見えない領域も含めた octree 全体の構造が「可視領域をどの粗さで間引くか」を決めている。

実機検証

Rikugi-en の同一構図で、クランプ無しのまま point budget を 2,000,000 → 12,000,000 に上げたところ（可視点数 2M→12M）、樹木・背景が明確に精細化し、giant points が大きく改善した。→ 十分な深さまで読み込めば、大きいデータでも見え方は小さいデータに収束していくことを確認。原理的に「十分な detail があれば同じに見える」という直感は正しい。

（参考スクショ: .cache/shots/40_rikugi_budget12M_noclamp.png）

残った局所的なディスクについて（別件）

budget を上げても一部（石の表面など）に残るディスクは、その場所の実スキャン点が元々まばらで、最深ノードでも spacing が大きいという 局所的なデータ密度の問題。ただしこれは「可視領域それ自体の密度」であり周囲の見えないデータとは無関係で、切り出した小データでも同様に見えるはず（＝上記 paradox とは別件）。

結論の精密化

• 「ビューア側の問題」という結論は正しいが、より正確には 「ADAPTIVE の点サイズが octree 階層に紐づき、その表示深さが（全体の bounding box で決まる octree 構造）×（point budget）で決まる」ことに起因する LOD/budget アーティファクト。
• したがって point budget の最適化（パフォーマンス vs 描画品質） #3（point budget 最適化）が本質的な対処であり、今回の maxSize クランプは「budget を上げずに巨大点だけ安価に抑える」対症療法という位置づけ。