Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm starting with GLSL shader programming and have been looking into RenderMonkey. Sadly, AMD no longer supports it. Why? Is there a successor to it?

share|improve this question

closed as off-topic by Byte56 Feb 4 '14 at 15:02

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions that are about "which tech to use" are outside the scope of the site. For more information, see this meta post" – Byte56
If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 29 down vote accepted

The bulk of this answer is going to be a response to the "Why?" part of your question, alas.

Well, there's FX Composer, from NVIDIA, which is a similar product -- it doesn't support GLSL but the languages it does support are quite similar. But it was last updated in 2009 and I know of no plans to update it further. Most high-end 3D modelling packages have material construction tools in them as well, which may or may not support GLSL.

I think the reason you see these products reaching end-of-life (and nothing coming out to replace them) is that the direction that shader development has taken doesn't lend itself well to generalized IDEs like this.

Even back when we just had vertex and pixel shaders, there tended to be a strong coupling between the game/engine-side data formats (and how that data is processed) and the shader input layouts and operations programmed within the shaders -- at least for the more interesting, complex effects.

Consider water-related effects, for example, which often involve deforming the geometry slightly in response to sums of sine waves (in addition to running a computation that sums similar waves into a texture to be bound to the pipeline as a bump map), as well as needing framebuffer copy textures to bind in order to simulation reflection, and so on. Most of that data comes from the CPU, and isn't built in to the shader itself.

As the nature of that coupling increased (due to increases in parallelism on the CPU side, allowing us to balance the interesting computations more evenly between CPU and GPU), it got harder and harder to design a general-purpose shader IDE because that IDE also has to have a way to script and replicate the data pipeline that a game is going to send to shader -- essentially it needed to be a plugin to an engine. As we added extra programmable stages to the pipeline -- geometry shaders, hull shaders, et cetera -- this only compounded the issue.

D3D tried to alleviate the problem with SAS, but I don't think that ever really caught on and it certainly hasn't scaled with advances in GPU technology.

As a result, specialized in-house or in-engine tools for building shaders evolved, and tools like FX Composer and RenderMonkey fell into disuse and were ultimately abandoned.

share|improve this answer
Is there a good future for OpenGL Shader Designer tool ? – iammilind Sep 28 '12 at 8:25
I don't know much about that tool, but my guess would be no, based on a very quick web search. – Josh Petrie Sep 28 '12 at 15:27

GLSL hacker. That's your answer

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.