The vertex color if all white does not interpolate visibly, so I would say you have a problem in vertex color values, or, vertex color attribute setting.
glVertexAttribPointer(1,4,GL_FLOAT,GL_FALSE,sizeof(VertexFormat),(void*)(offsetof(VertexFormat,VertexFormat::color)));
Are you sure your vertex colors are 4 component float vectors (see VertexFormat structure)? They generaly are 4 component vectors of bytes. If so change GL_FLOAT to unsigned byte.
(void*)(offsetof(struct TFontVertex, v)));
anyway you could change
glVertexAttribPointer(1,4,GL_FLOAT,GL_FALSE,sizeof(VertexFormat),(void*)(offsetof(VertexFormat,VertexFormat::color)));
to
glVertexAttribPointer(1,4,GL_FLOAT,GL_FALSE,sizeof(VertexFormat),(void*)(offsetof(struct VertexFormat, color)));and use
glVertexAttribPointer(0,3,GL_FLOAT,GL_FALSE,sizeof(VertexFormat),(void*)(offsetof(struct VertexFormat, position)));but dont enable vertexattribpointer before specifying these.
glgenvertexarrays does not return: GL_INVALID_ENUM, that seems that you have a problem somewhere else (before that line of code)
whenver you call glgeterror it returns the last error, and clears error list, so actually if you call glgeterror before glgenvertexarrays you should get the same gl_INVALID_ENUM
so load all shaders check with glgeterror
then create vbo check fo glgeterror if its still gl_invalid_enum after glgenvertexarrays then somethings wrong it shouldn't throw this.
anyway which version of opengl your card supports maybe you should delete #version tag in shaders.
like i wrote before you did these vbo and vo gluints global?
if yes i could talk about that:
since im on old notebook i cant test that so i am guessing
std::vector<VertexFormat> vertices;
vertices.push_back(VertexFormat(glm::vec3(0.25,-0.25,0.0),
glm::vec4(1,0,0,1)));
vertices.push_back(VertexFormat(glm::vec3(-0.25,-0.25,0.0),
glm::vec4(0,1,0,1)));
vertices.push_back(VertexFormat(glm::vec3(0.25,0.25,0.0),
glm::vec4(0,0,1,1)));
looks like you made your array check for values in debugger and see if you really have these values in that vector
glGenBuffers(1,&vbo);
glBindBuffer(GL_ARRAY_BUFFER,vbo);
glBufferData(GL_ARRAY_BUFFER,sizeof(VertexFormat) * 3, &vertices[0],GL_STATIC_DRAW);
&vertices[0] i am not sure but you may use &vertices.
also you could make that vector global to see if theres a sharing problem between cpu gpu.
i reckon i had problem with vectors in gl buffers too and i switched back to raw pointers.
you could post whole project code, that could help
std::vector vertices;
vertices.push_back(VertexFormat(glm::vec3(0.25,-0.25,0.0),
glm::vec4(1,0,0,1)));
vertices.push_back(VertexFormat(glm::vec3(-0.25,-0.25,0.0),
glm::vec4(0,1,0,1)));
vertices.push_back(VertexFormat(glm::vec3(0.25,0.25,0.0),
glm::vec4(0,0,1,1)));
I would probably change the colour values to 0.0 & 1.0 respectively as to avoid confusion and to see if it is any issues with if they are or are not of the right type also it makes it easier to look at and know what you expect. Even better would be to stick an f behind them all to say you want a float like
std::vector vertices;
vertices.push_back(VertexFormat(glm::vec3(0.25f,-0.25f,0.0f),
glm::vec4(1.0f,0.0f,0.0f,1.0f)));
vertices.push_back(VertexFormat(glm::vec3(-0.25f,-0.25f,0.0f),
glm::vec4(0.0f,1.0f,0.0f,1.0f)));
vertices.push_back(VertexFormat(glm::vec3(0.25f,0.25f,0.0f),
glm::vec4(0.0f,0.0f,1.0f,1.0f)));
As with filling your buffer
glBufferData(GL_ARRAY_BUFFER,sizeof(VertexFormat) * 3, &vertices[0],GL_STATIC_DRAW);
I would also suggest changing this to
glBufferData(GL_ARRAY_BUFFER, sizeof(VertexFormat) * vertices.size(), vertices.data(), GL_STATIC_DRAW);
if you change it to the above code it should have the right size even if you change your vector.
As for the problem of the colours does hard coding a colour into your shader change it to that colour? So something like
out_color = vec4(1.0, 0.0, 0.0, 1.0);
that should change the triangle to red. I know you don't want just a red one but this will eliminate the shader as the problem
if you change it to the above code it should have the right size even if you change your vector.
As for the problem of the colours does hard coding a colour into your shader change it to that colour? So something like
out_color = vec4(1.0, 0.0, 0.0, 1.0);that should change the triangle to red. I know you don't want just a red one but this will eliminate the shader as the problem
Actually it does not change anything.
I have to take the time to try all the other suggestions.
do use that shader above you need to disable attribarray for color, and do you even see a triangle?
If it doesnt change the triangle to redthat means there is a problem with the shader or the loading of itif you change it to the above code it should have the right size even if you change your vector.
As for the problem of the colours does hard coding a colour into your shader change it to that colour? So something likethat should change the triangle to red. I know you don't want just a red one but this will eliminate the shader as the problemout_color = vec4(1.0, 0.0, 0.0, 1.0);
Actually it does not change anything.
I have to take the time to try all the other suggestions.
Actually it does not change anything.
I have to take the time to try all the other suggestions.
You should pay closer attention to this.
#version 330 core
layout(location = 0) out vec4 out_color;
in vec4 color;
void main(){
out_color = color;
}
I didn't like it myself, you either do not specify pixel function output viably, or, version ... what is "core" written after 330?
I didn't like it myself, you either do not specify pixel function output viably, or, version ... what is "core" written after 330?
The output pixel is
layout(location = 0) out vec4 out_color;which is fine and the core bit refers to the shader program being core modern opengl
The output pixel is
layout(location = 0) out vec4 out_color;
which is fine and the core bit refers to the shader program being core modern opengl
The shader compiles and links succesfully, but wheather some clamping, saturating of color vector is implicit in this way of declarating pixel function output, I would consider. Also, I gess some conversion/modification happens at compilation time, so I would see the compiled assembling shader if possible, since we all know, that Opengl drivers implemented by vendors are not always the most reliable, especialy in new and fresh features, and you often need to adjust a lot of things to comply out in the wild safely.
