Null Components and You

Do you use the null coalescing operator?? If so, be careful about using it with properties of MonoBehaviour that return a component. For example, if you have an object with no rigidbody attached, the following example will not in fact add a rigidbody:

Rigidbody rb = rigidbody ?? gameObject.AddComponent<Rigidbody>();

Why? For some reason, these built-in properties (such as rigidbody, collider, and so on), actual return an object of the appropriate type that evaluates to null, rather than an actual null reference, even when the component does not exist. For example, on an object with no rigidbody, this line will log true:

Debug.Log(rigidbody.Equals(null));

On the other hand, this example will throw a NullReferenceException, as expected:

Rigidbody rb = GetComponent<Rigidbody>();
Debug.Log(rb.Equals(null));

As such, you can rewrite the first example in the following way and it should work:

Rigidbody rb = GetComponent<Rigidbody>() ?? gameObject.AddComponent<Rigidbody>();

Unity Biped 2.0

I finally emerge from my work cave today with an update to my Unity Biped tool, now compatible with Unity’s Mecanim animation system! Take a look at the 2.0 feature video below to get an idea of all of the new stuff. I just submitted it to the asset store this morning, so keep your eyes peeled, and please let me know about your experiences using it.

Any Biped Editor Users Out There?

Unfortunately, as a content developer for the Unity Asset Store, I have no real means of contacting customers directly, so I’m hoping there are some of you out there who might get in touch with me.

I’m working on some revisions to the Biped Editor, and am seriously considering committing some cardinal sins in the interest of making the code much easier for me to maintain and extend for future use. I’m looking at some technical changes that wouldn’t necessitate your updating in the middle of a project in production, but I wouldn’t want to prevent you from doing so if you wanted to take advantage of some new features. The main things I need to know right now are:

  • Are there any public APIs on which your pipeline currently relies, apart from the automated setup and GetUp() methods? Considering how much coupling was in place already, I sincerely doubt it, but I also don’t want to push the big red button with little more than an assumption behind it.
  • How seriously would it inconvenience you to have to fix a couple of compiler errors if you got a new update? (e.g., de-nested nested classes, changing method signatures that use bools to use enums, etc.)
  • How seriously would it inconvenience you to have to redo automated setup?
  • How seriously would it inconvenience you to have to re-link your get up animations?

Please feel free to contact me directly or to post here. Thanks!

On Accessibility

Up to this point, I’ve always done motion retargetting in MotionBuilder. Just this week, I finally tried out Maya’s HumanIK tools. I really like a lot of the design work that has gone into them! Setting up a character and getting up and running was a snap. Graphical views, as well as type-in fields with autocompletion really made everything a pleasant experience. If you haven’t looked at Maya’s HumanIK tools before, it’s worth checking out two different views of the character definition controls:

Human IK GUIs in Autodesk Maya

Unfortunately, for a not insignificant portion of the population, the same GUI looks like this:

Human IK GUIs in Autodesk Maya

While much about this GUI looks really nice and is laid out well, those of you out there with colorblindness are seeing the same image twice, and are unfortunately missing some of the most important information these GUIs convey about the state of the character definition at a glance. It’s nice to have the detail text in the corner, but not really ideal.

It’s easy for us to get wrapped up in technical/architectural pedantry or in details of layout and workflow, so it’s important to also keep accessibility in mind when we design tools for others to use.