DirectxMesh obj to cmo texture coordinates off

I'm having trouble getting the texture coordinates of the cmo to match how the mesh was unwrapped in blender. I am using the directxmesh to convert the obj to a cmo and the directxtk to load the cmo.

Relevant parts of code are as follows:

std::unique_ptr<DirectX::CommonStates> m_states;
std::unique_ptr<DirectX::IEffectFactory> m_fxFactory;
std::unique_ptr<DirectX::Model> m_model;

...

m_states.reset(new CommonStates(d3d11DeviceInterface.Get()));

m_fxFactory.reset(new EffectFactory(d3d11DeviceInterface.Get()));

m_model = Model::CreateFromCMO(d3d11DeviceInterface.Get(), L"unit.cmo", *m_fxFactory);

...

m_model->Draw(d3d11DeviceContextInterface.Get(), *m_states, local, view, proj);


The model and uv map in blender look like this:

Using the following directxmesh command: meshconvert unit.obj -cmo -y -nodds

the model looks like this in the program:

I thought this would be a simple matter of flipping the texture coordinates by adding the -fliptc switch to directxmesh meshconvert unit.obj -cmo -y -nodds -fliptc

But this changes the winding order resulting in backface culling on the wrong sides. Subsequently, I tried changing the culling face to clockwise with the -cw switch meshconvert unit.obj -cmo -y -nodds -fliptc -cw

Now the backface culling was happening on the correct faces but the texture coordinates were still wrong.

I'm rather lost as to what I have done wrong.

Edit: I seem to have figured out what is going on. The image seems to be flipped around the V axis. If I manually flip the image the coordinates match up to what is shown in blender. It's a shame I can't seem to find an option in blender to flip the UV coords along the V axis.

• I'm glad to hear you found a solution! Feel free to add it as an answer to make it easier for others to find. You'll be able to accept your own answer after a waiting period. – DMGregory Nov 20 '15 at 3:39
• The -fliptc is supposed to flip the UV coordinates in V, but I do assume you are doing the reverse winding at the same time. Maybe I should split them up. – Chuck Walbourn Nov 20 '15 at 5:28

I looked and I totally boned up the implementation of -fliptc. It was flipping in U instead of in V, and you could only do it if you were also reversing the face winding.
I've updated the master branch of GitHub with some fixes. -fliptc has been removed. Instead I added flipv which inverts just the v texcoord without reversing the winding, and -flipz which negates the z for LH vs. RH. -flip still exists to reverse the winding independent of these other options.
Generally the issue is that with OpenGL-based editors, the upper-left of the textures is right side up but when you render that in Direct3D it is upside down because the Y origin is inverted in OpenGL vs. Direct3D. The fix is supposed to be a simple flip of the v texcoord which is what -flipv now does.
Depending on the winding order of your source and if you are going to render doing blackface culling of counter-clockwise triangles or clockwise triangles, you might need to reverse the winding of the triangles. That is what -flip does. I had originally made them dependent operations, but they are really independent. The -ccw switch in meshconvert just informs the normal computation which winding to use for the front (and this happens before any -flip if it is applied).
Finally, depending on if you are going to render with a RH vs. LH view coordinate system, you might need to invert the Z positions (and normals if present). The new -flipz switch does that.