I try to encapsulate OpenGL functionality in a 3D editor to generate working source code interactively.
Now I’m working at an input mechanism for vertex attributes, which would work very much like the input of multiple texture coordinates - which leads to the following question:
Are generic vertex attributes really needed? The specification mentions, that they do already mirror existing vertex properties (such as color, fog, texture coordinates). Would there be any disadvantage, if I omit the generation of glVertexAttrib… commands entirely, and let the user pass data to vertex programs by the already existing mechanism (glVertex, glColor, glNormal and, probably most important, glTexCoord commands), which can be “abused” as any kind of data in vertex programs?
Are generic vertex attributes only of “cosmetic” nature, so that you don’t have to use a glTexCoord command, if in reality you want to encode, for example, an additional vertex displacement in it?
Not really what I wanted to hear. I guess you are right, though. According to this table of the GL_ARB_vertex_program specification
Generic
Attribute Conventional Attribute Conventional Attribute Command
--------- ------------------------ ------------------------------
0 vertex position Vertex
1 vertex weights 0-3 WeightARB, VertexWeightEXT
2 normal Normal
3 primary color Color
4 secondary color SecondaryColorEXT
5 fog coordinate FogCoordEXT
6 - -
7 - -
8 texture coordinate set 0 MultiTexCoord(TEXTURE0, ...)
9 texture coordinate set 1 MultiTexCoord(TEXTURE1, ...)
10 texture coordinate set 2 MultiTexCoord(TEXTURE2, ...)
11 texture coordinate set 3 MultiTexCoord(TEXTURE3, ...)
12 texture coordinate set 4 MultiTexCoord(TEXTURE4, ...)
13 texture coordinate set 5 MultiTexCoord(TEXTURE5, ...)
14 texture coordinate set 6 MultiTexCoord(TEXTURE6, ...)
15 texture coordinate set 7 MultiTexCoord(TEXTURE7, ...)
8+n texture coordinate set n MultiTexCoord(TEXTURE0+n, ...)
omitting generic vertex attributes would mean the loss of at least two attributes, limited access to others, and even dependency on more or less proprietary extensions for some.
However, this will lead to ambiguity in the application, since the support of ARB_vertex_program and ARB_fragment_program has to be only optional, and the traditional vertex attributes have to be accessed also for OpenGL implementations without the ARB program extensions.
This means that ppl can access the same attribute twice, if they don’t know what they do, which isn’t really pretty.
But I guess there is no beautiful workaround for this. Maybe I let the application doublecheck if traditional and generic attributes overlap and give an according warning - a solution I don’t like too much either.