microsoft / DirectXMesh

DirectXMesh geometry processing library

Home Page:https://walbourn.github.io/directxmesh/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Overloads for void* indices+DXGI_FORMAT

walbourn opened this issue · comments

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)

Most content tools work with 32-bit indices for the bulk of the pipeline, and then collapse to 16-bit at the end of it will fit. It could expand any 16-bit inputs early in the pipeline. As such, it seems like the majority of use is just the uint32_t versions, making the runtime selection less relevant.