Troubles parsing Wavefront .obj texture coordinates

Question

I'm coding my own .obj parser in objc for OpenGL ES 2.0 to get a better understanding on how this OpenGLES thing works. Loading the vertices and showing a model with vertex colors on it works like a charm. Just a small note: I'm using an index buffer.

The real problem is the mapping of the textures atm. As you'll see a little bit more down below, my texture isn't mapped the way it should be.

Here's how I think the .obj format works, please correct me if I'm wrong: the "f"-lines describe a face where the number before a slash defines the index of the vertex and the number after the slash defines a texture coordinate.

Consider the following .obj file (exported by Cinema 4D):

v -75 75 -50
v 75 75 -50
v -75 -75 -50
v 75 -75 -50

vt 0 0
vt 0 1
vt 1 1
vt 1 0

f 4/3 3/2 1/1
f 2/4 4/3 1/1

And the following texture:

Now, when I position the vertices in OpenGL ES 3D space and try to map the texture coordinates to each individual vertex, the mapping goes wrong. I could fix this by moving around some of the texture coordinate values but I realise this isn't the way to do it. I also tried to edit some of my .obj exporter settings to flip axises and/or uv mapping around but non of them result in a correct mapping. Is there something I'm missing in my theory concerning the .obj file format? One thing I might say already: I read yesterday that the coordinate system of the .obj format defines topleft as the anchor point of a texture. So I fixed that already in my parsing.

Here's a small summary with the current situation: Update: the coordinate system of the texture is the actual .obj texture coordinate system and NOT OpenGL's coordinate system. I translate the coordinates in my parsing algorithm to counter this.

Answer 1

I'm going to answer my own question: the problem seemed that I was using an index buffer to speed up performance, but my texture coordinates were still mapped to the original vertices.

Answer 2

As far as I know, the coordinate system you are reporting are not the correct one.

Actually it is something like this:

I know this is not probably the actual response to your question but I hope it sheds some light on it.

Answer 3

I found the similar problem parsing .obj files. In my case it seems that my .obj files use inverted V (2nd texture coordinate) axis. I solved the problem with this line of code. v = 1.0f - v;

Answer 4

Maurizio is correct in his representation of the opengl texturemapping coordinates.

By looking at your pictures I'd say that you should take a better look at your objC code. Assuming the .obj is correctly exported by C4D, it looks like you have your texture indices mixed up.

Plausible proof: switch the bottom left vertex with the bottom right vertex in the picture you posted ("Result Opengl") and your texture would come out right.

EDIT: actually, the fault may be in your texture loading code, but that doesnt explain the result you're getting. Even if the fault were in the texture loading then the texture would simply show up upside-down (because of the left-bottom opengl coordinate system). Suggestion: switch vt0 and vt3 in your code...