VBO and compute shader

OpenGL OpenGL: Basic Coding
1

hi!

I try to access to vertex list and face index.

glBindBufferBase(GL_ARRAY_BUFFER,10,((ModelGL*)(n->getModel()))->getVertex());
glBindBufferBase(GL_ARRAY_BUFFER,11,((ModelGL*)(n->getModel()))->getFaces());

and in my compute :

layout (std430,binding = 10) readonly buffer Vbuffer
{
vec3 vertex;
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
face faces;
};

It doesn’t work.
Any idea?

2

Solution : bind vbo as GL_SHADER_STORAGE_BUFFER

Now, i’ve a second problem, it seems do deal with padding.
My vertcies are vec3 and my faces are 3 int. I try std140 and std430 without good results…

3

My vertcies are vec3 and my faces are 3 int.

Even in std430 layout, 'vec3’s use the base alignment of 'vec4’s. So each array element is 4 values.

Also, the term “VBO” (to the degree that you should use that term) only applies to a buffer object that is bound to GL_ARRAY_BUFFER. Buffers can be bound to many targets, but they’re all still just buffer objects, no matter how you use them.

1 Like
4

To avoid thos f***ing padding issues, i tweak my acces to the VBO from

layout (std430,binding = 10) readonly buffer Vbuffer
{
vec3 vertex;
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
face faces;
};

to

layout (std430,binding = 10) readonly buffer Vbuffer
{
float vertex;
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
int faces;
};

To acces the data, the solution is simple :

vec3 readVertex(uint index)
{
return vec3(vertex[3index],vertex[3index+1],vertex[3*index+2]);
}

ivec3 readFace(uint index)
{
return ivec3(faces[3index],faces[3index+1],faces[3*index+2]);
}

Thanks!

5

It should be noted that the vec3 alignment thing was something specifically put into the API. Probably for a good reason. Which means you probably shouldn’t bypass it like this unless you have a good reason to do so. The compiler could easily turn your memory usage into 3 separate memory access operations, rather than a single one in the case of a vec3 (even padded to a vec4).

So this could be more of a memory/performance tradeoff.