Right now I am in the process of porting over this library so that it makes use of MGCB libraries but I am currently running into problems, primarily in the way that the FBX importer is loading in the content of the FBX file that I am using.
It seems that the FBXImporter written for MGCB is failing to load in all the required content. When I use my FBX asset with the XNA sample, it seems to work fine.
I exported the asset originally from Blender, and then converted from the old FBX DOM format (Blender exports in that way only), to the FBX 2013 specification and now it works fine. Perhaps the importer that is used with MonoGame does not support this format? But I figured that I would mention that anyway.
Right now it would seem that the importer is loading an insufficient of bones that are required by the processor in order to parse through all the animations.
After some brief investigation, it would seem that the FBX importer that is used by MGCB seems to only import some of the bones from the FBX asset.
The importer that XNA uses reports 15 bones where as the MGCB reports 10 for this asset.
The current FbxImporter has a few issues. In particular, skinned models and animations are not handled correctly.
In the last weeks I have rewritten the FbxImporter to support skinned models. I am now at a point were I can load all models and animations, which I have used previously with XNA. The changes are not yet public. I will prepare a few pull requests in the next days (probably next week).
I’d be really intrigued to see what these changes are. I’ve noticed that over the past year there has been significant work to get the MGCB FbxImporter working with the OpenAssetImporter.
I am going to take a look at it meanwhile to see if I can get a quick fix.
My code is still using the OpenAssetImporter. I have just rewritten the skinning/animation part in the OpenAssetImporter.
Did you modify any code that was part of the managed AssImp libs either?
Just to keep this thread up to date, I’ve taken a look at this. I’ve got my VS2010 and XNA instance running in Debug with the FbxImporter breakpointed and the NodeContent input in my watch window so I can see the output before processing with my SkinnedModelProcessor
I’ve also done the same with the NodeContent that is returned from the FbxImporter in MonoGame and it seems that the FbxImporter of MonoGame is doing something strange with bones that are stored within the asset. The reason I say this is because the output of either versions do not align with each other.
I’ll have to set up more use cases to determine if this is the case for all fbx assets, but if so then at least I have something to work with.
No, all changes in MonoGame.
I have posted a comment and a link to our OpenAssetImporter here: https://github.com/mono/MonoGame/issues/1209
Hi, can I ask when will your changes be public? I have developed a full game and the only part is missing to play/show the animations for my models and for that I would need the SkinnedModelProcessor … now everything is “just” a Model, no animations converted, all my charachters just moving around as ghosts!
The changes were merged about a year ago (PR #3336). But the fixes only apply to the FbxImporter. I am not sure what the state of the SkinnedModelProcessor for MonoGame is. (In our XNA/MonoGame engine we use a custom model processor and runtime model format.)
Many thanks for the clarification!
I have just downloaded the DigtalRune software and realised that there is a Monogame Pipeline tool in it (can be started by the pipeline.cmd command), but still, under FBX importer, there is no SkinnedModel processor, just the standard Model - Monogame one.
What am I doing wrong?
We have our own model class (Models and Meshes) and use own content pipeline extensions (Building Content).
Let me know if you need more information.
Well, yes, this is exactly what I did, started up your version of the monogame pipeline tool, referenced all the digitalrune pipeline dll-s, but I still see only Monogame types under FBX importer (anywhere), no sign of the digitalrune word at all.
What I see on this screenshot, I dont see in my machine:
I believe this happens when the Pipeline Tool does not find the DigitalRune pipeline DLLs.
- Have you unblocked the ZIP after downloading, before extraction? Otherwise, Windows may block the DLLs.
- Then please check the path to the pipeline DLLs. Absolute path should work. I don’t remember the search order for relative paths that MonoGame uses. I think it searches relative to the .mgcb project, then relative to the Pipeline.exe or working folder. Not sure.
The content pipeline DLLs and the MonoGame Pipeline Tool are in <DIGITALRUNE_FOLDER>\References\MonoGame\Windows.
I had to copy the DLLs next to the .mcgb file and reference them from there and now it works! Thanks for the hint!