Sign in to follow this  
noodleBowl

OpenGL Attribute locations for shaders matter?

Recommended Posts

noodleBowl    713

I have quick question when it comes to OpenGL ES 2.0 and shader attributes:
 
What is the best way to deal with the location that OpenGL assigns a shader attribute?

 

What I mean is when I use glVertexAttribPointer to "map" my vertex buffer / vertex shader the location matters in the sense that if one device returns 1 and 2 for my vertexPosition and color attributes. And then another device decides to returns 20 for the vertexPosition and 10 for the color attribute.

 

Wont that mess up my mapping? Causing the shader to mess up what should be displayed to the screen.

In this case my vertex buffer is packed like [VC VC VC VC]

Share this post


Link to post
Share on other sites
C0lumbo    4411

You can use glBindAttribLocation before linking to tell GLES which index to put each attribute in.

 

I'm pretty sure there's also a way of asking GLES where it has put each attribute, but I don't seem to be using that in my codebase, and I can't remember how to do it.

Share this post


Link to post
Share on other sites
cgrant    1826

If you are using generic vertex attributes, then you should have made the connection between the index being used in the glVertexAttribPointer call and the vertex attribute being used in the shader instead of assuming the shader compiler is going to fill in the blanks. Querying for the indices used by the shader take the guess work out the entire equation.

Share this post


Link to post
Share on other sites
SeanMiddleditch    17565
In general, yes, the indices matter... in that querying for them is a bad idea (you should never need or use glGetAttribLocation).

Use layout qualifiers to hardcode the attribute locations in your shaders.
 
layout(location = 0) in vec4 position;
layout(location = 1) in vec2 texCoord;
layout(location = 2) in vec3 normal;

The advantage is that now you can guarantee that all your shaders agree on attribute locations (e.g. position is always attribute 0 in all shaders, texture coordinates are always attribute 1 in all shaders that use textures, etc.) and your code can be made more or less completely agnostic to which shaders are in use; you can swap shaders at runtime and the code wont' have to recache attribute indices or anything.

Share this post


Link to post
Share on other sites
noodleBowl    713

I knew about the glGetAttribLocation() call, but I was more worried about the attributes location and my vertex buffer
 
For example if I pack my vertex buffer like this: [ VertPos Color | VertPos Color | VertPos Color | VertPos Color ]
Then a call using glVertexAttribPointer() looking like this:

glVertexAttribPointer(currentAttrib.location, currentAttrib.size, currentAttrib.type, currentAttrib.normalized, vertexAttribsStride, currentAttrib.offset)

Might mess everything up because of the offset not being the right value. But with the call C0lumbo gave this should no longer be a issue.

 

Makes me wonder how you specify your vertex buffer correctly without that call

Edited by noodleBowl

Share this post


Link to post
Share on other sites
C0lumbo    4411

I knew about the glGetAttribLocation() call, but I was more worried about the attributes location and my vertex buffer
 
For example if I pack my vertex buffer like this: [ VertPos Color | VertPos Color | VertPos Color | VertPos Color ]
Then a call using glVertexAttribPointer() looking like this:

glVertexAttribPointer(currentAttrib.location, currentAttrib.size, currentAttrib.type, currentAttrib.normalized, currentAttrib.offset, vertexAttribsStride)

Might mess everything up because of the offset not being the right value. But with the call C0lumbo gave this should no longer be a issue.

 

Makes me wonder how you specify your vertex buffer correctly without that call

 

I don't think it matters. In your glVertexAttribPointer call you're giving two pieces of information, there's the offset and the location.

 

The location relates to the index given to the attribute in the shader program

The offset relates to the position of the attribute within your interleaved vertices

 

