microsoft/directxmesh

DirectXMesh geometry processing library

DirectXMesh geometry processing library

http://go.microsoft.com/fwlink/?LinkID=324981

Copyright (c) Microsoft Corporation.

February 21, 2024

This package contains DirectXMesh, a shared source library for performing various geometry content processing operations including generating normals and tangent frames, triangle adjacency computations, vertex cache optimization, and meshlet generation.

This code is designed to build with Visual Studio 2019 (16.11), Visual Studio 2022, clang for Windows v12 or later, or MinGW 12.2. Use of the Windows 10 May 2020 Update SDK (19041) or later is required for Visual Studio. It can also be built for Windows Subsystem for Linux using GCC 11 or later.

These components are designed to work without requiring any content from the legacy DirectX SDK. For details, see Where is the DirectX SDK?.

Directory Layout

• DirectXMesh\

  • This contains the DirectXMesh library.

The majority of the header files here are intended for implementation the library only (DirectXMeshP.h, scoped.h, etc.). Only DirectXMesh.h and DirectXMesh.inl are meant as a 'public' headers for the library.

• Utilities\

  • This contains helper code related to mesh processing that is not general enough to be part of the DirectXMesh library.
    • WaveFrontReader.h: Contains a simple C++ class for reading mesh data from a WaveFront OBJ file.

• Meshconvert\

  • This DirectXMesh sample is an implementation of the meshconvert command-line texture utility from the legacy DirectX SDK utilizing DirectXMesh rather than D3DX.

This tool does not support legacy .X files, but can export CMO, SDKMESH, and VBO files.

• build\

  • Contains YAML files for the build pipelines along with some miscellaneous build files and scripts.

Documentation

Documentation is available on the GitHub wiki.

Notices

All content and source code for this package are subject to the terms of the MIT License.

For the latest version of DirectXMesh, bug reports, etc. please visit the project site on GitHub.

Release Notes

• Starting with the June 2020 release, this library makes use of typed enum bitmask flags per the recommendation of the C++ Standard section 17.5.2.1.3 Bitmask types. This is consistent with Direct3D 12's use of the DEFINE_ENUM_FLAG_OPERATORS macro. This may have breaking change impacts to client code:

  • You cannot pass the 0 literal as your flags value. Instead you must make use of the appropriate default enum value: CNORM_DEFAULT, VALIDATE_DEFAULT, or MESHLET_DEFAULT.

  • Use the enum type instead of DWORD if building up flags values locally with bitmask operations. For example, CNORM_FLAGS flags = CNORM_DEFAULT; if (...) flags |= CNORM_WIND_CW;

• The UWP projects and the Win10 classic desktop project include configurations for the ARM64 platform. Building these requires installing the ARM64 toolset.

• When using clang/LLVM for the ARM64 platform, the Windows 11 SDK (22000) or later is required.

Support

For questions, consider using Stack Overflow with the directxtk tag, or the DirectX Discord Server in the dx12-developers or dx9-dx11-developers channel.

For bug reports and feature requests, please use GitHub issues for this project.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

Credits

The DirectXMesh library is the work of Chuck Walbourn, with contributions from Dr. Hugues Hoppe, Alex Nankervis, James Stanard, Craig Peeper, and the numerous other Microsoft engineers who developed the D3DX utility library over the years.

Thanks to Matt Hurliman for his contribution of the meshlet generation functions.

Thanks to Adrian Stone (Game Angst) for the public domain implementation of Tom Forsyth's linear-speed vertex cache optimization, and thanks to Tom Forsyth for his contribution.

Thanks to Andrew Farrier and Scott Matloff for their on-going help with code reviews.

directxmesh's Issues

Meshconvert support for compressed vertices in SDKMESH

The Meshconvert tool currently writes using the following vertex format for SDKMESH:

DXGI_FORMAT_R32G32B32_FLOAT for normals/tangent/binormals
DXGI_FORMAT_B8G8R8A8_UNORM for colors
DXGI_FORMAT_R32G32_FLOAT for texcoords

