Closed usagi closed 6 years ago
normalの影響な気がする。
normal の強制再計算あり:
なし(現行動作):
法線の強制再計算あり:
なし:
絵から推量される問題点:
これらに加えて、ヘテロLODレベル間のテクスチャーマッピングまたは Adjacent 対応した法線計算にも考慮しないとならないかもしれない。
G3 と違い区画ごとにメッシュを分割しているため 0.5 px 調整してもタイル単位で左上は併せられるが、標高を Adjacent 補間している場合は右下方向に 1px 相当の Adjacent 補間がテクスチャーについても必要となる。素直に実装してもそこそこ遅くなるので、標高の Adjacent 補間と併せて効率化した実装の工夫を検討したい。
実用的な分解能で地図を見るレベルでは気にならないので、さしあたり Adjacent 補間ではなく線形補間してあげるだけでも実用には十分かもしれない。
そもそも地図絵のテクスチャーは "pixel" の中心がずれているわけではないので 0.5 px シフトすると不正確な表現になる。正解は外縁部をクランプして 0.5 px 分のみを引き伸ばす、である。
テクスチャーのエッジを CLAMP してテクスチャー境界が絵としてつながらない問題は解消した。
↑の対応後も境界で色の違いやズレがあるように見える事がある。こちらが恐らくエッジ部分の法線に起因する問題。
実用的な分解能では問題ないので今のところこの件はここまでの調整でよいことにしよう。より詳細に何かがユーザーニーズから問題視されるか、些細な見た目にも困る問題に具体的に遭遇したらより精密に制御を試みる事にする。
この調整は 4.0.0.10 に含める。
地形地図タイルには #3 により 4.0.0.9 からエッジ補間について標準設定を LinearEstimation から置き換えて導入となる Adjacent が導入される。同様の補間機能を絵として目に見える地図タイルにも提供したい。
但し、現在の実装では地図タイルは内部データを画素の連続、画素を RGBA の uint8 で保持しているため NaN のような無効値を直接は扱えないから、実装には何らかのオーバーヘッドを伴うため、実装方式について将来的にも問題とならないような対応を検討する必要がある。