View Full Version : Weird Glitch Drawing Every Other Triangle

09-02-2013, 02:06 PM
Can anyone help me out with what might be causing this to happen:
d (dot) pr/i/GB1Q -- Sorry, can't post links yet
This is my first time using indices and I don't know what's wrong. I made a simple shape in Cinema 4D and exported it, then imported it into the program. Any OBJ I import does the same thing. Does anyone have an idea what's causing this? I can post any code (java) if necessary.
Thanks in advance!

carsten neumann
09-03-2013, 02:47 PM
OBJ files often use different indices for each vertex attribute (position, normal, color, tex coord, etc.). This is not supported by OpenGL, you can only have one index that selects all enabled attributes for the vertex. You have to convert the data to use just a single index. If you search this forum you'll find many threads with instructions how to do that.

09-03-2013, 07:44 PM
That makes a lot of sense, but I can't seem to find any of these threads. Could you link me to one?

carsten neumann
09-03-2013, 09:12 PM
See this one for example.

09-05-2013, 02:01 PM
I'm having trouble following that, sorry. I'm really new to OpenGL and can only understand Java. Anything you can suggest for me?

carsten neumann
09-05-2013, 03:40 PM
The problem is basically this: an object in OBJ has a bunch of attributes for each vertex (say position, normal, tex coords), so we have 3 arrays (or similar data structure):

vec3f position[50];
vec3f normal[100];
vec2f texCoord[80];

The array sizes are completely arbitrary, but note that they can be different for the different attributes. Additionally, for an object with 3 attributes per vertex, a face is defined by a sequence of index triples. Each triple defines one vertex of the face and the first element of the triple is an index into the positions array, the second into the normal array, the third into the texCoord array. A triangle would be given by 3 triples, for example: 3/9/2 5/11/17 4/2/18. As mentioned before OpenGL only supports a single index for all active attributes, so the attributes and the index have to be rearranged to fulfil that requirement. Pseudo code (very similar to tonyo_au's version):

vec3f newPosition[100];
vec3f newNormal[100];
vec2f newTexCoord[100];
uint newIndex[200];

uint nextAttrib = 0;
uint nextIndex = 0;

for each index tuple:
if index tuple has NOT occured before:
// append attributes referenced by index tuple to new attributes
newPosition[nextAttrib] = position[index.pos];
newNormal[nextAttrib] = normal[index.normal];
newTexCoord[nextAttrib] = texCoord[index.texCoord];

remember that index tuple is associated with nextAttrib

// store a single new index that references the same attributes
newIndex[nextIndex] = nextAttrib;
newIndex[nextIndex] = index associated with index tuple

The tricky part is the "remember that index tuple is associated with nextIndex" bit, for that you need some kind of (hash-) map data structure that allows you to use an index tuple as key and a new index as value.

The algorithm becomes simpler if you don't want to generate a new index and don't mind the extra memory use of (unnecessarily) duplicated vertex attributes: You simply assume the if branch is always taken and don't bother remembering if you've seen an index tuple before and what new index value it is associated with.