[nobond]

I am trying to draw a cube with the VBO. Normally i can have 8 vertices and then using the index buffer, finally gldrawelement to do the final draw. The question is
if I am trying to using a face normal here. It seemed that I can not have an easy way to use the same index buffer to index the vertex array and the face normal?!

The only way i come up with is to duplicate the vertex from 8 to 36(12 triangles), so i repeat the vertex and normal where necessary. Is it sound silly or is therea better way to do this? The same idea apply to the texture as well. I think it is hard to use the same index buffer indexing both the pos array and tex co-ordiante array?

[rpg.314]

I don't get it when you say "same index buffer".

With vbo's, vertex coordinates, texture coordinates, and normals come together and form a packet. (ie, you can put them in a struct for simplicity). Now when you use an index buffer, the entire packet (or struct if you prefer) will be sent to the gpu. I don't think that there is any way to use buffer a for vertices and buffer b for normals.

[nobond]

For instance for a cube, you will have to use 36 vertices rather than 8 vertices? I mean only 8 of them have unique position info. But they have different texture/normal. So I have to put them into different "vertices" anyway?

Originally Posted by rpg.314

I don't get it when you say "same index buffer".

With vbo's, vertex coordinates, texture coordinates, and normals come together and form a packet. (ie, you can put them in a struct for simplicity). Now when you use an index buffer, the entire packet (or struct if you prefer) will be sent to the gpu. I don't think that there is any way to use buffer a for vertices and buffer b for normals.

[ProsperLOADED]

Originally Posted by nobond

The only way i come up with is to duplicate the vertex from 8 to 36(12 triangles), so i repeat the vertex and normal where necessary. Is it sound silly or is therea better way to do this? The same idea apply to the texture as well. I think it is hard to use the same index buffer indexing both the pos array and tex co-ordiante array?

AFAIK, this is how it must be done, you have to duplicate vertices if the same position must be used with different normals and/or texture coordinates. But notice that the cube is an extreme case : in most models, you don't have that many vertices to duplicate.

[nobond]

Great, that clear my mind. thanks

[Novum]

Interestingly the Wii and Gamecube GPUs can actually use different indices for different data

[nobond]

that is purely a driver thing. I think . HW even does not need to know it.

Interestingly the Wii and Gamecube GPUs can actually use different indices for different data

[Humus]

Originally Posted by nobond

The only way i come up with is to duplicate the vertex from 8 to 36(12 triangles), so i repeat the vertex and normal where necessary. Is it sound silly or is therea better way to do this?

Actually you only need 24 vertices. 4 per quad, 6 quads. You need 6x6=36 indices though, or if you use a triangle strip I think you can get it down 18 with the help of a couple of degenerate triangles.

Anyhow, while in this particular case you could've saved some by using multiple index buffers (if it was supported in hardware) normally that's not the case. Usually you lose more on the index storage than you gain in tighter vertex storage if you use multiple index buffers. Not to mention that it makes the hardware implementation much harder, in particular the posttransform cache since you'd now have to match a list of indices (variable size too!) to the cached result.

[nobond]

Yup. Triangle Strip Looks like a sensible thing since quad is not supported in ogl-es as well .

Originally Posted by Humus

Actually you only need 24 vertices. 4 per quad, 6 quads. You need 6x6=36 indices though, or if you use a triangle strip I think you can get it down 18 with the help of a couple of degenerate triangles.

Anyhow, while in this particular case you could've saved some by using multiple index buffers (if it was supported in hardware) normally that's not the case. Usually you lose more on the index storage than you gain in tighter vertex storage if you use multiple index buffers. Not to mention that it makes the hardware implementation much harder, in particular the posttransform cache since you'd now have to match a list of indices (variable size too!) to the cached result.

[Novum]

Originally Posted by nobond

that is purely a driver thing. I think . HW even does not need to know it.

Yes it does.

[onesvenus]

I was looking to post a new thread but I think that this would be a perfect place to ask as it's realted to the OP.

I'm using a texture atlas to texture my model. As you surely know I need a different u/v set of coordinates for every vertex/face pair. I want to use an index buffer to try to lower the number of vertices sent to the GPU but I don't know how to do this.

Does anybody know if I can create two index buffers, one for the faces, and the other one for the texture coordinates?

[Humus]

Not possible. The only thing close to it would be to create a vertex buffer containing the indices, then fetch the attributes manually in the vertex shader using the indices.

[onesvenus]

Originally Posted by Humus

Not possible. The only thing close to it would be to create a vertex buffer containing the indices, then fetch the attributes manually in the vertex shader using the indices.

And how would I do that? I have never done something like this on the vertex shader.
Now that you say that's not possible I'll look into alternatives.
The problem is that I have some very large models with lots of textures (I'm talking about ~2M tris with ~100MB of DXT1 compressed textures each). There is no way I could simplify more this models and I need to have them loaded on the GPU because I need to be able to change between them as fast as possible (without loading in between). So on startup time I load every model (using VBO) and the compressed textures and paint the first model. The problem is that when I want to change to another one the GPU waits blocked on the glDrawRange... call. I suppose that happens because as all the models doesn't fit on the VRAM it must transfer them from RAM to VRAM when needed. If you have any idea of how overcome this problem, I'd be very grateful.
I'm working on a GTX280 GPU.