I think a proposal like this would be significantly useful if it just mirrored the .fx file format (much like the CgFX attempted). Then, we’d have a real multi-platform solution. Having a GL-specific solution is no better than having a DX-specific solution, because >30% of the Windows market doesn’t have working OpenGL drivers.
I see one problem with this… the glslang is not really identical with HLSL, there are those little differences in the language. Altough haven’t really investigated the differences from a low level language semantic standpoint (maybe token substitution is enough?)
The reason nividia can do this is because they use their CG compiler wich has a language identical to HLSL. (Maybe the original glSlang designers sould have swallowed their pride and made it compatible with HLSL tough, as there don’t seem to be any good reasons for the differences.)
Charles
It’s just an idea, but what about a LoD feature?
Like
//
// Application visible variables
//
interface TestShader {
vec3 allVar;
technique A;
technique B;
technique C;
abstract vec4 difuseColor();
}
//
// Implementation
//
class TestShader {
vec3 privateVars;
vec3 privateVars2;
void test() {
}
void test2() {
}
technique A {
LoD 0 {
VertexShader =
FragmentShader =
}
LoD 1 {
VertexShader =
}
}
}
Originally posted by Corrail:
[b]It’s just an idea, but what about a LoD feature?
[/b]
I’m not sure if that really make sense on render technique description level. Imo LOD management is better done on material description level.
Material = render technique with (some) uniform parameters like textures and so on.
And then have for a material several LOD levels which can differ in render techniques and/or technique parameters.
What I don’t understand are your abstract variables. Is this something like preprocessor defines or includes? Or why do you need variables which are not defined in the shader. Where are they used?
And regarding the interface part: I think you can achieve similar behaviour without formally specifying the interface. With the layered approach render technique->material->materialbinding->mesh and semantic tags I think you don’t have to use something like formal interfaces. A render technique implementation can be used if there exist parameter(attributes/uniforms) sources for all requested parameters, regardless who or where they are provided. So all Materials/Meshes which provide all necessary parameters are compatible to a render technique. And render techniques are compatible to all Material/Meshes which provide all needed parameters.
yes, I would also prefer some one fits all solution, but like Pentagram said there are some problems. I think the biggest problem is the incompatible interface (uniforms, varying and attributes) definition in HLSL/Cg and GLSL. GLSL seem to have a more compile unit centric view. With global attribute, uniform and varyings in different shaders which are linked together. With HLSL/Cg you have more a function centric view. Functions with interface definition in the parameter list.
Hmmz I will probably drop the interface, it’s not as clean but it’s more like we are used from fx.
The abstracts are something I would like to keep tough. They would be used as follows
In fx file:
abstract vec3 lightFunc(...);
In your supporting (engine code)
Fragment f = new TextFramgent("vec3 lightfunc(...)"
" {calculations}");
effect->setParameter("lightFunc", f);
Some shaders whould thus have abstract light funcitons allowing the engine to plug in spot/directional/point/linear fallof/… lights based on what the artist selected without needing to program all cases in all shaders…
The reason I have put it in a fragment object is becuse the compiler caches based on the fragment so it doesn’t really compile on evey et (unless it’s a new fragment object of course) it’s just an more usefull way to do some sort of conditional select (besides having defines and conditionally compiling the same shader manually)The effects files handle it natively now.
The biggest problems are the abstract interface, since glslang seems to put everything in globals the abstract would need to know the internal implementation of the shader (breaking the whole idea) maybe giving abstracts a long parameter list can solve this or somehow define “public” globals that abstract can acess.
Charles