HyperText for Unity 4.6

If you’re already working in the open beta of Unity 4.6, you’re hopefully on your way to making a great UI with the new UI system. If you’re looking to get a little bit more out of the UI system though, I’m happy to report I have a new asset store package available today! The package, which I’ve called HyperText, adds some new functionality to the built-in Text component, including the ability to:

  • emit callbacks for different mouseover/touch states
  • create custom styles for links and your own rich text tags
  • easily reuse and manage styles throughout your project
  • display sprites inline with text as quads, and
  • automatically detect and tag keywords

Check out the 1.0 video for more info:

Continue reading HyperText for Unity 4.6

Property Backing Field Drawer

I have some updates for asset store tools that have been delayed a bit, but just put up a new free one that hopefully some of you will find helpful. It’s a custom property drawer that allows you to automagically invoke your properties or Get/Set methods associated with serialized backing fields. If you’re excited, you can go ahead and download it right now! If you have no idea what I’m talking about, then the rest of this post will hopefully make you excited. Continue reading Property Backing Field Drawer

A Better Maya to Unity Workflow

In the past, I’ve implemented tools and fixes to Unity’s import pipeline of native Maya files by manually modifying the FBXMayaExport.mel script. Unfortunately, these types of modifications are difficult to maintain. For one, they need to be redone every time the Unity installation is upgraded. Second, the files are buried in obscure places that require administrative privileges to modify them. It would be ideal if changes could be made in one place, one time, in a way that supported more modular design. So, I finally decided to take the time to sit down and tackle this problem.
Continue reading A Better Maya to Unity Workflow

Help—My Blendshapes Aren’t Working!

Every now and then, I get emails, comments, tweets, or some other communication asking me for help getting blend shapes into Unity with my (now quite old) Maya Extensions package. It’s understandable because the tool I put out was very fragile for a lot of reasons (many my own fault), and I simply haven’t had the resources to finish up and distribute an update. However, because Unity 4.3 now natively supports blend shapes, I have been advising everyone who only needs blend shapes to simply update to 4.3.

Unfortunately, due to errors in Autodesk’s FBX SDK, you can run into a bunch of problems in Unity if you export your models with anything newer than FBX version 2011 (e.g., blend shape data importing incorrectly, animation curves for blend shapes not importing). Although you can of course work around this problem by manually exporting your models as FBX and selecting the appropriate version, many people opting to use native Maya files (.mb or .ma) have instead begrudgingly used older versions of Maya. (While I have no personal experience with it, I’ve been told it’s a similar situation for Max users.)

Fortunately, there’s a fix you can implement to work in your latest version which at least resolves all problems I have encountered. Namely, you can make the following modifications to the FBXMayaExport.mel script in your Unity.

  • Mac: /Applications/Unity/Unity.app/Contents/Tools/FBXMayaExport.mel
  • Windows: C:\Program Files (x86)\Unity\Editor\Data\Tools\FBXMayaExport.mel

First, lines 43-48 read like this:

if (getApplicationVersionAsFloat() >= 2013)
    print "Setting FBX version to FBX201200.\n";
    // Ensure we are using a version of FBX that Unity can currently support
    FBXExportFileVersion FBX201200; 

They should be this:

if (getApplicationVersionAsFloat() >= 2012)
    print "Setting FBX version to FBX201100.\n";
    // Ensure we are using a version of FBX that Unity can currently support
    // and for which blend shape animation curves are not broken
    FBXExportFileVersion -v FBX201100; // NOTE USE OF -v FLAG

Second, line 96 has this command:

FBXExportHardEdges -v $exportNormals;

My understanding is that the only purpose of this command is to force physical separation of vertices with multiple normals for old versions of MotionBuilder that could not support multiple normals for a single vertex (see here and here). As such, I have encountered no adverse effects from changing it to the following:

FBXExportHardEdges -v false;

Hopefully these changes work for you, too! Let me know in the comments if you experience different results.