Showing posts with label unity3d. Show all posts
Showing posts with label unity3d. Show all posts

Sunday, 9 August 2015

Playing video with alpha transparency in Unity 5 using a custom shader

Playing videos in Unity has become much easier thanks to version 5 - even in the "personal" edition, you can apply a video as a texture/material to just about any surface (prior to v5 you had to have the "professional" version of Unity to play videos).

Having given up on Flash, we're looking to Unity for our game-writing needs, and that includes playing video with a transparent background. Given that it's 2015, surely Unity is capable of playing videos with a transparent background?

Well, it turns out not. Or at least, not easily.
Unity uses some variant of the Ogg Vorbis format for video (the Theora codec apparently) and, bizarrely, Quicktime to handle importing videos into the editor. And since the Theora codec doesn't support video alpha transparency, for a while it looked like we'd hit yet another brick wall. For a while at least.

A quick check on the Unity Asset store reveals a number of custom shaders and scripts that can apply chroma keying at runtime. So instead of using a video with an alpha channel, we should be able to simply use a video with a flat, matte green background, and key out the green on-the-fly.

One such off-the-shelf plugin is the Universal Chroma Key shader. But it doesn't work with Unity 5 (and we're still waiting for our refund, Rodrigo!). One that does work is the slightly more expensive UChroma Key by CatsPawsGames. It's easy enough to set up and use, and gives a half-decent result. It's good.

But not great.



After removing the green background, we're still left with a green "halo" around our main character - which is particularly noticeable when the video is actually playing. Some frames suffer more than others, but the result is a discernible green haze around our hero character. The only way to remove the green completely is to make the keying so "aggressive" that part of the main character starts to disappear too. And, obviously, this is no good for what we're after!

We spent quite a bit on different plug-ins from the online store, but UChroma gave the best results. And even that wasn't quite good enough for what we're after.

Just as we were about to give up on Unity, Scropp (Stephen Cropp) came up with a crazy idea - write our own shader. The reason it was so crazy? Well, some of us couldn't tell a texture from a material, let alone even understand what a shader is or does. Luckily, Stephen had a basic idea of how it all worked. And there were plenty of examples online about creating your own custom shader.

Our thinking was to create a shader which would accept not one, but two, material/textures. The first would be the footage we wanted to play, and the second would be a second movie texture, containing just the alpha data for the first movie. It seemed like it might be worth investigating.

We know that Unity doesn't support videos with alpha channels, but the idea of splitting it over two layers - one containing the footage, and one containing the alpha mask as a greyscale sequence seemed like a sensible one. So that's exactly what we did!

After creating our video footage with a green background and just the RGB (no alpha) channels -


- we exported the same footage from After Effects, only this time, exporting only the alpha channel (to a video format that also only supported RGB, no alpha)


Now it was simply a case of applying our footage video to one plane/quad and the alpha movie to another. Then simply play both movies together, and write a shader which took the alpha from one movie and applied it to the other. So far, so easy. One thing to look out for is that a movie texture doesn't automatically begin playing after being applied to a plane/quad. You need a simple script to kick it into life.

We simply created a "play video" script and dropped it onto each of our video containers. When we hit the "play" button in Unity, both videos started playing automatically:

using UnityEngine;
using System.Collections;
[RequireComponent (typeof(AudioSource))]

public class play_video : MonoBehaviour {

     // Use this for initialization
     void Start () {
          MovieTexture movie = GetComponent<Renderer>().material.mainTexture as MovieTexture;
          movie.loop = true;
          GetComponent<AudioSource>().clip = movie.audioClip;
          GetComponent<AudioSource>().Play ();
          movie.Play ();
     }
     
     // Update is called once per frame
     void Update () {
     
     }
}


The video player script should be pretty self-explanitory: simply get the audio and movietexture elements of the object that this script is placed on, and set them playing. It's that easy! The only stumbling block now is the "write your own custom shader" idea.

Let's start with the simplest of shaders - an unlit, video player shader.
Even if you don't full understand the "shader language" (as we still don't) it is possible to vaguely follow what's going on in the shader, with a bit of guesswork:

Shader "Custom/alpha1" {

     Properties{
          _MainTex("Color (RGB)", 2D) = "white"
     }

     SubShader{
          Tags{ "Queue" = "Transparent" "RenderType" = "Transparent" }

          CGPROGRAM
          #pragma surface surf NoLighting alpha

          fixed4 LightingNoLighting(SurfaceOutput s, fixed3 lightDir, fixed atten) {
               fixed4 c;
               c.rgb = s.Albedo;
               c.a = s.Alpha;
               return c;
          }

          struct Input {
               float2 uv_MainTex;
          };

          sampler2D _MainTex;
          void surf(Input IN, inout SurfaceOutput o) {
               o.Emission = tex2D(_MainTex, IN.uv_MainTex).rgb;
               o.Alpha = 1;
          }

          ENDCG
     }

}


