非常に大きなゆっくり回転する惑星を描く


8

ゆっくりと回転する惑星の非常に大きな(500ピクセル以下)グラフィックを描画したいと思います。これらのグラフィックは印象的なものです。これを行う最良の方法は何ですか?私は特定の3Dエンジンの経験がなく、このゲームがどのプラットフォームで動作するかさえわかりません。

  • 各フレームを事前にレンダリングすることもできましたが、500pxで10秒の回転周期で、これは惑星ごとに途方もない量のデータです。
  • 3Dエンジンを使用して、惑星のテクスチャを球に近づくメッシュにマッピングすることができますが、500pxでは、見栄えをよくするためにポリゴン数が膨大になる必要があるのではないかと心配しています。
  • 各ビューピクセルのx / y座標を球のテクスチャの座標空間に変換することで、テクスチャ球を効率的にレンダリングするだけの一種のカスタム3Dエンジンを書くことができますが、これは複雑であり、メリットを得ることができませんでしたグラフィックアクセラレーション。
  • 私が考えていない他の何か?

ここに私が何を意味するかのアニメーションGIFの例があります。(100x100 pxと60フレームで、それはすでにかなり巨大です、申し訳ありません。)これだけ、非常に大きく、非常にゆっくり回転し、よりスムーズにアニメートされることを想像してください。

代替テキスト

ただし、これが500x500ピクセルで10 x 25 = 250フレームの場合、数百MBのデータについて話しているため、この単純なアプローチは機能しません。


ターゲットプラットフォームがわからない場合、これを答えることは不可能です。
AttackingHobo 2010

1
まあ、それが500pxのサイズの場合、それは4G以前のiPhone /同等のAndroidではありません。

8
うーん、答えは単に「ザルコネン、最近のGPUがどれほど強力であるか分からない」だろうと思います。:P
ザルコネン2010

1
これは大量のデータのようには見えません。
共産主義者ダック

回答:



4

一定のカメラで球を見ているので、単純な事前計算されたルックアップテーブルを使用して、高品質のレンダリングを非常に高速に行うことができます。

事前計算ステップとして、任意の方法(通常はポリゴンまたはレイトレーシング)で、テクスチャマップされた球体をオフシーンバッファーにレンダリングしますが、テクスチャに基づいて色を計算する代わりに、テクスチャのu / v座標のみを保存します。

次に、実際の惑星をレンダリングするときに、単純な正方形をレンダリングし、各ピクセルについて、ルックアップテーブルから実際のu / v座標をフェッチし、それらのu / v座標を使用して惑星テクスチャからピクセルカラーをフェッチします。球を回転させるには、回転角度でU座標をオフセットするだけです。

このテクニックは、たとえばテクスチャマップされたトンネル効果など、デモシーンで非常に人気がありましたが、残念ながら、それについての適切なチュートリアルを見つけることができませんでした。


0

これを2D設定で行う場合は、前の質問を参照してください...

2D惑星テクスチャの3Dイリュージョン

同じ概念は、大きな画像で、空間の「穴」の下にあるレイヤーの地形テクスチャを動的に移動することでうまく機能します。

上記のリンクを読んで、これが私が何を意味するかを理解してください。


3
その方法とまったく同じように見えるので、私はその方法が本当に好きではありません。回転するときに歪みのない移動されるフラットテクスチャ。
AttackingHobo 2010

0

結果のアニメーションを最新のビデオコーデックで圧縮した場合、それは特に大きくはなく、「数百MBのデータ」に近く、馬鹿げたこともありません...

しかし、すでに述べたように、それはすべて、ターゲットプラットフォームが何であるかに依存し、他の誰もが言ったとおりです。滑らかな3D球体をレンダリングするだけでは、実際にはわずかな量のポリゴンと非常に少ないデータストレージしか含まれません(テクスチャがすべて存在し、非常に高い解像度であっても、標準のJPEG圧縮では何も起こりません)。

それはすべて、あなたがどれほどうるさいかにも少し依存します-あなたがすべての補間とエイリアシングを備えた現代のゲームだけでなく、最新のデモと同等のクォーターピクセルのスクロールルックとテクスチャの詳細を求めている場合8x FSAAでも問題が発生します-達成するためにほぼ無限に関与する可能性があります(そして少し芸術的なトリックも必要です)^^


1
-1-テクスチャには「標準のjpeg圧縮」は存在せず、3番目の段落は実際には意味がありません。「1/4ピクセルスクロール」は、OpenGL / Direct3Dの標準のフィルタリングを介して実現でき、AAはそのようなシーンでは簡単です。

本当です。私の弁護では、質問がアニメーションソリューションについて「惑星ごとの途方もない量のデータ」と述べたとき、私はデータスループットではなく、データストレージを考えました。最後の段落は、ほとんどの場合、基準がどのくらい高く設定されているかを尋ねるコメントでした。私はAAがささいなものだとは見たことがありません。エキゾチックな方法で何百回ものパスを行うフィルムの最も厳密なオフラインレンダリングソリューションでさえ、特に低密度のPC画面で動きが始まるとすぐにエイリアスが発生しますが、ほとんどの人はそうではありません。選り好み。
Oskar Duveborn 2010

0

これを行う従来の方法(高ポリゴン球でのテクスチャと通常のマッピング)でパフォーマンスに問題がある場合、多くの人が言及したように、その解像度では問題にならないはずです。

フラグメントシェーダーでそれを「レイトレース」します。カメラが固定されている場合、必要なのはフラグメントシェーダーへの均一な浮動小数点入力(回転角度)だけであり、シェーダーはテクスチャ座標の計算を処理できます。ライティングベクトルは、各フレームでも同じになる場合があります。アンチエイリアスに関しては、工夫の少ない完璧な球形のシルエットを取得することもできます(ピクセルが球の境界上にある場合、そのカバレッジを計算します)

これにより、パイプラインを介して送信するのは4つの頂点のみであり、ジャギーと戦うために巨大なマルチサンプルフレームバッファーを割り当てる必要はありません。

いくつかの受注生産のアルゴリズムを考え出さなければならないという犠牲を払って。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.