Not sure if this is still wanted, but I updated the DirectXMesh integration I wrote last year to adhere to the new glTF-SDK API. This add-on can optimize meshes (optimize index layout for drawing, remove geometric redundancies), generate tangent space data, restructure the mesh primitive data layout, and the vertex layout. The glTF-Toolkit.Test unit tests succeed in converting all test assets, which have passed glTF validators and visual inspection of mesh & animation data integrity.
An issue arose when integrating it with WindowsMRAssetConverter, however. The SerializeBinary function makes assumptions about the order of accessors and how the data is stored that breaks when processing this add-on's outputted Document. First, it strips all data into separate buffers via accessors, undoing the interleaving of data, such as vertex data (line 228). Second, it generates buffer view ids sequentially based on the order of the accessors it encounters (also within line 228). Then, while copying 'extension' and 'extra' data it does a hard replace of the buffer view based on that generated id (line 331). Since the old buffer view may very well have a different id than the new buffer view, this replace thrashes document integrity.
I'm not sure the purpose of these steps so I didn't attempt to modify it. Once this issue is resolved it seems ready for a pull.
Not sure if this is still wanted, but I updated the DirectXMesh integration I wrote last year to adhere to the new glTF-SDK API. This add-on can optimize meshes (optimize index layout for drawing, remove geometric redundancies), generate tangent space data, restructure the mesh primitive data layout, and the vertex layout. The glTF-Toolkit.Test unit tests succeed in converting all test assets, which have passed glTF validators and visual inspection of mesh & animation data integrity.
An issue arose when integrating it with WindowsMRAssetConverter, however. The SerializeBinary function makes assumptions about the order of accessors and how the data is stored that breaks when processing this add-on's outputted Document. First, it strips all data into separate buffers via accessors, undoing the interleaving of data, such as vertex data (line 228). Second, it generates buffer view ids sequentially based on the order of the accessors it encounters (also within line 228). Then, while copying 'extension' and 'extra' data it does a hard replace of the buffer view based on that generated id (line 331). Since the old buffer view may very well have a different id than the new buffer view, this replace thrashes document integrity.
I'm not sure the purpose of these steps so I didn't attempt to modify it. Once this issue is resolved it seems ready for a pull.