locked
Questions on 3D model formats and Direct3D (Windows 8) ...

    Question

  • Hi all -

    I'm working on a 3D game for Windows 8 (Metro style). My team usually works in XNA, but apparently that's not supported in Windows 8 Metro apps -- using Microsoft tools (yeah, I know about MonoGame, very cool).

    I noticed that the Direct3D sample in the Windows 8 SDK (Direct3D resource loading sample) demonstrates how to convert OBJ files to VBO files and then load them in the Direct3D Metro App.

    This all leads me to ask several related questions:

    • 1. What happened to the .X format that used to be the native (?) DirectX format? Is that no longer the favorite file format for models? Any samples that show a simpler path to load a model?
    • 2. What happened to the DirectX SDK tool that would convert .FBX=>.X or even display .X files? Is it still relevant?
    • 3. .VBO format? Wow, very mysterious. Yeah, I know it's the OpenGL favorite, but is that now the preferred file format for loading in DirectX? Has anyone noticed the fantastic void of information on this file format? Google doesn't even believe it's a real search -- it things your looking for .VOB format.
    • 4. Is it true that Microsoft is not providing a toolchain to create XNA Windows 8 Metro apps?

    Sorry to lump all these questions together, but I think they're related. And I'm mainly interested in the first question. But if y'all feel like answering the others, that'd be great.

    THANKS!

      - Dave Ferreira

    Wednesday, September 5, 2012 8:07 PM

Answers

  • The .X file format is very much tied to Direct3D 9 and has been legacy for many, many years. It dates back to the Direct3D Retained Mode in DirectX 3. The XNA Game Studio content pipeline makes use of the D3DX9 library to load an extract these old .X files because there's a fair amount of 'free to use' community art in that format. It's not suited as a runtime format for Direct3D 11 graphics.

    The vast majority of modern 3D art pipelines start with Autodesk .FBX files as the source. The runtime format is very much app-specific. There really isn't a "DirectX favorite runtime file format" for meshes.  The problem is that runtime formats tie strongly into a materials/effects system so there has to be some kind of mapping of legacy notions of materials from .X files to a programmable shader model. This also ties into animation systems, physics/collision, and tessellation all of which makes creating a 'universal' solution pretty difficult. The vast majority of the value in say Epic's Unreal Engine 3 is the art pipeline, effects system, runtime containers and playback mechanisms, etc.

    You'll see a mix of different approachs in the various Microsoft samples.

    • The ResourceLoading sample uses .VBO and provide a simple WaveFront OBJ to VBO conversion tool for basic geometry. It's a made-up format and is not related to the OpenGL "Vertex Buffer Object" format. It's just a dump of the binary data for a vertex buffer and an index buffer with two DWORDs at the top with the counts. It's essentially geometry without any notion at all of materials. BasicLoader's LoadMesh function just gives you the set of VBs and IBs back and it's up to the code to know how to associate it with shaders, sampler state, textures, materials constants, etc. to draw it.
    • MarbleMaze uses .SDKMESH adopted from the DirectX SDK samples. The current exporter for this is at <http://go.microsoft.com/fwlink/?LinkId=226208>. SDKMESH has a basic notion of materials but has no direct support for a programmable shader material model. It organizes the content as subsets to help with materials systems, but that's about as far as it goes. It does have an SDKANIM solution for skinned animation, but the actual rendering solution is not standardized. It's more complete than .VBO, but its still a 'toy' solution for sample purposes.
    • Visual Studio 2012 has a very simple content pipeline that generates .CMO files from .FBX files. There's a "Direct3D Starter Kit" sample in the works to demonstrate how to use it, but it's again a pretty simple format with a very simple materials model which associates with a few textures, a VS, a PS, and a sampler state.

    We are looking at doing something with the DirectXTK to include a Model class loading the .CMO and/or .SDKMESH files to give people a better starting point for samples and hobby projects, but this is defintely an area where there's no "official" mesh container format. At the moment, SDKMESH and the MarbleMaze sample's SDKmesh class is probably the best starting point at the moment.

    Compared to the story for textures (.DDS files are very much the "DirectX favorite format"), the story for geometry content is not a solved area.



    Thursday, September 6, 2012 8:38 PM

