This project has moved and is read-only. For the latest updates, please go here.

Fragmentation

Dec 31, 2013 at 12:27 AM
I know you guys probably can't comment on this, but it feels like there is fragmentation in Microsoft's developer story with respect to 3D. I'll leave XNA out of the discussion here and focus on present day MS technologies. I notice that Microsoft continues to invest in tooling for 3D development in Visual Studio. And as a result we have seen a migration of tools and technologies --

Mesh formats: .X, XNB, SDKMesh, to .CMO.
Content pipelines: XNA via FBX to VS Model Pipeline
And lastly, shaders: HLSL to DGSL

To be honest, I do not know what the compelling advantage is for using the CMO format other than VS2013 wants me to use it. Similarly, I wonder what lead MS to embrace DGSL over HLSL shader language with semantics for effect binding.

From an outsider's perspective these technology changes can feel arbitrary. I am hoping for MS to sell me on these technology changes and it seems strange that there isn't more evangelism to advocate their value... Maybe I am off-base, I don't know...
Dec 31, 2013 at 1:26 AM
Edited Dec 31, 2013 at 1:27 AM
There's no 'universal' solution for geometry or animation runtime file container formats. Textures and sound have established runtime formats that are widely used, but not meshes. Partly this is because so many developers roll their own, and partly because it's a complex problem space. Autodesk .FBX has established itself as the defacto standard for meshes as a 'source' format, but is a terrible runtime format.

.SDKMesh was created as a replacement for the legacy .X files (which date back to DirectX 3 Retained Mode) primarily for use in the Direct3D 10 and Direct3D 11 samples. I maintain support for it in DirectXTK and update the exporter tool mostly because it's the defacto runtime container for DirectX SDK samples.

We support .CMO and .DGSL in DirectXTK to supplant the need for the VS Starter Kit. This content pipeline has a number of issues--primarily that it doesn't directly support Feature Level 9.x which is needed for Surface RT, Surface 2, and Windows phone--but at least it's there. It's still very 'toy' but we want to support it as an option. The VS team is well aware of the limitations of the current .CMO/.DGSL pipeline.

I have a work item to look at how DirectXTK might use .XNB, but until or unless there's a solution for the XNA Game Studio content pipeline to move forward, it's pretty low priority. Remember that .XNB Is heavily tied to the .NET Serialization and type system, and that the defined types are tied to Direct3D 9 declarations and mesh formats.
Marked as answer by stonstad on 12/30/2013 at 7:30 PM