Blender and Mixamo

While the future of Mixamo is uncertain, at the time of writing (September 2015), there is a working integration with Blender.

Importing

Assuming you have a rigged, animated character created using Mixamo you export to Blender via FBX.
Upon importing the FBX, you may wish to change the model's scale. Sometimes models appear very small inside blender.

Issues

The main known issue ( At the time of writing! ) is that the model's rest position is not compatible with that used by animations. Pretty broken, eh?
Although it takes a bit of patience, you can pose your model to look like the animated rig's rest position, then apply the armature modifier in Blender. In effect this modifies the geometry of the model to make it compatible with the rig.

Limitations

• Keys at every frame. Take patience to remove unneeded key-frames (may reduce file size). 
• No inverse kinematics. Inverse kinematics can be added to the rig but this will not retroactively apply to imported animations.
• Non standard bone names. This is unpleasant (long prefixes) and will break mirroring schemes. I wrote a small script to fix this.
• Inverted hip bone. The solution to this is to uncheck 'inherit rotation' from the spine bone. Works, but animations created in this way should be kept separate from your Mixamo animations.
• Unexpected rotation of some bones. With leaf bones (e.g. fingers, head) as far as I could judge you can rotate the bone's rest position without breaking existing animations.

Creating new animations

Given the above, you can create new animations based on the Mixamo rig. Depending on how your rig is setup you may need to create these separately from your Mixamo animations.

Remember that Unity doesn't need all animations to be stored in the same file. So creating your own animations separately won't be a problem. If, on the other hand, you don't know how to put several animations in the same file, read here.

Experimenting with friction in Unity

Initial setup

Let's create a plane. Next create a cube and place it right on top. Add a box collider and rigid body to the cube.

Basic friction

Let's create a Push script adding a force to the cube at every fixed update:

GetComponent<Rigidbody>().AddForce(force,ForceMode.Force);

ForceMode.Force indicate a continuous force. The result of applying a horizontal force is interesting: under 10 units (Newtons, I hope) the box doesn't budge. At 10, it doesn't slide, instead, it topples. This strongly suggests that friction is present.

Next we create a so called Physic Material. Default friction value is 0.6 for static and dynamic (see definitions here). At around 0.3 the box is moving, and doesn't topple.

Moving platforms

Turn off the Push script and create a Move script applied to the plane. Since the plane is not a rigid body no point in applying forces. Instead we generate a linear translation inside Update() or FixedUpdate()

transform.position += velocity * Time.deltaTime;

