Texture coordinates do not map correctly in Direct3D11 game engine

Question

I beg your pardon if this question has been already answered elsewhere or if this is the wrong site, but I have a serious issue with rendering textures with Direct3D 11.

Using Cinema 4D R17, I created a simple cube, triangulated all polygons, and UV mapped a texture, as you can see here:

and it renders correctly.

Next, I exported the file to .x because I created a simpler mesh format and .x is ideal for getting vertices, indices, normals, texture coordinates, etc. This conversion is perfect as all data from the source file is successfully transferred to my file (I checked and double checked it).

However, when I upload the file in my game engine, I get the following result:
The cube is being rendered incorrectly where that strange pattern forms.

This is the original .x file (I included only relevant parts):

Mesh CINEMA4D_Mesh {
  8;
  // Cube. These are vertices.
  -0.01;-0.01;-0.01;,
  -0.01;0.01;-0.01;,
  0.01;-0.01;-0.01;,
  0.01;0.01;-0.01;,
  0.01;-0.01;0.01;,
  0.01;0.01;0.01;,
  -0.01;-0.01;0.01;,
  -0.01;0.01;0.01;;

  12;
  // Cube. These are indices.
  3;0,1,3;, // '3;' means that this face contains 3 vertices.
  3;2,3,5;,
  3;4,5,7;,
  3;6,7,1;,
  3;1,7,5;,
  3;6,0,2;,
  3;0,3,2;,
  3;2,5,4;,
  3;4,7,6;,
  3;6,1,0;,
  3;1,5,3;,
  3;6,2,4;;

  MeshNormals {
    8;
    // Cube
    -0.408;-0.408;-0.816;,
    -0.667;0.667;-0.333;,
    0.667;-0.667;-0.333;,
    0.408;0.408;-0.816;,
    0.408;-0.408;0.816;,
    0.667;0.667;0.333;,
    -0.667;-0.667;0.333;,
    -0.408;0.408;0.816;;

    12;
    // Cube
    3;0,1,3;,
    3;2,3,5;,
    3;4,5,7;,
    3;6,7,1;,
    3;1,7,5;,
    3;6,0,2;,
    3;0,3,2;,
    3;2,5,4;,
    3;4,7,6;,
    3;6,1,0;,
    3;1,5,3;,
    3;6,2,4;;

  }
  MeshTextureCoords {
    8;
    // Cube
    1.0;1.0;,
    0.0;1.0;,
    1.0;0.0;,
    1.0;1.0;,
    1.0;1.0;,
    1.0;0.0;,
    0.0;1.0;,
    1.0;0.0;;
  }
  MeshMaterialList {
    2;
    12;
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1,
    1;

    Material C4DMAT_NONE {
      1.0;1.0;1.0;1.0;;
      1.0;
      0.0;0.0;0.0;;
      0.0;0.0;0.0;;
    }
    Material C4DMAT_Mat {
      1.0;1.0;1.0;1.0;;
      1.0;
      0.0;0.0;0.0;;
      0.0;0.0;0.0;;
      TextureFilename {
        "tex.bmp";
      }
    }

    {C4DMAT_Mat}
  }
}

I also invert the vtexture coordinate (v = 1 -v). This is the vertex data I extract:

8 // Number of vertices.
-0.01 -0.01 -0.01 -0.01 0.01 -0.01 0.01 -0.01 -0.01 0.01 0.01 -0.01 0.01 -0.01 0.01 0.01 0.01 0.01 -0.01 -0.01 0.01 -0.01 0.01 0.01 // Vertices stored in X, Y, Z.
1 0 0 0 1 1 1 0 1 0 1 1 0 0 1 1  // Texture coordinates stored in U, V.
36 // Indices count.
0 1 3 2 3 5 4 5 7 6 7 1 1 7 5 6 0 2 0 3 2 2 5 4 4 7 6 6 1 0 1 5 3 6 2 4 // Indices. 
tex.bmp // Texture file name.

I read that there might be a conflict between texture coordinates of vertices that are shared among different faces and that resolving this would imply not using index buffers.

EDIT: I did what @wondra said (replaced texture coordinates with 0 0 0 1 1 0 1 1 0 1 0 0 1 1 1 0 and it looks better indeed:

I am not sure what is wrong here. Could anybody help me? Thank you.

UPDATE: The Cinema 4D .obj is broken. Use Blender or anything else.

Answer 1

I you look carefully your cube in Cinema4D, the top most corner show different texture coordinate for the side and the top ( probably the same between front and right side, but the texture can't let me state it for sure ).

And in your final cube indices, you only have a range [0..7]. On the GPU, a vertex is a full tuple of values with a single index. It means that your cube is not made of 8 vertex but 24, because each corner has to be split for his own normal and texture coordinate.

Once you split each face properly, you should get the correct visual. A cube is not the best example of index buffer because the vertex reuse rate is quite low, but you still get the idea.

Answer 2

It turns out that the .obj file exported by Cinema 4D was broken.

Using Blender or anything else to create the .obj file seems to solve the issue.