Sign in to follow this  
Maddibob

Shared vertices

Recommended Posts

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

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by BlackSheepI invite you to read up on such exciting functions as glIndexPointer, glTexCoordPointer, etc;
Those functions just tell OpenGL where the arrays for the different per-vertex attributes are, they don't let you use multiple index arrays (by the way, glIndexPointer is for using color-index mode data with vertex arrays). The way you tell OpenGL which array of indices to use is through the glDrawElements and glDrawRangeElements functions.

Just to reiterate what timford said, it's impossible to use different index buffers for different per-vertex attributes.

Share this post


Link to post
Share on other sites
I looked back through my code - I have one index array referencing individual vertex, texcoord arrays etc. Apologies all :$

Ok, even if you only have one index array, you still need to pass 24 or 36 indices into the rendering calls, which can be generated from the 2 separate vert / texcoord arrays. Still saves memory when there's a lot of mesh data.

<devil's advocate>
If you want to be really fussy about it, the guy didn't even specify an API (although we can assume that the LaMothe reference implies DirectX). In software rendering, you can do any damn thing you like :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this