It's actually taking the color vector instead of the vertex vector. I noticed because I set the colors to random(), and the triangle clusterfudge that is my cube keeps changing shape when I reload the program.

I'm in the process of updating my code to match OpenGL3/4 standards and use PyGLM instead of numpy. Unfortunately it looks like my pointers are getting scrambled by the VAO.

I checked my view, perspective, and model matricies and they appear to be correct. I have also tried transposing them to no avail. Here's the VBO:

   vector                               color (random)
 [[-0.25       -0.25        0.25        0.4582803   0.8329993   0.36713707]
 [-0.25        0.25        0.25        0.7530541   0.87386566  0.07133926]
 [ 0.25        0.25        0.25        0.2536045   0.34725097  0.5796058 ]
 [-0.25       -0.25        0.25        0.4582803   0.8329993   0.36713707]
 [ 0.25        0.25        0.25        0.2536045   0.34725097  0.5796058 ]

Here's my shader code:

#version 420
layout (location=0) in vec3 vertex_attrib;
// in vec3 texcoord_attrib;
// layout (location=1) in vec3 normal_attrib;
layout (location=2) in vec3 color_attrib;
out vec3 vertex;
// out vec3 normal;
out vec3 color;

uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;

void main() {
    gl_Position = projection * view * model * vec4(vertex_attrib, 1.0f);
    vertex = gl_Position.xyz;
    // normal = normal_attrib;
    color = color_attrib;

Commenting/uncommenting the normal location appears to do nothing.

VAO code where it binds the pointers for the VBO:

        for args in self.vptr_args:

# args for the two calls of glVertexAttribPointer: (result of the print)
# index=0, size=3, typ=GL_FLOAT, normalized=GL_FALSE, stride=0, pointer=None
# index=2, size=3, typ=GL_FLOAT, normalized=GL_FALSE, stride=0, pointer=c_void_p(12)

I'm terribly confused. The only thing I can think of is that PyGLM says it's using high-precision floats which is messing up the offset?

enter image description here

Edit: GLGets

VertexPointer 0
Enabled:  1
Size:  3
Type:  5126
Stride:  0
Buffer binding:  1
Ptr: 0
VertexPointer 1
Enabled:  1
Size:  3
Type:  5126
Stride:  0
Buffer binding:  1
Ptr: 12
  • \$\begingroup\$ Stride 0 in GL is used to indicate tightly packed, non-interleaved data. From looking at your data it seems you should be using stride 24 for both glVertexAttribPointer calls. \$\endgroup\$ – Maximus Minimus Jul 11 '19 at 7:10

This is happening because you're using a stride parameter of 0.

In OpenGL stride 0 means that the data is tightly-packed and not interleaved; in your case this does not apply as your data layout is an interleaved vertex with the first 3 floats representing position and the second 3 representing colour.

The correct stride to use is 24, i.e. (and assuming a 4-byte float on your platform) sized for 6 floats.

  • \$\begingroup\$ Thank you! I thought stride was for abcabc type setups for some reason, despite having it set correctly on a previous iteration. \$\endgroup\$ – Alex Weavers Jul 11 '19 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.