This project has moved and is read-only. For the latest updates, please go here.

CMO model problem

Feb 13, 2014 at 10:05 AM
Edited Feb 13, 2014 at 11:46 AM
I use Model::CreateFromCMO(...), but my app crashed. I found that it doesn't generate dds file which is used for the model's texture. That leads a "can not find the file "error. How to set the project to generate the dds file. My texture file is jpg format. I know set image content pipeline, but I am not going that way. I set Mesh content pipeline to the fbx file, it can generate the .cmo file with a long name, User_document...._.cmo. But why the jpg file doesn't do this.
Feb 13, 2014 at 6:29 PM
Edited Feb 13, 2014 at 6:30 PM
Adding the JPG to the project should be sufficient.

Using 3-D Assets in Your Game or App
Feb 14, 2014 at 3:29 AM
Edited Feb 14, 2014 at 3:41 AM
Thanks! I have added the JPG file to my project. Sorry that I have a mistake in my expression. I set effect of the fbx to default Lambert from C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\VsGraphics\Assets\Effects\Lambert.dgsl. And it generate the cso file with the long name. But when i set the texture of the fbx with my JPG file, it doesn't generate the dds file.
I also see that the StarterKit sample can generate the texture dds file with the long name.

Model::CreateFromCMO(...) will read the texture file to a long name, but my program doesn't generate the file.
Feb 26, 2014 at 9:21 AM
Edited Feb 26, 2014 at 9:24 AM
I found the reason why the program doesn't auto generate the dds file from jpg. It 's because that the name of the project directory is too long...Isn't the DXTK offering mechanism to detect this?
Marked as answer by Tianyaa on 3/7/2014 at 2:44 AM
Feb 26, 2014 at 6:52 PM
DirectXTK's Model loader was throwing an exception to indicate that it couldn't find the file at runtime. It sounds like your project directory naming issue was a general path-length problem at build-time...
Marked as answer by walbourn on 2/26/2014 at 10:52 AM
Feb 28, 2014 at 2:03 AM
Edited Feb 28, 2014 at 2:05 AM
Thanks walbourn! I mean that if my directory name was too long, the auto-generate dds file will be named with the long directory name, User_Document....As we know the file's name can't be too long. So there's no dds file generated. Sorry that I don't know how the dds file was generated with a long name. I will make a deep research on the code source. Thank you for your patience!
Feb 28, 2014 at 6:46 AM
The VS 2012 content pipeline uses the project name to 'unique' the filename which results in this really long name. I believe VS 2013 resolved this.
Mar 7, 2014 at 10:42 AM
Edited Mar 21, 2014 at 11:09 AM
I use the vs2013, but it also generates the long name dds file. I think it's the Mesh Content Pipeline which raise this problem while the Image Content Pipeline don't.
Mar 19, 2014 at 1:31 PM
Edited Mar 19, 2014 at 1:35 PM
I wish I saw this thread earlier. I had the same problem earlier this morning and wasted an hour or so troubleshooting it until I realized that it had to do with the path length. If your DDS name ends up being too long due to the name concatenation that VS2013 does, it will just silently fail to export.

It really boggles my mind how they (Folks who wrote VSGraphics module, not DXToolkit guys) could have done such a great job at converting a fairly complex format (I have not so far seen a case where it can't process an FBX file) into a simpler CMO format, but then they have such an epic fail on basic things like directories, basic error handling (refer to my other thread about cryptic 4317 error when trying to export to a directory that doesn't exist) and naming conventions. Couldn't they have just exported every CMO in its' own separate folder named the same as the CMO and then just dump all the textures and CMO file in there, without doing that silly name concatenation...