Gen.Kenobi, on 24 January 2012 - 02:09 PM, said:
Yeah, but i guess the main issue with this code(or hierarchy or rig) is that it has several different bones that does different things - there's the DEF bones, the MCH, the ORG ones. I don't know if the game supports the IK/FK solvers. And I also have no clue from where to start to parse this into the skeletons.xml file. It's quite confusing for me.
Looks like the DEF bones are the ones that are important (since they're the only ones listed as joints in the inverse bind pose array, around line 1086). As far as I know, animations made with that rig will only animate those bones.
Someone can correct me if I'm wrong, but basically: all the rigs used in the game have a <standard_skeleton> entry which lists the bones actually used by the game. Then they have one or more <skeleton> entries, each one maps a different set of bone names and hierarchies back to the original <standard_skeleton>. This lets us have multiple differently named and structured rigs mapped back to a single standard one, for instance there could be one set for Max, one for Blender, one for Maya, etc. When a COLLADA file is imported into the game, it looks up the bone names and tries to find a matching skeleton or throws an error if there's no match.
So if you can map your rig to the standard biped, that would be the best route so we have interoperability between existing animations and models. As far as how to do that, it seems like if you don't give a <target> entry for a bone in a given <skeleton>, then it will coalesce into its parent, so maybe it would work if you can only list <target> for the important DEF bones. You need 29 bones (including root) to be compatible with existing bipeds. I don't know if it will work even if you do that, I guess it depends on how robust our version of FCollada is and how good Blender's exporter is...
0
shiprigtest2.zip 136.53K
25 downloads
)
