Reputation: 551
I am working on a .obj handler in c++. Importing the data shouldn't be a Problem, but i do not understand why it is possible, that a .obj (e.g. exported from blender) has more 'vt' entries than 'v' entires. If someone could explain me that, i would be very happy!
Thanks!
Upvotes: 9
Views: 3743
Reputation: 1
There is much confusion caused by the naming in the LWO format. The lines labelled 'v' are actually defining points and not vertices. When the faces are defined these points are converted into vertices, which gives a cube 24 vertices, but only 8 points.
Upvotes: 0
Reputation: 31
I found the source of the problem. I had prematurely optimized my program, and didn't realize that texture coordinates could be of a larger quantity than vertex coordinates due to the fact that textures are mapped per face rather than per vertex, so each vertex could have many texture coordinates mapped to it. Hopefully someone will learn from my mistakes.
Something I found strange though was initializing an sf::RenderWindow
prior to running my .obj
parser resulted in no error messages being thrown and the crash to be reported in a completely different area than it was actually happening.
Upvotes: 1
Reputation: 4283
The number of position, normal and texture coordinates may be different because two vertices may share a coordinate in one space but differ in another.
Think of a box (8 verts) using 6 different rectangular shapes (one per face) in texture space -> that's 6*4=24 texture coordinates.
Edit: A common uv-map for a box looks like below (14 texture coordinates). I've annotated three different vertices: A
, B
and C
. Note that in a box every vertex is adjacent to three faces which has to be true in the uv-map also. C
gets a texture coordinate which is adjacent to three faces, but B
has to be duplicated and A
tripled to do so.
Upvotes: 8