If I draw a single plane, the texture coordinates are mapped correctly. (4 Verts, 4 TC, 6 Indices(2 polys))
Even if it's subdivided, (9 Verts, 9 TC, 27 Indices(8 polys)) the texture will display:
(Maya complex plane)
I can take my [written] Obj converter and load the Texture coordinates into the buffer. However, if I extrude a face in Maya, and even applying a planar UV map to "repair" the broken uv's, (above) the texture coordinates get really wild in-engine. (below)
Is there an issue with Obj texture coordinate format?
Update: I've drawn with D3D11_PRIMITIVE_TOPOLOGY_LINELIST, and noticed a change in indexing as well.. Would this be the issue? or should I reconstruct texture coords as brushed on at http://www.gamedev.net/topic/600234-texcoord-count-is-different-than-vertex-count/
This issue was caused by the texture coordinates index not being equal to the vertex index. To resolve the problem, the texture coordinate index had to be ordered such as to line up with the vertex index.
For this issue, I was able to resolve using a brute force method that fit my understanding, which is slow, that catalogs the entire Vertex/Texture Coordinates as a key and reconstructs the full explicit array of vertices and Texture coordinates from their indices, filling a custom struct that fits the needs of my application.
There are other faster solutions that involve using a hash http://programminglinuxgames.blogspot.com/2010/03/wavefront-obj-file-format-opengl-vertex.html
A related issue with normals: OpenGL - Index buffers difficulties
And 3 index buffers
And a good explaination: Why is my OBJ parser rendering meshes like this?
And further resources on obj format: http://en.wikipedia.org/wiki/Wavefront_.obj_file
OBJ resources: http://www.martinreddy.net/gfx/3d/OBJ.spec http://www.fileformat.info/format/wavefrontobj/egff.htm
Also, the MeshFromObj10 Tutorial from the DirectX library helps some, getting it done in an efficient way. There's no easy way around coding it, outside of find a third party source.