So what's going on with this shader?
The first thing to notice is the #pragma command. This is basically called on every pixel that passes through this shader. So we've created a surface shader, each pixel is passed through the "surf" (surface render) function, the "nolighting" (lighting render) function, and the parameter "alpha" tells the shader that not all pixels are fully opaque (apparently, this can make a difference to the drawing order of the object, but we've taken care of this with our "tags" line).

Our nolighting function simply says "irrespective of the surface type or lighting conditions, each pixel should retain its own RGB and Alpha values - nothing in this shader will affect anything in the original texture".

A shader which applies specific lighting effects would have much more going on inside this function. But we don't want any lighting effects to be applied, so we simply return whatever we're sent through this function.

The other function of note is the "surf" (surface render) function. This accepts two parameters, an input texture and a surface output object. This function is slightly different to most shaders in that we don't set the surface texture (Albedo) on our output surface, but the "emission" property.

Think of it like this - we're not lighting a texture that's "printed" onto the plane - we're treating the plane like a television; even with no external lighting, your telly displays an image - the light is emitted from the actual TV screen - it's not dependent on external lighting being reflected off it. This is the same for our plane in our Unity project. Rather than set the "texture" of the plane surface, to match the pixels of the input texture, we're emitting those same pixels from the plane surface.

This is why we have the line
o.Emission = tex2D(_MainTex, IN.uv_MainTex).rgb;
instead of
o.Albedo = tex2D(_MainTex, IN.uv_MainTex).rgb;

If you drop your video onto a plane and add the shader (above), you should see the video being drawn as an unlit object (unaffected by external lighting) with no shadows (since the light is emitting from the plane, not being reflected off it). Perfect! We're written our first "no-light" shader!


Now the trick is to apply the alpha from the alpha material to the shader being used to play the video. That's relatively simple, but needs a bit of a careful editing to our original shader:

Shader "Custom/alpha1" {

     Properties{
          _MainTex("Color (RGB)", 2D) = "white"
          _AlphaTex("Color (RGB)", 2D) = "white"
     }

     SubShader{
          Tags{ "Queue" = "Transparent" "RenderType" = "Transparent" }

          CGPROGRAM
          #pragma surface surf NoLighting alpha

          fixed4 LightingNoLighting(SurfaceOutput s, fixed3 lightDir, fixed atten) {
               fixed4 c;
               c.rgb = s.Albedo;
               c.a = s.Alpha;
               return c;
          }

          struct Input {
               float2 uv_MainTex;
               float2 uv_AlphaTex;
          };

          sampler2D _MainTex;
          sampler2D _AlphaTex;
          
          void surf(Input IN, inout SurfaceOutput o) {
               o.Albedo = tex2D(_MainTex, IN.uv_MainTex).rgb;
               o.Alpha = tex2D(_AlphaTex, IN.uv_AlphaTex).rgb;
          }

          ENDCG
     }

}


The main changes here are:

Properties now include two materials/textures: the texture for the video to play, and a texture for the alpha mask. The input structure now includes both the texture to play and the alpha texture and the final line in our "surf" (surface render) function has changed:

Instead of setting the alpha (transparency) of every pixel to one (fully opaque) we look at the pixel in the alpha texture and use this to set the transparency of the pixel. Now, instead of each pixel being fully opaque, a white pixel in the alpha texture represents fully opaque, a black pixel represents fully transparent, and a grey shade, somewhere inbetween, indicates a semi-transparent pixel.



We also need to ensure that the play_video.cs script is applied to both planes and untick the "mesh render" option in the alpha plane (so that it does not get drawn to the screen when the game is played).


Hitting play now and we see our video footage playing, with an alpha mask removing all of the green pixels.

Well. Sort of.

After the video has looped a couple of times, it becomes obvious that the two movies are slowly drifting out of sync. After 20 seconds or more, the lag between the movies has become quite noticeable.



It looks like we're almost there - except it needs a bit of tweaking. Having our video and alpha footage on two separate movie clips is obviously causing problems (and probably putting quite a load on our GPU). What we need is a way of ensuring that the alpha and movie footage is always perfectly in sync.

What we need is to place the video and alpha footage in the same movie file!

After a bit of fiddling about with our two movies in After Effects and that's exactly what we've got....

