Understanding/Defeating the UnitConversion Node

 We all know this guy, right?

There's no end to the scorn for the unitConversion node in the rigging community. Spawning themselves between your connections, cluttering up your beautiful node network! What gives?!
Well once you understand why they exist, I hope you'll see they're not that big a deal, but even so, there are ways to avoid them depending on your scenario.

Most everything in maya exists in the scene as nodes. Maya's all about nodes. And nodes contain and pass information to eachother via attributes. But that information can exist in a number of different data types.
Data types like Integers (for whole numbers), Floating Points (for numbers with decimal values), Strings (for human-readable words/sentences).
Attributes of two different data types don't play well with eachother. Not without some massaging.
It's kind of like in algebra. 2a and 4b cannot be added together. We don't know how many of b a is, or how many of a b is.
Likewise, if we took the output of a string attribute, whose value is "fish", and tried to plug it into an attribute that is expecting a number value of some kind, Maya would be right throw that string value back in our face and tell us the connection is impossible.

UnitConversion nodes will be automatically generated in a number of situations but I'm going to guess that most of the time for you it's been when you make a connection between a translate and rotate attribute:

Well you see, this is exactly the situation I'm talking about.
In Maya, translate and scale attributes are of the data type 'linear'.
Meanwhile rotate attributes are of data type 'angle'.
That makes sense. When we input 180 into rotate Z, we don't mean 180 units, we mean an angle of 180 degrees. We'd be upset if that wasn't how Maya interpreted our 180 input.
But these differences in data type means that rotate attributes can't talk to translate or scale attributes. Not without an interpreter of sorts.

unitConversion to the rescue.
Maya's unitConversion node exists to reconcile different data types.
If a translate attribute is sending 25 units in data type linear into a rotate attribute that expects an input of data type angle, a unit conversion node will be generated between them whose job is to figure out how many degrees 25 units amounts to, and then output that in the form of an angle value into the rotate attribute.

Unfortunately, that's just the way it must be. If you need a rotate attribute to talk to a scale attribute, or a time attribute to talk to a translate attribute, etc. a unitConversion node will have to be there to allow them to talk to eachother.

Okay. But... what about this also very common scenario?

Two?!
Two unit conversion nodes, just to run a simple multiplication on some rotate information?
And it's not even a case of a rotate attribute trying to talk to another kind of attribute, it's one rotate attribute talking to another. This isn't fair!

What's happening here is that most of the commonly known math nodes native to Maya take and output linear values like from translate or scale attributes. So when you use them on angle values, those values first have to be converted to linear. And if those math nodes are outputting their result to an angle type attribute then the output will need to be converted back to an angle value.
All this because nodes like multiplyDivide, and plusMinusAverage only want to talk to linear values.
But that means two unitConversion nodes! Why can't the math node play nice with angles instead?!

Oh, you mean like... this little devil?

Yes, Maya ships with all kinds of nodes you'd never know existed. The documentation really is... not.
This guy is the 'animBlendNodeAdditiveRotation'.
I know that's a mouthful. As bad as Autodesk are at telling you certain nodes exist, they're even worse at naming them. In the node editor, I just hit tab and type 'tiveRot' and it'll show up in the suggestion dropdown.

The additiveRotation node (which is what I'm going to call it from now on because I'm not from fucking Neptune) is a node that deals in angle values, not linear values. What's more, it's a multiplication node and an addition node all in one.
It has the following inputs: inputA, inputB, weightA, and weightB.
InputA and inputB are themselves compound attributes, each containing an X, a Y, and a Z attribute.

The output is (inputA*weightA)+(inputB*weightB)
So if you want to use it as an add node, two add two angle values together, you'd plug those values into inputA and inputB and leave both weight attributes at 1.
If you wanted to use it as a mult node, and multiply an angle value by some other value or input, you'd plug it into inputA and set weightA to your desired multiple. Or plug something into weightA to drive the multiple. Keep in mind: the two weight attributes are data type linear, so they're easy to talk to from most other nodes and attributes.
And if you wanted to multiply two angle values and then add them together, you can do all that in the one node.

There are actually a whole bunch of these animBlendNodeAdditive nodes under Maya's hood, all functioning much the same way but for different data types (and there are a lot of data types...)
Another that's relevant is 'animBlendNodeAdditiveDA' which does exactly the same thing as additiveRotation but for just one channel instead of three. More efficient if you're only dealing with one rotate attribute rather than all three.
If you're wondering, the 'DA' stands for 'double angle'.
Don't ask. The 'double' thing is about decimal precision and memory reservation. It's... it doesn't matter! That's why it's called that.

Like I said, if you want a connection between attributes of two different types, a unitConversion node is unavoidable. But if you're just trying to do some math on a value and have no need to change its data type in the process - if it's an angle value such as from a rotate attribute then additiveRotation and additiveDA are here for you :  )