The plane moves, but the box doesn't. So we have friction, but it's a one way affair. Yet the box and plane are still interacting: Once the plane has been removed from under it, the box falls (though, it doesn't topple).

Add a rigid body to the plane and check kinematic. Restart the simulation. Now the plane still slides under the box. Upon reaching the edge, however, the box topples.

Still no friction?

Uncheck kinematic and gravity. This time we get an error: Unity considers that the mesh collider is not convex so it won't allow physics on it. I wouldn't try making the plane convex so I replaced it by a box collider. Without gravity the plane won't fall on its own. However the box is now pushing it downwards. No good.

We don't want this plane to fall so, freeze Y position along with all rotation axis. Now the plane yet again slides under the box, which finally topples.

Still no friction?

Substitute the original Push script to the Move script. Now the plane is dragging the box away (this works with any Force mode).

Finally, re-apply the physic material and lower the friction. Somewhat surprisingly, it now takes significantly low friction values (~0.01) to the box to topple off the plane.

The uncanny experiment

In rigid body settings, freeze the plane's location and rotation (all axis). Run the simulation and observe: the box is moving, then topples off the plane: the plane now behaves like a rolling carpet.

Conclusion

• Friction is a property of colliders, not rigid bodies.
• Friction applies to moving rigid bodies using forces: when moving a solid over static terrain, we needn't add a rigid body to the terrain to simulate friction.
• Friction doesn't apply to kinematic bodies: therefore, to define a moving platform with correct friction:
• Must have a collider
• Must have a rigid body
• Kinematic is unchecked
• Move the platform using forces.
• Take advantage of rigid body constraints.

Did Mixamo solve the animation problem?

At the time of writing, all commercial services at Mixamo are down following their purchase by Adobe. In the meantime, their animation system is in demo mode. And it looks like Blender support improved. Let's have a look.

A first run with Mixamo

(21:40) I exported my model (obj format) from Blender. I decided to only use the .obj since I don't have textures.

(21:52) Auto-rigging config is manual but placing joints only takes a couple of minutes (really). Then according to a caption, it will take about 2 minutes for auto-rig to complete.

(22:04) Chose a few basic animations. Plays nice in preview, now I would like to export them. Go My Assets and select Collada as export format. Oh well. This proved to be somewhat fiddly as I needed to checkout animations. Although their shop is down this is still doable.

(22:12) Let's try to export these animations. Choosing collada, non uniform frame reduction

(22:37) I could get my model and animations back into blender but the export results looked weird.

(22:49) After fiddling for a bit, I somehow established a correct import configuration.

Tips

• Correct DAE export for blender requires exporting with skin and no keyframe compression
• On some animations (typically, walking, running, ...) check 'in place' to prevent the model from moving while animating.

(P)review

Mixamo is a complete animation solution. It seems to work pretty good, especially with humanoid characters.
Auto-rigging isn't a feature that I absolutely need, and I'm not sure how it would fare with complex meshes. Apparently, it works.

Pros:

• Good performance in web client.
• Blender import actually works.
• Free stuff

Cons:

• Their animation collection is big, not huge. Maybe enough to prototype stuff and create a AA game.
• High number of keyframes may be affecting file size.
• In Blender
• Animations need to be imported separately
• Rig and model import with each animation.
• Animations get in with incorrect names.
• Models get in wrongly scaled
• Inept rigs
• One key frame per frame?

Until then...

Adobe purchased Mixamo, pulling the plug on sale services without a go-live date. They also pulled the plug on Mixamo's UAS (Unity Asset Store integration) so it's overall a very bad time to invest time and effort into Mixamo; more so considering that, it's hard to believe that Adobe will encourage improving Blender integration. Casual devs will welcome the fact that some of their tools and services (10 rigs, 20 animations) for free while they transition into the unknown.

About aeronautic coordinates

Often confused with Euler angles, aeronautic coordinates are useful in games (even if you're not writing a flight simulator)

Used in 3D applications, Euler angles 'in general' often become an endless source of surprise, confusion and pain. In contrast, aeronautic coordinates use well defined conventions

Please assume a vehicle's nose (think of a plane) is pointing towards Z positive, and its right wing is lying along the X axis. Many game developers find this orientation intuitive.

Aeronautic coordinates, consist in pitch, yaw and roll, also known as atttidue, heading and bank.
In some litterature you will find the term 'attitude' used to refer aeronautic coordinates altogether.

Unity3D implementation => [source]

Useful definitions.

• Pitch/Attitude - an angle indicating whether a vehicle is flying upwards or downwards. 
• Yaw/Heading - an angle indicating a vehicle's general direction/course. In the real world, cardinal points (north, south, east, west) are often used to refer a vehicle's heading but this is unpractical when dealing with computers.
• Roll/bank - an angle indicating whether a vehicle is tilted or not. For example, a plane is 'tilted' when their wings do not lie in the horizontal plane. 

Calculations

While there are many ways to extract aeronautic coordinates from a transform, and quite possibly several correct ways to do so, I will suggest an approach which I hope you will find safe and intuitive. 

I assume that you have access to the forward, right and up vectors associated with your transform.

Then you can use the following recipes:

Pitch:
   Return -asin( forward.y )

Yaw:
   Let F be the ground projection of the forward vector.
   Let R be the ground  projection of the right vector
   If u is small/degenerate:
      Let α be the angle between R and the right vector (1,0,0)
      Return R.z<0 ? α : -α
   Otherwise... 
      Let α be the angle between u and the forward vector (0,0,1)
      Return F.x>0 ? α :-α

Roll
   Return -asin(right.y)

Important: Your forward, right and up vectors must be normalized.
Occasionally APIs return components (slightly) without the [ -1, 1 ] inclusive range. clamp right.y, forward.y to make sure that this doesn't happen, otherwise asin would return incorrect values.

Additional note

With some implementations, the heading is undefined when a vehicle is pointing straight up. This satisfies the (flawed) intuition that a vehicle pointing upwards isn't going north, east, west or south. It is a flawed intuition because, even when a plane is flying straight up, you can infer its heading from the position of its wings. The suggested recipe and linked implementation leverage this idea to avoid errors.

Smartphones still strong against tablets

Unity Technologies happen to maintain detailed statistics suggesting that smartphone users outdo tablets on their install user base. Here's a summary of the iPhone vs iPad breakdown:

• iPhone: 62%
• iPad: 37%

Bootcamp, a late 2010 Macbook Air, Win 8 Pro, an SD card, and a SL of BS

Bootcamp does not agree to my custom, partitioned drive.
Depending on the target version of windows, running from an SD card may be possible (see Vanderi's blog).

Backing up everything.

Using disk utility, I un-partitionned without re-installing OS-X (Select the HD, go to the 'partition' section then remove all but the boot partition and recover unused space).

Bootcamp is asking for an optical drive. I want to install windows from my SD card. This is only a warning. Ignoring it (for now).

Next it's complaining that I don't have USB drive plugged in. Confusing but, actually, bootcamp is trying to download drivers needed to run windows on my Mac.
Let's get a USB drive.
Needs to be FAT formatted.

Bootcamp tells me that it can download drivers for Windows 7. Pity, because I don't have that, which MS aren't selling anymore. No support, no problem (says Ars Technica)? Apple's compatibility chart insists that I can't.

Success story installing Win7 then upgrading.

Bootcamp is being pissy about my Windows install files sitting inside an SD card. Apple confirm it's not okay.

Maybe I can install windows 8 without Bootcamp. Software 7 blogged about it.

Windows wants NTFS but all we can make is a FAT partition, which is fine.
Back to Disk Utility let's make a FAT partition.
I now have a FAT partition, Wakugumi.

Looks like I might get a chance to install Win 8, if I hold down the option key at restart, and should expect a bumpy ride.

Nice, except it doesn't work. Proposed solution. Oh wait. Look here. And... well. After trying everything else, what worked for me was simply to make some "free space" instead of creating an actual FAT partition with Disk Utilities. Then start installing windows, and create the partition using the provided interface.

Software 7 suggests a patch to improve stability; I didn't wait to verify whether it was stable or not, I applied the patch.

Software 7 signal other issues; to mitigate this I tried running my Bootcamp drivers. The top exe refuses to run outright but I was able to run a batch of semi-randomly selected drivers, which somewhat improved the behaviour of the track-pad. Apparently it used to be possible to download the Win 8.x drivers without fuss (meaning, from Apple), no longer. Got them from a free DL site. Still waiting. Oh wait... can still download them from Apple.

• Track-pad not working. Works better now but still no 2 fingers scroll.
• Can't adjust volume and brightness. Not solved. My display is bright, and there is no sound.

Downloaded 8.1 Bootcamp drivers. Driver won't be fooled, still doesn't run. I can selectively install device drivers.

Upon restarting, Windows indicates that the 'PC' needs repairing, undoes all my changes, reruns minor installation cores.

From there...

• Using BootCamp5.1.5621 as downloaded from Apple
• Installed AppleMultiTouchTrackPadInstaller64 otherwise trackpad is really sluggish. Even after installing this, you still have half of a trackpad running with no scrolling gesture, no right button. Suggestions here.

Searching, I found useful suggestions:

• Bypass bootcamp's compatibility check
• Run bootcamp in Windows 7 compatibility mode
• Run with enough privileges.

Bypassing compatibility checks and running with sufficient privileges is explained here and here's a little more details:

• Don't run via 'Setup'. Instead, run via BootCamp\Drivers\Apple\Bootcamp (depending on your package this may be called BootCamp64 or similar)
• You can disable the compatibility check by running "trouble shoot compatibility" in BootCamp context menu.
• Run the suggested command via cmd.exe.

I tried this with drivers downloaded from apple, and I tried this with the Windows 7 drivers downloaded via bootcamp. A clean re-run appeared to work fine initially. That is, until I accidentally closed the MBA's lid while installing Visual Studio. Following this, the MBA rebooted and Windows went into repair mode.

MultiSub

In July 2014 (one year ago!) I did a little work on a sub multiplexing application. Its purpose is very simple and practical: allow viewers whose native language differs to share subs on a single screen.

Finding Chinese subs

Finding Chinese subtitles has become difficult since shooter.cn went down (but see here). Downloading subs in a foreign language is a roundabout routine anyway.

• Often, I need to find the name of the movie in its original language.
• Go to Wikipedia zh, searching the film's original title. This is to retrieve the Chinese name.
• I use subhd.com to find Chinese subtitles. At the time of writing it looks like subhd.com doesn't support Safari anymore.
• There are a few subtitle formats around. I use Jubler to convert from substation alpha (*.ass, *.ssa) to SubRip (*.srt).
• I often process videos in *.mkv format. One problem with this is that subs are baked into the mkv file. On OS-X I use MKVToolNix via homebrew. Once installed, in terminal (this is a command line tool):
  
  
  mkvinfo FILENAME.mkv
  
  
  => sift through the output to get the subtitle track index and the encoding (often, *.ass or *.srt)
  
  
  mkvextract tracks "FILENAME.mkv" TRACK_INDEX:OUTPUT_FILENAME.xxx
  
  
  => self explanatory?
  
  

Combining subs

Trivially, my utility parses the sub lists, merges, re-indexes. My player (VLC) manages overlaps gracefully. It would be cleaner to do this while merging the subs, but it's a lot more work.

A user interface

Today I built a trivial user interface for multiuser. Took 2 or 3 hours I guess; it is very, very simple.

Plans

I guess I'll try to submit MultiSub to the mac app store. Since I'm not planning on selling it, I could also make it available on free download sites.