ARB program generic vertex attributes importance

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?

There are 16 per-vertex attributes. Not all of them are mirrored by existing GL functionality.

Also, some of the existing mechanisms (glFogCoord) expect data of a particular size (1-dimensional). The ARB_vp can handle data of 4-coordinates.

So, yes, you should handle generic attributes.

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.

Thanks for the reply.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.