Hello. I made converter from obj file to my format. The problem is that one subset in rendered with wrong texture. I already added tons of debug prints and for some reason one subset is rendered with wrong positioned texture it seems. Everything in the fromat seems fine, but i see one house totally grey... (model viewer shows everything properly tho). Are there any common pitfalls or something i may be unaware of? I am trying to resolve it since a few hours :(

I cant find any mistake, even going manually through the file and comparing results with my exporter. Some obj files load just fine and in this one i got a grey house...

I fuond 2 models on the internet, properly loaded both, but still the first one renders wrong in my engine. What may be wrong?

If I had to guess it is material mapping.

Usually multi material objs use materials with "usemtl" you had better then use the correct textures defined in the accompanying mtl file.

For example here is a simple cube.obj:

Check your UV coordinate settings.

I have found many OBJ files with UV coordinates less than zero and greater than one.

If you are clamping your texture coords, then anything less than 0 will be 0 and anything greater than 1 will be 1.

I seriosuly did not expect that many responses from you guys, thanks a lot.

i am currently digging in ASSIMP source code (because it properly renders it). he mesh is "The City" from this link:

http://tf3dm.com/3d-model/the-city-39441.html

The problematic group is g_bldgs2 (i cut the other subsets, the rest are rendered properly), this is how it should look like:

http://i.imgur.com/Qkr7Esy.png

I attach the rar with .obj and .mtl

And how it looks like here http://i.imgur.com/JI6BhVH.jpg

I already added tons of debug prints, it says that it uses the "cty2x.jpg" for that group which is the proper one. Can anyone reproduce the problem? I've literally no idea what may be wrong. I downloaded 5 additional meshes from the internet and they render properly, but the city texture problem...

The weird thing in this mesh i see is that there is one "g" for group and usemtl changes inside without "g" change- i split that into two separate groups with separate materials

I just read the topic carefully again and thats exactly what efolkertsma is talkin about. But im still bit confused (and why there is not "g" in your example? That would crash my parser... :) ). But anyways, after removing unnecessary groups in the attached file there is no usemtl inside group amd the file looks "clean", but still renders incorrectly.

From what i see, i can completely ignore "g" and separate the groups basing on material, right? Or maybe you recommend any other, common well documented format?

Greetz

Okay so i spent today optimising my converter, and actually ALL the textures are mapped wrong way. It was just impression of "good looking houses".

This is how it looks here http://i.imgur.com/PVDd6zr.jpg

While it should like http://i.imgur.com/ZNBqI9L.png

So the conclusion is it is not a tiny mistake but some bigger issue with UV mapping i am unaware of. I went through the mesh tutorial once again, but well... i am fed the UVs from the file and i just pass it to the shader. What may be wrong?

BINGO!

texCoord.v = 1.0f - it.texCoord.v;

Now it maps proerply. Why?? Is it something with left/right handed issue? Can someone explain why reversing the v coordinate fixed the problem?

Okay, i got the maths behind lh and rh.... :) Well I wish i knew it 2 days before :)

Good to hear that you resolved your issue. I thought about the material mapping since you had stated that you had some objects come in correctly, which in my mind excluded the UV mapping.

Anyways, here is a reasonable explanation for it http://thedev-log.blogspot.ca/2012/07/texture-coordinates-tutorial-opengl-and.html

TL;DR version: In DirectX top-left is (0,0) in OpenGL bottom-left is (0,0). This has to do with DirectX being more centered around memory -> screen layout (address 0 is top-left) whereas OpenGL is taking the more mathematical approach of x,y axis which means y increases upwards, aka bottom-left is (0,0)