OpenGL Texturing issue

Newbie & Debugging Questions
#1

I wrote my own .obj to mesh importer, and it is working ok, probably.
But with some meshes, some of the times with some quads, it appears to somehow “mess up” the texturing of the quad.
It would appear that the center of the quad is not being textured, but two of the edges have some texture on them. Which confuses me,
because if its using the texture on the quad, and no part of the texture is black, then none of the quad should be black right?

Here is an image where you can see so quads of the mesh being textured properly, everything looks exactly as it should. (ignoring the dirt on the left where the some of the texture is black.)

Here is a picture from the other side of the mesh where you can see the center of the texture is black, but if you look closely the bottom and top have a little texture :

Here is a closer look at the dirt quad that is black in the center :

I checked in my modeling program (Blender) and the normalized texture quardinates being used on the quads in the modeling program match the broken quads in my application.

Not sure whats going on here, but my hope is that one of you have seen somthing like this before.

#2

I actually can’t figure out the exact problem with the texture coordinates by looking at the images.

But just keep in mind that vertex / texture coordinate and normal indices start with ‘1’ and not ‘0’ (like the Array-indices) in .obj files.

Also, you might try to invert the texture coordinates (that means instead of [icode]v[/icode] use [icode]1.0f - v[/icode])

#3

Maybe this will help. These are the texture quardinates for the quad with the brick texture that is not being textured properly. (Image #2 in the original post)
(0.999937, 0.263838)
(0.640323, 0.394499)
(0.640323, 0.095902)
(1.001755, 6.3E-5)

Im a little confused about what this means. So should the quardinates be this instead?
(1.999937, 1.263838)
(1.640323, 1.394499)
(1.640323, 1.095902)
(2.001755, 1.000065)

#4

Uh, no.

I just wanted to say, when you have your face definitions (looking about like this):

f 2/24 5/34 29/13

the numbers represent the vertex indices:

f vi/vti vi/vti ...

where vi is supposed to mean vertex index and vti vertex texture index

The indices are the n-th vertex / vertex texture definition from the list of those:

`
v 0.14780 2.1908 4.14890 // this is vertex index 1 (!) (it doesn’t start at 0, that was my point)
v 1.19 2.7852 3.3489 // this is vertex index 2
v … // this is vertex index 3

vt 0.319 0.25 // this is vertex texture index 1 (!)
vt … // and so on…
`

Hope, you get my point now :slight_smile:

It could be that all the texture coords would be shifted, but it’s unlikely… :confused:

#5

I understand what you mean now, thanks. I dont think its the issue but Ill look into it anyway.

#6

Okay. I’m pretty much clueless otherwise :confused:

#7

Ok, I’ve determined that the bug only happens when the texture is less than 1024 by 1024 resolution. It works perfectly when the image res is higher than that.