Sunday, 31 May 2015

Messing about with Unity 5 and BVH motion capture

Unity is a great platform for putting games together. But it can also be really, really frustrating. A mix of visual and code-based development reminds me very much of Flash, circa version 5 (or MX). Building stuff is fun and easy - but when you come back to a project after a little while, trying to find which object contains which script can be a real pain.

Similarly, the visual-based editor can lead to really annoying lost hours, as you trawl through numerous online examples and forums, trying to understand why everyone else can get a figure to animate, while yours remains resolutely inert on the screen!

But it's worth persevering with; and once you've worked out it's quirks and remembered which tick boxes to click on (and, more importantly, in which order), you can often be rewarded with some what I tend to think of as "scriptable animations". Sure, Unity has a full development system on the backend but, until you go way below the surface, it's not much more than Actionscript 2 gave us Flash developers in the late 90s.

In particular, getting 3d model rigs and skeletons to line up between 3ds Max and Unity can be a bit of a trial (especially if the model is bought from the Unity Asset store and has a Unity/mecanim-friendly rig, but isn't particularly easy to use in 3ds Max). This makes using motion capture (BVH) files a bit of a trial too.

But after some fiddling about, and messing about with both Unity and 3ds Max (it was very hit-and-miss so a write-up may have to wait until we can work out exactly what we did and how to repeat it!) we managed to get the example Brekel motion capture file (from a Microsoft Kinect v2 system) played out by one of our characters:

While the first two orcs remain under the control of the scripts they were imported with, the third little character is completely under the influence of our BVH file (which in turn has been converted into a mechanim-friendly .anim file, and is being driven by the mecanim/animator controller).

The characters are also wearing modified armour - 3d models that we took into 3ds Max and modified a bit, to make them more customisable (is that even a word?).

Each helmet basically has all possible options enabled, and in script we loop through each character on the stage and delete the parts of their armour that we no longer require.

The character in the middle is wearing a modified helmet with no script applied - all the different combinations are visible. The orc on the left has a "tribal-style" helmet, complete with horns and a skull and a full face guard. The orc on the right is more lightly armoured, and so has a lighter helmet, consisting of a few spikes on the top and a single face protector bar.

By creating different helmet types in the 3ds Max, then merging in components from the previous helmet style, we're able to create a range of armour for our orcs. In the image above, we've an (as yet untextured) German-style helmet, complete with face guard, ear-flaps, skull and a spike on top. Any or all of these component parts can be modified using script, so one model can be configured to give a number of different helmet types.

By mixing and matching just a couple of different props, we'll be able to create a horde of orcs, each slightly different from the next and each armoured differently, while maintaining the feel of the armour being made from whatever spoils they may have found lying around - either at the end of an earlier game of Blood Bowl, or on a battlefield (hence the World War reference in some of the armour).