I want to create shaders but I need a tool to create and see the visual result before I put them into my game. As to determine if there is something wrong with my game or if it's something with the shader I created. I've looked at some like Render Monkey and OpenGL Shader Designer from what I recall of Render Monkey it had a way to define your own attributes (now as "in" for vertex shaders >= 330) easily though I can't remember to what extent. Shader Designer requires a plugin that I didn't even bother to look at creating cause it's an external process and plugin. Are there any tools out there that support a scripting language and I could easily provide specific input such as float movement = sin(elapsedTime()); and then define in float movement; in the vertex shader ?

It'd be cool if anyone could share how they develop shaders, if they just code away and then plug it into their game hoping to get the result they wanted.

  • \$\begingroup\$ What do you want to create shaders for? As in, what software does your game run on? \$\endgroup\$ – MickLH Sep 7 '13 at 17:40
  • \$\begingroup\$ Opengl ? At least I don't think GLSL works for anything else. \$\endgroup\$ – skln Sep 7 '13 at 19:27

Since I get the idea that you have rolled your own custom game software, you might as well roll your own shader tool. If you show the GLSL compile errors you are halfway there.

To bring the experience up to something realistically usable, integrate inotify into your shader loader, and trigger your engine to re-compile shaders when a change happens on disk.

This will give you a truly What-You-See-Is-What-You-Get interface for developing GLSL code without wasting massive effort. You can then use any code editor and your own engine will provide live preview. (Works great with always-on-top or multi-monitor)

EDIT: For windows you can use FindFirstChangeNotification

| improve this answer | |
  • 2
    \$\begingroup\$ +1 - editing in the engine is by far the best approach as you'll automatically have all your real levels, textures, lighting environment, and any relevant C++ code (player controls, simulation, procedural content etc.) all right there. In a standalone shader editor you'll have to do extra work to import all that stuff, or limp along without it. It's not difficult to write a shader hot-reload system and it improves your productivity like 1000%. \$\endgroup\$ – Nathan Reed Nov 6 '13 at 23:34
  • 1
    \$\begingroup\$ +1 - I agree with the in-engine approach and use it myself. I would like to add, that I believe it's pretty common to create a special shader-debugging scene/enviroment/level inside your game, where you can validate a shader's correctness under fixed, known condition, e.g. an empty image-based-lighting scene for reviewing surface shader behaviour. That way, you will be able to benefit from a reliable test-enviroment, similar to what any tool would offer you, but also from having your shaders work in the engine from the get-go. \$\endgroup\$ – Invor Nov 7 '13 at 0:37

I think it depends a little of what you are trying to achieve with your shader. But there are some online tools that can do the trick for simple shaders:


http://glsl.heroku.com (Click create new effect on the top-left corner)


Also, the galeries in these pages have a lot of shaders where you can read code and get inspired!

| improve this answer | |
  • \$\begingroup\$ Those are some really cool sights but it seems they are more for means of creating some awesome abstract art and sharing it with other people but not actually creating shaders in a game. I don't really see any 3D or such in the first 2, and the third one ... well I wouldn't want to program in that lol. Not sure if they support GLSL version 3.30 either, I should have mentioned that earlier, the version I am targeting. \$\endgroup\$ – skln Sep 7 '13 at 20:48
  • \$\begingroup\$ Is your problem debugging shaders? Usually I apply a police of doing shaders in steps, validating each one by returning the values in the pixel shader and checking if they are reasoble. In shader programming there is no place to run: you have debug returning values. There is no way to attach a debugger since shaders run in the graphics card. stackoverflow.com/questions/2508818/how-to-debug-a-glsl-shader \$\endgroup\$ – dsilva.vinicius Sep 7 '13 at 21:16
  • \$\begingroup\$ @skln No, WebGL is not up to OpenGL 3.3 standards. But I still think this answer makes sense, because any source + running examples you can lay your hands on, are going to teach you more about developing shaders... right? \$\endgroup\$ – Engineer Nov 6 '13 at 23:54

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