Should provide an option to use smaller normal formats like R11G11B10_FLOAT, colors should be able to use R10G10B10A2_UNORM or D3DDECLTYPE_DXGI_R11G11B10_FLOAT, and could use DXGI_FORMAT_R16G16_FLOAT for texture coords.

Remove use of DWORD in public interface

I changed most of the functions to take C++ Standard Types, but never fixed up DWORD out of concern for changing link signatures.

I should really change it to something standard.

Setup for building with MinGW unclear

I can see the project is supposed to build with MinGW. I have setup an MSYS2 environment, but I don't seem to be able to understand the setup required to build.

I see from the CMake config file that the project depends on Directx-Headers and DirectxMath, which I have cloned in a folder accessible by MSYS2. However, I can't build Directx-Headers; it seems MSYS2 is using its own includes instead of the Windows SDK ones, which miss some required macros. I opened a separate issue about this, but I assume I'm opening an issue here in case I am missing something obvious.

Retire Windows 8.1 Store, Windows phone 8.1, and VS 2013 projects

At some point we should remove support for these older versions in favor of UWP apps

DirectXMesh_Windows81.vcxproj
DirectXMesh_WindowsPhone81.vcxproj

This would also be a good time to retire the VS 2013 compiler support:

DirectXMesh_Desktop_2013.vcxproj

Please put any requests for continued support for one or more of these here.

Meshlet generator generates non-connected meshlets

Is this a known issue? In case it's not, I have a (very basic) reproducer I can share.

Stanford bunny as sum of all the meshlets seems to have all primitives:

Example of non connected meshlet:

Hiding a few meshlets results in holes, so primitives are not redundant.

ComputeTangentFrameEx

The basic ComputeNormals and ComputeTangentFrame do not perform any vertex splits, so artifacts can be found on large angle changes.

An alternative version is needed which would be able to duplicate vertices to resolve these problems.

enum CTF_FLAGS
{
   CTF_DEFAULT = 0x0,
       // Default is to compute normals using weight-by-angle

    CTF_WEIGHT_BY_AREA = 0x1,
        // Computes normals using weight-by-area

    CTF_WEIGHT_EQUAL = 0x2,
        // Compute normals with equal weights

    CTF_WIND_CW = 0x4,
        // Vertices are clock-wise (defaults to CCW)

    CTF_DONT_ORTHOGONALIZE = 0x10,
    CTF_ORTHOGONALIZE_FROM_U = 0x20,
    CTF_ORTHOGONALIZE_FROM_V = 0x40,

    CTF_DONT_NORMALIZE_PARTIALS = 0x80,

    CTF_WRAP_U = 0x100,
    CTF_WRAP_V = 0x200,
    CTF_WRAP_UV = 0x300,
};

struct CTFVertex
{
    uint32_t vertex; // index of the 'original' vertex
    XMFLOAT3 normal;
    XMFLOAT4 tangent; // .w is handedness
    XMFLOAT3 bitangent;
};

HRESULT ComputeTangentFrameEx(
   _In_reads_(nFaces*3) const uint16_t* indices, _In_ size_t nFaces,
   _In_reads_(nVerts) const XMFLOAT3* positions,
   _In_reads_(nVerts) const XMFLOAT2* txtcoords, _In_ size_t nVerts, 
   _In_reads_(nFaces*3) const uint32_t* adjacency,
   _In_ DWORD flags,
   _In_ float partialEdgeThreshold,
   _In_ float singularPointThreshold,
   _In_ float normalEdgeThreshold,
   _Inout_ std::vector<CTFVertex>& frames, _Out_ size_t& nDupVerts );

HRESULT ComputeTangentFrameEx(
   _In_reads_(nFaces*3) const uint32_t* indices, _In_ size_t nFaces,
   _In_reads_(nVerts) const XMFLOAT3* positions,
   _In_reads_(nVerts) const XMFLOAT2* txtcoords, _In_ size_t nVerts, 
   _In_reads_(nFaces*3) const uint32_t* adjacency,
   _In_ DWORD flags,
   _In_ float partialEdgeThreshold,
   _In_ float singularPointThreshold,
   _In_ float normalEdgeThreshold,
   _Inout_ std::vector<CTFVertex>& frames, _Out_ size_t& nDupVerts );

