OpenGL 3.2 Core
Posted 08 January 2010 - 08:45 PM
I've a question about OpenGL 3.2 Core specification and Vertex Buffer Object.
This tutorial is yet the "state of the art"?
If we talk about the rendering in OpenGL, using the core specification, is this the right way?
Posted 09 January 2010 - 04:14 AM
Not quite. glVertexPointer(...) and glColorPointer(...) have been deprecated.
The *new* way to do things is to do everything with with more generic functions. The downside is that you must create your own vertex and fragment shader programs. The up side is that the opengl api is simplified and is more flexible. You can specify any data you want to be sent to your shaders with attributes and uniforms (ie, glGetAttribLocation).
What I recommend is to, for each mesh, have a vertex VBO that contains striped data (ie, x1,y1,z1, r1,g1,b1, x2,y2,z2, r2,g2,b2...) and also one poly VBO. You could also pack in normals into the vertex VBO, or any other data that you want.
When you draw, you call glBindBuffer(...) to bind the vertex VBO.
Then you call glVertexAttribPointer(...) to let your shader know which stripes of your vertex VBO go with which attributes. In the case of having only coordinate and color information, you would have to call glVertexAttribPointer twice, once to tell the shader where the coordinates are, and once to tell it where the colors are.
Then you would glBindBuffer(..) your poly VBO and then call glDrawElements(...)
I hope that helps
Posted 09 January 2010 - 01:02 PM
And in this I can store each information that I need (vertex, normals, color, ecc...).
Posted 09 January 2010 - 04:42 PM
For example, say for a mesh you have a VBO for its vertices that contains data for 4 vertices, then you would also have a VBO for its polygons. The VBO for the polygons might contain the array of GLints (1, 2, 3; 1, 3, 4) which would say that you have 2 polygons, the first made up of the vertices number 1, 2 and 3, and the second made up of vertices 1,3, and 4. So the poly VBO refers to the vertices in the vertices VBO.
Is it clear now? It took me quite a bit of searching and time to get all this figured out the first time I did it.
To summarize (leaving out some openGL calls), to do things the *new* way, you need to:
1. Write a vertex shader and a fragment shader and use the appropriate openGL functions to compile and enable the shaders for use.
2. Make two VBOs for each mesh(one for vertices, one for polygons).
3. Use the glGetAttributeLocation(...) to get handles for the attribute variables in your shader program.
4. Use glVertexAttribPointer(...) to set your VBO to those attribute variables in your shader program.
5. Draw you polygons with glDrawElements(...)
If I get the time, I should really make a full tutorial about this...
Posted 10 January 2010 - 12:20 PM
Is it clear now?
Posted 10 January 2010 - 04:39 PM
Even if you want to add normals or any other information for the vertices you can put that in the VBO you have for vertices.
For example, say your vertex shader has takes in two attribute variables, "position" and "normal".
The VBO for the vertices could look like:
[x1,y1,z1,nx1,ny1,nz1; x2,y2,z2,nx2,ny2,nz2;...] where x,y,z are the positions of each vertex, and nx, ny, nz make up normal vector for each vertex.
When you call glVertexAttribPointer(...) you supply starting point, size, and stride parameters for the values that should get assigned to the attribute variables in your shader program.
When your vertex shader runs, it runs once per each vertex, so the first time it runs, the attribute variable "position" in your vertex shader would get the value (x1,y1,z1) and the attribute variable "normal" would get the value (nx1,ny1,nz1). The next time it runs, "position" would get (x2,y2,z2), and "normal" would get (nx2, ny2, nz2) and so on.
I believe that it is also possible, if you prefer, to make separate VBOS instead of packing all the vertex information together in stripes into one vertex VBO. You could have something like:
Vertex Position VBO
Vertex Normal VBO
Vertex Color VBO
You would have to make quite a few more glBindBuffer calls, but that likely isn't going to hurt performance too much.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users