vertex and fragment shaders in same file

[RS]

Hello
I have a suggestion regarding GLSL shaders that from my point of view would speed up, facilitate and improve developing GLSL shaders:
that there is to be only one common shader file instead of two separate (one for the vertex shader and another one for the fragment/pixel shader) like it is now.

Then instead of the one obligatory main() function you could in this common shader file have the two obligatory functions fmain() executing the fragment program and vmain() executing the vertex
program.

Then you would not have to switch between two files to answer questions like "Did I declare that varying variable in the other file?", "Was it
of the proper type?" etc.etc.

This would make it easier to find errors, (slightly) reduce total code mass and reduce the number of files in the development environment
file 'tree' so it would be quicker to spot the file you want to code in next.

This might also be more natural with coming unified shader GPU:s.

Could you please consider this unless there is some reason I don't know about making it an unfeasible idea.


regards

[V-man]

For example, unified shader vs non-unified
http://www.theinquirer.net/default.aspx?article=32769

So, it doesn't mean putting your vs and fs in the same file.

[mjkrol]

You can do it yourself.

/* common declarations */
 
#if COMPILING_VS
 
/* vertex shader code */
 
#else if COMPILING_FS
 
/* fragment shader code */
 
#endif

Then, if you load it from file to "myshader" buffer, you can do the following:

char *myshader;    /* the code above */
char *vsdefines = "#define COMPILING_VS\n";
char *fsdefines = "#define COMPILING_FS\n";
char *vshader[2] = { vsdefines, myshader };
char *fshader[2] = { fsdefines, myshader };
 
/* compile vshader and fshader */

Cheers

[Overmind]

The OpenGL spec has nothing to do with how you store your shaders in files. It just wants a string from you.

For example, I store my shaders embedded in XML files. Although my shaders are one shader per file, nothing prevents me from storing multiple shaders in a single file, or even embed the shader source directly in the material definition.

How the shaders are stored is entirely up to you, the GL spec does not mandate a file format. Just write a loading function that can load multiple shaders from one file.

[Gipsy]

sgrsd

[nib]

Here are some naive observations...

I think a multi pass kind of deal like cgfx would be cool. So, instead of ping pong between different fbos and or buffers, for instance, just use the multipass functionality in the glsl script. Opengl just handles it.

Maybe if opengl came with some default scripts every user would not have to rewrite opengl all over again! You know rebuilding the wheel over and over again -- good for college kids I suppose. Thank god for shader gen, render monkey, shader designer etc. oops none of it runs on a mac. Before in opengl 1.x, I'd have to write a few lines to have a light ... now I have to write an entire program and do math etc.

[Overmind]

There are scene graphs and other libraries for that kind of thing.

If you don't want to reinvent the wheel, use some library. But what can be done on top of OpenGL should not go into OpenGL core. Especially when it's something as complex as an FX framework. The drivers have enough bugs as it is now

now I have to write an entire program and do math etc.

You have to write a program AND do math? Now that's hard. Are you sure you're in the right profession?

[RS]

Thank you guys.
After realizing that glShaderSource(...)
seams to 'clear' the codestring pointer
arguments after each call I got it to work.

[tranders]

Originally posted by nib:
Maybe if opengl came with some default scripts every user would not have to rewrite opengl all over again! You know rebuilding the wheel over and over again -- good for college kids I suppose. Thank god for shader gen, render monkey, shader designer etc. oops none of it runs on a mac. Before in opengl 1.x, I'd have to write a few lines to have a light ... now I have to write an entire program and do math etc.

I'm behind you 100%. Shaders are a great thing but IMO harken back to the RISC vs. CISC debates back in the 80's and early 90's. Shaders let you do things really fast but to do simple things (e.g., OpenGL vertex shading) you have to code up the entire lighting model. I think the ARB should publish/post/support/maintain open source "stock" shaders that implement the current fixed function pipeline (and application code fragments for loading and communicating with them).

[knackered]

This is insane.
I think what I've read over the last few months on these forums with regards the next major GL release has just gone to show how far OpenGL drifted from its original purpose - to abstract a rendering pipeline. A pipeline that has gone from Submit-Transform-Light-Rasterize, to Submit-UserGeometryProgram-UserVertexProgram-UserFragmentProgram-Blend.

OpenGL is *not* a general purpose graphics library (even though the G and L may lead you to think so...they should change the name). It *has* to be about one thing - allowing you to communicate with a GPU, any GPU, in a unified conformant way. It's the first layer exposed to the user - why do you think stuff like this belongs in your lowest level of communication?
Anything else should be a library that *uses* OpenGL to perform what you want.

Ooooo, it makes me mad.