All replies

  • The .X file format is very much tied to Direct3D 9 and has been legacy for many, many years. It dates back to the Direct3D Retained Mode in DirectX 3. The XNA Game Studio content pipeline makes use of the D3DX9 library to load an extract these old .X files because there's a fair amount of 'free to use' community art in that format. It's not suited as a runtime format for Direct3D 11 graphics.

    The vast majority of modern 3D art pipelines start with Autodesk .FBX files as the source. The runtime format is very much app-specific. There really isn't a "DirectX favorite runtime file format" for meshes.  The problem is that runtime formats tie strongly into a materials/effects system so there has to be some kind of mapping of legacy notions of materials from .X files to a programmable shader model. This also ties into animation systems, physics/collision, and tessellation all of which makes creating a 'universal' solution pretty difficult. The vast majority of the value in say Epic's Unreal Engine 3 is the art pipeline, effects system, runtime containers and playback mechanisms, etc.

    You'll see a mix of different approachs in the various Microsoft samples.

    • The ResourceLoading sample uses .VBO and provide a simple WaveFront OBJ to VBO conversion tool for basic geometry. It's a made-up format and is not related to the OpenGL "Vertex Buffer Object" format. It's just a dump of the binary data for a vertex buffer and an index buffer with two DWORDs at the top with the counts. It's essentially geometry without any notion at all of materials. BasicLoader's LoadMesh function just gives you the set of VBs and IBs back and it's up to the code to know how to associate it with shaders, sampler state, textures, materials constants, etc. to draw it.
    • MarbleMaze uses .SDKMESH adopted from the DirectX SDK samples. The current exporter for this is at <http://go.microsoft.com/fwlink/?LinkId=226208>. SDKMESH has a basic notion of materials but has no direct support for a programmable shader material model. It organizes the content as subsets to help with materials systems, but that's about as far as it goes. It does have an SDKANIM solution for skinned animation, but the actual rendering solution is not standardized. It's more complete than .VBO, but its still a 'toy' solution for sample purposes.
    • Visual Studio 2012 has a very simple content pipeline that generates .CMO files from .FBX files. There's a "Direct3D Starter Kit" sample in the works to demonstrate how to use it, but it's again a pretty simple format with a very simple materials model which associates with a few textures, a VS, a PS, and a sampler state.

    We are looking at doing something with the DirectXTK to include a Model class loading the .CMO and/or .SDKMESH files to give people a better starting point for samples and hobby projects, but this is defintely an area where there's no "official" mesh container format. At the moment, SDKMESH and the MarbleMaze sample's SDKmesh class is probably the best starting point at the moment.

    Compared to the story for textures (.DDS files are very much the "DirectX favorite format"), the story for geometry content is not a solved area.



    Thursday, September 6, 2012 8:38 PM
  • Very good. Thanks for all the clear info.

    BTW -- Regarding your comment "The .X file format ... has been legacy for many, many years."

    "Many, many years" ago I watched Dwight Eisenhower's funeral on a black and white TV. "Just recently" DirectX 9 was brand new.

    Just some perspective.  ;)

    Thursday, September 6, 2012 10:39 PM
  • Direct3D Retained Mode was introducted in 1996. It was not included with the Windows Vista OS released in 2006, so it basically lasted 10 years. That's a long time in the graphics industry...

    Monday, September 10, 2012 7:00 PM
  • Thank you for this information,

    I have tried to use the .sdkmesh to get something up and running quickly. I tried making a sphere in max 2012 exporting to .fbx then converting with the tool to by running it in a command prompt to .sdkmesh but for some reason when I try and load it instead of the marble in the maze game I just get a runtime error are there any specific options in max or the exporter that should be used to make it work? any idea what settings were used for the maze game meshes? any help would be greatly appreciated as I am doing the Microsoft and train 2 game, Game jam in Luton tomorrow evening and would love to do a 3D game I pretty much understand the examples fundamentals but getting our own meshes to load is proving troublesome.

    Thursday, September 13, 2012 8:07 PM
  • Hi Chuck.  Thank you for your helpful response.  I replied to your message here: http://directxtk.codeplex.com/discussions/373614

    Tuesday, October 9, 2012 7:11 PM
  • Hey Dave,

    If you want to build .x files, try Artismo.  It is a poly modeling suite that produces .x files with animation.

    RightBytes is sponsoring three indie teams right now during their beta and you can get a copy for your project here.

    http://www.rightbytes.com/rightbytes/artismo

    If you want to go with a different format let me know and I can look into adding it to the export features.

    Happy Coding!

    Jason

    Sunday, October 28, 2012 12:39 AM
  • The January 2013 release of DirectXTK now has support for loading and rendering rigid models from .CMO files or .SDKMESH files.

    See http://directxtk.codeplex.com/

    Saturday, January 26, 2013 12:45 AM
  • Thank you thank you thank you guys!  I can't tell you how excited I am by the support for model meshes!
    Saturday, January 26, 2013 2:27 AM
  • Not supporting your own format is ridiculous, absurd, and undermines all of my work with .x files which I can create without the use of any software. I think selling <apologies Adobe>, meant Autodesk, by not supporting your own format is a crappy deal and I refuse to try to learn Adobe FBX. I made the mistake of buying all your stuff and it's useless without being able to use things it takes one person years to do. You should have support for .x templates built right along side selling adobe format.

    Calvin Lynch

    Upset Customer

    PS: I think that the FBX loader can be modified to load Legacy X files instead of FBX so I'll just go with that idea in mind. Overall a very nice job on Visual Studio 2013. Don't let my unhappiness with .x fool you. I like Visual Studio in general. Just a little frustrated with the upgrades getting to a start point with the new stuff. Overall it's a great platform...



    • Edited by IQ100 Tuesday, May 13, 2014 11:46 PM
    Sunday, May 11, 2014 10:36 PM
  • Note that FBX is Autodesk, not Adobe. FBX has become the defacto standard for model data, which is why there are so many importers based on it.

    .X files date back to DirectX 3 (1996), and were deprecated with Direct3D 10 (2006). They are still popular with hobbyist software, and you can still use it to model if you choose. You just need to expect a conversion or importing process rather than the ability to directly load .X files into your apps. You also shouldn't load .FBX files directly in your apps either.


    Monday, May 12, 2014 3:28 PM
  • I gotcha Chuck and corrected my mistake... Actually I can go from .X to .dae, then .dae, to .fbx, then .FBX to .cmo (built in 2013 I think?) or convert to .SDKMESH... The sample I have that makes use of .CMO doesn't work with the default teapot.cmo, or I'm doing something wrong, for some reason but the DirectXTK with .SDKMESH works very well (Audio Sample very cool stuff)... I'll shut up now...

     Calvin

    PS: Changed my avatar to reflect my contribution to your DirectXTK Sample.. One of my Stealth Models..

    • Edited by IQ100 Wednesday, May 14, 2014 3:18 AM
    Tuesday, May 13, 2014 11:57 PM
  •      Hi All,

         the ".X" format is rather straight forward. It is deprecated, I know, but it is so well documented that it is easy (although somewhat laborious) to create a custom importer. Just think of it as a "text file" and process it as such to load vertex & bone structures. The C++ framework that comes included in the 3D project templates welcomes this kind of custom routines. That's what I did, and it works like a charm. I'm even using some shaders that I used with XNA.

         Best Regards,

         Tarh Ik


    Tarh ik

    Tuesday, October 7, 2014 9:19 PM
  •      To give more information about the process, the x-file is divided in sections (using "{}" as begin and end):

     * Mesh: This one contains your vertices as 3D coordinates, and your faces (this will be referred as "index" buffer, I'm not sure why)
     * MeshNormals: This one contains your normals, and they should match the information in "Mesh"
     * MeshTextureCoords: This one contains the texture coordinates PER VERTEX
     * Material / MeshMaterialList: I use these ones a lot, although I've been advice not to use too many of them.
     * SkinWeights: These ones are your weights for skinning (if you're using them)
     * Frame: These ones are your skelleton of bones.

    Everything else I pretty much ignore it.

         I hope it helps.

         Best Regards,

         Tarh Ik


    Tarh ik

    Tuesday, October 7, 2014 9:29 PM
  • It's reasonable to parse .X files for content pipelines, but you should really be using something else as the binary format. Binary .X files are still essentially token streams, and that's likely to be a lot more complicated than you actually need for runtime usage.
    Tuesday, October 7, 2014 11:18 PM
  •      Hi Chuck,

         I agree, binary files are quite a pain. I like using text files, though, so I can compile them at run-time. Of course, this is in a case-by-case basis, and everyone has a preference. My personal approach is to have animations as individual text files (well, xml files to be honest), so I can compile them when the game is running, based on the 3D model I'm applying it. In that way, I can use the same animation in different models, even if their internal bone structure is sligtly different. Side-effects of this approach are a rather small loadtime and a quite small installer.

         Then again, this is just my [unique] case / personal opinion, and I understand why the recommended approach is to migrate to fbx files. Just my two cents.


    Tarh ik

    Wednesday, October 8, 2014 5:37 PM