And now we need yet another amendment to our shader. We lose the alpha texture (since it's now part of our main texture) which actually simplifies the script a little bit. But instead of using the main texture for the alpha channel, we use the main texture shifted half-way in the y-axis.



Here's the code for the updated shader:

Shader "Custom/alpha1" {

     Properties{
          _MainTex("Color (RGB)", 2D) = "white"
     }

     SubShader{
          Tags{ "Queue" = "Transparent" "RenderType" = "Transparent" }

          CGPROGRAM
          #pragma surface surf NoLighting alpha

          fixed4 LightingNoLighting(SurfaceOutput s, fixed3 lightDir, fixed atten) {
               fixed4 c;
               c.rgb = s.Albedo;
               c.a = s.Alpha;
               return c;
          }

          struct Input {
               float2 uv_MainTex;
          };

          sampler2D _MainTex;

          void surf(Input IN, inout SurfaceOutput o) {
               o.Emission = tex2D(_MainTex, IN.uv_MainTex).rgb;
               o.Alpha = tex2D(_MainTex, float2(IN.uv_MainTex.x, IN.uv_MainTex.y-0.5)).rgb;
          }

          ENDCG
     }

}


Now we're almost there.


Gone are the nasty out-of-sync issues, and the alpha mask applies perfectly on every frame of the video. Underneath the video we can still see our alpha mask, wherever the video footage has been drawn. We've decided that this is because if no more mask exists, the shader uses the previous "line" of mask and continues to draw in the same place as the previous "scan line".

This could easily be fixed by drawing a single horizontal black line along the bottom of our alpha mask footage (so the final scan line of the mask is 100% transparent, along its full length, and this would be applied to every pixel below our main character).

Another approach might be a simple "if" statement:

if(IN.uv_MainTex.y < 0.5){
     o.Alpha=0;
}else{
     o.Alpha = tex2D(_MainTex, float2(IN.uv_MainTex.x, IN.uv_MainTex.y-0.5)).rgb;
}


which yields the following result:


Well, it looks like we're nearly there.
There's still an occasional slight tinge around the character, particularly where there's a lot of fast motion (or motion blur) in the footage. If you look closely under the arm supporting the gun in the image above, you can see a slight green tinge. But in the main, it's pretty good.

There are a couple of ways of getting rid of this extra green:

The most obvious one is to simply remove the green from the video footage. Since we're no longer using this colour as a runtime chroma-key, there's no need for the background to be green - it could be black, or white, or some grey shade, somewhere inbetween (grey is less conspicuous as an outline colour than either harsh black or harsh white, depending on the type of background to be displayed immediately behind the video footage).

The other way of removing this one-pixel wide halo is to reduce the alpha mask by three pixels, then "blur" it back out by two pixels. This creates a much softer edge all the way around our main character (helping them to blend in with any background image) and removes the final pixel all the way around the alpha mask.

We had settled on a combination of both of these techniques when Scropp came up with the "proper" way to fix it: "clamp green to red" rendering. What this basically means is that for each pixel, compare the green and red channels of the image, and if the green value exceeds the red, limit it to be not more than the red channel.

If you think about it, this means that any pure green colour will be effectively reduced back to black. But any very pale green tint will also be reduced a tiny bit. Pure white, however, would not be affected, since it has the same amount of red as it does green.

Any pure green colours get blended to black. Very light green shades are blended more to yellow (when mixing RGB light, equal parts red and green create yellow) or pale blue (a turquoise colour of equal parts blue and green with very little red would be blended more to a blue colour as the green element is reduced). But for the colour to be a very light shade, it has to have lots of red, green and blue in it, so the amount of colour adjusted is actually pretty small.

So our final shader code looks like this:

Shader "Custom/alpha1" {

     Properties{
          _MainTex("Color (RGB)", 2D) = "white"
     }

     SubShader{
          Tags{ "Queue" = "Transparent" "RenderType" = "Transparent" }

          CGPROGRAM
          #pragma surface surf NoLighting alpha

          fixed4 LightingNoLighting(SurfaceOutput s, fixed3 lightDir, fixed atten) {
               fixed4 c;
               c.rgb = s.Albedo;
               c.a = s.Alpha;
               return c;
          }

          struct Input {
               float2 uv_MainTex;
          };

          sampler2D _MainTex;
          if( tex2D(_MainTex, IN.uv_MainTex).g > tex2D(_MainTex, IN.uv_MainTex).r ){
                o.Emission = tex2D(_MainTex, IN.uv_MainTex).r;
           }else{
                o.Emission = tex2D(_MainTex, IN.uv_MainTex).rgb;
           }

           if(IN.uv_MainTex.y < 0.5){
                o.Alpha=0;
           }else{
                o.Alpha = tex2D(_MainTex, float2(IN.uv_MainTex.x, IN.uv_MainTex.y-0.5)).rgb;
           }

          ENDCG
     }

}


And the result looks something like this:


Bang and the nasty green halo effect is gone!


The best bit about Stephen's approach is that as well as getting rid of the green spill that creates the green halo effect around our main character, it also helps reduce any obvious green areas on the skin and clothes, where the greenscreen might have been reflected onto it.

So there we have it - from three days ago, with no obvious way of being able to play a transparent video against a programmable background, to a custom Unity shader that does exactly the job for us! Things are starting to look quite promising for our zombie board/video game mashup....


Sunday, 31 May 2015

Editing BVH files

Motion capture is becoming quite accessible to the indie game developer, thanks to the Microsoft Kinect device. Although it didn't really take off as a dedicated game controller, in the same way that the Nintendo Wii of a few years back, it has proved very popular as a PC connected USB-device for all kinds of 3D applications.


There are two flavours of Xbox Kinect - the v1 (top) is the original device, originally released for the Xbox 360. The improved v2 version (bottom) was released for both the Xbox One and for PC as a development kit from Microsoft. Over time, Microsoft stopped producing the PC version and instead created an adapter to make the Xbox version compatible with any PC supporting a USB3 port.

Using either of these sensors, it's pretty easy to do motion capture with a half-decent PC and any one of a number of mo-cap applications. You can even do mo-cap directly in Unity with something like Cinema Mo Cap, which supports both types of Kinect device.


Although motion capture with a Kinect is (relatively) cheap - about £200 for the hardware and software, compared with £15,000 for a profession set-up - some of the captured motions leave a little bit to be desired, and almost always require some degree of "cleaning up" to remove rogue movements and the odd limb-twitch.

And this is where the cheap vs expensive approach really shows. Raw motion capture data is great for capturing key poses, but the problem with a lot of cheap mo-cap solutions is that they don't provide any editing tools - they simply expect you to use the motion capture data as provided.

This has two main drawbacks:

The first is that every now and again the mo-cap software mis-interprets the position of a limb or extremity (usually a foot or a finger) which creates strange glitches in the animation when played back.

The second is that a massive amount of extra data is captured that isn't really necessary. Most 3D packages provide "tweening" for animating a 3d character between two poses. BVH mo-cap files include all the inbetween movements as the subject moves from one pose to another.

If we had a way of capturing just the keyframes with the "important" poses in them (just before/after a major movement) we'd be able to eliminate both of these problems in one - we'd only need to keep the actual poses that add to our character movement, and in doing so, we could easily exclude any poses that contained glitches.

The problem with this approach is cost.
Mo-cap editing software is expensive.
And we're pretty cheap.
So we set about creating a simple mo-cap editor.

Now recreating a 3d animation from mo-cap data would be cool, but there's loads of this software around that does a far better job than we could do in a weekend. So we're not going to do that. We're going to use the fact the the BVH (mocap) data file format is pretty basic, to allow us to parse an animation file and extract only the data we're interested in.

For example, a BVH file consists of  a simple skeleton description, followed by a number of rotations for each "bone" or joint in the skeleton.

As we're looking at the Brekel motion capture software, we had a look at the sample data they provide from their Microsoft Kinect capture solution. The header of their BVH file looks something like this:

HIERARCHY
ROOT Hips
{
   OFFSET 0.000 77.138 0.000
   CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
   JOINT LeftHip
   {
      OFFSET 8.415 0.567 3.660
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT LeftKnee
      {
         OFFSET 0.000 -39.733 0.000
         CHANNELS 3 Zrotation Xrotation Yrotation
         JOINT LeftAnkle
         {
            OFFSET 0.000 -37.972 0.000
            CHANNELS 3 Zrotation Xrotation Yrotation
            End Site
            {
               OFFSET 0.000 0.000 11.130
            }
         }
      }
   }
   JOINT RightHip
   {
      OFFSET -8.415 0.567 3.660
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT RightKnee
      {
         OFFSET 0.000 -39.733 0.000
         CHANNELS 3 Zrotation Xrotation Yrotation
         JOINT RightAnkle
         {
            OFFSET 0.000 -37.972 0.000
            CHANNELS 3 Zrotation Xrotation Yrotation
            End Site
            {
               OFFSET 0.000 0.000 11.130
            }
         }
      }
   }
   JOINT Chest
   {
      OFFSET 0.000 32.175 0.000
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT Chest2
      {
         OFFSET 0.000 23.529 0.000
         CHANNELS 3 Zrotation Xrotation Yrotation
         JOINT LeftCollar
         {
            OFFSET 1.862 -0.567 0.239
            CHANNELS 3 Zrotation Xrotation Yrotation
            JOINT LeftShoulder
            {
               OFFSET 17.792 0.000 0.000
               CHANNELS 3 Zrotation Xrotation Yrotation
               JOINT LeftElbow
               {
                  OFFSET 26.436 0.000 0.000
                  CHANNELS 3 Zrotation Xrotation Yrotation
                  JOINT LeftWrist
                  {
                     OFFSET 24.686 0.000 0.000
                     CHANNELS 3 Zrotation Xrotation Yrotation
                     JOINT LeftFinger0
                     {
                        OFFSET 4.877 -1.044 3.608
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT LeftFinger01
                        {
                           OFFSET 2.665 -0.000 -0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT LeftFinger02
                           {
                              OFFSET 2.543 -0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET 2.667 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT LeftFinger1
                     {
                        OFFSET 9.232 -0.301 2.144
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT LeftFinger11
                        {
                           OFFSET 4.225 0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT LeftFinger12
                           {
                              OFFSET 2.654 -0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET 1.958 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT LeftFinger2
                     {
                        OFFSET 8.920 0.000 -0.000
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT LeftFinger21
                        {
                           OFFSET 4.863 0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT LeftFinger22
                           {
                              OFFSET 2.765 0.000 -0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET 2.006 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT LeftFinger3
                     {
                        OFFSET 8.689 -0.126 -2.087
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT LeftFinger31
                        {
                           OFFSET 4.538 0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT LeftFinger32
                           {
                              OFFSET 2.305 0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET 1.923 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT LeftFinger4
                     {
                        OFFSET 8.391 -0.817 -3.758
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT LeftFinger41
                        {
                           OFFSET 3.044 -0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT LeftFinger42
                           {
                              OFFSET 1.975 0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET 1.667 0.000 0.000
                              }
                           }
                        }
                     }
                  }
               }
            }
         }
         JOINT RightCollar
         {
            OFFSET -1.862 -0.567 0.239
            CHANNELS 3 Zrotation Xrotation Yrotation
            JOINT RightShoulder
            {
               OFFSET -17.792 0.000 0.000
               CHANNELS 3 Zrotation Xrotation Yrotation
               JOINT RightElbow
               {
                  OFFSET -26.436 0.000 0.000
                  CHANNELS 3 Zrotation Xrotation Yrotation
                  JOINT RightWrist
                  {
                     OFFSET -24.686 0.000 0.000
                     CHANNELS 3 Zrotation Xrotation Yrotation
                     JOINT RightFinger0
                     {
                        OFFSET -4.877 -1.044 3.608
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT RightFinger01
                        {
                           OFFSET -2.665 0.000 -0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT RightFinger02
                           {
                              OFFSET -2.543 0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET -2.667 -0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT RightFinger1
                     {
                        OFFSET -9.232 -0.301 2.144
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT RightFinger11
                        {
                           OFFSET -4.225 -0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT RightFinger12
                           {
                              OFFSET -2.654 -0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET -1.958 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT RightFinger2
                     {
                        OFFSET -8.920 -0.000 0.000
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT RightFinger21
                        {
                           OFFSET -4.863 0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT RightFinger22
                           {
                              OFFSET -2.765 -0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET -2.006 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT RightFinger3
                     {
                        OFFSET -8.689 -0.126 -2.087
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT RightFinger31
                        {
                           OFFSET -4.538 -0.000 0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT RightFinger32
                           {
                              OFFSET -2.305 -0.000 -0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET -1.923 0.000 0.000
                              }
                           }
                        }
                     }
                     JOINT RightFinger4
                     {
                        OFFSET -8.391 -0.817 -3.758
                        CHANNELS 3 Zrotation Xrotation Yrotation
                        JOINT RightFinger41
                        {
                           OFFSET -3.044 0.000 -0.000
                           CHANNELS 3 Zrotation Xrotation Yrotation
                           JOINT RightFinger42
                           {
                              OFFSET -1.975 0.000 0.000
                              CHANNELS 3 Zrotation Xrotation Yrotation
                              End Site
                              {
                                 OFFSET -1.667 0.000 0.000
                              }
                           }
                        }
                     }
                  }
               }
            }
         }
         JOINT Neck
         {
            OFFSET 0.000 0.767 0.000
            CHANNELS 3 Zrotation Xrotation Yrotation
            JOINT Head
            {
               OFFSET 0.000 6.907 0.000
               CHANNELS 3 Zrotation Xrotation Yrotation
               End Site
               {
                  OFFSET 0.000 14.799 0.000
               }
            }
         }
      }
   }
}

And after all this junk, we start to see the actual animation data:

MOTION
Frames: 1222
Frame Time: 0.033333

-19.09096 86.72628 -193.07651 -0.17976 -3.92397 0.68769 11.14140 7.20556 -0.92078 -2.29540 5.11692 1.91521 -4.62996 20.50473 12.81783 -1.86685 12.98398 -2.19955 4.44833 -6.98297 -8.14759 1.86476 28.76261 -3.89672 -0.15640 2.07988 0.12122 -0.19043 2.47325 0.22838 -13.72436 1.22983 -4.97758 -56.87571 -0.90905 2.53451 4.08357 4.61863 -27.81969 90.82480 13.02917 -11.51783 -0.00002 -0.00001 0.00000 0.00000 -0.00000 0.00000 0.00000 0.00000 0.00003 -0.00000 0.00000 -0.00000 -0.00000 0.00000 0.00000 -0.00000 0.00001 -0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 20.66945 1.98194 5.24341 45.82977 -3.28564 -12.81110 -4.51496 4.06287 32.23806 -67.48892 16.51301 3.78246 40.90540 11.75460 -3.91033 0.00000 0.00000 -5.00000 0.00000 -0.00000 -60.00000 -2.00000 0.00000 0.00000 -2.00000 -0.00000 -0.00000 -2.00000 -0.00000 -0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 0.00007 -0.00009 0.00017 0.36586 5.18664 -1.03638

-18.93125 86.57366 -193.57823 -0.16391 -3.94172 0.83452 10.91408 7.45215 -0.60187 -1.98701 4.62638 2.93570 -4.33215 20.72713 11.94433 -2.08694 12.07617 -2.03624 4.64667 -5.82190 -8.21822 2.01918 28.58089 -4.24085 -0.15541 2.07988 0.18790 -0.18295 2.47323 0.31173 -13.54430 1.22964 -5.07436 -56.47004 -0.41186 2.11939 4.26038 4.77343 -29.40027 91.83288 13.19723 -10.56911 -0.00002 -0.00001 0.00000 0.00000 -0.00000 0.00000 0.00000 0.00000 0.00003 -0.00000 0.00000 -0.00000 -0.00000 0.00000 0.00000 -0.00000 0.00001 -0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 20.79433 2.03776 5.34991 45.90844 -3.74690 -12.70695 -4.24716 3.86554 32.13912 -66.30006 16.40318 4.01541 40.90540 11.75460 -3.91033 0.00000 0.00000 -5.00000 0.00000 -0.00000 -60.00000 -2.00000 0.00000 0.00000 -2.00000 -0.00000 -0.00000 -2.00000 -0.00000 -0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 0.00007 -0.00009 0.00017 0.38941 5.29672 -1.33426

-18.69029 86.44820 -194.06238 -0.13211 -3.93218 0.98746 10.64748 7.47083 -0.35351 -1.75983 4.40165 3.84590 -4.08096 20.97137 11.17286 -2.40106 11.17657 -1.92644 4.91138 -4.70405 -8.28357 2.14832 28.34713 -4.54350 -0.15157 2.07987 0.23891 -0.17385 2.47322 0.37546 -13.39292 1.21721 -5.08208 -56.20360 0.13947 1.70207 4.39204 4.79714 -30.64237 91.87553 13.25845 -8.73148 -0.00002 -0.00001 0.00000 0.00000 -0.00000 0.00000 0.00000 0.00000 0.00003 -0.00000 0.00000 -0.00000 -0.00000 0.00000 0.00000 -0.00000 0.00001 -0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 -0.00004 0.00000 0.00000 -0.00005 -0.00000 -0.00000 -0.00003 -0.00001 0.00000 20.85100 2.04922 5.36268 46.08860 -4.05784 -12.48223 -3.93563 3.70835 31.93921 -65.79578 16.03147 4.05839 40.90540 11.75460 -3.91033 0.00000 0.00000 -5.00000 0.00000 -0.00000 -60.00000 -2.00000 0.00000 0.00000 -2.00000 -0.00000 -0.00000 -2.00000 -0.00000 -0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 80.00001 -0.00001 0.00001 90.00000 -0.00000 0.00001 70.00000 0.00000 0.00000 0.00007 -0.00009 0.00017 0.28722 5.38471 -1.59374

The motion data follows the structure of the defined skeleton exactly. So in our example, the first root of the tree is the hips bone/joint. This is defined as having 6 "channels"- the X,Y,Z positions of the hips in real space, and the Z,X,Y rotation applied to the hips. The position of every bone in the skeleton after this is in relation to the "root" bone.

This means that the first six values on each line of the motion data define the position and rotation of the hips joint. The next entry in the skeleton is the left-hip joint. This is defined as having three rotational values. So the next three values in each line of the motion data (the sixth, seventh and eighth values) define the rotation of the left-hip joint. The next joint in the skeleton is the left-knee, defined with three channels, so the ninth, tenth and eleventh values in the motion data are the Z,X,Y rotation values for the left-knee joint.

And so the motion data continues, each set of three values relating to the next bone in the skeleton. To confirm that this is true, we can take any line of motion data and apply it the skeleton description in the BVH header file. Here is the first line of motion data, applied to the skeleton:

MOTION
Frames: 1222
Frame Time: 0.033333

ROOT Hips -19.09096 86.72628 -193.07651 -0.17976 -3.92397 0.68769
JOINT LeftHip 11.14140 7.20556 -0.92078
JOINT LeftKnee -2.29540 5.11692 1.91521
JOINT LeftAnkle -4.62996 20.50473 12.81783
JOINT RightHip -1.86685 12.98398 -2.19955
JOINT RightKnee 4.44833 -6.98297 -8.14759
JOINT RightAnkle 1.86476 28.76261 -3.89672
JOINT Chest -0.15640 2.07988 0.12122
JOINT Chest2 -0.19043 2.47325 0.22838
JOINT LeftCollar -13.72436 1.22983 -4.97758
JOINT LeftShoulder -56.87571 -0.90905 2.53451
JOINT LeftElbow 4.08357 4.61863 -27.81969
JOINT LeftWrist 90.82480 13.02917 -11.51783
JOINT LeftFinger0 -0.00002 -0.00001 0.00000
JOINT LeftFinger01 0.00000 -0.00000 0.00000
JOINT LeftFinger02 0.00000 0.00000 0.00003
JOINT LeftFinger1 -0.00000 0.00000 -0.00000
JOINT LeftFinger11 -0.00000 0.00000 0.00000
JOINT LeftFinger12 -0.00000 0.00001 -0.00000
JOINT LeftFinger2 -0.00004 0.00000 0.00000
JOINT LeftFinger21 -0.00005 -0.00000 -0.00000
JOINT LeftFinger22 -0.00003 -0.00001 0.00000
JOINT LeftFinger3 -0.00004 0.00000 0.00000
JOINT LeftFinger31 -0.00005 -0.00000 -0.00000
JOINT LeftFinger32 -0.00003 -0.00001 0.00000
JOINT LeftFinger4 -0.00004 0.00000 0.00000
JOINT LeftFinger41 -0.00005 -0.00000 -0.00000
JOINT LeftFinger42 -0.00003 -0.00001 0.00000
JOINT RightCollar 20.66945 1.98194 5.24341
JOINT RightShoulder 45.82977 -3.28564 -12.81110
JOINT RightElbow -4.51496 4.06287 32.23806
JOINT RightWrist -67.48892 16.51301 3.78246
JOINT RightFinger0 40.90540 11.75460 -3.91033
JOINT RightFinger01 0.00000 0.00000 -5.00000
JOINT RightFinger02 0.00000 -0.00000 -60.00000
JOINT RightFinger1 -2.00000 0.00000 0.00000
JOINT RightFinger11 -2.00000 -0.00000 -0.00000
JOINT RightFinger12 -2.00000 -0.00000 -0.00000
JOINT RightFinger2 80.00001 -0.00001 0.00001
JOINT RightFinger21 90.00000 -0.00000 0.00001
JOINT RightFinger22 70.00000 0.00000 0.00000
JOINT RightFinger3 80.00001 -0.00001 0.00001
JOINT RightFinger31 90.00000 -0.00000 0.00001
JOINT RightFinger32 70.00000 0.00000 0.00000
JOINT RightFinger4 80.00001 -0.00001 0.00001
JOINT RightFinger41 90.00000 -0.00000 0.00001
JOINT RightFinger42 70.00000 0.00000 0.00000
JOINT Neck 0.00007 -0.00009 0.00017
JOINT Head 0.36586 5.18664 -1.03638

With this information, it should be pretty trivial to create an interface (in VB6 of course!) that can read and re-create the BVH skeleton tree visually:


We've added in some tick boxes in the tree structure, to allow us to select which bones/joints we want to include (or remove, if necessary). By walking through the tree structure, we're able to re-create the BVH structure, amended with bones removed if required.


By ticking and unticking boxes in our editor, we're able to remove entire limbs and tree branches from the skeleton. In this example, we've removed the left forearm, hand and fingers, as well as the right ankle and foot.


Of course removing a bone (or bones) from the skeleton means we also need to split each line of the motion data, and re-create it to apply only to the bones selected in the interface. This is also a relatively trival exercise, but one that needs careful attention, since removing the wrong set of three values can vastly effect the rest of the animation.

Lastly, we added in a list of "keyframes" we want to capture into our editor. So instead of recreating the entire bvh file as captured, we can take only the frames we're interested in from the BVH data. This is done by simply reading through the original BVH motion data and if the line number (plus the offset from where the motion data starts) matches any one of the keyframes required, the motion data is parsed and re-applied to our modified skeleton, before being written to a second BVH file.

By using this approach, we've been able to create motion capture files with only the bones/joints we're interested in (for example, removing the lower limbs from an animation from which only the upper torso is only required) as well as only the key poses from the animation we need to recreate the animation in our Unity game. This results in much smaller files, with only a tiny amount of data in them (compared to the original animation files).

Of course a BVH file containing only the key poses we're interested in won't play back at the correct speed (since we've dropped about 98% of the captured data). But by capturing only the key poses, after importing into Unity, we can stretch the imported animation out, using the original animation to work out how many frames to leave between each key pose. And we still need to load the original data into some kind of BVH playback application (such as BVHViewer) in order to see the animation being played out on a 3d character. But using a bvh-viewing app allows us to select a frame with a pose we want to keep and then simply enter this frame number into our VB editor app - it's a bit clunky, but it works. And, as much as anything, doesn't cost a penny!


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).

Thursday, 28 May 2015

Modelling in 3DS Max - getting started

After commissioning some disappointing custom 3D models, we figured it was time to knuckle down and give this 3DS Max thing a go. Our electronic board game is still on a back burner, but smoldering along - this time we're looking at creating some fantasy football teams (and considering making some custom animations using a Kinect for mo-cap but more on that in the future!)

Our original commission was for a couple of human footballers and a couple of orcs.
The initial photos came back looking like one character had been created, then simply re-shaped and re-skinned to create three other derivatives. Not quite what we were looking for!

Luckily the Unity Asset store had just what we needed - some nice, slightly cartoon-y looking orc characters, ready-rigged, with a few sample animations included.


These orcs not only keep their humanoid shape, but also manage to capture the ork-iness of an orc: the long, muscular arms and slightly hunched stance tell you that these are definitely not just human characters that have been coloured green.

In fact, we're not quite sure how to go about "re-skinning" these fellas, but it can be done. For now we're more interested in getting a usable character or two. These characters also come with a couple of bits of armour, which can be attached to empty game objects, placed on the elbows, shoulders and knee joints.


What we needed was a bit of 3DS Max magic, to create some custom armour that we can then simply hook onto these connection points on the model. Here's a run down of how we created our first ever 3DS Max model, from scratch.

Firstly, we're creating a "blood-bowl-like" shoulder pad, complete with raised edges and lots of spikes. This is like a squashed-up half-orange shape, with a bit of modification. This is how we did it:

The first thing was to create a sphere, and rotate it so that the "segments" travelled around the object, from top to bottom. Then we reduced the number of segments as low as we could go without it looking too angular.


We only actually want half a ball, so we changed the "hemisphere" option to 0.5.
Setting "slice" to 180 meant that as well as only drawing half the ball vertically, this half-ball shape was cut horizontally, so only 180 (of the total 360) degrees of the shape were drawn


We then made two copies of this quarter-ball shape, and placed one each to the left and to the right of the original. We made one slightly larger than the original and placed it - slightly higher and slightly to the right - of the original.


With the first shape selected, we created a new compound shape object and selected "pro-boolean". This allows shapes to be added together, subtracted from each other and combinations of these functions. Ensuring our first shape was selected first, we went for subtraction and started picking.


When we selected the (larger) shape that was overlapping the original, it immediately took a big slice out of the original shape.


We then took the other shape (previously deposited to the left of the original) and scaled it down slightly, before positioning it in the "empty space" just created. Then created a clone of this (smaller) shape and put it to one side.


Already it's starting to look a bit like a shoulder pad from a Games Workshop character (although at this stage it's more sci-fi Space Marine than fantasy Blood Bowl player) To make 3DS Max treat this as one continuous shape, we once again created a compound shape - only this time selecting unison as the pro-boolean modifier, and selected both pieces.


We're starting to get there - only we've a big solid lump of a shape, rather than a nice, hollow shoulder pad. So after shrinking the new quarter-ball shape (that we set aside earlier) just a smidgen, we placed it slightly offset from the shoulder pad shape:


Another compound shape/pro-boolean substraction, and our shoulder pad is really starting to look like a "proper" 3d model.


All that remained now was to scale the shell to make it slightly less wide (while retaining the height) using the scale cursor selector from the top toolbar....


... and add some cones-for-spikes:


A few extra shapes were thrown down (cylinder slices under the spikes, additional compound shapes on the corners of the shoulder pads) and we're pretty much done!


Skinning - or UV-mapping - 3d models is an art within itself. We managed to create a half-decent layout, ready to create a bitmap to apply to our model. But this is going to need some serious planning to get a half decent result. But so far, we're pretty pleased with making a 3d shape that not only looks ok, but exports as FBX and imports perfectly into the Unity game engine.

Maybe it won't be too long 'til we have a team full of Orcs ready to play Digital Blood Bowl after all.....