ModelData.Bone class is used for data storage - the model compiler writes this class to file. ModelBone is the runtime representation of a, well, model bone. Therefore, the first one - is the storage structure, while the second represents the runtime structure.

SharpDX.Toolkit assembly contains all classes that are used by several components at once. For example SharpDX.Toolkit.Compiler uses ModelData.Bone to write data to a compiled model file, and SharpDX.Toolkit.Graphics is using it to read model data from the file at runtime. So, for animation, you could have a class ModelData.AnimationNode in SharpDX.Toolkit assembly (used for data storage) and a ModelAnimationNode class in SharpDX.Toolkit.Graphics which will be used at runtime.

Does this makes sense?

"SharpDX.Toolkit.Compiler uses ModelData.Bone to write data to a compiled model file, and SharpDX.Toolkit.Graphics is using it to read model data from the file at runtime."

No, it isn't. Runtime Model loading hold no connection to ModelData.

ModelCompiler compiles ModelData from file using assimp, then saves it as implemented in ModelData.Serialize, then, at runtime, the model is loaded NOT using Model data serialization implementation, but duplication of serialization method implemented into ModelReader.ReadModel(ref Model), called by Model.Load(...).

From ModelData.Serialize(..):
"// This code should not be modified without modifying the serialize code in Model."

Well.. we could do it somehow more elegant but I guess this is fine.

Ok, if you can propose any improvements - feel free to open a pull request.

The main reason for code duplication is to avoid double allocation at runtime, as a model can have serveral bones/materials...etc and I wanted to avoid a bit to pressure the GC. That's why the serializer are somewhat duplicated. One for offline compiling (ModelData) with simple layout, no runtime dependencies (Texture2D...etc.) and the pure runtime version (Model) that has runtime dependencies. The work to maintain it is relatively low; It was a couple of hours to develop and a version handling skinning should not generate lost of additional work for the serialization part.