A couple of weeks ago, I posted up an example video for an automated Blend Shape extraction tool I made for Unity and Maya. Moving this tool back into Touch KO 2.0, I needed it to work in conjunction with another big AssetPostprocessor script that sets up my boxer prefabs. Basically, I needed to make sure that my blend shapes were all set up on the character before I start building the prefab, so that I can link them up as needed.

My first thought was to make my prefab setup script inherit from the blend shape importer, call the base method, and then call all of my setup stuff. This approach would work, provided that my base method appropriately contained controls to avoid reduplication of information. Then I stumbled across this function. All I had to do was add it to my AssetPostprocessor class that sets up my boxer prefab.

/*
 * Ensure this script executes after blend shapes have been set up
 * */
public override int GetPostprocessOrder ()
{
	return 100;
}

I don’t have very complicated needs like branching and so on, but I do have a library of common code that I share across projects. This library contains a bunch of useful stuff that doesn’t rely on any game systems: things like helper classes, math classes, serialization for built-in types, and so on. The trouble is, I’m often working simultaneously on a bunch of projects that share my library (or worse still parts of my library), and so it can be a pain in the neck to push the changes out across all my projects. As such, I took the time to set up a system using Subversion working on top of my UAS projects in order to synchronize my library code.

Apart from Unity, you obviously need Subversion. If you’re on OS X, this is part of Snow Leopard, so you’re good to go. Because I’m not especially adept at all the setup, and because there are plenty of really good tutorials, I won’t go through all the details. Basically, you need to prepare a repository somewhere and get a good SVN client. If you’re on OS X, I really recommend Cornerstone. It’s not open source, but it does some key things I need:

1. It has a great GUI. Apart from letting you do things easily, it also allows you to set up each working copy to show when it is out of sync, so I know which Unity projects needs to pull down new library updates.
2. The GUI lets you effortlessly modify your snvignore settings, allowing you to exclude all of your non-library code from your SVN repo. For example, I only want to include folders like Assets/ Scripts/Library, and Assets/Editor/Library, so I want to be able to easily exclude my per-project code and assets from the SVN repo.
3. It lets me take advantage of sparse checkout features in SVN. This feature was actually the deciding factor for me, as I distribute packages in the Unity Asset Store with limited copies of my library code. For example, my Biped Editor package contains library code for my VectorHelpers class, but not FloatMatrix. This requirement was also part of the reason I opted for SVN instead of Git. Maybe it’s possible to manage it easily with Git, but it wasn’t something I was up for fighting against!

The basic requirement to make this work as painlessly as possible is to have parallel structure in your Unity projects. I have a generally parallel structure, but because of Asset Store requirements, for example, my library code needs to be in folders like Assets/PackageName/ Scripts/Library, whereas all of my games are simply Assets/ Scripts/Library. Because of this issue, instead of making my Assets folder top-level in my repo, the repo simply has Scripts/Library, Editor/Library, and Plugins/Library at the top level. The problem in the video, as you can see, is that all of my working copies for my games are called Assets, whereas having Assets as the top-level folder in my repo would allow Cornerstone to display my Unity project folder names in the working copy list, so I wouldn’t have to look in the inspector to double-check what project I’m in. Depending on your SVN client, you may or may not experience this problem. Probably the absolute easiest way to set your project up is to have an Assets/Library and an Assets/Game folder in your project, the latter of which contains all of your actual per-game stuff. Using this organization, you would only have to apply svnignore to the Assets/Game folder in your working copy, instead of having to add all of your individual project folders. I leave it up to you to know what is best for your needs, but it suffices to say “stop and think about it before you pull the trigger.” Once you’ve picked out your organization system, export your library code as a unitypackage from Unity’s main menu.

At this point, create a new, empty Unity project and make it a working copy of your new SVN repo. In my case, I had to point to my project folder and call the working copy Assets because of my organizational structure. Again, if your repo will contain Assets, your project folder can be your working copy folder, but you’ve probably already figured that out.

Now, import your unitypackage into this empty project using the one you just created. This will populate your project with your library code.

Finally, check your library into the repo and voila! Now you have a common code library under version control sitting on top of your Unity project, which is managed using the Asset Server.

Now, if you set up a new project, just always make it a working copy of your repo first thing. If you dump all of your game assets into a folder that is already ignored (e.g., Assets/Game), then you shouldn’t have further work to do. Otherwise, make sure you remember to ignore your non-library folders when you commit any library code changes to your SVN repo. Using a client like Cornerstone, any new folders will show up in bold in your working copy view, and you can easily ignore them from the inspector or using the RMB context menu.

If you want to get extant projects set up on your SVN repo, you may want to first rename your extant project folders whose names conflict with those on the repo. You can then make your project a working copy and move over anything from your renamed folders that you need to keep and ignore or commit to the repo.

I hope some of you find this helpful, but if not at least I’ve documented it for myself!

At any rate, the component that I created is designed to let animation data, rather than procedural velocity values, drive a character’s motion in space. The component sits on top of Unity’s animation API to let you simply play, crossfade, and blend animations using any of the existing API methods, and the computer takes care of everything else after the fact. The way it works is by tracking the position and rotation of the pelvis in the space of the character’s root node for each active AnimationState and then backward applying this motion to the root node itself and snapping the pelvis back into its position hovering over the root. Since the source code is all available in the project, I won’t belabor the details too much here, but you can certainly ask me if you have any questions. (The one thing perhaps worth mentioning, as an addendum to the video, is that the pelvis forward axis is not strictly necessary for computing output: only for displaying debug information. For computation, the character’s rotation is determined using the pelvis right axis.)

You can download an example project from Mixamo that contains the component as well as a sample character with some animations. Because the tutorial video on the Mixamo website is compressed pretty substantially, I have also uploaded a copy to my Vimeo account in case you would like to watch it in full HD resolution.