問題タブ [procedural-generation]

シンプレックス ノイズ アルゴリズムの C# での実装の1 つを次に示します。

各ノイズ関数 (2d、3d、および 4d) は、-1 から 1 の範囲に収まるようにコーナーの寄与をスケーリングします (これは return ステートメントのマジック ナンバーです)。これは合理的です。私の知る限り、これらは実験的に解明されたものです。

問題は、これを任意の数の次元にテンプレート化したいことです。この要因は、それを行うための 1 つの障害と思われるため、その倍率を取得するアルゴリズム的な方法を見つけたいと思います。どの要因がスケールに寄与しているかを知るにはアルゴリズムに精通していませんが、推測する必要がある場合は、上部の順列テーブルが主要なものだと思います.

おそらく実現不可能だと言うだけで、これについて何か考えがある人はいますか？

3D オブジェクトのテクスチャを頻繁に更新する必要があります。(手続き的に生成されたパターンであるため、キャッシュすることはできません。フレームごとに動的に生成する必要があります)

これを行う最速の方法は何ですか?

最初に copyPixels() 経由で bitmapData を更新し、次に Texture.uploadFromBitmapData() 経由でこのビットマップデータをフレームごとに再アップロードすることを考えましたが、これは非常に遅いと聞きました (データをシステム RAM から GPU RAM に移動するため)。

GPU でテクスチャを直接操作する方法はありますか?この手順を回避できますか?

さて、ウェブ上で見つけられるPerlinとSimplexノイズの間の多くの比較があります。しかし、私が最も興味を持っているのは、3次元の両方の処理時間の単純な比較があるものを本当に見つけることができませんでした。私はその人気のあるPDFを読みました（そしてそのほとんどを理解しました-イェーイ！）が簡単な質問に答えることはできません。最適な実装を想定した場合、3Dの方が速いのはどれですか。

このstackoverflowの質問の回答は、シンプレックスが私の場合のかなり明確な勝者であることを示唆しています。もちろん、正反対を主張する他のリソースがあります。

ただし、一般的なステートメントでは、パーリンノイズの複雑さはO（2 ^ N）であるのに対し、シンプレックスの複雑さはO（N ^ 2）であるようです。これは、3Dの場合、Perlinの場合は8、Simplexの場合は9を意味します。しかし、あるサイトで、シンプレックスは実際にはO（N）であるというステートメントを見つけました。では、ここで何が真実であり、それが3Dの速度にとって実際に何を意味するのでしょうか。

私はここで途方に暮れています、私は本当に主に3Dアプリケーション（洞窟を含むランダムな地形生成用）の使用法に興味があり、それを同じくらい速くしたい場合はどちらを使用すべきかという質問に対する良い答えを見つけることができません可能。

だから多分誰かがここで私を助けることができます:)

みなさん、こんにちは！

私は現在、道路網の手続き型生成を検討しており、Lシステムアルゴリズムに出くわしました。このテーマに関するさまざまな科学論文、およびこのテーマに関する論文のさらなる論文から私が理解していることから、アルゴリズムは「グローバル目標とローカル制約」を使用するように変更され、地形などの入力値に合うように取得されたパスが変更されますと人口密度。これで、その部分を理解するか、少なくとも全体的な概念を理解しましたが、アルゴリズムをどのように変更する必要がありますか？

現在、一連のルールに従ってタイムステップで変更される文字列があります。次に、文字列を分析し、文字を調べながら移動して回転し、結果をレンダリングして、画面に美しいパターンを表示します。

さて、主要道路のネットワークを作成するために、ルールセットで基本公理を使用してから、制約を適用する必要がありますか？もしそうなら、良い開始値とルールのセットは何でしょうか？

それとも、基本的なルールセットを制約とグローバルな目標に置き換える必要がありますか？もしそうなら、元のLシステムアルゴリズムの残りは何ですか？

どんな助けでも大歓迎です、そして私がこれをC＃とXNAでやっている記録のために、私はこれがもっと理論的な面にあると思いますが。

御時間ありがとうございます、

カール

Lazarus/Free Pascal でカスタム ウェーブを再生および合成するにはどうすればよいですか? ソリューションは、ゲーム エンジンの場合と同様に、リアルタイムに対応する必要があります。また、マルチプラットフォームである必要があるため、win32、Linux、および Mac で使用できます。FMOD/BASS は、商業的に使用したい場合に料金を払いたくないので (該当する場合でも) 使用できません。

私の目標は、パーティクル (頂点) ごとに手続き的に生成されたテクスチャを含むパーティクル システムを作成することですが、three.js を使用して、Canvas と WebGL レンダラーの両方で動作するようなパーティクル システムのプロトタイプを作成するのは難しいと感じています。

私が達成しようとしている基準：

1. レンダラー非依存(ParticleCanvasMaterial は WebGL では動作しません)
2. 円形のテクスチャ(ParticleBasicMaterial はキャンバス テクスチャが好きではないため、円形を出力できません)
3. これらのテクスチャを手続き的に生成します (準備された円テクスチャで loadTexture を使用することはできません)。

これは現在 three.js で可能ですか? いくつかの機能がありませんか?

Cellular Automata と Midpoint Displacement はどちらも、生成プロセスを完了するために生成されるグリッド自体に関する情報に依存しています。パーリン/シンプレックスノイズは、他の座標を知らなくても任意の座標を計算できるように、所定のマップを使用して特定の場所のデータを生成する唯一の方法です。

私が説明しようとしているこの違いの用語はありますか? うまくいけば検索可能な何か？

ありがとう、ティム

現在、ちょっとした楽しみのために小さなプロジェクトに取り組んでいます。OpenGL を使用した C++、WinAPI アプリケーションです。

六角形のグリッドでプレイされる RTS ゲームになることを願っています。基本的なゲーム エンジンが完成したら、さらに拡張する予定です。

現在、私のアプリケーションは、頂点と高さマップの情報を保持する VBO で構成されています。高さマップは、中点変位アルゴリズム (ダイヤモンド スクエア) を使用して生成されます。

六角形グリッドを実装するために、ここで説明したアイデアを採用しました。通常のグリッドの奇数行を下にシフトして、複雑になりすぎずに六角形を比較的簡単にレンダリングできるようにします (願っています)。

数日後、まとまり始め、マウス ピッキングを追加しました。これは、グリッド内の各ヘックスを一意の色でレンダリングし、この FBO 内の特定のマウス位置をサンプリングして、選択したオブジェクトの ID を識別することによって実装されます。セル (下のスクリーンショットの右上に表示されます)。

私のプロジェクトの次の段階では、より「プレイ可能な」地形の生成を検討したいと考えています。私にとってこれは、各六角形の形状が上の画像に見られるものよりも規則的であることを意味します。

だから最終的に私のポイントに来て、そこにある：

• 六角形のすべての点を 1 つの平面 (同一平面) に配置する現在の方法で頂点を平滑化または調整する方法。

編集：ここでポイントを共平面にする方法に関する情報を探している人にとっては、素晴らしい説明です。

• この種のことのより良い制御を可能にする手続き型地形生成へのより良いアプローチ。
• これを可能にする別の方法で頂点情報を表現する方法。

明確にするために、私は隆起したエッジまたはプラットフォーム (以下に示すように) を備えた平らな六角形のグリッドを実現しようとしているわけではありません。

)

すべてのジオメトリが結合して次のビットにつながるようにしたいと思います。

私は現在のようなもの (起伏のある丘と地形は比較的良好) を達成したいと思っていますが、台地はより制御しやすくなっています。これにより、必要に応じてより詳細なメッシュを追加できる、後で領域 (再生できないタイル) をコード化する柔軟性が得られます。

フィードバックは大歓迎です。私はこれを学習演習として使用しています。すべてのコメントを歓迎します。

現在、私は次のことを行っていますが、それは遅い方法だと確信しています。基本的に、私はグリッドを調べて、a) 星が存在するかどうか、b) 星がある場合はどのようなタイプかを判断します。私がすべきだと思うことは、既知の値 (たとえば current_star_density * 0.25) を使用し、それを使用して一連の点をプロットすることです。私が不確かな部分は、その量をプロットするときに重複を防ぐ方法だと思います.

どんな助けでもありがたく受け取られます。これは、コードの関連部分です。

球の周りに一連のランダムなフロート (0.0f - 1.0f) がある場合 (または 2D グリッドでも機能する場合)、それぞれが隣接するものと約 0.1f だけ異なる場合、これらを変換する方法はありますか?それぞれのRGB値は、色を取得する可能性が（本質的に）等しい方法で、隣接する色と約0.1fだけ異なります（したがって、一部の色は他の色よりも偏っていません）？

私が使用している方法はthisです。各頂点の最終オフセットが完了した後、すべてのオフセットを 0.0 から 1.0 の float 値にスケールダウンします。これらの float 値は値の初期分布を反映しています。役立つ場合はコード スニペットを投稿できますが、興味がある場合は編集中です。

これが潜在的な答えです、Hot Licksに感謝します! ただし、もう少し均等な分布を与えるものはいいかもしれません. それでも、それは始まりです（それ自体はちょっとクールです）、はい、ありがとうございます！

編集：余分なものの多くを削除し、質問の要点に到達しました。コード スニペットやその他の関連情報に興味がある場合は、編集内容を確認できますが、これは私が求めているのは実際には大部分です。

edit edit: (部分的な) ソリューション コード スニペットを追加しました。