Forgive me if this question seems odd, but I have been wondering, what is the design choice behind this limitation?
What I would love to do is simply specify the offset in bytes where the data in the VBO is allocated, and parse it based on its size using the attribute pointers.
Is there a way to do this?
Am I missing something which would make this unfeasible from the API standpoint?
Array rendering means pulling from some set of the array elements as defined by the currently bound VAO. But these array elements can be sourced from many buffers. So any “byte offset” would have to be per-buffer being used.
By contrast, indexed rendering provides a byte offset for the index buffer. This is because there can only be a single index buffer; it’s a fixed and known quantity, so the API can take it as a parameter.
The number of offsets needed for array rendering depends on the structure of your vertex format. Thus, the API can’t provide a single simple parameter; it would need to take an array of offsets based on the number of attached array buffers.
What you’re effectively wanting to do is to change the byte offset for the start of each vertex array buffer. And with separate attribute formats, you can do that easily enough by just calling glBindVertexBuffer(s) between draw calls.
Thanks for the swift reply.
While what you wrote is very informative, I am not exactly sure if it would help my case. To further explain:
I have a VBO that can contain both, data with elements and data without elements. Imagine it has the following data (And each mesh defines vertices with multiples of 8):
8 8 8 3 8
where the 8 is the number of vertices for the mesh without any elements,
3 are the elements for the previous 8 vertices and the last 8 is another object without elements.
Drawing the first 8 is not an issue, as 16 is divisible by 8, so the first draw is at index 0 and the second at index 1.
Drawing the third is also not a problem, as I am using glDrawElementsBaseVertex, which takes third argument as an offset, so I can just easily specify the address and let it do its thing.
However if I want to draw the last 8 again, I have a problem since 27 is not divisible by 8.
This leaves me with two options. Either introduce padding. (So the 27 is padded with 5 * sizeof(vertice)) bytes, so I can call glDrawArrays with index 4, or look for something else.
Ideally, I would want something like glDrawElementsBaseVertex which allows me to specify the offset and work with it from there
What do you mean by “elements” here? Are you talking about indices (as in glDrawElements)? I don’t really understand the layout of your data.
Or you call glBindVertexBuffers with new byte offsets, as I suggested.
What do you mean by “elements” here? Are you talking about indices (as in
glDrawElements)? I don’t really understand the layout of your data
Yes that is what I mean.
The example is super oversimplified. The point is that there is data that doesn’t have indices/elements and there is data that does in the same VBO.
I did solve this by using padding—which is nice, but any additional input for better / more native possibilities would be also awesome.
Or you call
glBindVertexBufferswith new byte offsets, as I suggested.
Should I concern myself with performance bottlenecks when using this method? I imagine I would have to rebind that each time I draw a new mesh.