Render efficiently with only vertex shader [closed] - c++

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 9 years ago.
Improve this question
I have a file from which I read vertex-positions/-uvs/-normals and also indices. I want to render them in the most efficient way possible. That's not the problem. I also want to use a vertex shader to displace the vertecies, from bones and animations.
Of course I want to achieve this in the most efficient way possible. The texture is bound externally, nothing I should care about.
My first idea was to use glVertexAttribute* and glBindBuffer* etc. But I can't figure out a way to get my normals through like when I do glNormal, glTexCoord they get processed by OpenGl automatically.
Like I said I ONLY can use vertex shaders, fragment etc. is already "blocked".

Answer 1

What version of GLSL are you using?
This probably will not answer your question, but it shows how to properly setup generic vertex attributes without relying on non-standard attribute aliasing.
The general idea is the same for all versions (you use generic vertex attributes), but the syntax for declaring them in GLSL differs. Regardless what version you are using, you need to tie the named attributes in your vertex shader to the same index as you pass to glVertexAttribPointer (...).
Pre-GLSL 1.30 (GL 2.0/2.1):
#version 110
attribute vec4 vtx_pos_NDC;
attribute vec2 vtx_tex;
attribute vec3 vtx_norm;
varying vec2 texcoords;
varying vec3 normal;
void main (void)
{
gl_Position = vtx_pos_NDC;
texcoords = vtx_tex;
normal = vtx_norm;
}
GLSL 1.30 (GL 3.0):
#version 130
in vec4 vtx_pos_NDC;
in vec2 vtx_tex;
in vec3 vtx_norm;
out vec2 texcoords;
out vec3 normal;
void main (void)
{
gl_Position = vtx_pos_NDC;
texcoords = vtx_tex;
normal = vtx_norm;
}
For both of these shaders, you can set the attribute location for each of the inputs (before linking) like so:
glBindAttribLocation (<GLSL_PROGRAM>, 0, "vtx_pos_NDC");
glBindAttribLocation (<GLSL_PROGRAM>, 1, "vtx_tex");
glBindAttribLocation (<GLSL_PROGRAM>, 2, "vtx_norm");
If you are lucky enough to be using an implementation that supports
GL_ARB_explicit_attrib_location (or GLSL 3.30), you can also do this:
GLSL 3.30 (GL 3.3)
#version 330
layout (location = 0) in vec4 vtx_pos_NDC;
layout (location = 1) in vec2 vtx_tex;
layout (location = 2) in vec3 vtx_norm;
out vec2 texcoords;
out vec3 normal;
void main (void)
{
gl_Position = vtx_pos_NDC;
texcoords = vtx_tex;
normal = vtx_norm;
}

Answer 2

Here's an example of how to set up an vertex buffer in GL 3 with packed vertex data: Position, color, normal, and one set of texture coords
typedef struct ccqv {
GLfloat Pos[3];
unsigned int Col;
GLfloat Norm[3];
GLfloat Tex2[4];
} Vertex;
...
glGenVertexArrays( 1, _vertexArray );
glBindVertexArray(_vertexArray);
glGenBuffers( 1, _vertexBuffer );
glBindBuffer(GL_ARRAY_BUFFER, _vertexBuffer);
glBufferData(GL_ARRAY_BUFFER, _arraySize*sizeof(Vertex), NULL, GL_DYNAMIC_DRAW );
glEnableVertexAttribArray(0); // vertex
glVertexAttribPointer( 0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (GLvoid*)offsetof(Vertex,Pos));
glEnableVertexAttribArray(3); // primary color
glVertexAttribPointer( 3, 4, GL_UNSIGNED_BYTE, GL_FALSE, sizeof(Vertex), (GLvoid*)offsetof(Vertex,Col));
glEnableVertexAttribArray(2); // normal
glVertexAttribPointer( 2, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), (GLvoid*)offsetof(Vertex,Tex1));
glEnableVertexAttribArray(8); // texcoord0
glVertexAttribPointer( 8, 4, GL_FLOAT, GL_FALSE, sizeof(Vertex), (GLvoid*)offsetof(Vertex,Tex2));
glBindVertexArray(0);
glBindBuffer(GL_ARRAY_BUFFER, 0);
The first parameter to the Attrib functions is the index of the attributes. For simplicity, I'm using aliases defined for NVIDIA CG: http://http.developer.nvidia.com/Cg/gp4gp.html
If you're using GLSL shaders, you'll need to use glBindAttribLocation() to define these indices, as explained in Andon M. Coleman's answer.