The D3DXComputeTangentFrameEx function supported vertex splitting based on various thresholds.

The real question is if anyone needs the full original D3DX9 algorithm with all it's complex 'singularity group' handling, or if the current functionality is sufficient for modern needs.

At a minimum, there needs to be a duplicate vertices version to handle mirrored seams...

Retire support for VS 2015

In 2020, I plan to retire support for VS 2015. The following projects will be removed, and the NuGet directxmesh_desktop_2015 package will be deprecated in favor of one built with VS 2017 and/or VS 2019:

DirectXMesh_Desktop_2015
DirectXMesh_Desktop_2015_Win10
DirectXMesh_Windows10_2015
DirectXMesh_XboxOneXDK_2015
Meshconvert_Desktop_2015

Please put any requests for continued support for one or more of these here.

Exporting obj's is broken for indices >999

When exporting OBJ files, the OBJ file will be broken on most 3D viewers including the one built into Windows when the indices exceed 999. The reason is because the face indices are formatted with comma separation which is not expected for OBJ files.

I've root caused this to the call to the following code called right at the start of wmain that causes the output of uint's to have comma separation.
std::locale::global(std::locale(""));

An easy fix is to drop in the following right at the start of Mesh::ExportToOBJ:
// Revert the locale to classic so that indices aren't comma separated. Comma separation will trip up most obj viewers os.imbue(std::locale::classic());

Meshconvert - ignores specular, emisive and normal textures in ExportToCMO

Meshconvert / Mesh.cpp seems to output multiple textures for SDKMesh format (ExportToSDKMesh), but for the CMO format it only outputs the diffuse texture and writes blanks for all other textures (ExportToCMO in Mesh.cpp lines 1574 ti 1583)

Since CMO as a format supports up to 8 textures per material, is there a reason for this?

(Also, ModelLoadCMO in DirectXTK only populates the diffuseTexture, but all the other material texture names are there to use).

OptimizeFacesLRU

A common alternative algorithm to the Hoppe vertex-cache strip order optimization in D3DX is Tom Forsyth's algorithm. This provides more robust 'device independent' support, and is a bit faster by avoiding the need for adjacency information.

Forsyth, T.; "Linear-Speed Vertex Cache Optimisation". September 2006 Link

HRESULT OptimizeFacesLRU(
   _In_reads_(nFaces*3) const uint16_t* indices, _In_ size_t nFaces,
   _In_ size_t nVerts,
   _Out_writes_(nFaces) uint32_t* faceRemap,
   _In_ uint32_t vertexCache = OPTFACES_V_DEFAULT );

HRESULT OptimizeFacesLRU(
   _In_reads_(nFaces*3) const uint32_t* indices, _In_ size_t nFaces,
   _In_ size_t nVerts,
   _Out_writes_(nFaces) uint32_t* faceRemap,
   _In_ uint32_t vertexCache = OPTFACES_V_DEFAULT );    

Compilation issues with Intel C++ 18 compiler

The Intel C++ 18 compiler (18.0.1) has some internal bugs with std::make_unique that need fixed before the code will safely compile.

error : assertion failed at: "shared/cfe/edgcpfe/templates.c", line 7609
effect = std::make_unique();

Publish a NuGet packge with DX12 support for Win32 desktop

The NuGet package DirectXMesh_Uwp includes DirectX 12 support side-by-side with DirectX 11, but the directxmesh_desktop_2015 only supports DirectX 11 for Windows 7 support.

I should publish a DirectXMesh_desktop_win10 package that includes the DirectX 12 support for desktop apps that require Windows 10.

Remap functions used vertexRemap incorrectly

The legacy D3DXOptimizeVertices and D3DXWeldVertices define the vertexRemap as:

The value stored in pVertexRemap for a given element is the source vertex location in the new vertex ordering.

Which would be oldLoc = remap[newLoc]

The DirectXMesh versions are returning this data, but the Remap functions are treating the vertexRemap as the inverse: newLoc = remap[oldLoc]

I think the confusion here stems from the fact that the various ID3DXMesh class operations internally use remaps that are newLoc = remap[oldLoc], but the D3DXOptimizeVertices and D3DXWeldVertices functions explicitly inverse it to oldLoc = remap[newLoc]

