*** UPDATE July 31st, 2012 ***
Hello everyone,
Sorry about the delays… real life, a game I’m working on, and a baby in the works has a way of interrupting the best of plans. However, I have been steadily plugging along, putting in a few hours here and there every week to refactor the whole Skinz framework and include some additional functionality. I can see the finish-line on the horizon so I’m posting some info on what to expect.
- Skinz will be free to use with full functionality.
I simply can’t bother with supporting this product as any revenue generated from it will not be worth the amount of time and effort necessary to support it and answer questions. However, I will be making the source-code available for purchase and it will be priced according to the time and effort I’ve put into it (ie. it won’t be cheap). To those who are disappointed at this : you’re free to invest the same amount of time and effort I spent in understanding all the technical intricacies of stitching together multiple meshes and optimizing them, create your own Skinning framework, and sell that for the price of a hamburger… I am sure that you will find after dividing your revenue by the amount of labor you’ve put in that you’ve earned a whole 5 cents an hour! 
- Unity Free and Pro supported.
That’s right, I’ve refactored Skinz so that you can use it with either Free or Pro. To do this, I created an IO abstraction layer that lets you treat AssetBundles and Resources in the same manner, so those of you who don’t have Pro will be able to use the Skinz framework and if you so choose, switch to Pro at a future date by changing only one line of code. This IO abstraction layer is available for use as part of the API so that you can use it in your own non-Skinz projects.
- XML-based config
I have completely done away with the old filename based Skinning scheme; instead, you now specify your skins in an XML config file. This makes for a much more legible and flexible format and also means you can now share the same image over multiple skins.
- New Atlas generation , MipMap, and Image Scaling functionality.
I have added my own version of Texture2D.PackTextures functionality that can generate multiple atlases, includes a rotate option for those who want to maximize their packing, and lets you decide whether or not you want it to resize your images to fit. The framework currently contains an implemenation for the MaxRects packing algorithm (considered one of the best packing algorithms) but is flexible enough to let you implement your own. The framework also includes MipMap creation and Image scaling functionality that currently contains an implementation for Lanczos 3 and 8 resampling (considered one of the best quality scaling algorithms) but is flexible enough to let you implement your own. I will add other filters as time permits (such as Box, Bell, Mitchell, etc…).
- Animation Plug n Play, use across multiple models
The new framework now supports loading/unloading animations on the fly so you can optimize which animations are loaded at any time. You can also share animations across multiple models; that is, you can take the animations from Model A and have it run on Model B; as long as the bone names match, you’re good to go!
- General API improvements
As you can see, I’ve tried as much as possible to abstract a lot of the supporting functionality so that it’s flexibile enough for you to plug in your own implementations. I’ve done the same to the core Skinz functionality which means if you choose not to use my specific implementation of Skinz you have the tools to implement your own.
Optional - I’ve been toying with the idea of extending Skinz to work with static meshes (ie. non-rigged), that way your static models can reap the benefits of the Skinz framework (such as combine and optimization features). The modification is fairly trivial, but it’s bound to conflict with some paid assets on the asset store such as Draw Call Minimizer and Batching Tools; that is, I’m not sure it’s fair to make similar functionality available for free as part of my package when those authors depend on their paid assets for their revenue… I’ll probably put this on hold until people start rioting at my door.
*** END UPDATE ***
Hello everyone,
Within the next week (or two) I plan on releasing a Skinning package for Unity Pro users. This package gives you the ability to stitch together multiple body-parts at runtime that is extremely easy to use. It allows for switching between different skins on a character (like League of Legends) or switching between different body-parts on a character (like Diablo). It also allows you to remove body-parts which can come in handy for those of you making games where the character can lose an arm, a leg, or their head! When it comes to stitching the character together, it produces the most efficient mesh and materials/shaders combination for the least amount of draw calls and the best possible performance. It does this by combining all the meshes together while also merging all the materials/shaders together using atlases generated on the fly. Switching between body-parts is very easy as well, and all it takes are the following two lines :
characterWardrobe.WearItem(“head”, “HelmOfValor”);
myCharacter = characterWardrobe.Generate();
If you want to make the head disappear :
characterWardrobe.WearItem(“head”, null);
myCharacter = characterWardrobe.Generate();
Switching between body-parts will not interrupt the animation in any way, so it is seamless and transparent. Importing your characters is also made very easy because of the declarative style. We have a mesh and texture naming scheme where your artists can specify pretty much any shaders they want to use, as well as which textures are the main texture, bump-map, parallax, etc… Then, when it comes time for the developer to import, it’s as easy as clicking the fbx and clicking the import menu option. This is a very important and often overlooked feature since it means that the developer (or integrator) no longer has to worry about textures/shaders/materials that are supposed to be in the artist domain, you let them take care of it and all you have to do is click the import button and you’re done! You’re also not limited to having to put all your body-parts into one file; you can split your body parts into multiple files and let the importer take care of sorting it out. It makes extensive use of the Asset Bundles feature, and we make the bundles very small in order to minimize RAM usage.
I built the system mainly for use in a game that I am developing, but seeing that there’s not much out there in the way of skinning frameworks I decided to make mine available for purchase. There is, of course, the CharacterCustomization sample that Unity provides, but my system goes far beyond what that system is capable of and is also much easier to use. It was, however, a very important learning tool for me back when I first started getting my nose wet in Unity so I would like to thank it’s creator Bas Smit for such an excellent resource.
I am trying to gauge whether or not there is much of a demand for such a framework since I don’t see many people asking for it, so if you’re interested at all in such a system please let me know by replying to this thread with any specific features you would like to see.
Cheers!
El Diablo
Download Fully-Functional Free Version Here : advanced dynamic atlas generation and material merge feature included but currently capped at a limited number of uses per game instance.
IMPORTANT : Before running the demo, make sure your stats window is up. While running, you can toggle the GUI on and off with the space-bar; disabling the GUI will let you see the actual number of draw-calls.
Setup Guide
Importing your characters into Unity
The automated import process requires that you name your meshes and textures according to our naming convention. This is done in order to match them up and create the appropriate shaders. In this manner you can specify almost any shader type (including custom shaders) and assign textures to them automatically.
Our system introduces two important concepts : the body-part and the skin.
Let’s say that you have a character model in which you have it broken down into several conceptual parts such as Head, Top, Legs, and Feet (similar to the system used in games such as Diablo or World of Warcraft). You also have it such that there are several variations of each part. For example, you may have two different head meshes : one where he’s bald, and another wearing a spartan helmet. In this example, the concept of a Head would be considered a “body-part”, and the two physical head variations (bald and spartan) would be considered “skins”. In our system, you would be able to easily swap from a bald head skin to a spartan head skin by doing the following :
characterWardrobe.WearItem(“head”, “spartan”);
or vice-versa :
characterWardrobe.WearItem(“head”, “bald”);
Now there are games out there that don’t require the ability to swap out parts of the body. For example, the game League of Legends doesn’t offer the ability to customize your character by individual body parts. Instead, they offer you different skins for each character. This is also easy to do in our system when you think of the entire character as a single body-part. For example, let’s say we have a model of a mage containing two variations : IceMage and FireMage. Here we’re not swapping individual parts, so what are we swapping exactly? Well, the entire character of course! So if you think of the entire character as one big conceptual body-part, then you’ll realize that you can easily swap between Ice and Fire skins by doing the following :
characterWardrobe.WearItem(“character”, “ice”);
or vice-versa :
characterWardrobe.WearItem(“character”, “fire”);
You should now have a pretty solid understanding of the two important concepts of a body-part and a skin. Now we will discuss how to name your meshes and textures.
Naming scheme
Mesh/Texture names cannot contain the following characters as they are special characters reserved for use by our system :
Plus sign +
Minus sign -
Underscore _
Meshes
Mesh names must start with the name of the body-part it belongs to followed by an underscore (_) and the name of the skin.
Example 1 - character model contains individual swappable pieces (Head, Top, and Legs) :
head_Leather
head_Chain
head_Plate
top_Leather
top_Chain
top_Plate
legs_Leather
legs_Chain
legs_Plate
Example 2 - character model contains different variations of the same character (Ice, Fire, Lightning, Air)
character_Ice
character_Fire
character_Lightning
character_Air
Textures
Texture names must match the name of the corresponding mesh; however, this is not enough. In addition to that, you need to specify the name of the shader that it should use as well as specify which texture should be the main texture, the bump-map texture, etc… Let’s use the “character_Ice” mesh from Example 2 and specify that it should be a Bumped Diffuse shader as well as specify which texture should be the main texture and which should be bumped.
First, we need to tell the system which shader to use as well as which texture is to be the main/base texture. We do this by following the texture name with a plus (+) sign and the short-name for the shader we want to use :
character_Ice+bdif.png
The system now knows to associate the above texture with the “character_Ice” mesh. It also knows that the “character_Ice” mesh needs to be rendered with a “Bumped Diffuse” (“bdif” being its short-name) shader. It also knows to use this texture as the main/base texture for the “Bumped Diffuse” shader.
Now we need to specify the other textures that should be used in the “Bumped Diffuse” shader, in this case the bump-map. We do this by following the texture name with a minus (-) sign and the short-name for the texture type :
character_Ice-bump.png
The system now knows to associate the above texture with the “character_Ice” mesh. It also knows that it is to be used as the bump-map (“bump” being its short-name) for the “Bumped Diffuse” shader used to render the “character_Ice” mesh.
So for a quick recap, the plus (+) sign is used on a texture to specify the type of shader to use and that it is to be that shader’s main/base texture. The minus (-) sign is used by all the other textures to specify the texture’s texture-type (ie. normal-map, height-map, etc…).
Advanced
Multiple skins per mesh
You are not limited to using one texture per mesh as our system is flexible enough to accommodate multiple textures. This may be accomplished by following your texture name with an underscore and a new skin name that overrides the one used on the mesh. Let’s use the “character_Ice” mesh from Example 2 to show how we can specify three skins for it called BlueFrost, LightBlueFrost, and WhiteFrost.
character_Ice_BlueFrost+bdif.png
character_Ice_BlueFrost-bump.png
character_Ice_LightBlueFrost+bdif.png
character_Ice_LightBlueFrost-bump.png
character_Ice_WhiteFrost+bdif.png
character_Ice_WhiteFrost-bump.png
Since we are specifying three different skins for the character_Ice mesh, we can no longer refer to the Ice skin as we did previously :
characterWardrobe.WearItem(“character”, “ice”);
The above no longer works because the Ice skin no longer exists; it has been replaced by three other skins. Instead, you should now swap between all the skins in Example 2 by doing the following :
characterWardrobe.WearItem(“character”, “bluefrost”);
or
characterWardrobe.WearItem(“character”, “lightbluefrost”);
or
characterWardrobe.WearItem(“character”, “whitefrost”);
or
characterWardrobe.WearItem(“character”, “fire”);
or
characterWardrobe.WearItem(“character”, “lightning”);
or
characterWardrobe.WearItem(“character”, “air”);
You should now be able to specify multiple skins per mesh.
Texture Propagation
Sometimes you may find yourself in a situation where you need to use the same texture multiple times. For example, in the “Multiple skins per mesh” section, we created three skins for one mesh and each skin required a main texture and a bump-map texture. What if we wanted to use the same bump-map for all three skins instead of having to specify it each time? In that case we would do the following :
character_Ice_BlueFrost+bdif.png
character_Ice_LightBlueFrost+bdif.png
character_Ice_WhiteFrost+bdif.png
character_Ice-bump.png
The above works because our system will propagate the bump-map to all skins deriving from “character_Ice”, which in this case are the three skins BlueFrost, LightBlueFrost, and WhiteFrost.
If we want to specify a bump-map that would apply to all the skins in Example 2, we would do the following :
character-bump.png
The above would propagate the bump-map to all five skins deriving from “character”, which in this case are the six skins BlueFrost, LightBlueFrost, WhiteFrost, Fire, Lightning, and Air.
Import Guide
Your model’s project folder structure should resemble the following :
Characters
Female
Female.fbx
textures
...
Male
Male.fbx
Head.fbx
Body.fbx
Legs.fbx
textures
...
Importing models whose components are all in one single FBX
Select the FBX (or more than one if you would like to perform this action on several models at once) and select “Import/Generate Materials” from the menu. Once that is finished, select “Import/Generate Asset Bundles” from the menu.
Importing models whose components are in multiple FBX’s
Select all the FBX’s containing each component (each FBX must contain a single part) and select “Import/Generate Materials MULTI” from the menu. Once that is finished, deselect everything, then select an FBX containing ONLY the rig (this must be your first selection) followed by each of the other components containing a single part each and select “Import/Generate Asset Bundles MULTI” from the menu.
Go for it!