Direct access to buffer objects from shader

This is hopefully a very simple question. Given that data in OpenGL is now governed by buffer objects, in what ways is it possible to access buffer data directly from a shader? Here are a few (but limited) ways I know of.

  1. Through texture reads. Works only for FBO’s I guess and is slow because of how involved texture read tex2D() are. Also you are bound by maximum size limitations of textures.

  2. Bindable Uniform. This extension allows us to bind any type of buffer object to a uniform variable. I would assume this is faster then a tex2D(). The uniforms are limited in size to 64kB.

  3. NV_shader_buffer_load. Is this what I am looking for? It is vendor specific however, so not excactly optimal.

Is there a more general access, that is not size limited and does not require a specific type of buffer or access method.

Just to put things in context, let me give you an example where this might be useful. I would like to calculate vertex normals for an animated mesh. This requires access to the 1-ring neighbours of each vertex. If I could bind a VBO with vertex positions and make theese available to a vertex shader I could easilly evaulate the vertex normals. This assumes that also the indices of the 1-ring neighbours is available to the shader (theese could be passed as vertex attributes). Indices would be used to point into the buffer.

vertex shader displace -----> transform feedback positions ----> vertex shader normals ----> transform feedback normals —> complete mesh with both displace positions and displaced normals

If you nevertheless are going to pass so much of a vertex data, why not keep normal and transform it together with position?

have you looked into the texture buffer functionality ? this might be what you are looking for, and has been ARB approved.

In my example the displacement function that I am using is deformation driven (i.e a displacement function of several non trivial input parameters). Moreover the deformation function is discontinous and therefor not differentiable (although it usually behaves). The consequence is that I can not simply create a function (similar to the displacement function) that calculates the new vertex normals. I could choose a different displacement function, but that is not my call unfortunatly =)

Awsome, that is excactly what I need. It looks to have significantly simplified texture calls compare to tex2D() (no filtering, integer indexing), so hopefully the performance is alot better too. Thanks.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.