Thanks for the input... I'm glad to know that more people think about limitations of GLSL (as opposed to F.e. HLSL).

So far I'm deciding whether I need some more preprocessing than just includes and running specific code for specific shader models (both is already implemented).

You have a problem: GLSL is kind of stupid. You can a) work around this problem as needed b) devise a new block of code to solve this problem. You're using a and it already works. If you choose b, you now have two problems. That's why most of us are using hackjob include mechanisms; writing a more elaborate parser is a pain in the ass and most of us don't want to do it despite the quirks that are there now. It requires more code that is difficult to write correctly and robustly.

At some point your shader will crash or somehow malfunction. Do you really want to be wondering whether the problem is the shader, the driver, or your intermediate compiler?

#Promit You exactly summed the things I've been thinking about. So far I came up with a bit creative solution for the game engine - as it heavily utilizes modularity and system internally compiles just GLSL shader code, I decided to "off-load" this work to plug-in, and different plug-ins will take care of F.e. just loading the files (and doing no preprocessing), or F.e. doing some pre-processing ...

E.g. you have set of plugins, through one of these you load shader file, their output is GLSL shader code (which I can dump to some text file), from there the engine compiles this shader code and links it (possible errors are dumped to log files).

I thought about making a play on words of "extend opengl" (keyword in java) but meh, no ideas.

I'm gradually coming round to the idea that for anything more than simple demos, writing shaders by hand is for the birds.

A decent graph-based material designer, and a runtime component that generates full shaders from the material definition, is really very pleasant...

I've read that there are some people against those, saying that if the visual designer is too high level you can't do interesting things with it, and that if its too low level its better to write the shader and be done with it.

Anyway I've seen a few shader editors where you can define new nodes made from other low-level'ish nodes and have all the functionality in one place, a library of shader nodes. It does seems pretty handy.

I'm redoing my GL support in the near future, but my plan is to parse my shader code offline, converting it into an intermediate representation, and then using that to generate streamlined GLSL code for the engine to use (with all includes/preprocessor statements resolved, basic optimisations applied, whitespace/variable names trimmed, etc).

Screw using raw GLSL.

As far as I know, there's no OpenGL method of any sort that accepts and uses a callback though.

See GL_ARB_debug_output.

I'm using pure GLSL with the built-in preprocessor, plus I process #includes manually in cpp, but that's it. With this I've implemented an uber-shader system, I personally didn't feel the need for much more.

As far as I know, there's no OpenGL method of any sort that accepts and uses a callback though.

See GL_ARB_debug_output.

Ah of course. And I added debug output support recently, too. Silly of me to forget about it. But it just makes it that much harder to explain the bizarre include extension.