Irrlicht with Glew? Or howto check the syntax of a shader...

[GrafZahl]

Hi everyone,

I tried Irrlicht some weeks ago and it is amazing, how easy the usage of this engine is. However now I have a question to the experts.
During Shader development (with GLSL) I realized, that I want to have something more advance. For example something like a preprocessor for my shaders. To include files with "library functions" or to set preprocessor defines in the shader (so I can use the same shader for different purpose).
So I implemented a shader preprocessor class with Boost::Wave, that works quite well together with Irrlicht.
But then I realized, that I also want to do a test-compile of my shaders before I use them as Irrlicht material.

This has the advantage, that I can collect the error output and print it into a log-file instead of the std::cerr output and to change the fileposition according to the preprocessor input files, when an error was found. Furthermore Irrlicht just outputs warnings when there are also errors and I want to see Shader compile warnings anyway.

That's why I want to use glew to perform a test-compile of all shaders, before they are being using in the scene.
However for that I have to call the glewInit function and I wonder, if this might lead to issues with Irrlicht, when another library tries to use the same resources (OpenGL)?

As far as I understand, the glewInit function just maps the OpenGL function addresses to names and only for the part of software, where I use the glew symbols. So basically, since Irrlicht is mapping the OpenGL function names by itself, this should not have any impact on the engine.
Furthermore, the functions calls to OpenGL for compiling a shader should not have any side effects to the engine, right? Since by creating a new shader object, I will get a unique handle for that and as long as the engine does not use the same shader-handle, the function should not mix up anything - even when Irrlicht is doing some other stuff in "parallel" (other thread).

However especially in multi threading I should use glew contexts (GLEW MX) to be on the safe side.

What do you think? Do I oversee something?

Thanks for your feedback,
Graf Zahl

[GrafZahl]

Hi Again

In the meanwhile I came up with another Idea: Instead of using GLEW interface to compile the shaders, I found the GLSLang project. This is a Open GL reference compiler, that claims to be completely standard and very strict (not like the NVidea compiler, that seems to be quite relaxed). This reference compiler can either be used as stand-alone program or as static library for own applications.

I think this should be the best solution.

Best regards,
Graf Zahl

[hendu]

You should keep in mind some drivers are buggy, and will choke on valid GLSL (which the official compiler will pass), for example AMD and Intel blobs and most mobile drivers.

[GrafZahl]

Hi Hendu

Thanks for that hint, you are right. For example my NVidea Graphic Card accepts statements in GLSL that are not according to the standard, but allowed in Cg for example. Maybe the NVidea GLSL compiler uses shared resources with the Cg compiler?
However this is exactly the point where the independent GLSLang compiler helps during development: With this compiler I found some issues in my shaders, that where just accepted by the NVidea driver.

In the end, the GLSLang compiler is just a second source for checking during GLSL development, but it will not give me 100% confidence if my shader will work on every graphic card in world. When I want to release my shaders, there is no way around to test it on as much graphic cards and computers as possible. But this is business as usual and the same for every piece of software

BR, Graf Zahl