🐅 🐵 🥦 惑星マップの手順生成 🧒🏿 👉🏼 🌳

幻想的な世界を扱う地図作成についてです。

手続き型マップ生成のステータス

現時点では、カードの手続き型生成はすでに主にゲーム業界の枠組み内で開発された広範なトピックです。ロールプレイやアクションゲームの単純な画像から戦略ゲームのタイルカードまで、さまざまな種類のカードを自動的に生成する方法があります。前者はゲームの場所のアイデアを与え、領土の狭い範囲によって特徴付けられ、後者は惑星全体の広大な領域をシミュレートできますが、詳細はほとんどありません。

小さなエリアのマップとレリーフを作成する方法は、以前からよく知られています。

中央値変位法、ノイズ関数法（ノイズ関数）。最近では、ゲームポリゴンのポリゴンマップ生成による平面の分割に基づいた興味深い方法が登場しました。人為的な救済のための様々なリソースへのリンクを含むサイトがあります。

原則として、ほとんどの場合、問題は景観をモデリングするためのテクスチャの作成に限定されますが、景観がどれほど美しく壮観であっても、これはまだ本格的な地図ではありません。

一般に、私たちは将来的にレリーフとマップを区別します：レリーフは一種のテクスチャであると見なし、レリーフとは異なり、マップを「タッチ」できます。これは、マップオブジェクトが別のエンティティである必要があることを意味します。さらに、マップの存在は、レリーフの存在と観察をキャンセルしません。

素晴らしい地図を提示する方法としてのGISとOpenStreetMap

地球の地図を操作するための多くのソフトウェアツールと標準があります。地理情報システムは、あらゆる種類の地理データをキャプチャ、操作、分析、表示するように設計されています。 OpenStreetMap（OSM）は、地理データを収集して自由に利用できるように設計されたGISの一例です。

OpenStreetMapプロジェクトの開発の結果として登場した、多種多様なGISだけでなく、多くのソフトウェアツールと技術は、素晴らしい惑星の地図を操作するために使用されるように頼みます。 地球がその表面とともに存在するとき、そのようなものがすでに存在した場合。

手続き型惑星生成

次に、（指で）惑星を生成するための提案された方法を説明します。惑星規模での救助を非常に迅速に行うと、コンピューターシステムの限界に到達します。実行される計算の数は、球上のグリッドポイント間のステップの減少に対して二次的に増加します。これが、惑星規模の地図が作成されなかった主な理由です。 2番目の理由は、グローバルな河川ネットワークを実装し、それを救済にリンクする必要があることです。

球近似としての二重円錐

このタスクに着手する際に最初に生じるのは、三角関数の計算を回避することですが、これは球では不可能です。球体にテクスチャを作成するには、まず立方体などの通常の多面体の端に描画し、次に球体に表示する方法があります。このようなマッピングを持つ多面体の角度が歪みを与えることは明らかです。この方法を大きな惑星に適用すると、歪みが目立ちすぎます。このアプローチの別のバリエーションを使用します。

隙間なしで、基部で接続された丸い円錐上に惑星の球を表示します。同時に、赤道線は円錐の接続線と一致する必要があります 。コーンにレリーフを構築するプロセスの最後に、球体への逆マッピングを行います。もちろん、歪みを避けることはできませんが、さまざまな方法でマッピングを行うことにより、結果として生じる歪みを球体上で異なる方法で分布させることができます。良いニュースは、三角関数の計算を完全になくしたことです。

作業用ディスプレイとして、子午線に沿った距離を保存するオプションを使用します。垂直方向では歪みを完全に回避し、水平方向では歪みが直線的に増加し、極付近では歪みの増加が減少し、最大1.57に達します。

このようなマッピングは、極近くに海または白い斑点がある惑星に適しています。赤道または中緯度では、導入された歪みを視覚的に認識することは困難です（選択されたメイングリッドによって導入された歪みがより顕著になる場合があります）。

2つのレベルのカード生成

