Shared vertices
Author
I read an excerpt from an Andre Lamothe book today which said that creating 36 vertices for a cube is a waste of time when you can just create 8 and index them. If a vertex holds texture coordinates, how can a cube be created using 8 vertices if you want, say, a texture for each of the 4 sides and a different texture for the top of the box?
I can see why only creating 8 vertices would be faster, but for more detailed models where a texture changes between vertices, is this possible?
Thanks
Don't think so... as far as I know you can't specify different indices for vertex/normal/texcoord/etc arrays.
Quote:Original post by Maddibob
... If a vertex holds texture coordinates, how can a cube be created using 8 vertices if you want, say, a texture for each of the 4 sides and a different texture for the top of the box? ...
It can't, however you can do it with 24 (6x1x4) vertexes instead of 36 (6x2x3) using an index buffer. Maybe you thought he meant "8", when he meant "24".
You can create an array of 8 vertices for the points, then a separate array of 36 indices into that array. Similarly, you can create an array of 24 sets of texture vertices / coords, and a separate array for indexing into that. For tiny scenes of a boxes, you wouldn't see much speed boost, but you would save quiet a lot of memory (percentage-wise). For larger scenes, where data will be likely batched and cached on the card, the gains in speed and storage can be quite significant.
Quote:Original post by BlackSheep
... and a separate array for indexing into that. ...
Hmmm. Can you show some sample code?
Sorry, got muddled with my index stuff (reading old code at late hours does that!)
What I meant was:
Have two arrays:
1) Vertices - x,y,z * 8 vertices = 24 (floats?)
2) Texture Coords - u,v * up to 24 (4 per face using 6 quads) or 36 (3 per face using 12 triangles) = max 96 (floats?)
Then two index arrays of 24 or 36 indices (depending on using quads or triangles). One array holds indices into the Vertex array as defined above, the other hold indices into the TexCoord array as defined above.
For a one-box scene, the overhead of the index arrays negates the memory saving gained by using the index arrays - it would be better to just brute force the whole thing. Larger scenes with closed meshes will quickly benefit, as an index typically consists of 2 shorts (1 for the vertex, one for the texcoord), rather than 5 floats (x,y,z,u,v), saving 16 bytes per vertex.
My code is hideous, you wouldn't want it. The OpenGL references and MSDN stuff explain it all pretty clearly though.
What I meant was:
Have two arrays:
1) Vertices - x,y,z * 8 vertices = 24 (floats?)
2) Texture Coords - u,v * up to 24 (4 per face using 6 quads) or 36 (3 per face using 12 triangles) = max 96 (floats?)
Then two index arrays of 24 or 36 indices (depending on using quads or triangles). One array holds indices into the Vertex array as defined above, the other hold indices into the TexCoord array as defined above.
For a one-box scene, the overhead of the index arrays negates the memory saving gained by using the index arrays - it would be better to just brute force the whole thing. Larger scenes with closed meshes will quickly benefit, as an index typically consists of 2 shorts (1 for the vertex, one for the texcoord), rather than 5 floats (x,y,z,u,v), saving 16 bytes per vertex.
My code is hideous, you wouldn't want it. The OpenGL references and MSDN stuff explain it all pretty clearly though.
Your code to accomplish this is hideous because it's nonexistant :) It is impossible to use different indeces for different parts of the vertex data.
Hopefully that will change one day though, because it'd be nice.
Hopefully that will change one day though, because it'd be nice.
Author
I thought it was impossible. Andre, as good as he is, should have mentioned in his "you don't wanna do it like that" prose, that it's fine for either wire-frame models, or models where every vertex is an interpolated texture coord like a texture-wrapped sphere, but not for things like a crate, or even a human type model.
I suppose you could split the model down into batches if it's complex enough, one batch to handle all the vertices which share texture coords and one for the rest which don't. Although with video cards blatting out the rate of tris they do now, I doubt it'll be worth the effort.
Thanks guys
I suppose you could split the model down into batches if it's complex enough, one batch to handle all the vertices which share texture coords and one for the rest which don't. Although with video cards blatting out the rate of tris they do now, I doubt it'll be worth the effort.
Thanks guys
Quote:Original post by timford
Your code to accomplish this is hideous because it's nonexistant :) It is impossible to use different indeces for different parts of the vertex data.
Hopefully that will change one day though, because it'd be nice.
It seems to me that this would defeat the purpose of indices in the first place, and probably not use any less memory.
Quote:Original post by timford
Your code to accomplish this is hideous because it's nonexistant :) It is impossible to use different indeces for different parts of the vertex data.
Hopefully that will change one day though, because it'd be nice.
Nope, my code is hideous. It's full of global variables, poor data structures, and botched code - the hallmarks of rushed work intended solely for hobby programming. However, I can assure you that it exists, and is therefore possible. I invite you to read up on such exciting functions as glIndexPointer, glTexCoordPointer, etc;
Those are the functions on which my non-existant code is built ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
