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\$ Jul 11, 2019 at 7:10

1 Answer 1


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\$ Jul 11, 2019 at 8:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .