Hm,can anyone see what might be wrong with this set of data?

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.