Meshconvert support for importing X files

The original DirectX SDK tool meshconvert imported from legacy .X files and produced .sdkmesh files.

The meshconvert sample currently supports importing from Wavefront OBJ and VBO files, and can export VBO, CMO, and SDKMESH.

Ideally it would also support importing from legacy .X format files as well.

This would either require an extensive parser implementation or simply using the legacy DirectX SDK / DirectSetup deployed D3DX9_43 DLL if it is present.

WaveFrontReader fails when mtl names have spaces in them

meshconvert.exe fails to process .obj files that refer to .mtl files with spaces in their names, and .mtl files that refer to image files with spaces in their names. It’s a result of the fstream implementation of >> for strings. It delimits based on spaces.

Use cup.obj file as an example. Rename the .mtl, and .jpg files to “microsoft cup.xxx” and edit the .obj and .mtl files to reference the renamed files (both files are pretty short and can be edited with notepad or VS).

Meshconvert support for glTF2

The glTF open standard is intended as a simple, modern runtime format for models. In addition to reading from Wavefront OBJ, meshconvert should be able to read from gltf files.

Warnings when building with clang

The library will build with clang, but generates a number of warnings.

Note that DirectXMesh assumes you are using C++14, so you should use -std=c++14 with clang along with the newer releases of DirectXMath (3.12 or later)

Mesh::Optimize unique_ptr for remap is not declared as array type

Probably a typo. Other unique_ptr uses are correct.

std::unique_ptr<uint32_t> remap(new (std::nothrow) uint32_t[mnFaces]);

Should be:

std::unique_ptr<uint32_t[]> remap(new (std::nothrow) uint32_t[mnFaces]);

This mistake appears in two places, both for an array named remap.

https://github.com/Microsoft/DirectXMesh/blob/60028e807a602277f23a89a6334fd42bda473d5a/Meshconvert/Mesh.cpp#L609

https://github.com/Microsoft/DirectXMesh/blob/60028e807a602277f23a89a6334fd42bda473d5a/Meshconvert/Mesh.cpp#L642

Simplify Mesh

Simplifies a mesh using a vertex/edge decimation algorithm.

HRESULT D3DXSimplifyMesh(
  _In_   LPD3DXMESH pMesh,
  _In_   const DWORD *pAdjacency,
  _In_   const D3DXATTRIBUTEWEIGHTS *pVertexAttributeWeights,
  _In_   const FLOAT *pVertexWeights,
  _In_   DWORD MinValue,
  _In_   DWORD Options,
  _Out_  LPD3DXMESH *ppMesh
);

Schroeder, Zarge and Lorensen “Decimation of Triangle Meshes” SIGGRAPH 1992 link

Hoppe, DeRose, Duchampy, McDonald, Stuetzle, “Mesh Optimization”, SIGGRAPH 1993 link

Hoppe, "Progressive meshes", SIGGRAPH 1996 link

This would be most useful for automatic "level-of-detail" generation, but this kind of solution is not commonly used as it lacks artist control. There are a number of simplification programs that run in the context of various art tools that might be more robust.

Remove VS 2012 adapter code

As part of dropping VS 2012 projects, can clean up the following code:

• Remove C4005 disable for stdint.h (workaround for bug with VS 2010 + Windows 7 SDK)
• Remove DIRECTX_CTOR_DEFAULT / DIRECTX_CTOR_DELETE macros and just use =default, =delete directly (VS 2013 or later supports this)
• Remove DirectXMath 3.03 adapters for 3.06 constructs (workaround for Windows 8.0 SDK)
• Remove some guarded code patterns for Windows XP (i.e. functions that were added to Windows Vista)
• Make consistent use of = {} to initialize memory to zero (C++11 brace init behavior fixed in VS 2013)
• Remove legacy WCHAR Win32 type and use wchar_t

Add PLY import/export support to meshconvert

Common portable asset format .PLY.

https://en.wikipedia.org/wiki/PLY_(file_format)

http://paulbourke.net/dataformats/ply/

Public domain implementation: https://github.com/ddiakopoulos/tinyply

