PDA

View Full Version : Adding custom code to programmers shaders?



paul_g_griffiths
02-22-2017, 01:59 PM
I'm creating an engine which I hope to release to programmers, they can create their own shaders.
Now, I want to add some uniforms to the shaders and a little bit of code to the "main" function of the fragment shaders.

What's the best way of going about this?

I could do an std::string search for "void main()" and then "{" then add in some code, and add some uniforms to the beginning of the file too.

Is there a better way of handling this, like a GLSL parser library that is good?

Any advice appreciated.
Thanks.

Silence
02-23-2017, 10:18 AM
I'm not really sure of what you want to achieve. You can release your shaders as read/write text files with providing documentation about each uniform and their uses.

Cornix
02-23-2017, 12:14 PM
I assume what the OP wants is to use code injection in GLSL shaders.

I am personally not aware of any libraries that provide AST's for shaders or anything like that. But as far as I understood a full AST is not needed, just very rough code analysis to find code blocks and the likes. This should not be too difficult to implement for an experienced developer.

john_connor
02-23-2017, 01:30 PM
I'm creating an engine which I hope to release to programmers, they can create their own shaders.
Now, I want to add some uniforms to the shaders and a little bit of code to the "main" function of the fragment shaders.

What's the best way of going about this?

I could do an std::string search for "void main()" and then "{" then add in some code, and add some uniforms to the beginning of the file too.

Is there a better way of handling this, like a GLSL parser library that is good?

i'd avoid that, why giving up control over the shaders ? the user doesnt have any other control over the graphics pipeline (e.g. the attributes, uniforms, etc), what you can do is to give the user the possibility to select the "program object" YOU created:
-- make a phong shader
-- make a gouraud shader
-- make a flat shader
-- make a cel / toon shader
-- make another set of lighting shaders ...
just allow the user to select between those programs

paul_g_griffiths
02-24-2017, 02:04 AM
i'd avoid that, why giving up control over the shaders ? the user doesnt have any other control over the graphics pipeline (e.g. the attributes, uniforms, etc), what you can do is to give the user the possibility to select the "program object" YOU created:
-- make a phong shader
-- make a gouraud shader
-- make a flat shader
-- make a cel / toon shader
-- make another set of lighting shaders ...
just allow the user to select between those programs

That's not true, if I want users to create uniforms etc then I just have to program it, not too dificult.

It's just that alowing such a feature future proofs my engine and encourage more people to use it. As you can see from this screenshot, the engine is becoming a little special. :)

https://s22.postimg.org/vg28i9zv5/demo.jpg

https://s17.postimg.org/gj5kbn6xr/demo2.jpg

https://s12.postimg.org/uhbksp1i5/demo3.jpg

paul_g_griffiths
02-24-2017, 02:13 AM
I assume what the OP wants is to use code injection in GLSL shaders.

I am personally not aware of any libraries that provide AST's for shaders or anything like that. But as far as I understood a full AST is not needed, just very rough code analysis to find code blocks and the likes. This should not be too difficult to implement for an experienced developer.

Yea, don't know why I posted this thread really as simple std::string search is quite simple. Just thought I would ask anyway.

GClements
02-24-2017, 11:23 AM
Is there a better way of handling this, like a GLSL parser library that is good?

It depends upon how much of the burden you can reasonably place on the programmer. You can give them certain rules regarding the format of shaders and expect them to be followed.

Otherwise, you can use the GLSL parser from Mesa (which should be MIT licensed, being part of X11). That will be more robust (e.g. it won't fail because the programmer added an extra space, unlike a simple string search), but also more work; possibly a lot more work.