GLSLシェーダープログラミングから始めて、RenderMonkeyを検討しています。悲しいことに、AMDはもはやサポートしていません。どうして?後継者はいますか?
GLSLシェーダープログラミングから始めて、RenderMonkeyを検討しています。悲しいことに、AMDはもはやサポートしていません。どうして?後継者はいますか?
回答:
この答えの大部分は、「なぜ?」に対する応答になります。質問の一部です。
NVIDIA のFX Composerがあります。これは同様の製品です。GLSLをサポートしていませんが、サポートしている言語は非常に似ています。しかし、2009年に最後に更新されたので、これ以上更新する予定はありません。ほとんどのハイエンド3Dモデリングパッケージには、GLSLをサポートする場合としない場合があるマテリアル構築ツールも含まれています。
これらの製品が寿命に達した(そしてそれらを置き換えるものは何も出ていない)のは、シェーダー開発の方向性がこのような一般的なIDEに適していないからだと思います。
頂点シェーダーとピクセルシェーダーだけを使用した場合でも、ゲーム/エンジン側のデータ形式(およびそのデータの処理方法)と、シェーダー内でプログラムされたシェーダー入力レイアウトと操作との間には、強い結合がある傾向がありました-少なくともより興味深い、複雑な効果のため。
たとえば、サイン波の合計に応じてジオメトリをわずかに変形させることを伴う水関連の効果を検討します(同様の波をバンプマップとしてパイプラインにバインドするテクスチャに合計する計算を実行することに加えて)。シミュレーションの反射などのために、バインドするフレームバッファコピーテクスチャが必要です。そのデータのほとんどはCPUからのものであり、シェーダー自体には組み込まれていません。
そのカップリングの性質が増加するにつれて(CPU側の並列性が向上し、興味深い計算をCPUとGPUの間でより均等に分散できるようになったため)、汎用IDEシェーダーIDEの設計がますます難しくなりましたゲームがシェーダーに送信するデータパイプラインをスクリプト化して複製する方法が必要です。基本的に、エンジンへのプラグインである必要がありました。パイプラインに追加のプログラム可能なステージ(ジオメトリシェーダー、ハルシェーダーなど)を追加したため、問題がさらに悪化しました。
D3DはSASの問題を軽減しようとしましたが、それが実際に広まったとは思わず、GPUテクノロジーの進歩に伴って確実に拡張されていません。
その結果、シェーダーを構築するための専用の社内ツールまたはエンジン内ツールが進化し、FX ComposerやRenderMonkeyなどのツールは使用されなくなり、最終的には廃止されました。
GLSLハッカー。それがあなたの答えですhttp://www.geeks3d.com/glslhacker/