手続き的に生成されたテクスチャはどうなりましたか？[閉まっている]

少し前に、手続き的に生成されたテクスチャが大きな問題になり、多くの人々/企業がいくつかの深刻な利点（小規模な展開、潜在的に高速な読み込み、高品質、スケーラブルなテクスチャ、潜在的に安価な製造など）に本当に興味を持っていたことを思い出します）。

私が言うことができることから、バズは死んでいて、私のレーダーのゲームはそれらを使用していません。何が起こった？

手続き型テクスチャがNaturalMotionのものと同じように動くことを期待していました（ゆっくりですが着実に採用されています）。

手続き型テクスチャリング用のコンテンツ作成ツールが最大の障害となっています。アーティストはPhotoshopでの処理を非常に高速に行っており、プロシージャルテクスチャリングの潜在的な利点は、コンテンツ作成時間の増加を上回っていません。

Allegorithmic（http://www.allegorithmic.com/）には、手続きオプションをよりユーザーフレンドリーにするために開発した興味深いツールがいくつかあります。しかし、それらのユーザビリティについて実際にコメントするほど十分に遊んでいない。

芸術的なコントロールが失われ、ストレージオプションのサイズが大きくなったため、これは売れ行きが悪くなりました。それに加えて、アーティストを再教育する必要がありますが、伝統的なテクスチャリングが得意なアーティストを雇いました。サイズや独自のテクスチャリングが実際に問題でない限り、一般的な手続き型の方法はほとんどありません。

基本的に、大きな銃はそれをサポートしていないため、あまり使用されていません。.kkriegerのようなクールなもの（少し古いですが）がありましたが、ロード時にすべてのテクスチャを生成しなければならなかったため、その（以前の）ロード時間はかなり遅かったです。

次世代エンジン（Unreal 4など）で何かを見るかもしれませんが、開発に対するゲインが十分に大きいとは思いません。

AAAの世界には例があります。たとえば、Sporeは、作成したクリーチャーのテクスチャとアニメーションを手続き的に生成しています。

プロシージャルテクスチャには、アートディレクターがアーティストの作品を確実に指し示すことができず、「その部分をもう少しXにしてください」と言うことができないという問題があります。これは、手続き型シェーディングシステムがXを安価にまたはまったくサポートしていない可能性があるためです。

たとえば、レンガシェーダーはきれいな茶色のレンガをサポートしますが、80年前に広告が描かれ、10年前にグラフィティが描かれたレンガはサポートしません。または、1,000個の茶色のレンガのうち1個の紫色のレンガを持つことをサポートしていない場合があります。アートディレクターの好みにアピールするため、まさにその1つのスポットで。

もちろん、実際のテクスチャはこれらすべてをサポートでき、この意味で実際のテクスチャは手続き型テクスチャよりも優れています。

プロシージャルテクスチャは、特定のユースケースが他のユースケースよりも優先されるため、芸術的なコントロールを発揮します。実際のテクスチャでは、このような制御はほとんど行われません。

ただし、テクスチャメモリはシェーディングを行うALUユニットから非常に多くのサイクル離れているため、GPUハードウェアは手続き主義を強く好みます。

まあそれはまだゲームのための素晴らしいアイデアのようです。プレイヤーの周囲の世界がより自然に見えるように、テクスチャをオンザフライでプロシージャルに生成できるため。ビッグデータは必要ありません。解像度を上げるために必ず使用できます

典型的な時間メモリのトレードオフがあります。さて、好むと好まざるとにかかわらず、手続き型生成はメモリ時間を節約するためにCPU時間と引き換えになります。実際、ストレージが安くなり、人々は常に読み込み時間を短くしたいので、傾向は逆になります-事前に生成または撮影されたアセットは速度と引き換えにメモリを消費します。

jpgは手続き的に生成されたバージョンよりも高速にロードされますか？ほとんどの場合、はい。jpgが2MBで、一度ロードした場合、なぜ手続きを行う必要があるのですか？実行時に、テクスチャはとにかく同じ量のRAMを使用します（非圧縮でGPUメモリにロードされます）