円錐図法を使用した単純化を考慮しても、惑星全体の計算はメモリ消費の観点からコストがかかります。この問題を解決するために、2レベルの生成に頼ります。まず、メインまたはグローバルグリッドを生成します。このグリッドの主なパラメーターは数量gnで、赤道の4分の2 ^gnに等しいグリッド分割数を決定します。メイングリッドで高さを生成するプロセスにより、クリーチャーのメインセクションが明らかになります。また、陸と海に落ちるポイントの数の比率によって海面を設定します。

作られた惑星の例では、gn = 7。これはかなり控えめな量であり、アルゴリズムを最適化してハードウェアを構築する過程で、新しい惑星のgnを徐々に増やすことが可能になります。

メイングリッドを構築するプロセス。 4 * 2 ^gn赤道をポイントで長さlの同一のセグメントに分割し、ゼロ子午線に沿って北までの距離lで後退し、現在の緯線を4 *（2 ^gn -1）セグメントに分割します。さらに極までプロセスを続け、各反復で後続の各平行線上のポイントの数を4ずつ減らします。南半球でも同じことを行います。各グローバルグリッドポイントは、円錐上の菱形を定義し（例外：比較可能な菱形を持たない極点）、二重円錐全体が菱形に分割されます。これらは、平面ではなく、丸い円錐の表面上の菱形であることに注意してください。次の図は、gn = 2の場合に上部円錐の4分の1を含む菱形のメインネットワークのフラグメントを示しています（精度を主張せず、ポイントを明確にするのに役立ちます）。

ダブルコーンのグリッドへの移行は、予期しない結果につながります。メイングリッド（極なし）のポイントは、次元2 ^{gn x} 4 * 2 ^gnの配列に配置されます。これを行うには、まず南円錐と赤道の点を配列に入力し、次に北円錐の点を右の空いている座席に置き、左から右に展開します。その結果、多くの円錐ベースのアルゴリズムは、球体で可能なアルゴリズムよりも単純に見えます。

ここでは、たとえば、半径rの南極の近傍の高さを1だけ増加させる関数のコードがどのように見えるかを示します（より一般的な場合、プロジェクトコードの実際の関数は異なって見えます）。

import Data.Array.Base import Data.Array.ST type Height = Int type GHeights = UArray (Int,Int) Height type GHeightsMutable s = (STUArray s (Int,Int) Height) -- | Make Heights array mutable thawGHeightsArr :: GHeights -> ST s (GHeightsMutable s) thawGHeightsArr = unsafeThaw -- | Increase values around south pole shiftSouth :: GHeights -> Int -> GHeights shiftSouth hs r = runSTUArray $ do a <- thawGHeightsArr hs mapM_ (\y -> (mapM_ (\x -> do v <- readArray a (x,y) writeArray a (x,y) (v + 1) ) [1..4*y]) ) [1..r] return a

メイングリッドにレリーフを生成する場合、いくつかの重要な陸地の形成に努めています。河川システムは土地セクションごとに独立して構築されるため、計算を並列化するには、土地を別々のセクションに分離することが重要です。これは、メイングリッドの高さの分布を表す惑星のモデルです。

次のレベルに進むために、各菱形にローカルグリッドを確立し、菱形の頂点（メイングリッドに属する）の既知の高さに基づいてレリーフを構築します。したがって、結果として生じる緩和は一種のマルチフラクタルになります。

ローカルグリッドの主なパラメーターはln値で、2方向のグリッドステップ数を設定します：2 ^ln +1および2 * 2 ^ln +1。図は、ln = 3にローカルグリッドがある菱形の例を示しています。

レリーフを生成するために、1つの菱形の高さの配列のみがメモリに必要なアルゴリズムを実装できます 。これにより、高解像度のマップオブジェクトを持つ惑星を生成できます。

複雑で多段階のアルゴリズムを使用してプロジェクトを実装する場合、多くの場合、中間データのビジュアルイメージを構築する必要があります。たとえば、惑星を作成する過程での島の平均サイズの画像です。菱形への分割は破線で示されています。