Source asset: http://graphics.stanford.edu/data/3Dscanrep/

Retire Windows Vista support

The library is written using Direct3D and Windows APIs that work on Windows Vista Service Pack 2 with KB971644 installed (a.k.a. the DirectX 11.0 Runtime). At this point, there's little need for Windows Vista support, and I don't really have any way to support or test such an ancient operating system.

Concatenate Mesh

A function to combine multiple meshes into a single mesh.

HRESULT D3DXConcatenateMeshes(
  _In_   LPD3DXMESH *ppMeshes,
  _In_   UINT NumMeshes,
  _In_   DWORD Options,
  _In_   const D3DXMATRIX *pGeomXForms,
  _In_   const D3DXMATRIX *pTextureXForms,
  _In_   const D3DVERTEXELEMENT9 *pDecl,
  _In_   LPDIRECT3DDEVICE9 pD3DDevice,
  _Out_  LPD3DXMESH *ppMeshOut
);

The original D3DX function would create a 'union' of the input layouts as needed to generate the final vertex buffer if a specific one was not provided.

The DirectXMesh version would likely only operate on the indices and an array of XMFLOAT3 positions, and provide a remap array for each of the original input mesh indices to the new indices for dealing with other vertex data.

Retire VS 2017 support

Visual Studio 2017 reaches it's mainstream end-of-life on April 12, 2022. I should retire these projects that time:

• DirectXMesh_Desktop_2017.vcxproj
• DirectXMesh_Desktop_2017_Win10.vcxproj
• DirectXMesh_GDK_2017.vcxproj
• DirectXMesh_Windows10_2017.vcxproj
• Meshconvert_Desktop_2017.vcxproj

Along with all the associated test suite VS 2017 projects.

I am not sure when I'll be retiring Xbox One XDK support which is not supported for VS 2019 or later. That means I'm not sure if I'll delete DirectXMesh_XboxOneXDK_2017.vcxproj or not with this change.

Conversion of vertex declaration to input layout

A number of legacy file formats (.x files, .sdkmesh, .xnb, etc.) all encode the vertex buffer description as a Direct3D 9 vertex decl.

These would be functions to perform a robust conversion of D3DFVF codes and/or D3DVERTEXELEMENT9 array to a D3D11_INPUT_ELEMENT_DESC array.

The implementation of this function would need to handle the fact that d3d9.h is a "desktop only" header.

Mouse movement is very jerky at higher sensitivities

Just putting the raw mouse deltas in is fine but often isn't fast enough. Scaling the deltas makes the mouse movement incredibly jerky when the mouse is moving diagonally, which seems to be a symptom of the deltas being stored as integers. If this is intended, is there a way to smooth out the movement and increase the sensitivity?

meshconvert.exe Windows 10 Crash

Hello, while using the meshconverter(downloaded it yesterday), it seems to be crashing after it starts reading a *.fbx file. The *.fbx file I am using is attached.

Tested (crash on read):
meshconvert TestScene.fbx -cmo -nodds -flipz -y
meshconvert TestScene.fbx -n -op

Assets.zip

Thanks for any of your help.

Overloads for void* indices+DXGI_FORMAT

All functions that currently take indices have overloads for uint16_t (16-bit) or uint32_t (32-bit) which relies on compile-time resolution to select the correct version:

HRESULT Validate(
   _In_reads_(nFaces*3) const uint16_t* indices, _In_ size_t nFaces,
   _In_ size_t nVerts, _In_reads_opt_(nFaces*3) const uint32_t* adjacency,
   _In_ DWORD flags, _In_opt_ std::wstring* msgs );

HRESULT Validate(
   _In_reads_(nFaces*3) const uint32_t* indices, _In_ size_t nFaces,
   _In_ size_t nVerts, _In_reads_opt_(nFaces*3) const uint32_t* adjacency,
   _In_ DWORD flags, _In_opt_ std::wstring* msgs );

The library could have a third overload to support runtime selection of 16-bit vs. 32-bit which is how the legacy D3DX library handled indices:

