A number of my projects over the past few years have been to provide modern replacements for the full range of functionality provided in the now legacy D3DX library: DirectXMath in the Windows 8.x SDK, DirectX Tool Kit and the DirectXTex texture processing libraries on CodePlex. To round out that set, I’ve created DirectXMesh for geometry processing functionality such as computing triangle adjacency, computing normals and tangent frames, and vertex cache optimization.

DirectXMesh is hosted on CodePlex and GitHub. The latest version of the library, documentation, notes on future work, release history, and other information is available there.

Platforms: The code is designed to build with the Windows 8.x SDK using Visual Studio 2010, 2012, or 2013 and works on Windows Vista, Windows 7, Windows 8.x Win32 desktop, Windows Store apps, and Xbox One.

Update: Meshconvert, a sample using DirectXMesh that is a command-line tool replacement for the DirectX SDK sdkmesh conversion utility, is now available on CodePlex.

Porting Notes

Here’s a handy table of equivalents for D3DX (see Living without D3DX for a complete listing):

D3DXCleanMesh Clean
D3DXComputeNormals ComputeNormals
ID3DX10Mesh::GenerateAdjacencyAndPointReps GenerateAdjacencyAndPointReps
ID3DX10Mesh::GenerateGSAdjacency GenerateGSAdjacency
ID3DX10Mesh::Optimize AttributeSort
D3DXOptimizeFaces OptimizeFaces
D3DXOptimizeVertices OptimizeVertices
D3DXValidMesh Validate
Comments (12)

  1. Mike says:

    Will this be supported in XNA 5?

  2. walbourn says:

    See many gaming press sites on February 1, 2013: "However, there are no plans for future versions of the XNA product"

  3. Nassim says:

    Will this support different lods generation of the same mesh ?

  4. walbourn says:

    I did not implement the simplification routines from D3DX9. There is a CodePlex work item to track this request if you want to up-vote it, but in general I think most people are better served by commercial products or custom built LODs.

  5. Ofek says:

    Will there be a replacement for D3DXLoadMeshFromX?   How about DrawSubset?   (or is rendering completely off the radar for a mesh class?)

    We're currently still using DirectX9, and are considering upgrading in phases: first the D3DX functionality to these replacements (DirectXMesh, DirectXMath etc.) and only then the actual rendering engine.   Would you say it is a viable strategy, or are these two too coupled?  

    Thanks!   (for the post, the hard work – and in advance for the answers).

  6. walbourn says:

    @Ofek – The X file format has been deprecated for a long, long time but I know it is still popular. My current recommendation is to use a conversion tool to get it into Autodesk FBX and the use an exporter there of some kind. The Model class in the DirectX Tool Kit supports loading of CMO and SDKMESH but you can easily write your own loader for it as well, and it does rendering (DirectXMesh is for tools primarily to prepare content, and DirectX Tool Kit is for runtime stuff like rendering). I have a work item to look at a way to deal more directly with .X files to get it into .CMO or .SDKMESH, but it's definitely a longer term project.

  7. walbourn says:

    @Ofek – The only reason to use Direct3D 9 at all today is for Windows XP targeting, which is extremely challenging (and on Windows 8.x you don't have any debugging support at all for it). You can certainly use DirectXMesh and DirectXTex to prepare content for Direct3D 9 and can even get much of those libraries to build for Windows XP, and you can technically use DirectXMath for Windows XP but it's a bit of a hack to do so. For Windows Vista or later, you don't need Direct3D 9 at all because Direct3D 11 has broad hardware reach with 10level9 feature levels. At a minimum you should move towards an abstraction model where you can render with Direct3D 11 or Direct3D 9, but many new applications and games can just drop Direct3D 9 / Windows XP entirely.

  8. Ofek says:

    @Chuck – thanks for the quick reply.  

    The only reason the *develop new content* on Direct3D 9 is XP targeting.  When you have a million LOC app that uses D3D9 and does *not* need any new graphics features, you'd be hard pressed to find a business case for re-writing the graphics engine.   Your work comes a long way towards lowering the migration barrier (and kudos for that!)  I just need to form a clear picture of the barrier that remains.

    So IIUC you're saying the idea of separating D3DX migration from D3D migration does not hold?

  9. walbourn says:

    @Ofek – Moving away from D3DX is strongly encouraged as much as possible, but for Direct3D 9 development it can be difficult to avoid using D3DX9 at least in some capacity. You can use DDSWithoutD3DX which supports Direct3D 9, D3DCompile, and DirectXMath/XNAMath. If you use FX, you have to stick with D3DX9 for that.

    My other point is that the ability to support a Direct3D 9 application at all is diminished on the latest versions of Windows, and that's likely to continue. Be sure to read Migrating to Direct3D 11 (and by reference Direct3D 9 to Direct3D 10 Considerations) to know what's going to be a challenge moving forward.

  10. Oscar says:


    Is there a function similar to CDXUTMesh10::ConvertToAdjacencyIncides?


  11. walbourn says:

    If you mean CDXUTSDKMesh::CreateAdjacencyIndices, then this just ends up calling ID3DX10Mesh::GenerateAdjacencyAndPointReps and then ID3DX10MeshGenerateGSAdjacency, so you would get the same result from GenerateAdjacencyAndPointReps and then GenerateGSAdjacency

  12. Gigaplex says:

    "For Windows Vista or later, you don't need Direct3D 9 at all because Direct3D 11 has broad hardware reach with 10level9 feature levels."

    Those feature levels are problematic. We've got code that runs on DirectX 9 that requires shader model 3, and the 10Level9 feature levels don't support shader model 3. That means we're forced to use shader model 4 to get the features we need, and now we're required to drop support for hardware that used to work.