How to include GLSL code in a release product

I’m looking for a good way to include GLSL code in our C/C++ application. In the examples I’ve seen, the code is included in separate .glsl files. It would be inappropriate to include glsl files with our application. I’ve seen other examples where the code is encoded directly in C strings like this:

const char *pVertexProgram110 =
  "varying vec2 vTexCoord;
"
  " 
"
  "void main() {
"
  "  vTexCoord   = gl_MultiTexCoord0.st; 
"
  "  gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
"
  "}
";

This doesn’t seem very elegant. I was hoping to have each GLSL program in its own file. Does anyone know of a good way to include GLSL code in a C/C++ application without releasing the .glsl files to the end user?

Use separate files and encrypt them with a text encryption library, perhaps? You could also roll your own encryption/decryption scheme using a key, depending on how secure you want the files to be. Even if you were to embed the shaders in the application itself, a tool as simple as unix “strings” can be used to extract them.

Yes encryption is the way to go - if you have a lot of shaders have a look at glsw - OpenGl Shader Wrangler - at the Little Grasshopper

You can do any of the following

[LIST=|INDENT=1]
[li]include the strings as you yourself posted above but which is possible in multiple fashions[/li][ul]
[li]define a const char* the way you already showed above[/li][li]use the pre-processor’s stringification functionality[/li][li]if you’re gonna go to C++11 any time soon, use raw string literals, which will let you write the source code like you were writing a normal text[/li][/ul]

[li]include the source code as text[/li][li]map ASCII characters to some other value so you can’t read the text without knowing the mapping and some function to unscramble the text - this way you can also produce seemingly obfuscated binary files[/li][li]go full blown encryption like malexander and tonyo suggested[/li][/LIST]

The first option is common at least for small projects and even for larger applications this is a viable solution for instance for fallback shaders of some kind. Also, you can guarantee that basic functionality expressed with shaders, like a tone-mapping algorithm or something, is always available with your application. This is cool if you have a stock set of features your application/library (think 3D engine etc.) is supposed to provide but may be overridden by the user/developer. The major drawbacks with pre-C++11 techniques is the tedious authoring and stupid compiler-dependent quirks and, first and foremost, increased executable size. It will also increase start-up time due to increased amounts of data having to be pushed into memory before actual execution.

The second option, which is basically open-source GLSL, is fine for most cases, even for larger projects if you keep your stuff together and don’t have users stupid enough to temper with your distributed files - or mean users trying to steal your stuff and sell it as your own. Side-effects include accidentally missing files, encoding or line-ending issues and some people may steal your work and claim it as their own - but that’s a risk to take when doing open-source stuff.

The third option is cool for simple obfuscation but also increases your implementation’s complexity and shader loading times. And it also still has the problems with files having to be consistent between the distributed files and the files on your development machine. Also, since this is just a simple mapping, it’s not too hard to “decrypt”. However, it sufficiently scare most people away so they don’t mess with the code.

The fourth option is far superior in terms of securing your code but it will probably introduce a third party dependency to en- and decrypt your code. This will also increase loading times and may lead to consistency problems.

Personally I’d go with

[ul]
[li]fallback and minimally guaranteed shaders included in the executable - this will get more sweet when using C++11[/li][li]the rest in human readable text files[/li][/ul]

There is 0 point in encrypting one’s shaders: this is because one sends the shaders as plain text to the GL implementation, and there are GL interceptors (and in truth it is not rocket science to make one either). As a side note there are GOOD end-user uses for GL interceptors.

On the other hand you can obsuficate the shaders and ship those.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.