HRESULT Validate(
    _When_(indexFormat == DXGI_FORMAT_R16_UINT,
            _In_reads_bytes_(nFaces*sizeof(uint16_t)))
    _When_(indexFormat != DXGI_FORMAT_R16_UINT,
            _In_reads_bytes_(nFaces*sizeof(uint32_t)))
        const void* indices,
    _In_ DXGI_FORMAT indexFormat,
    _In_ size_t nFaces,
    _In_ size_t nVerts, _In_reads_opt_(nFaces*3) const uint32_t* adjacency,
    _In_ DWORD flags, _In_opt_ std::wstring* msgs );

This work item would entail adding a third overload to the following methods:

• ComputeVertexCacheMissRate
• GenerateAdjacencyAndPointReps
• ConvertPointRepsToAdjacency
• GenerateGSAdjacency
• ComputeNormals
• ComputeTangentFrame (XMFLOAT3 version)
• ComputeTangentFrame (XMFLOAT4 version)
• Validate
• Clean
• OptimizeFaces
• OptimizeFacesEx
• OptimizeVertices
• ReorderIB
• ReorderIB (in-place)
• ReorderIBAndAdjacency
• ReorderIBAndAdjacency (in-place)
• FinalizeIB
• FinalizeIB (in-place)

WaveFrontReader update to support per-vertex color extension

While more of a 'hack' than an extension, some tools support exporting/importing WaveFront OBJs with per vertex color thrown in

####
#
# OBJ File Generated by Meshlab
#
####
# Object VERTEXPAINT_004_OBJ.obj
#
# Vertices: 284
# Faces: 281
#
####
mtllib ./VERTEXPAINT_004_OBJ.obj.mtl

vn 0.029683 0.730087 -0.682709
v 1220.094482 -572.500000 177.713943 0.984314 0.764706 1.000000  

# "3 vals for Vert and 3 vals for Col"

vn 0.000000 0.858139 -0.513418
v 1291.571533 -609.439636 -28.628490 0.921569 0.219608 1.000000
vn 0.303129 0.896367 -0.323480

https://gamedev.stackexchange.com/questions/21303/how-can-i-include-vertex-color-information-in-obj-files

FAILED (80070002) when converting a .obj to skdmesh

I'm using the following commands I have also tried with various arguments but still no luck.

meshconvert monkey.obj
and
meshconvert monkey.obj -sdkmesh

monkey.zip

Windows Subsystem for Linux support

Between directx-headers for dxgiformat.h and directxmath, it should be possible to build DirectXMesh for Linux targets.

The work would be done in the source and for CMakeLists.txt, leveraging find_package.

Meshconvert support for extended Wavefront OBJ materials

Currently the WaveFrontReader.h parses map_Kd as a texture file, and that's it.

There are a number of extensions created over the years to extend the format noted on the wiki and in the full spec which we could parse as well:

• SDKMESH has a texture slot for a specular map which we could load from map_Ks. SDKMESH files also sometimes use this slot for emissive, so that would be from map_Ke or map_emissive.

• SDKMESH has a texture slot for a normal map which we could load from map_Kn or norm.

• SDKMESH could be hacked a bit to support PBR using the map_Pr, map_Pm values although we'd want glTF2 style RMA maps combined into a single file...

There are also some 'options' that should be ignored instead of assuming the line after the command is all just a filename.

GeneratePointReps() undefined behavior with too few vertices

hashSize is calculated as:

size_t hashSize = nVerts / 3;

Which is zero if nVerts is less than 3. It is then used like:

 uint32_t hashKey = (*reinterpret_cast<const uint32_t*>(&positions[vert].x)
     + *reinterpret_cast<const uint32_t*>(&positions[vert].y)
     + *reinterpret_cast<const uint32_t*>(&positions[vert].z)) % uint32_t(hashSize);

Which causes a divide-by-zero exception.

I think one way to fix this could be:

size_t hashSize = std::max<size_t>(nVerts / 3, 1);

Also, ConvertPointRepsToAdjacencyImpl() has the same problem but I didn't want to make the title longer.

meshconvert doesn't support wildcards in filenames

meshconvert does not support wildcards like *.sdkmesh

Suppport for Direct3D 12

