If i have a 3d model with fixed geometry, but either color values that change in time, is it possible to store them separately? For example, suppose I have a grid with x,y,z,r,g,b.
The x,y,z will not change, but the rgb will. Ideally, there would be a buffer that would be loaded with the values, leaving the x,y,z untouched. Is it possible to split the sources between two separate VBOs in GLSL?
Another scenario: For a polyhedron, each vertex may be associated with multiple faces. I know some people just store each vertex multiple times so that each can have its own associated u,v.
I assume for this second scenario, there is no way for me to do it, because even if I could keep track of a separate block of u,v coordinates, there is only a single index. But I just want to verify?
Yes, you can separate vertex attributes. That’s done at api level, not at the shader level. So you could provide your coordinate vertex data with from one vertex buffer and color data from another vertex buffer that you update/change when needed. What you cannot do, is use different indices in one draw call.
Yes. The buffer that is used for an attribute is the one which is bound to GL_ARRAY_BUFFER at the time of the corresponding glVertexAttribPointer call. So each attribute can use a different buffer. OpenGL 4.3 and later has an alternative API for attribute specification: glVertexAttribBinding, glBindVertexBuffer and glVertexAttribFormat.
You have to duplicate a vertex if you want any attribute to not be shared by all copies. The simplest approach is that every triangle has its own copy of each of the three vertices, but this is inefficient. It’s more efficient to only duplicate vertices which lie on texture seams (or on sharp edges for normals).
It’s possible to implement an OBJ-like structure, where each OpenGL vertex contains indices for position, normal and texture coordinates and you have arrays (stored in uniforms, UBOs, SSBOs, or textures) containing the actual data. But this is probably the least efficient approach. In general, forcing OpenGL deal with whatever data structure you happen to have will be less efficient than structuring the data in a manner that’s convenient for the GPU.