I've been reading about "stitching" GLSL shaders together as we're trying to allow with our utility class (i.e. attaching multiple shaders of the same type).
Here are a couple of posts I found about it:
Unfortunately, linking multiple shaders together into one program is not often done, and therefore not well-tested. When I tried to do this originally, I had serious issues on both NVidia/Linux and Mac OS X.
Source: http://www.idevgames.com/forums/thread- ... l#pid37881
GLSL provides for multiple shader objects to be created, assigned GLSL source text, compiled, be attached to a program object, and then link the program object.
NVIDIA’s current driver doesn’t fully compile shader objects until the program object link. At this time all the source for a single target is concatenated and then compiled.
This means (currently) there is no efficiency from compiling shader objects once and linking them in multiple program objects.
Looks like this is still a bug on ATI. If I try to link together two vertex shader objects, one with main() and another just with a function, I get "ERROR: There was no main in the program." It doesn't matter the order in which I link them.
Source: http://www.opengl.org/discussion_boards ... Post252512
All of that, and
the fact that it doesn't work at all in OpenGL ES
, leads me to wonder why we are going to all this trouble in the first place.
It might be better to just allow for one-to-one (one vertex, one fragment) to ensure good practice and OpenGL ES compatibility.
Thoughts? I'm all for minimizing clutter. Besides; how many users will actually need to use this? And if they are that advanced, they will probably be better off pre-processing the source to allow for custom "import/include" statements (which I'm gathering is the way many big game companies do it).
We can still allow the design to separate shader compiling / linking process -- for advanced users who want to catch the errors separately.