Return to Answer

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around. Only when doing something meaningful with the buffer data (e.g. using it as vertex attribute source) you finally give meaning (and corresponding alignment requirements) to the data.

So in your case you have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls). So both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) have to be properly aligned at GLfloat[3] boundaries, which they already are (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So you don't have to worry about alignment issues in your example and your errors are caused by something else.

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around. Only when doing something meaningful with the buffer data (e.g. using it as vertex attribute source) you finally give meaning (and corresponding alignment requirements) to the data.

So in your case you have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls). So both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) have to be properly aligned at GLfloat boundaries, which they already are (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So you don't have to worry about alignment issues in your example and your errors are caused by something else.

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around. Only when doing something meaningful with the buffer data (using it as vertex attribute source) you finally give meaning (and corresponding alignment requirements) to the data.

But you don't have to worry about alignment in your case. You have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls) and both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) are already properly aligned at float[3] boundaries (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So your errors are caused by something else.

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around. Only when doing something meaningful with the buffer data (e.g. using it as vertex attribute source) you finally give meaning (and corresponding alignment requirements) to the data.

So in your case you have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls). So both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) have to be properly aligned at GLfloat[3] boundaries, which they already are (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So you don't have to worry about alignment issues in your example and your errors are caused by something else.

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around.

But you don't have to worry about alignment in your case. You have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls) and both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) are already properly aligned at float[3] boundaries (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So your errors are caused by something else.

First of all that quote you give doesn't really apply to glBufferSubData itself, but to the actual buffer data at a whole when used (by whatever GL functions that actually work on the buffer object, like drawing from a VBO), since glBufferSubData doesn't have any notion of any multi-byte data types yet, it just copies a bunch of bytes around. Only when doing something meaningful with the buffer data (using it as vertex attribute source) you finally give meaning (and corresponding alignment requirements) to the data.

But you don't have to worry about alignment in your case. You have a buffer that you use as an array of 3-component 32-bit float vectors (as specified by the glVertexAttribPointer calls) and both your position and normal data (and the corresponding offsets specified in glVertexAttribPointer) are already properly aligned at float[3] boundaries (given that GL's GL_FLOAT type has the same size and alignment as C++'s float type, which is virtually always the case). So your errors are caused by something else.