問題タブ [heightmap]

更新問題の原因が見つかりました - 更新セクションの質問の最後を参照してください。

メイン シーンに特別な平面オブジェクトを追加する THREE.js (r60) を使用する複雑なアプリがあります。プレーン ジオメトリは、内部で提供された base64 uri イメージ (サイズ 16x16、32x32、または 64x64 ピクセル) からの高さマッピングによって決定されます。このシーンには、2 つの静的ライト (周囲光と指向性) と、オンとオフを切り替える 1 つの可動ポイント ライトがあります。

複雑なアプリ では、ポイント ライトは平面オブジェクトによって反射されません。(「R」キーまたはボタンを押すと、ポイントライトが切り替わります)。

ライトが正常に動作する THREE.js 最新バージョン (r70) を使用して 、最初の JSFiddle の例を作成しました。

[更新]古い THREE.js ライブラリ (r60) を使用して2 番目の JSFiddle の例を作成しましたが、これも問題なく動作します。

複雑なアプリ (r60) の問題は、システムの容量やタイミング/シーケンスに関係している可能性があると思われます。他の単純なシーン オブジェクト (ボックスとシリンダー) は、システム アクティビティ (CPU、メモリ使用量）。これらの単純なオブジェクトは、1 回の実行では反映されますが、次の実行では反映されない場合があります。しかし、ハイト マップされた平面オブジェクトは、一貫してポイント ライトに対して反射しません。これらの動作は、(i) Win7 ラップトップおよび (ii) Android Kitkat タブレットで観察されます。

高さマッピング プロセスが原因の一部である可能性があります。ハイトマップ プレーンをコメント アウトし、単純な同様のプレーン オブジェクト (ランダムに割り当てられた z レベルを持つ) をアクティブにすると、後者のプレーンが期待どおりに動作する (つまり、ポイント ライトを反射する) ためです。

通常のアプローチは、複雑なアプリをr70にアップグレードし（簡単な手順ではありません）、アプリのチャンクを無効にして原因を絞り込むことだと思います。ただし、ハイト マッピングが実装されている方法 (コールバックなど) が、ハイト マッピングされた平面がポイント ライトを反射しない原因の 1 つになっている可能性があります。

[再作成] したがって、以前に引用した正しく動作する (r70) JSFiddle の例のコードを誰かが見て、明らかな設計上の欠陥を指摘していただければ幸いです。 -ロードされたアプリ) は、ハイト マッピングされた平面がポイント ライトを反射できない可能性があります。

(r70) JSFiddle の完全なコード (html や css ではなく JavaScript):-

アップデート

問題はフェージングの結果であるようです。この新しい JSFiddle(r70)を参照してください。ポイントライトは関数 init() で作成されますが、シーンに追加されないか、追加された後すぐにシーンから削除されます。次に、さまざまなグラフィカル メッシュ オブジェクトが作成されます。ポイントライトが (アニメート ループで) シーンに追加された時点では遅すぎます。メッシュ オブジェクトはポイントライトによって照らされません。

手続き上の解決策は、後で使用する場合にシーンからポイントライトを削除しないことです。それらを一時的に「消す」必要がある場合は、強度を下げて後で上げてください。 myPointLight.intensity = 0.00

ここにある高さマップ シェーダーの例を、8 ではなく 32 ビットの精度で動作するものに転用しようとしています。進行中のコードは github にあります: https://github.com/bgourlie/three_heightmap

高さマップは .NET で生成されています。高さは 0f...200f の範囲内で、次のメソッドを使用して 32 ビットのカラー値 (Unity のColor struct ) に変換されます。

カラー データは png としてエンコードされ、結果は次のようになります。

頂点シェーダーはこの画像データを取得し、RBGA 値を元の高さの値に変換します (こちらの質問で回答された手法を使用します)。

結果は間違いなくめちゃくちゃです：

この行を変更することで、よりフラットにすることができます。

これにより、より平坦な画像が得られます。少なくとも、生成された地形の輪郭がきれいに表示されますが、ほぼ完全に平坦な平面が表示されます (目立たない変化ではありますが、わずかな変化があります)。

私はいくつか間違ったことをしていると思いますが、何がわからないだけです。元のフロートを正しくエンコードしているかどうかはわかりません。頂点シェーダーで正しくデコードしているかどうかはわかりません (取得している値は確かに 0 ～ 200 の範囲外です)。また、一般的に 3D グラフィックスの経験もあまりありません。したがって、私が間違っていること、または一般的にこれを達成する方法についての指針をいただければ幸いです。

ここでも、自己完結型の進行中のコードがここにあります: https://github.com/bgourlie/three_heightmap

山岳地帯の標高マップがあります (z 値を持つ大きな 2D 配列)

高さマップ上の特定のポイントのすべてのコンパス方位の見かけの水平角の高さを知りたいです。

説明のために、このウェブサイトには私が欲しいものの例がいくつかあります。

編集:私はこれを行う関数を見つけようとするのをやめ、現在自分自身を書いています。

私のアプローチは、ポイントから放射状に線を引き、それらの線に沿って高さを補間してから、各線にmax(z/r)沿って取得することです。

すでにこれを行っている関数を知っている場合は教えてください。そうでない場合は、すぐにアップロードできることを願っています。

そこで、コードを使用して地形を生成しようとしましたが、問題が発生しました。heightmapResolution を割り当てると、地形のサイズが 2 の累乗倍になります。

たとえば、heightmapResolution が 513 の場合、地形のサイズは 16 倍になります。heightmapResolution が 257 の場合、地形のサイズは 8 倍になります。

私が理解しているように (そしてこれも読んだことがあります)、heightmapResolution は地形のサイズに影響を与えるべきではありません。

サイズの増加は X 軸と Z 軸でのみ発生することを強調しなければなりません。高さは変わらず。

これが私の TerrainData を生成するブロックです。地形サイズの変更は、Debug.Log で既に確認できます ("大きな地形サイズ: " + TerrainData.size); heightmapResolution を割り当てた直後。

なぜこれが起こるのかについてのアイデアはありますか?

私は現在、OpenGL を使用した海洋レンダリング システムに取り組んでいます。高さマップは fft で計算され、見栄えがします。しかし、ハイトマップから法線マップを生成することでいくつかの問題があります。法線マップは、事前計算された高さマップをテクスチャとして使用して、フラグメント シェーダーで作成されます。法線を計算するには、sobel フィルターを使用します。コードは次のとおりです。

z0 - z7 は、高さマップ テクスチャからの高さ値です。法線は正しく計算されますが、法線テクスチャには島の段差/継ぎ目が現れ、法線マップの滑らかさが損なわれます。ハイトマップは継ぎ目/エッジがなく非常に滑らかに見えます。

高さの値との境界にそれぞれいくつかの数値の間違いがあると思いますが、それを修正する方法がわかりません。

Unity で使用するために、作成したグレースケールの高さマップを RAW ファイルに変換する必要があります。Google でこれを行う方法を数時間検索しましたが、役に立ちませんでした。Photoshopなしでこれを行う方法はありますか？ファイルは JPG として保存されましたが、必要に応じて BMP に変換できました。

C# のハイトマップ (またはハイトフィールド) クラスに双一次補間を実装しようとしましたが、Wiki の数学がよくわかりません。これは、heightfield クラスの実装です。NotImplementedException をスローする 2 番目の関数 Mathf.BilinearInterpolation(...) があります。