Change Set 15430

Topics: Developer Forum
Coordinator
Jan 5, 2007 at 7:08 PM
Hey, Michael, thanks for aiming to make the library work for Microsoft's importer. I feel this is a good goal.

However, I have three models that used to work with my importer and don't work anymore. Now I get this exception:

Error 1 Node has more than one BoneContent child. Unable to determine which one is the skeleton root. C:\XNAOld\XNAFont\WindowsGame1\WindowsGame1\test.x WindowsGame1

I couldn't find this exception anywhere in the code, so is the X Importer now calling Microsoft's importer?

Also, the animations seem to run less smooth now, which I will look at. I have also had problems using the library with Microsoft's importer on some animations.

I will take a look at these things.

Developer
Jan 6, 2007 at 5:48 AM
David,

Sorry for breaking your build. Suddenly I felt irresistable urge of releasing FBX importer support to the world as I saw lots of people having problems with unreliable X exporters in MAX and other apps. It depressed me seeing people struggling with X models when I had working FBX and BVH in my hands.

I tried to make it as compatible with previous releases as possible and spent lots of time adjusting cutom X importer to be compatible with Microsoft's. But the custom importer with Change Set 15430 still does not work on some models. For example, it works on Tiny.x but does not work on unmodified Tiny_4anim.x from DirectX SDK. I am stuck with these problems in importer and definetely need your help and community help to fix the problems.

The exception you got is aparently from MeshHelper.FindSkeleton(). This method is used to obtain a skeleton to pass to MeshHelper.FlattenSkeleton() which in turn is used to obtain bone indices for skinning. Though I think it is coming from ModelProcessor, not from importer.

Microsoft's MeshHelper.FindSkeleton() method uses very obscure algorithm and I have trouble figuring out what importer should produce to make the MeshHelper.FindSkeleton() happy. Moreover, I am not sure what Microsoft's importer wants from the model at all. If I understand correctly you are getting this exception with Microsoft's importer too?

One way to fix the problem would be to use AnimationController.FlattenSkeleton() with custom importer. Please note that this still requires upgrades to AnimationController.FlattenSkeleton() as the current implementation is very primitive and won't work out of the box. Are you ready to start that journey? It's a difficult path. I will be able to provide some help but as I already mentioned I was unable to do this myself.

Another way is to revert to previous implementation of AnimationController, maybe have two AnimationControllers, but this would break run-time compatibility of models imported with custom and Microsoft's importers. I don't recommend that. I think life will be a lot easier if we stick with Content Pipeline DOM for models, skeletons and vertex buffers.

Yet another way is to modify your models so that Microsoft's X importer works on them. Is this possible?

On animations running less smoothly: this is quite probably a bug. I will help to fix it if you tell me more details on how to reproduce it.




Coordinator
Jan 9, 2007 at 10:18 PM
I thinking making animation work on both importers is the best approach. I'll look over the code and give more details. It seems that models imported by Maya do not work on the microsoft importer but do work on mine, and this is the same with some milkshape models. I am sure there are models that work on Microsofts importer but not on mine as well.
Coordinator
Jan 9, 2007 at 10:52 PM
I found out why the animations are choppy. The animations are no longer interpolated to 60 frames per second in the content pipeline like they were in the previous change set, and instead, the animations just step through the frames provided in the files.

This could also cause a wide variety of errors in animation transforms.
Coordinator
Jan 9, 2007 at 11:07 PM
Another problem is that more bones are used than need to be used. Bones that influence 0 vertices should not need to be passed to the matrix palette.

I'm not entirely sure how the microsoft importer/processor create the indices. I know that every bone in Tiny affects the animation, but for many models this is not the case. My importer prunes the indices so that as few bones as possible are used, so it will likely not work as is for the majority of the models due to changes in 15430 to the way AnimationController works.

The problem right now is a lot is being done during run time that should be handled in the pipeline. I think that the microsoft importer passes BoneContentCollection objects as a vertex channel to the processor, and it is here that the BoneContentCollection channel should be pruned. Also, the animation should once again be interpolated in the pipeline. I suggest that we make the current release archived so that we don't mislead people.
Jan 10, 2007 at 7:52 AM
Interestingly enough, the bear .X file included in the "Special" release also doesn't work with the new importer. It says something about there being no head bone.

(Using milkshape here, and none of my exports are working, for what it's worth).