Jump to content
  • Advertisement
Sign in to follow this  
MARS_999

OpenGL GLSL and attributes

This topic is 4437 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

As of now I only call
glGetAttribLocation();// to setup my attributes I send to GLSL

After thinking about it I am like how does OpenGL know what index I want to use? Does the driver automatically find an open index 0-15 and assign a value to my location when I call glGetAttribLocation? Or do I need to call
glBindAttribLocation();

in addition to glGetAttribLocation to assign a index to my attribute? such as
glBindAttribLocation(p, 1, "tangent");
loc = glGetAttribLocation(p, "tangent");

Thanks

Share this post


Link to post
Share on other sites
Advertisement
You bind attributes before you link to tell the GLSL imp what number you want to map to what attribute. This doesn't have an effect until you link a program.

You call the get function to get attributes post-link to get the driver assigned index.

As a rule, you won't set and get, you'll do one or the other, depending on if you want to force a location or not.

Attribute locations only change on a link, as such you can cache results until then (same as uniform locations).

Beware that because of how NV's GLSL imp works on some(/all?) of their cards if you ask the drive to map an attribute to a number which is used for a built in attribute and then use that attribute things wont go well.

For example, you bind 'myFoo' to location 2.
You then use the built in glNormal() functions, the data from which goes into attribute slot 2.
Problems will occur.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
You bind attributes before you link to tell the GLSL imp what number you want to map to what attribute. This doesn't have an effect until you link a program.

You call the get function to get attributes post-link to get the driver assigned index.

As a rule, you won't set and get, you'll do one or the other, depending on if you want to force a location or not.

Attribute locations only change on a link, as such you can cache results until then (same as uniform locations).

Beware that because of how NV's GLSL imp works on some(/all?) of their cards if you ask the drive to map an attribute to a number which is used for a built in attribute and then use that attribute things wont go well.

For example, you bind 'myFoo' to location 2.
You then use the built in glNormal() functions, the data from which goes into attribute slot 2.
Problems will occur.



So if I don't want to use location #1 for any reason I can just forget the glBindAttribLocation and just call glGetAttribLocation and let the driver give me a index number then?

On the topic of locations only change on a link, if you don't change the data ever you shouldn't have to call the glUniform*() due to the data should still be loaded since you didn't want to change it? Now the vertex data I am assuming you need to update this every frame e.g..


glVertexAttribPointer(Shader.shaderVariable[3], 3, GL_FLOAT, GL_FALSE, vertexStride, BUFFER_OFFSET(offsetForTangents));
glEnableVertexAttribArray(Shader.shaderVariable[3]);



Share this post


Link to post
Share on other sites
Something I should have made clear in my last post, but due to issues I didn't, is that you can mix and match the setting and driver alloated ids.

Say you had 3 attribs;
foo, bar, moo.
You could tell the driver you want 'foo' and 'moo' to get at locations 4 and 6, link the shader and then ask for the location of 'bar'.

The locations used by the driver can't be assumed however, so in the above example you could get any number back which isn't 4,6 or 0 (0 is a special case and you must submit data to it to have things work, this can be done by binding a generic attribute to it OR by using glVertex*() or the glVertexPointer() functions).

For shader objects, uniform data does indeed track state, so when you rebind a program the uniform data will be as it was when it was unbound. This is handy because it means you don't have to set wasteful state information (as the uniform data is uploaded when you bind, which means if you uploaded it again you are basically uploading it twice), which is very important for texture samplers as these are expensive to change (a whole validation and lookup phase happens to see if the texture bound to the texture unit you are assigning a sample can be accessed correctly given the current texture units state and the type of sampler, see the 2005 performance video in the Forum FAQ for more details).

To be honest, when it comes to attributes I don't know if they track state or not, they could do as its only a matter of remembering an address/VBO offset, but I've never monkeyed around to try.. maybe I should...

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Something I should have made clear in my last post, but due to issues I didn't, is that you can mix and match the setting and driver alloated ids.

Say you had 3 attribs;
foo, bar, moo.
You could tell the driver you want 'foo' and 'moo' to get at locations 4 and 6, link the shader and then ask for the location of 'bar'.

The locations used by the driver can't be assumed however, so in the above example you could get any number back which isn't 4,6 or 0 (0 is a special case and you must submit data to it to have things work, this can be done by binding a generic attribute to it OR by using glVertex*() or the glVertexPointer() functions).

For shader objects, uniform data does indeed track state, so when you rebind a program the uniform data will be as it was when it was unbound. This is handy because it means you don't have to set wasteful state information (as the uniform data is uploaded when you bind, which means if you uploaded it again you are basically uploading it twice), which is very important for texture samplers as these are expensive to change (a whole validation and lookup phase happens to see if the texture bound to the texture unit you are assigning a sample can be accessed correctly given the current texture units state and the type of sampler, see the 2005 performance video in the Forum FAQ for more details).

To be honest, when it comes to attributes I don't know if they track state or not, they could do as its only a matter of remembering an address/VBO offset, but I've never monkeyed around to try.. maybe I should...


Well I am thinking they don't track state for attributes. I uploaded my data to my VBO once and then didn't call it again and nothing renders.... So apparently OpenGL needs to know where to get the array data from all the time for every VBO. I have a few VBOs one for my terrain and one for my skydome so the data must get wrote over and doesn't hold a table or something to lookup the array locations for each VBO or VA?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!