texture coordinates

Its up to you really. OpenGL is quite flexible. You can specify interleaved data formats or have them separated out. On a Windows PC - usually its a simpler affair to have the per vertex attributes separated out as it makes no difference on the memory access patterns. This is different to some console/PDA devices where using interleaved data formats is required to get best performance.

So, assuming your data is in separate memory buffers the code might look like:


For this to work; your per vertex data (texture, normal, vertex) must be arranged in separate buffers. The glVertexPointer () is used to specify where in the buffer the vertex data lies. Its similar with the normal and texture commands. The most common arrangement for texture data is to use 2-valued floats for each vertex element in the model. For normals, its always a 3-valued float per vertex element.

thanks for the reply Bionic Bytes.
My problem is that to me it seems that texture coordinate vector is not a per vertex info. Lets say I have a cube with 8 verticies, and rendering it as a indexed geometry couses a vertex to be rendered more than once. Imagine one corner to be uppper left in texture(0,1), but for other wall that shares this vertex this vertex is upper right corner in texture(1,1). so I consider textuire coordinates to be per face info. How do I sort them, Do I understand it wrongly?

Texture coordinates are per vertex. You need exactly one texture coordinate per vertex. No more, no less; exactly one. The cube is the perfect example of the issues that can emerge when using indexed primitives.

In OpenGL, a vertex consists of all its attributes. Position s only one attribute that makes the vertex, and texture coordinate is another. If any attribute is different between two vertices, the two are not the same and cannot be shared.

So concider the cube. It has 8 unique positions, but all 8 positios are shared among 3 different faces with different texture coordinates. This makes a total of 8*3=24 unique vertices in a cube when you add texture coordinates, not 8. So the two vertices you're giving as an example are not the same (they have different texture coordinates) but you're still trying to share them with the same index. This won't work, becuase they are not the same. Only identical vertices can be shared.

So just think about it like this instead. Make a structure that contains all the attributes you need. In you case, position and texture coordinate.

struct myvertex{    GLfloat pos[3];    GLfloat tc[2];};

How many of those structures do you need to fill out to completely describe all vertices for the cube? Eight is not enough; you will need 24 of them, and all of them with unique values (although depending on how you orient your texture for each face, one or two may be identical; this is just a coincidence though).

thanks Brother Bob, I start to understand it a bit
My cube has 8 verticies and 12 triangles, if i read number of texture coords vectors in a max script I get 12 vectors. Thats strange isnt it? So I have to assign each texture vector to 12 verticies? In 3ds max help it says:
"In order to find out which texture vertex corresponds to a mesh vertex, you have to do the following:

1. Take the index of the mesh vertex.

2. Find out which faces reference the index of the vertex.

3. Note the number of the vertex (1st, 2nd or 3rd - .x, .y or .z) inside each face.

4. For each face referencing the vertex, get the texture face* with the same index.

5. Get the index of the respective texture vertex from the texture face - 1st, 2nd or 3rd / .x, .y or .z

6. The vertex you got corresonds to the mesh vertex we started with.

7. Repeat steps 3 to 6 for all faces found.

"
* triple vector with indexes to texture vector
So this way I get 36 texture vectors. So do I need 12 verticies or 36 verticies?
Every vertex is referenced in 4 triangles so it has 4 shared verticies that differs only in texture vectors, right? So I need 36 verticies for the cube?

Think of it this way:

OpenGL renders each triangle for itself. For each triangle it requires the knowledge of 3 vertices. These 3 vertices must provide every and all information needed to render the face.

That means:
Where in the current space is the vertex located? => position
How is the face oriented? => normal
Which texel of texture 0 is shown? => texcoord0
Which texel of texture 1 is shown? => texcoord1
...

Since all these informations are needed per vertex, each distinct combination of such parameters needs to be delivered as a different vertex to OpenGL (if using indexing).

When rendering a cube with a single texture, you will need to distinguish 4 vertices per quad, what makes a total of 24 vertices (as Bother Bob has already mentioned). Although the cube shows indentical vertex position at corners, e.g. the normals are different (or else the cube would not look sharp edged).

The texture of a cube can be an unrolled 6 side one. Due to unrolling you will get 14 different texture coordinates. If you separate the 6 quad sides but still provide them in the same texture, you will deal with 24 texture coordinates. If you separate them furthur (i.e. into triangles) you will need 36 texture coordinates.

As you can see, the minimum needs depend on a variety of factors. However, 24 is the minimal count of vertices you will need for a cube.

This type of geometry problem is common. For example the Wavefront OBJ format is a good example. The data for the OBJ format is in a normalized form. That is it is optimized for storage - it is not however, suitable for rendering. You must de-normalize it so that each vertex has its own texture, normal and other per vertex state. Typically, this means duplicating vertex data so that unique tuples of (vertex + texture + normal) can be found.