5

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:

512x512 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.

Summary

polyclick
  • 2,704
  • 4
  • 32
  • 58
  • Have a closer look at how the "v" and "vt" values in the .obj file correlate. OpenGL does not handle texture coords (and normals) the same way they are respresented in the OBJ file. So, without "moving around some of the texture coordinate values", you map the bottom-left point of your texture to the top-right vertex and vice versa. Remember that you cannot do texture coord indexing independently from vertex indexing in OpenGL. See http://stackoverflow.com/questions/4233152/how-to-setup-calculate-texturebuffer-in-gltexcoordpointer-when-importing-from-ob – Thalur Jan 27 '12 at 13:59
  • Not yet, but found the problem that caused this. I was using an indexbuffer for performance reasons and this mixed up the mapping between the texture coordinates and the vertices. – polyclick Jun 11 '12 at 14:53

4 Answers4

6

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

Actually it is something like this:

Coordinate System

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

Maurizio Benedetti
  • 3,557
  • 19
  • 26
  • 1
    I'm sorry but that's incorrect. 3rd point in this answer: http://stackoverflow.com/a/5605027/341358 – polyclick Jan 13 '12 at 16:03
  • @bclaessens just opened the OpenGL book and I confirm what I have reported previously. Then it is up to you to trust it or not, I am reporting it with full honesty and with the intent to help. Cheers. p.s. my OBJ loader works flawlessly. – Maurizio Benedetti Jan 13 '12 at 16:19
  • It's true that the OpenGL Texture coordinate system has the bottom left corner as het origin for a texture. But, and if I may, believe the post of the previous linked stackoverflow post, this differs for the .obj standard. Anyway, apart from the fact if the origin is located at the top or the bottom, that still doesn't solve the problem. The problem then still persists but flipped vertically. – polyclick Jan 15 '12 at 02:59
  • 1
    @bclaessens I am guessing that a possible cause of the problem could be linking of the textures coordinates with the corresponding vertices. Have you paid attention to the fact that vertex counting and textures counting starts from one in the OBJ files while any memory array starts form zero? It is evident that the vertices coordinates have been well done (otherwise you would loose the geometry) but I suggest to keep an eye on the texture indexing since the behavior you show could be explained by that problem. could you please attach some code? – Maurizio Benedetti Jan 17 '12 at 20:13
4

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;

Pavel Melnikov
  • 965
  • 9
  • 8
3

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.

polyclick
  • 2,704
  • 4
  • 32
  • 58
1

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...

Erik
  • 804
  • 1
  • 8
  • 18