VBOs with vertex and normal indices

I’ve done a search on the internet and in the forum about the problem of having a number of normals different of the number of vertices for a model.

It’s possible, when using VBOs to have an index array for the normals in order to not duplicate data?

For instance, when I have a cube, each vertex has tree normals, one for each face. How can I deal with this using VBOs?

AFAIK the index array always indexes all enabled vertex attribute arrays, when you use a glDrawElements() draw call of course.

Now if you want to do your own vertex attribute lookups in the shader based on index list(s) you pass in (or cascaded lookup of normal vectors using position and normal “indices” you pass in for the position and normal attributes, for instance), you could theoretically index positions and normals with different lists. But depending on how you do this it may or may not play nice with the post vertex shader cache, causing you to lose efficiency when reusing verts.

If you pass the indices in as the vtx attribs, should work without killing your cache, though the cost of doing the indirection to lookup the real positions and/or normals may very well hurt your net perf. You can try it and see.

Dark Photon, thanks for your reply. The problem I’m facing is exactly how to use a different list for the normals (and other vertex attributes).

Every example code I saw works in the same way. Define a list of vertices, define a list of normals (one for each vertex), set the pointers with glVertexPointer and glNormalPointer and call glDrawElements once. Doing this will use all the data set with glVertexPointer and glNormalPointer with a single list of indices (Am I correct?)

Now, let’s say I wanna a high performance approach (in the case where I might have different normals for the same vertex). In this case I’m gonna need to duplicate some vertices in order to have the same number of vertices and normals. Do you agree that maybe I’ll spend more time processing the model mesh instead of rendering?

That’s not my case, I need to render static data and having duplicate data is not a concern. But I’m trying to figure out how to manage a dynamic mesh in a modeling program for instance. I think that keep duplicate data in memory may be not pratical for huge models.

Yes. That’s the standard glDrawElements() usage.

Now, let’s say I wanna a high performance approach (in the case where I might have different normals for the same vertex). In this case I’m gonna need to duplicate some vertices in order to have the same number of vertices and normals. Do you agree that maybe I’ll spend more time processing the model mesh instead of rendering?

Depends on the model and GPU, and it’s worth a try, but I’m skeptical that it’ll be faster. With GPU it’s all about maximum throughput. Computation is super-cheap. It’s memory accesses that are expensive, especially random access reads. This feels more random, but whether it’s faster or slower will depend on the GPU and your data. If your batches are tiny, then this issue probably isn’t worth discussing because it won’t be the bottleneck.

That’s not my case, I need to render static data and having duplicate data is not a concern. But I’m trying to figure out how to manage a dynamic mesh in a modeling program for instance. I think that keep duplicate data in memory may be not pratical for huge models.

Well give it a shot. Store the positions in a buffer or texture, store the normals in a buffer or texture, then pass in indices for the vtx attrib(s) that lookup into those buffers or textures.