CODEWITHSUNDEEP
openglshaderopengl-3opengl-4
interfect
interfect

Reputation: 2877

How should modern OpenGL shaders be written so as to be compatible with each other?

In the fancy new versions of OpenGL (3.0 and 4.0 up), built-in vertex attributes like gl_Vertex are being deprecated. The "new way" to actually render anything is to specify your own vertex attributes for position, color, etc., and then bind these custom attributes to buffers.

My question is this: how can one do this without closely coupling the rendering code and the shader? If I write a shader that uses "position" as the vertex position, the host code using the shader has to know that and pass vertex data as "position". If I want to use a different shader that was written to take vertex data in "vertex_pos", I have to either rewrite that shader first, or modify my host code to send vertex data as "vertex_pos" instead.

Is there a set of best-practice names for standard vertex and fragment attributes that all shaders should be using? Or are there Balkanized engine-specific standards, such that a shader written for one engine cannot work on another without modification? Or are there no standards at all, such that, in general, every object needs its own custom rendering code to match its custom shader?

Upvotes: 7

Views: 3203

Answers (3)

Radu094
Radu094

Reputation: 28414

See my question for a list of possible implementations of attribute/uniform semantics. I'm afraid even with OpenGL 3.4 this issue is not going to be resolved and you are pretty much left to your own devices to define a contract between your shaders and your code.

Upvotes: 0

datenwolf
datenwolf

Reputation: 162164

Just keep calling them the old names. If you've got a core profile (i.e. no backwards compatibility) the reserved names of older GLSL specs are freed up declared as unavilable; redeclaring them for binding vertex attributes. Seems to change their availability attribute. In the compatibility profile those variable names are preallocated and binded.

So it boils down to this: Keeping the old naming in the shaders is a convenience and seems to work with the current GLSL compilers. If you want to go safe use the preprocessor to rewrite the gl_ prefix reserved names into an self choosen prefix and bind that one.

Upvotes: 3

Bahbar
Bahbar

Reputation: 18005

First, to answer your question. I am unaware of any such standard naming convention.

But... it is more complicated than attribute names. Hidden under the question is the notion of attribute semantics. Each of the input attributes have some form of semantics that each shader expects.

And what I learned from the fixed gl_ names is that they under-specify their semantics.

  • Which space is gl_Position in ? (answer: it completely depends on what the host passed in. The engine does not have to pass in something that is local-space, e.g. if it transformed it already as it required world space for different reasons).
  • is gl_TexCoord1 a texture coordinate, or really, a tangent ? what about its range ? Is it encoded ?

It's not clear that a specific nomenclature could be found that really addresses all those issues, but it would be required to make various engines compatible.

More problematic, it's not even obvious that a specific engine (or specific asset) would have the capability to provide specific attributes required by a shader coming from a different engine. What then ?

Those are all reasons why we end up with balkanized shader environments.

Upvotes: 1

Related Questions