摘自http://forum.unity3d.com/threads/16485-quot-stitch-multiple-body-parts-into-one-character-quot
So I have many many models. Each has a skeleton, material, etc.
I want to take some of these and combine them into one so I can apply animation commands to one rather than many (and so they stay in sync).
I have one mesh, say MeshA with the following hierarchy:
MeshA
-AllJoint
-AllTrans1
-Take 001
-MeshA
Take 001 being a sample animation clip
MeshA being the mesh
MeshB is similar in hierarchy however has the same bone structure (down to every detail). MeshA is a body, and MeshB is arms.
I want to "stich" MeshB into MeshA so that I can apply animations to MeshA and have MeshB work....
Currently, I just create a base object, put MeshA and MeshB under it, and apply animations to them individually (it gets really tedious with more than just these 2, specially when the animations get out of sync or I want to do blending).
How do I "stich" these 2 together as it says in the Unity2.1 features?
Ok, here we go, finally got around to jotting a bit down!
Bones - Just a hierarchy of GameObjects. The transforms are what the system uses Animation Clips - Collection of vectors to modify transforms. Animation clips reference the bone by name I believe (although I haven't tested this fully, it works in my scripts).
So, you want to stitch some models together to share the bones and share an animation component. Took me a bit to figure this out, then again I'm a bit slow 
Where does the information in a model object go in Unity GameObjects? Answer is, quite simply, in the components!
When an object is updated in the Unity engine it's components interact with Unity in different ways. If it has a MeshRenderer component, then it has geometry data to send to the rendering system. A rigid body component would send geometry data to the physics system for simulation. And so on......
We all know a static mesh is easier to render than a dynamic one (one where the vertices are changing all the time) as the dynamic one causes the graphics card to do more state changes and thus slows down rendering. Although today's technology is very capable of doing this without slowing down, developers tend to take that as a queue to overload the system with regards to dynamic objects.
With that I introduce you to MeshFilters, MeshRenderers and SkinnedMeshRenderers! These are the bread and butter of the models in unity!
A static Model (procedural), which requires no animation (bone animation), would need a MeshFilter to hold the Model Geometry and a MeshRenderer to render the geometry. Being new to Unity from 2.0 and on I can only assume this was kept this way, meaning 2 separate components, to A. Stay backwards compatible in the engine and B. Allow for compiled geometry to quickly be accessed in an organized fashion. I believe the MeshFilter stores the geometry source whereas it sends a compiled version to the MeshRenderer upon creation. The MeshRenderer merely adds materials, shadows, and so on based on your configuration of the MeshRenderer.
A dynamic model (non-procedural) has the combination of the MeshFilter and MeshRenderer all built into one. It stores the source mesh, does lookups for bone structures, compiles the geometry and then stores it in it's own renderer for when Unity requires it to be rendered.
That's all great, and probably somewhat inaccurate (Hey, I didn't promise you an insiders look into the Unity engine, just a compilation of all the testing I have been doing to get my own projects off the ground in addition to my decades of experience with creating engines in C++ and so on), but how do I add one model to another in code? Alright, enough Unity Component Theory and on to application......
Adding objects to a Static GameObject: Simply add a MeshFilter, and set the sharedMesh variable to the mesh you want. If you want a texture on that mesh, just add a MeshRenderer and set materials of that MeshRenderer to whatever materials you want displayed (some meshes have multiple UV layers, or multi-texturing, this is set in the MeshRenderer on which material is pointing to which UV set). A link to the MeshFilter Docs: http://unity3d.com/support/documenta...eshFilter.html A link to the MeshRenderer Docs: http://unity3d.com/support/documenta...hRenderer.html
Adding objects to a Dynamic GameObject: Yeay, get ready to get dirty! First thing of great note is that the MeshFilter and MeshRenderer of the Static Object have been combined into one great SkinnedMeshRenderer. I will talk more about that later but for now, lets talk about bones! So, we have a bone structure in an existing GameObject, how do we identify it? I mean in my models I see (in some cases, but I will get to exceptions later) the following objects under the root object after I import it:
RootImportedObject -AllTrans1 -AllJoint -InfoObject (named the same as the rootImportedObject)
When I look at the AllJoint I will see more children, something like this:
AllJoint -JNT_C1_Hip01 --JNT_C1_Leg_R01 --JNT_C1_Leg_L01 -JNT_C1_Spine01 --JNT_C1_Head01 ---JNT_C1_Head02
Each one of them is named. Ok, so that's the bone structure, I need to keep that AllJoint intact! The AllTrans1? Not sure what that is, it has a control object, and then all the same bone names below it in the same structure as the AllJoint. I deleted this from my model and noticed no change in animation, so I am not sure what it is for, although I can say it is merely a hierarchy of transforms just like the AllJoint is.
The InfoObject in the above hierarchy holds the components for my SkinnedMeshRenderer and any materials used.
Exceptions: Now I feel it important to mention exceptions to what I have found above. The importer does it's best to create the same structure for animated assets however based on how it was exported (and from what asset creation tool, or modeler), it might slip up from time to time. Although it doesn't affect how the animation works, or looks, it affects how the information is kept in the hierarchy. I HAVE found the InfoObject to actually be one of the bones; where a bone, one of the children bones deep down in the hierarchy, had the SkinnedMeshRenderer and Materials components. So in a Script, I had to do a search on the game object for ALL Components in children for SkinnedMeshRenderers in order to locate them and copy them over to the target object.
So how do the animations actually work? The answer is, as it would seem, by name. You call the clip by name, the clip calls the bones by name, and so on. When you run an animation in the Animation Component it does a search (when you add the component the first time) through the Object it's attached to and through all it's children to find all the bones it needs to move/rotate/transform by name. If I remove the JNT_C1_Leg_R01 object from my hierarchy above and try to run the animations associated with this model Unity will error out with a reference somewhere along the lines of "bone differences" or something (I forget the error). BUT I can move JNT_C1_Leg_R01 somewhere else in the hierarchy, like parent it to the spine or head, and the animation will still work (although the visual outcome will be very funky as the original hierarchy is now different than intended, and a guy that is supposed to be running might look like he's doing some funky dance instead).
Ok, so the Animation works with the bones by name, how does that correlate to the actual mesh? By a predetermined array pointing to each bone of course. The SkinnedMeshRenderer has a Bones array built into it, you simply create an array of those transforms (the bones above) and set that bone array to it. The skinned mesh renderer looks at the bones and their transforms and then modifies the geometry of it's internal MeshFilter. It then compiles the geometry and sends it to it's internal MeshRenderer (remember I told you that the SkinnedMeshRenderer combined the MeshRenderer and the MeshFilter). The Internal MeshRenderer does it's magic on it and sends it to Unity's renderer for display.
Link to the SkinnedMeshRenderer: http://unity3d.com/support/documenta...hRenderer.html
Wonderful, you told me exactly what 36 hours of reading the documentation can tell me, how do i do it already? Ok ok.... We will take MyTorso and MyArm, both animated model assets I just imported into Unity and we will go through the scripting necessary to stitch the two together. Now remember that their bones have to be the same setup; meaning they have to have bones by the same name or the same skeleton when they are exported.
So, Drag MyTorso and MyArm on to the scene of Unity. Lets create a script that stitches MyArm INTO MyTorso leaving us with just MyTorso to animate and what not in other scripts.
-
var objPlayer : GameObject;
-
var objLimb : GameObject;
Ahhhh, that fresh code smell! We have two Editor Refferenceable objects Add this script to any game object (even player), and drag MyTorso onto objPlayer and drag MyArm onto objLimb. The first thing we will need to do is to look through objLimb for our SkinnedMeshRenderer, once we find it (or them, hehe, remember we can have multiple meshes and what not on them) we will then begin the construction on objPlayer.
-
AddLimb( objLimb, objPlayer );
-
-
{
-
ProcessBonedObject( SkinnedRenderer, RootObj );
-
}
YEAY our first function! I like to write independent functions so that I can easily move code from one project to another as much as possible. So if your curious why somethings are in there that probably wont pertain to this tutorial, bare with me.
So above we send our objPlayer in as a root object (or destination object) and the objLimb's SkinenedMeshRenderer in as the target object (or our object we need to copy over). I pass the Renderer in instead of the GameObject because we will need to re-find it to get it's info anyhow. And since we can reference a gameObject from a component, it just seems best to pass what we are actually looking for. You'll see that I do a search for all SkinnedMeshRenderers in the object, then iterate through each one passing it to a processbone function. It is in that function where we will actually do the stitching, so on we go:
-
{
-
/* Create the SubObject */
-
/* Add the renderer */
-
/* Assemble Bone Structure */
-
/* Assemble Renderer */
-
NewRenderer.bones = MyBones;
-
NewRenderer.sharedMesh = ThisRenderer.sharedMesh;
-
}
-
-
{
-
var ReturnObj : Transform;
-
return ThisGObj.transform;
-
{
-
ReturnObj = FindChildByName( ThisName, child );
-
if( ReturnObj )
-
return ReturnObj;
-
}
-
return null;
-
}
Whoa, busy busy busy! Two functions for the price of one! Ok, enough cheesy references....... So what are we doing above? We passed in the RoobObject and our SkinnedMeshRenderer from the object we want to stitch into the root. First, and because I like organization, we create an object to hold all this info in the root object. Remember it doesnt matter where in the rootobject this info resides as long as the bones it refferences stay the same (or stay the same name/heirarchy). K, so I create it, name it what our limb object was named (so we know what it is), and parent it to the root object (or our torso in this case). Next we add the SkinnedMeshRenderer component to our new subobject. This will hold the same stuff our arm has with the exception of the bones being referenced from the torso object. Now we need to find the bones, by name, from the old limb object and create an array of them to insert into the new renderer. This uses the second function above. You can see we look through the bones of the arm, get the name of each, find them by name in the torso, and create an array based on that info. Lastly we set the bones of the new renderer to our new bones reference array. Set the mesh, and the materials, and BAMMMM!!!!
After this, we can run animations, move the bones around manually, or what have you and you will see the limb follow along as if it were the same mesh as the torso.
This is all I have time for now, and feel free to make any corrections to this as I don't assume this to be accurate. I only know it works from all the testing I have done from my own projects [/quote]