A version of VBReader, VBWriter, and ComputeInputLayout which use D3D12 types.

Stripify Mesh

The original D3DX mesh optimize function supported an option for stripifying D3DXMESHOPT_STRIPREORDER. We support this with OptimizeFaces (passing 0 for the vertexCache size), but the resulting IB is still a triangle list as was the case in the original D3DX library.

This proposed function would convert index buffers from D3D_PRIMITIVE_TOPOLOGY_TRIANGLELIST to D3D_PRIMITIVE_TOPOLOGY_TRIANGLESTRIP. See Wikipedia

On older generation GPU hardware, using triangle strips over triangle lists was a performance win. This is no longer true on modern GPUs even mobile platforms. While it does result in slightly smaller indices, it is generally far more useful to use triangle lists and optimized for vertex cache reuse. The main reason to include this functionality in DirectXMesh is for completeness and for creating performance references.

NvTriStrip

Stewart, J. "Tunneling for Triangle Strips" PDF

Evans, F., Skiena, S., Varshney, A.; "Optimizing triangle strips for fast rendering", Visualization 1996. PDF

Akeley, K., Haeberli, P., Burns, D.; tomesh.c. C Program on SGI Developer's Toolbox CD, 1990

Retire legacy Xbox One XDK support

The only scenario that still uses VS 2017 is for the legacy Xbox One XDK. This task is drop support for this older Xbox development model and remove the following projects:

DirectXMesh_XboxOneXDK_2017.sln

Split Mesh

A function to break a mesh into multiple index buffers/vertex buffers based on a specified size.

void D3DXSplitMesh(
  _In_   LPD3DXMESH pMeshIn,
  _In_   const DWORD *pAdjacencyIn,
  _In_   const DWORD MaxSize,
  _In_   const DWORD Options,
  _Out_  DWORD *pMeshesOut,
  _Out_  LPD3DXBUFFER *ppMeshArrayOut,
  _Out_  LPD3DXBUFFER *ppAdjacencyArrayOut,
  _Out_  LPD3DXBUFFER *ppFaceRemapArrayOut,
  _Out_  LPD3DXBUFFER *ppVertRemapArrayOut
);

This primary use of this function is to take a mesh that requires 32-bit indices into a set of meshes that only requires 16-bit indices, which is most useful when preparing meshes for Feature Level 9.1 devices.

Meshconvert support PBR SDKMESH variant materials

Existing sdkmesh materials only contain up to three textures (diffuse, normal, and specular) plus traditional Lambert/Phong colors.

This work item is to create a sdkmesh version 2 that defines PBR materials: albeto, normal, occlusion/metalness/roughness and optionally emissive.

MSVC conformance mode build failure in WaveFrontReader

We build DirectXMesh as part of MSVC rolling regression tests, and with the latest compiler toolset we found this source issue under the C++ standards conformance mode "/permissive-".

wavefrontreader.h(555): error C3861: 'XMFLOAT3': identifier not found
        BoundingBox::CreateFromPoints(bounds, vertices.size(), reinterpret_cast<const XMFLOAT3*>(vertices.data()), sizeof(Vertex));
                                                                                      ^

The issue is that the type XMFLOAT3, and the type BoundingBox, are defined in the DirectX namespace, where lookup cannot find them from the template definition. Unlike other functions in this class, LoadVBO doesn't have a local using namespace DirectX; declaration. If you add that, lookup succeeds.

This failure doesn't appear in the non-conformant default mode likely because a using directive for the DirectX namespace appears before the template is instantiated, so lookup succeeds in the instantiation context.

Using on linux

Thanks for your job.
I want to know wow to use this tool on Linux system?

I think it is not possible to compile directly on Linux. When I do this, I will report an error

/usr/local/include/directxmath/DirectXMath. h: 150:10: fatal error: sal.h: no file or directory
#include "sal.h"
^~~~~~~
Compilation interrupted.

The file sal.h is only available on windows I think.

So I tring to use vcpkg tool. I installed it successfully, but it can't run.

CMakeLists.txt

cmake_minimum_required(VERSION 3.1.0)