The two things don't have to be in the same order. Attribute location could be colour then position. Your vertex buffer layout could be position then colour. It'd still work fine (although now you've got me wondering if there might be some performance cost).

Share this post


Link to post
Share on other sites
noodleBowl    713

I don't think it matters. In your glVertexAttribPointer call you're giving two pieces of information, there's the offset and the location.
 
The location relates to the index given to the attribute in the shader program
The offset relates to the position of the attribute within your interleaved vertices

 

At first I was not sure, but then it clicked. That offset param is geared towards the vertex buffer packing. Not the way the attributes are presented in the shader code

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By Arulbabu Donbosco
      There are studios selling applications which is just copying any 3Dgraphic content and regenerating into another new window. especially for CAVE Virtual reality experience. so that the user opens REvite or CAD or any other 3D applications and opens a model. then when the user selects the rendered window the VR application copies the 3D model information from the OpenGL window. 
      I got the clue that the VR application replaces the windows opengl32.dll file. how this is possible ... how can we copy the 3d content from the current OpenGL window.
      anyone, please help me .. how to go further... to create an application like VR CAVE. 
       
      Thanks
    • By cebugdev
      hi all,

      i am trying to build an OpenGL 2D GUI system, (yeah yeah, i know i should not be re inventing the wheel, but this is for educational and some other purpose only),
      i have built GUI system before using 2D systems such as that of HTML/JS canvas, but in 2D system, i can directly match a mouse coordinates to the actual graphic coordinates with additional computation for screen size/ratio/scale ofcourse.
      now i want to port it to OpenGL, i know that to render a 2D object in OpenGL we specify coordiantes in Clip space or use the orthographic projection, now heres what i need help about.
      1. what is the right way of rendering the GUI? is it thru drawing in clip space or switching to ortho projection?
      2. from screen coordinates (top left is 0,0 nd bottom right is width height), how can i map the mouse coordinates to OpenGL 2D so that mouse events such as button click works? In consideration ofcourse to the current screen/size dimension.
      3. when let say if the screen size/dimension is different, how to handle this? in my previous javascript 2D engine using canvas, i just have my working coordinates and then just perform the bitblk or copying my working canvas to screen canvas and scale the mouse coordinates from there, in OpenGL how to work on a multiple screen sizes (more like an OpenGL ES question).
      lastly, if you guys know any books, resources, links or tutorials that handle or discuss this, i found one with marekknows opengl game engine website but its not free,
      Just let me know. Did not have any luck finding resource in google for writing our own OpenGL GUI framework.
      IF there are no any available online, just let me know, what things do i need to look into for OpenGL and i will study them one by one to make it work.
      thank you, and looking forward to positive replies.
    • By fllwr0491
      I have a few beginner questions about tesselation that I really have no clue.
      The opengl wiki doesn't seem to talk anything about the details.
       
      What is the relationship between TCS layout out and TES layout in?
      How does the tesselator know how control points are organized?
          e.g. If TES input requests triangles, but TCS can output N vertices.
             What happens in this case?
      In this article,
      http://www.informit.com/articles/article.aspx?p=2120983
      the isoline example TCS out=4, but TES in=isoline.
      And gl_TessCoord is only a single one.
      So which ones are the control points?
      How are tesselator building primitives?
    • By Orella
      I've been developing a 2D Engine using SFML + ImGui.
      Here you can see an image
      The editor is rendered using ImGui and the scene window is a sf::RenderTexture where I draw the GameObjects and then is converted to ImGui::Image to render it in the editor.
      Now I need to create a 3D Engine during this year in my Bachelor Degree but using SDL2 + ImGui and I want to recreate what I did with the 2D Engine. 
      I've managed to render the editor like I did in the 2D Engine using this example that comes with ImGui. 
      3D Editor preview
      But I don't know how to create an equivalent of sf::RenderTexture in SDL2, so I can draw the 3D scene there and convert it to ImGui::Image to show it in the editor.
      If you can provide code will be better. And if you want me to provide any specific code tell me.
      Thanks!
    • By Picpenguin
      Hi
      I'm new to learning OpenGL and still learning C. I'm using SDL2, glew, OpenGL 3.3, linmath and stb_image.
      I started following through learnopengl.com and got through it until I had to load models. The problem is, it uses Assimp for loading models. Assimp is C++ and uses things I don't want in my program (boost for example) and C support doesn't seem that good.
      Things like glVertexAttribPointer and shaders are still confusing to me, but I have to start somewhere right?
      I can't seem to find any good loading/rendering tutorials or source code that is simple to use and easy to understand.
      I have tried this for over a week by myself, searching for solutions but so far no luck. With tinyobjloader-c and project that uses it, FantasyGolfSimulator, I was able to actually load the model with plain color (always the same color no matter what I do) on screen and move it around, but cannot figure out how to use textures or use its multiple textures with it.
      I don't ask much: I just want to load models with textures in them, maybe have lights affect them (directional spotlight etc). Also, some models have multiple parts and multiple textures in them, how can I handle those?
      Are there solutions anywhere?
      Thank you for your time. Sorry if this is a bit confusing, English isn't my native language
  • Popular Now