VAO problem

OpenGL
1

There is something of an annoying problem with VAOs. It stems from how VAO attributes are connected to Program object attributes. That is, the Program object attributes (strings) have a number assigned to them, and the VAO must provide numbers that match.

This is sometimes OK, but it can be bad for certain patterns of OpenGL use. Namely, if you let Program objects choose the attribute IDs itself.

Basically, it goes like this. Each VAO should (theoretically) represent a mesh. So, you should be able to render a mesh with multiple different Program objects, so long as those Program objects take the same attributes.

However, since the Program objects are what define the attribute IDs, every time you bind a VAO to a program that it wasn’t bound to before, you have to query the program object for its version of the attribute IDs.

Basically, the problem comes from overloading the old API. Attributes in glslang are based on strings, so the VAO binding for an attribute should take an attribute string rather than an attribute ID.

2

Could you let the shaders specify which id to assign to each attribute. As there are no longer any specific ids (i.e. 0 for vertex position), it makes sense to give control of this to the developer.

So when declaring attributes in your shader you’d do:

attribute vec3 pos = 0;
attribute vec3 normal = 1;
attribute vec2 texCoord1 = 2;
etc…

Regards
elFarto

3

I’m pretty sure that this is not valid according to the language.

Even so, what you’re basically saying is that I need to consistently assign each attribute that I might use a particular number, and never (in all of my shaders) go above 16.

Why use numbers at all?

4

I know it’s not valid, it’s a possible solution to the problem.

Strings would solve the problem, but then you need to ensure that you use the same name instead of ensuring you use the same number.

You don’t need to assign each attribute a particular number. For example, if you have one shader that accept one type of vertex, you’d use:

attribute vec3 pos = 0;
attribute vec3 normal = 1;
attribute vec2 texCoord1 = 2;

and you might have another shader that accepts a different structure:

attribute vec3 pos = 0;
attribute vec3 normal = 1;
attribute vec3 velocity = 2;
attribute vec2 texCoord1 = 3;
attribute vec2 texCoord2 = 4;

I’m sure the 16 attributes per vertex limit can be increased and if there is any limit, you’d hit it with strings or numbers.

Regards
elFarto

5

I think you’re missing the point.

You’re saying that I need to adopt some ridiculous HLSL-like semantic convention, where I always bind the attribute that represents “position” to attribute 0, the attribute that represents “normals” to attribute 1, etc.

This is needlessly and unacceptably restrictive. I don’t need some semantic layer; I already have a naming convention for these things. Just give me a version of glVertexAttribPointer that takes a string instead of an attribute index.

6

Wouldn’t that be quite a bit slower? Sure it could be convenient, but switching on an integer (attribute index) is much faster than string comparisons.

7

Sure it could be convenient, but switching on an integer (attribute index) is much faster than string comparisons.

1: Not that much faster. String compares (particularly case-insensitive ones like this) can be done easily as a series of integer compares.

2: The alternative is to call glVertexAttribPointer each time I use a VAO with a particular Program. Which is exactly what VAO is supposed to be avoiding.

8

Yes, DX9 HLSL did this and it’s what put me off; I liked being able to just throw things together and grab the varyings at runtime to use.

DX10 is a step forward in that, at declaration creation, you bind to strings (which are still semantics in the HLSL/.fx declaration but are free form) and the runtime sorts it out for you.

It seems like HLSL took a nice step forward and OGL3.0 is a stumbling step backwards… :expressionless:

And this is ofcourse don’t at creation time, not during draw time, by draw time this is all sorted out and it’s a simple bind and go.