set(VCPKG_DIR /home/nys/libs/vcpkg)
set(CMAKE_TOOLCHAIN_FILE ${VCPKG_DIR}/scripts/buildsystems/vcpkg.cmake
CACHE STRING "Vcpkg toolchain file")

message("using vcpkg: " ${CMAKE_TOOLCHAIN_FILE})
project(vckpg_demo)
set(directxmesh_DIR ${VCPKG_DIR}/installed/x64-linux/share/directxmesh/)
find_package(directxmesh CONFIG REQUIRED)

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} Microsoft::DirectXMesh Microsoft::DirectXMesh::Utilities)

main.cpp

int main(){ return 0; }

when I using cmake .., I got the errror message:

-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
using vcpkg: /home/nys/libs/vcpkg/scripts/buildsystems/vcpkg.cmake
CMake Warning (dev) at /home/nys/libs/vcpkg/installed/x64-linux/share/directxmesh/directxmesh-config.cmake:27 (if):
  Policy CMP0057 is not set: Support new IN_LIST if() operator.  Run "cmake
  --help-policy CMP0057" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  IN_LIST will be interpreted as an operator when the policy is set to NEW.
  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at /home/nys/libs/vcpkg/installed/x64-linux/share/directxmesh/directxmesh-config.cmake:27 (if):
  if given arguments:

    "(" "NOT" "directxmesh_FIND_COMPONENTS" ")" "OR" "(" "library" "IN_LIST" "directxmesh_FIND_COMPONENTS" ")"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


-- Configuring incomplete, errors occurred!

Revisit Meshlet generation performance

See https://twitter.com/charshenton/status/1728962623096668177?s=20

SDKMesh reader utility

While SDKMESH is primarily a run-time format, it would be useful to have a SDKMeshReader.h similar to the WaveFrontReader.h utility (storing the data in std::vector and the like) to support importing of SDKMESH for tools instead of just output only.

reading somefile.obj FAILED (80070002)

Problem converting from obj files into sdkmesh i have tried with three object.

Weld vertices in mesh

Welds vertices that share attributes based on a epsilon threshold.

HRESULT D3DXWeldVertices(
  _In_     LPD3DXMESH pMesh,
  _In_     DWORD Flags,
  _In_     const D3DXWeldEpsilons *pEpsilons,
  _In_     const DWORD *pAdjacencyIn,
  _Inout_  DWORD *pAdjacencyOut,
  _Out_    DWORD *pFaceRemap,
  _Out_    LPD3DXBUFFER *ppVertexRemap
);  

Ericson, C. "Real Time Collision Detection", Chapter 12.1, Morgan Kaufmann Publishers, 2005

C# compatibility

Hello,
Would it be possible to either have a C API or COM API so that it's possible to write a c# wrapper for this? I've successfully created a DirectX c# wrapper that works with UWP, but I'm definitely missing these tools, such as directxmesh or directxtex to speed up development (CMO models, DDS texture compatibility for instance).

Thank you.

Direct3D 9 FVF helpers

The original D3DX9 library contains these functions for working with Direct3D 9 'fixed-function' flexible vertex formats (FVF):

D3DXGetFVFVertexSize
D3DXGetDeclVertexSize
D3DXGetDeclLength
D3DXDeclaratorFromFVF
D3DXFVFFromDeclarator

A DX11 & DX12 version of D3DXDeclaratorFromFVF could be useful in DirectXMesh

Could also provide a simple header in Utility for FVFs that implements the Direct3D 9 original functionality for these five functions.

MeshletGenerator parameter types not match

For function ComputeMeshlets, uniqueVertexIB must have type vector<uint8_t>. For function ComputeCullData, uniqueVertexIB must have type vector<uint16_t> or vector<uint32_t>. Should this have the same type of the original index buffer all the time?
After ComputeMeshlets, every two uint8_t in uniqueVertexIB represents one vertex. The result is correct but the declaration of these functions are confusing.

Meshlet generation

Add support for meshlet generation to use with Mesh Shaders

ARM64 version of meshconvert

The VC++ projects only currently build x86/x64 versions of this tool for desktop.

The CMakeLists.txt supports creating the ARM64 version of this tool, so this should be added to the VC++ projects.