次の形式の 2D 高さマップがあります
06 36 39 42 43 55 ...
37 40 43 43 45 46 ...
40 43 44 45 46 48 ...
44 44 46 47 48 50 ...
41 44 45 47 48 48 ...
...
そして、それをグリンベースの輪郭形式に再マップする必要があります(さらにスプライトにマップできるようにするため)
. . . . | . .
. . . . \ . .
. . . / / . .
. . . | . . .
. . . | . . .
. / - / . . .
ここでは、平坦なエリア、まっすぐな崖、崖の角 (それぞれ 2 つの異なる可能性を表しています).
を意味します。|
-
/
\
標準的なマーチング スクエア アプローチを試してみましたが、隣接するケースに過負荷がかかるため、3 つの近傍のみをサンプリングすると、かなり多くの問題が発生することがわかりました。(下の余分な場違いなまっすぐな崖に注意してください)
. . . . | . \
. . . . \ \ .
. . . / / - .
. . . | - . .
. . . | . . .
. / - / . . .
私が望むのは、この種の処理に役立つアルゴリズム/アプローチへの参照です。ある種の深さ優先検索を使用した輪郭ウォーキングがオプションであることは知っていますが、まだ試していないため、最後の手段として残しておくことをお勧めします。一部のフィーチャの表現の問題もあります。たとえば、1 要素の厚さの崖の尾根を含めるか、単に無視するかです。もう 1 つのオプションは、生成された輪郭を通過させ、それらを変更して滑らかに適合させることですが、これは本当にハックに思えます...