[GLSL] Should I define "(layout = i) in" variables like uniform?

[mitras1]

Code: Select all

layout (location = 0) in vec3 pos;
layout (location = 1) in vec3 normal;

I already wrote a shader I need and now I am integrating it into irrlicht

[CuteAlien]

Something I'm still struggling a bit myself. I think you can do that as long as the order is the same as in S3DVertex (or one of it's derivated structs).

In OpenGL and GLES1 I usually work with gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord0 (to n). This isn't really recommended anymore it seems, but not sure if using layout location is better (as those variables do still work in Irrlicht+glsl, so I suppose they are send anyway - I guess ignoring those is better if you have a more flexible vertex format than Irrlicht offers right now).

In OGLES2 (in the ogl_es branch of Irrlicht) there are fixed bindings to the names in EVertexAttributes.h (inVertexPosition, inVertexNormal, ...) which can be used.

Afaik layout location is always having higher priority, so I suppose if you use that you could write a single shader which works on OGL and ES1 and ES2 all the same (thought maybe not the only difference). So that might be an advantage?

The place where I do use binding qualifiers myself currently is for texture samples, like:

Code: Select all

layout(binding = 0) uniform sampler2D ColoredTextureSampler;	// texture 0 
layout(binding = 2) uniform sampler2D ReflectionMapSampler;	// texture 2

Also if you have another stage (geometry shader) I think layout location can be useful to pass variables between shader stages, but I'm not yet too familiar with that.

[mitras1]

One more thing. Do irr::video::E_VERTEX_SHADER_TYPE/E_PIXEL_SHADER_TYPE even matter if you only use opengl shaders?

[CuteAlien]

Not seeing it used anywhere in OpenGL drivers. I guess only makes sense for d3d. Might have to do with d3d compiling to assembler earlier than GL so maybe it needs to know it's target, but I'm not sure.

I'm a bit confused why it still passes this on to COpenGLSLMaterialRenderer when that one does nothing with it. I guess that can be removed (edit: changed now in [r6634], so they were indeed useless - same for the entry-point names btw).