aimed for OpenGL.
A certain OpenGL code works fine with some example hard coded data:
GLfloat vertices[] = { 1,1,1, -1,1,1, -1,-1,1, 1,-1,1, // v0-v1-v2-v3
1,1,1, 1,-1,1, 1,-1,-1, 1,1,-1, // v0-v3-v4-v5
1,1,1, 1,1,-1, -1,1,-1, -1,1,1, // v0-v5-v6-v1
-1,1,1, -1,1,-1, -1,-1,-1, -1,-1,1, // v1-v6-v7-v2
-1,-1,-1, 1,-1,-1, 1,-1,1, -1,-1,1, // v7-v4-v3-v2
1,-1,-1, -1,-1,-1, -1,1,-1, 1,1,-1}; // v4-v7-v6-v5
GLubyte indices[] = {0,1,2,3,
4,5,6,7,
8,9,10,11,
12,13,14,15,
16,17,18,19,
20,21,22,23};
However, using data from COLLADA (indexed with deindexer utility or manually indexed), the outcome is wrong (partial, e.g. 2 squares facing each other):
exported_vertices (24 in number): 1.00000 1.00000 -1.00000 1.00000 -1.00000 -1.00000 -1.00000 -1.00000 -1.00000 -1.00000 1.00000 -1.00000 1.00000 1.00000 1.00000 1.00000 -1.00000 1.00000 -1.00000 -1.00000 1.00000 -1.00000 1.00000 1.00000
parsed_and_exported_indices: 0 1 2 2 3 0 4 5 6 6 7 4 8 9 10 10 11 8 12 13 14 14 15 12 16 17 18 18 19 16 20 21 22 22 23 20
similar results are with baked xml with deindexer utility:
collada vertices (72 in number): 1 1 -1 1 -1 -1 -1 -1 -1 -1 1 -1 1 1 1 -1 1 1 -1 -1 1 1 -1 1 1 1 -1 1 1 1 1 -1 1 1 -1 -1 1 -1 -1 1 -1 1 -1 -1 1 -1 -1 -1 -1 -1 -1 -1 -1 1 -1 1 1 -1 1 -1 1 1 1 1 1 -1 -1 1 -1 -1 1 1
cooked indices by deindexer (same): 0 1 2 2 3 0 4 5 6 6 7 4 8 9 10 10 11 8 12 13 14 14 15 12 16 17 18 18 19 16 20 21 22 22 23 20
What might be wrong in the code? (or the model data)
It’s supposed to be modelling a common cube.