我从GLSL着色器编程开始,一直在研究RenderMonkey。可悲的是,AMD不再支持它。为什么?是否有继任者?
我从GLSL着色器编程开始,一直在研究RenderMonkey。可悲的是,AMD不再支持它。为什么?是否有继任者?
Answers:
这个答案的大部分将是对“为什么?”的回应。您的问题的一部分,a。
恩,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/