Shawn Hargreaves Blog
Chuck, awesome fellow that he is, has been slaving away on a 3D model loading solution for the DirectX Tool Kit. Documentation here. I won't bother to repeat all the details in this post, but as a quick summary:
This is an implementation of a mesh renderer similar to the XNA Game Studio Model, ModelMesh, ModelMeshPart design. It can load data from two different model formats:
Note: Model currently only supports rigid models. Support for animation, skinning, and frame hierarchy is on our radar for the future, but not yet implemented.
Check it out, let us know what you think, and a big thank you to Chuck for filling what until today was the biggest hole in our little toolkit!
Cool. DirectXTK is like next XNA but written in C++. Also question is there Sound API in DirectXTK ?
Why not embed the FBX SDK?
One of our goals for DirectXTK is to focus on the 'sweet spot' that hits many platforms at once including Windows Store apps, Windows phone 8, and Win32 desktop Direct3D 11 apps. Direct3D 11 has both the most 'known holes' and is the most 'cross platform' of APIs for these targets.
Game audio is basically cross platform already with XAudio 2.8 available for Windows Store apps, Windows phone apps, and Win32 desktop apps on Windows 8. XAudio 2.7 has to be used for Win32 desktop apps on Windows 7 and Windows Vista. There are some differences, but it isn't hard to write code that can compile against both libraries for the most part.
The same is true of Common Controller gamepad input via XINPUT.
The area that has some room for utility work is a solid 'dual-use coding' implementation of a WAV file loader and a tool for properly padding out WAV file data for Async I/O (to replace what the legacy DirectX SDK XACTBLD tool could do for wave banks).
> Why not embed the FBX SDK?
FBX format is very big, very complicated, and very inefficient to load. It is designed for high fidelity exchange of data between modelling programs, rather than for easy loading into a runtime D3D object model. Thus it is usually better to use an offline preprocess to convert FBX into some other format that better fits D3D.
There is also a pragmatic issue that the FBX SDK won't work at all in the context of a Windows Store or Windows Phone app. So to load models on those platforms, it is not just desirable but necessary to run the FBX stuff as a preprocess on your desktop PC.
Also, have you looked at the size (in byte on disk) of the Autodesk FBX DLLs or static libraries? They are huge. Also, the Autodesk FBX SDK API tends to change radically every few years to track their product development which makes it rather challenging to use them as a 'standard' for a runtime container format.
I'm completely out of the loop on game development and 3D APIs, but I have to wonder what was wrong with the XNB intermediary format and using FBX as build-time format? It did support skeletal animation and it was -in my opinion- one of the big things XNA had going for it, at least for anyone attempting 3D development. I'm sure you've got excellent reasons for the choices that have been made, but from the backseat here it looks like we've come full circle back to DX9 with rudimentary .X model support.
I'm just a poorly informed relic though, so I'd actually welcome the complete deconstruction of my observation.
.xnb is an interesting option - something Chuck and I have discussed and would like to support when time permits. It has two main issues, which is why we decided to start with .sdkmesh:
- The XNA tooling to generate .xnb files is tied to Visual Studio 2010, so developers would have to keep an older version of Visual Studio around for building their content. Not impossible, but kindof an awkward workflow.
- .xnb format is closely tied to .NET serialization mechanisms and the .NET type system. It's not impossible to write a C++ loader for it, but much tricker than parsing the things from .NET code. For instance what is the C++ equivalent of "object Tag" or "Dictionary<string, object>"? .xnb files rely heavily on type system extensibility (for instance skinned animation is an extension, not part of the core Model type) so a good C++ implementation really does have to support subclassing, polymorphic types, generic collections, and suchlike .NET type complexities.
Shawn Please help ,, last time
in the respect for tom miller,frank(microsoft gamestudio), savage(blade3d),the shawn(microsoft phone8),david weller(now at nvidia) and all the others members of the xna team,, the supercool dudes
now that it all over the news that xna is dead
can microsoft please release the source code for the xna content pipeline
so xna can leve on in monogame ,, like you see this great game "Skulls of the Shogun"
is made in c# monogame = Microsoft XNA
please microsoft help on here ,, you have lost 10.000 developers acording to gamasutra
i think it is more than this you have lost
you are now a SLAVE to unity game framework, so please help on here..
xna was an easy step into game making, c# is an easy step into c++ code
unity create script people , not real programers
that is why xna was a good framework
please help on here microsoft
one more thing as David Helgason kind put the words, "Microsoft welcome to slaveri"
do you whant this microsoft ,,
Microsoft please help so we can take this to the level of an worthy opponent
please release the content pipeline source code ,,
the fbx pipeline
the xof pipeline
"TALK TO YOUR CO WORKERS PLEASE SHAWN IF IT CAN BE DONE,, please
@Michael Hansen... grow up...
Anything on when animated meshes will be supported by the DXTK? I am in dire need of it and have not been able to use any other format :(