yousry wrote:Without support for GLSL includes, subroutines and partial compilation such uber-shader should be avoided. You will end up in an if else labyrinth which is unfavorable for GLSL.
That's true. That's why I propose that OpenGL3 shaders should be a separate file, and should not be mixed with OpenGL1.2 compatible shaders.
For the simplicity of the 1.2 shaders, the IFDEF solution is manageable, for OpenGL3 shaders a different mechanism can be used if needed. In fact I have already implemented a mechanism in our material system for managing shader options to be compiled in. The shader system in MH automatically manages and caches compiled shaders and compiles then when needed. The shading options to enable can be set in the Material object, as well as the texture maps that serve as input for these shaders. Generic shader arguments are also accepted.
You can see this system at work when you enable the "Material editor" plugin in Settings (then restart MH). It gives you a visual editor that allows configuring the material. Shaders with custom input parameters will make new input fields pop up in the editor. Radio boxes allow enabling or disabling shader options, which controls the DEFINE pre-processor statements.
I have not yet had the time to document the shader mechanism, but you should be able to understand it pretty quickly by looking at the existing shaders in the data/shaders/glsl folder and playing around with the material editor.
yousry wrote:If I understand you correctly you would prefer per-pixel normals instead of vertex normals?
I started with this task and you can give some early feedback . You can find the patches as attachment including the shader compile-trees. (A validation against the khronos spec)
Great! I'll have a look
Yes, we definitely want per-pixel normals. Now, I might be wrong as it's been a while since I looked at the shader code (most of the current shader code in MH is written by me, still) but I thought we were already using per-pixel normals. But no guarantees that they are actually correct.
yousry wrote:For physically based shading we would need access to additional uniforms.
As mentioned above, chances are that the current material system already offers what you need.
If I remember correctly, I still need to complete the task of allowing arbitrary 4x4 or 3x3 matrix uniforms in the material system, but floats and textures already work.
Do you have a GitHub clone
We're currently only hosted on bitbucket. I have planned to create a read-only github copy, but haven't gotten around to it yet.
Creating it is nothing, but I need to set something up that automatically keeps it in sync.