   GLSL and attributes
  As of now I only call glGetAttribLocation();// to setup my attributes I send to GLSLAfter 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 callglBindAttribLocation();in addition to glGetAttribLocation to assign a index to my attribute? such asglBindAttribLocation(p, 1, "tangent");loc = glGetAttribLocation(p, "tangent");Thanks   
  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.   ;Quote:Original post by phantomYou 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]);;  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...   ;Quote:Original post by phantomSomething 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?   