Maya has a looooot of utility nodes. I still occasionally find new ones that I wish I'd always known about.
Before we look at some of them, I just wanna point out something important: A lot of nodes in Maya when placed in the node editor appear to not have any inputs, or at least not the ones your looking for. A lot of attributes will only become exposed when you right click on the node and pick 'Show All Attributes'. I don't understand why they couldn't map this to the 4 key.
Oh yes. The 1 key hides everything, 2 shows the attributes that have connections, and 3 shows all attributes... except all the ones it doesn't.
Before we look at some of them, I just wanna point out something important: A lot of nodes in Maya when placed in the node editor appear to not have any inputs, or at least not the ones your looking for. A lot of attributes will only become exposed when you right click on the node and pick 'Show All Attributes'. I don't understand why they couldn't map this to the 4 key.
Oh yes. The 1 key hides everything, 2 shows the attributes that have connections, and 3 shows all attributes... except all the ones it doesn't.
Oh. Well can I expose those too?
Sure can!
I assume with the next key in that very clearly and deliberately established sequence?
nnnnnope : )
Sure can!
I assume with the next key in that very clearly and deliberately established sequence?
nnnnnope : )
Things like transform and shape nodes have a crazy number of attributes and most of them are rarely needed by the user, so it makes sense to hide them unless you specifically go looking for them - but many utility nodes don't show you any attributes by default. So clicking Show All Attributes often feels like Maya asking you "Are you sure? Are you sure you want this node to not be literally useless? Are you sure??"
Now then!
What do you do when you need to multiply the output of some attribute?
You might use the trusty multiplyDivide node.Aight. What if you need to add two outputs together?
The plusMinusAverage node? Fine. Okay.
The plusMinusAverage node? Fine. Okay.
These are perfectly good options. They're nodes that are native to Maya, so other people opening your files won't have any issues. But you have more options than you might have realised.
Consider that both the multiplyDivide node and the plusMinusAverage node have three channels. Whatever operation you set them to, they can perform for three separate inputs. Very handy considering those inputs are often in the form of a vector in three dimensional space, such as a translateX, translateY, and translateZ output.
Consider that both the multiplyDivide node and the plusMinusAverage node have three channels. Whatever operation you set them to, they can perform for three separate inputs. Very handy considering those inputs are often in the form of a vector in three dimensional space, such as a translateX, translateY, and translateZ output.
But certainly not always. Sometimes we only need to perform the operation on one value.
I don't know about you, but it irks me to summon a node with space reserved for three different values when I only have the one. It feels like a waste.
I don't know about you, but it irks me to summon a node with space reserved for three different values when I only have the one. It feels like a waste.
I just want a multiply node or an addition node with only one channel
multDoubleLinear -
Overly complicated name perhaps. A simple "multiply" would have done. But whatevs. It is exactly what I just described. It has an input1 attributes and an input2 attribute. Plug a value into input1 and multiply it by a second input going into input2, or just set input2 manually if you're wanting to multiply by a constant.
Simplicity itself.
Simplicity itself.
addDoubleLinear -
Exactly the same as multDoubleLinear but performs an addition instead, adding input1 and input2 together.
That's all very nice. But... addDoubleLinear isn't quite plusMinusAverage with a single channel. I mean, plusMinusAverage is more than just an addition node, it allows you to change the operation from addition to subtraction if you want. Or averaging.
And multiplyDivide is so valuable because it can be switched to division, or exponentiation. Can your fabled multDoubleLinear do that?
And multiplyDivide is so valuable because it can be switched to division, or exponentiation. Can your fabled multDoubleLinear do that?
Well... err. No. No it can't. But you know what can do all of that?
floatMath -
Oh now this one's robust! A simple math node for a single channel with aaaall the functions.
One channel, takes a value into floatA and performs an operation on it using floatB. And that operation can be set to addition, subtraction, multiplication, division, exponentiation, min, and max.
Those last two are limiting functions. They can be used to cap an input, not letting the output be above or bellow floatB's value.
Those last two are limiting functions. They can be used to cap an input, not letting the output be above or bellow floatB's value.
This node is what you might call semi-native to Maya. It's part of a plugin, but it's a plugin that ships with every copy of Maya, so at least in my experience there's no need to be squeamish about introducing it into a pipeline.
The plugin in question is lookdevKit.mll. So if you go to create the floatMath node and it seems not to exist, it's likely because the plugin has unloaded itself. Because I guess that 'Auto Load' option in the Plug-in Manager is taken more as a suggestion than a proper setting.
The plugin in question is lookdevKit.mll. So if you go to create the floatMath node and it seems not to exist, it's likely because the plugin has unloaded itself. Because I guess that 'Auto Load' option in the Plug-in Manager is taken more as a suggestion than a proper setting.
floatConstant -
Another node that comes with the lookdevKit plugin. This one's so handy it's amazing Maya had nothing of the sort until only a few years ago. It has one attribute: float.
What does it do with float? Nothing. Absolutely nothing.
This is just a node that hold onto a constant of your choosing and feeds it to other nodes.
What does it do with float? Nothing. Absolutely nothing.
This is just a node that hold onto a constant of your choosing and feeds it to other nodes.
Traditionally you'd just store constants by manually inputting them into the inputs of other math nodes - and maybe locking it for extra peace of mind.
But often you want to make a big deal of that constant and actually put it somewhere easy to find, in case you ever need to go back and adjust it. And if the constant has a node of its own, you can label that node and make it clear what this constant is meant to represent. As you might expect, often node networks are somewhat front-loaded with floatConstant nodes, since while you can feed the output of another node into the float attribute, I've no idea why you'd ever want to.
Well - I tell a lie - often I find myself doing just that when I want to test if a node network is working as intended but I'm not ready to plug it into my rig and potentially mess things up. So I'll generate a temporary floatConstant node and plug the network's output into it and see what number it shows me.
But often you want to make a big deal of that constant and actually put it somewhere easy to find, in case you ever need to go back and adjust it. And if the constant has a node of its own, you can label that node and make it clear what this constant is meant to represent. As you might expect, often node networks are somewhat front-loaded with floatConstant nodes, since while you can feed the output of another node into the float attribute, I've no idea why you'd ever want to.
Well - I tell a lie - often I find myself doing just that when I want to test if a node network is working as intended but I'm not ready to plug it into my rig and potentially mess things up. So I'll generate a temporary floatConstant node and plug the network's output into it and see what number it shows me.
unitConversion -
Of course you're already acquainted, but consider that the unitConversion node is basically just a multiplication node. When Maya generates one automatically to convert an input of one data type to an output of another, Maya's basically just applying an exchange rate between the different data types and assigning the necessary value to the unitConversion node's conversionFactor input, which is literally just the multiplier.
So if you make your own unitConversion nodes, they can absolutely be used as super light but reliable multiplication nodes.
The only reason you might not want to is for readability concerns. If somebody is looking through your node network trying to discern how it works (or even yourself after walking away for a hot minute) it might pay not to use the node that everyone has trained themselves to ignore since it's usually just doing the kind of data conversion that's very important to a computer program but pointless to us when trying to understand the information flow of a node network.
Often being deliberate is worth doing things only 99% efficiently.
So if you make your own unitConversion nodes, they can absolutely be used as super light but reliable multiplication nodes.
The only reason you might not want to is for readability concerns. If somebody is looking through your node network trying to discern how it works (or even yourself after walking away for a hot minute) it might pay not to use the node that everyone has trained themselves to ignore since it's usually just doing the kind of data conversion that's very important to a computer program but pointless to us when trying to understand the information flow of a node network.
Often being deliberate is worth doing things only 99% efficiently.
clamp -
What's this? A straight forward and successfully descriptive name? Christmas has come early!
The clamp node is a simply limiter on any value.
If you want for example a node's translate Z to drive something, but you don't want that influence to stop at say 60, you can intercept the connection with a clamp node and limit that value to a maximum of 60.
"Can't I just stop the node from being moved more than 60 in the Limit Information section of the attribute editor?"
You can - but suppose that node is driving two different things, one of which you do want to be effected by tz values beyond 60. In that case, you don't want to limit the translation of the driver, you want to limit the information coming out of it, so that limit can be applied to one driven object but not the other. Like so:
The clamp node is a simply limiter on any value.
If you want for example a node's translate Z to drive something, but you don't want that influence to stop at say 60, you can intercept the connection with a clamp node and limit that value to a maximum of 60.
"Can't I just stop the node from being moved more than 60 in the Limit Information section of the attribute editor?"
You can - but suppose that node is driving two different things, one of which you do want to be effected by tz values beyond 60. In that case, you don't want to limit the translation of the driver, you want to limit the information coming out of it, so that limit can be applied to one driven object but not the other. Like so:
reverse -
The reverse node has three channels, and for each of them it takes a value in zero-to-one space and flips it around to one-to-zero space.
What does that mean?
If you've an attribute that goes between zero and one, you plug it into a reverse node and if that attribute is set to one, the reverse node's output will instead be zero. If you set the attribute to zero, the reverse node's output will instead be one. And if you set the attribute to 0.5, the reverse node's output will be 0.5.
0 = 1
0.1 = 0.9
0.2 = 0.8
0.3 = 0.8
0.4 = 0.6
0.5 = 0.5
0.6 = 0.4
0.7 = 0.3
0.8 = 0.2
0.9 = 0.1
1 = 0
You get me?
A common scenario: say you've a custom attribute that goes from 0 to 1, and it's plugged into a constraint that takes two different objects as targets, and you want the custom attribute to control the blend between these two targets. One target is turned all the way up when the attribute is at 1 while the other is turned all the way down. But if you drag that attribute down to zero, you want the targets' weights to flip.
One of those weights is simple, you just plug the custom attribute right in. But how do you get a 0 to 1 value form your attribute to equate to 1 to 0 for the other weight?
Just run it through a reverse node and presto.
What does that mean?
If you've an attribute that goes between zero and one, you plug it into a reverse node and if that attribute is set to one, the reverse node's output will instead be zero. If you set the attribute to zero, the reverse node's output will instead be one. And if you set the attribute to 0.5, the reverse node's output will be 0.5.
0 = 1
0.1 = 0.9
0.2 = 0.8
0.3 = 0.8
0.4 = 0.6
0.5 = 0.5
0.6 = 0.4
0.7 = 0.3
0.8 = 0.2
0.9 = 0.1
1 = 0
You get me?
A common scenario: say you've a custom attribute that goes from 0 to 1, and it's plugged into a constraint that takes two different objects as targets, and you want the custom attribute to control the blend between these two targets. One target is turned all the way up when the attribute is at 1 while the other is turned all the way down. But if you drag that attribute down to zero, you want the targets' weights to flip.
One of those weights is simple, you just plug the custom attribute right in. But how do you get a 0 to 1 value form your attribute to equate to 1 to 0 for the other weight?
Just run it through a reverse node and presto.
remapValue -
This one is supes handy indeed! Suppose you have an attribute that goes from 0 to10. Decimal system FTW, right? But, oh no! You want it to drive an object that you want to move between, say, scale 23.8 and scale -3.9
Well... I guess you could cobble together an equation with some multiply nodes. The attribute output goes from a smaller number to a larger one but the desired corresponding scale values go from a larger number to a smaller number, so... you'll need a reverse node in their somewhere, but reverse nodes only look at numbers in a range of zero to one, so you'll need to divide the output to get it into that range at some point, and...
...Oh hell, let's just use the remapValue node to handle all of that for us, no questions asked!
...Oh hell, let's just use the remapValue node to handle all of that for us, no questions asked!
Don't know what linear interpolation is? I'll explain.
There are five inputs to worry about.
The inputValue, which in this case you'd just plug your driver attribute's output into.
inputMin and inputMax, where you set the range of possible input values you want the node care about.
And outputMin and outputMax, where you set the new range that you want the input to be converted to.
Don't be fooled by the "min" and "max" nature of those last two. outputMin corresponds to inputMin, and outputMax corresponds to inputMax.
In this case, and input of 0 becomes and output of 23.8, and an input of 10 becomes an output of -3.9.
And the half way between 0 and 10, which is 5, becomes half way between 23.8 and -3.9, which is... (one moment...) 9.95.
As you can see, this node's a real life saver given all the painful, manual math we'd have had to do with other nodes.
condition -
The condition node allows you to take an input, and output one of two possible outputs depending on whether or not that input meets a certain condition. Why would we want to do that? We're smart, we can check for ourselves if it meets that condition!
Of course we can, but remember, nodes re-evaluate as soon as the input changes, which means if the input is constantly changing, the condition node can switch back and forward between the two outputs on the fly.
If you're done any scripting or programming, this is the node equivalent of an if/else statement.
Of course we can, but remember, nodes re-evaluate as soon as the input changes, which means if the input is constantly changing, the condition node can switch back and forward between the two outputs on the fly.
If you're done any scripting or programming, this is the node equivalent of an if/else statement.
The condition node might look a little daunting, but that's mainly because it's another node with three channels.
firstTerm: This is where you'll connect your input.
secondTerm: This is where you'll put the value you want to compare your input value to. This'll make more sense when I explain the next input...
operation: This is basically you choosing which question the node is asking about the firstTerm and secondTerm inputs. You're options are equal, not equal, greater than, greater or equal, less than, less or equal.
So if the firstTerm input is 5 and the secondTerm input is 3.1, and the operation is set to greater than, the question the node is asking itself is "Is 5 greater than 3.1?"
firstTerm: This is where you'll connect your input.
secondTerm: This is where you'll put the value you want to compare your input value to. This'll make more sense when I explain the next input...
operation: This is basically you choosing which question the node is asking about the firstTerm and secondTerm inputs. You're options are equal, not equal, greater than, greater or equal, less than, less or equal.
So if the firstTerm input is 5 and the secondTerm input is 3.1, and the operation is set to greater than, the question the node is asking itself is "Is 5 greater than 3.1?"
Now let's look at the remaining inputs
colorIfTrue and colorIfFalse: Both are divided into three channels, labelled R, G, and B. This is another node that gets the names of its attributes from the assumption that this node would be used to manage colour data, but in rigging, we usually use it for spatial data. They'd probably be better off names something like 'outputIfTrue' and 'outputIfFalse'. But oh well.
And finally we have simply...
And finally we have simply...
output: Also split into three channels.
Here's the deal, colorIfTrue is where you put the values that you want the node to output if the answer to its questions is yes.
Here's the deal, colorIfTrue is where you put the values that you want the node to output if the answer to its questions is yes.
colorIfFalse is where you put the values you want the node to output if the answer is no.
So to go back to my previous example, if I put in colorIfTrueR a value of 60, and in colorIfFalseR I put a value of -40, then the node will be asking "Is the input greater than 3.1?"
And if the input is indeed greater than 3.1, then the condition node will output 60. But if the input is not greater than 3.1, the condition node will output -40.
And if the input is indeed greater than 3.1, then the condition node will output 60. But if the input is not greater than 3.1, the condition node will output -40.
And where the condition node becomes especially powerful is when you consider that the colorIfTrue and colourIfFalse attributes don't need to be set as constants but can instead by plugged from other nodes.
In this situation, think of the condition node as acting like gate-keeper in your highway of values and outputs, choosing between two lines of a node network and deciding which output it will let through the next stage, based on whether its condition is being met on any given frame.
In this situation, think of the condition node as acting like gate-keeper in your highway of values and outputs, choosing between two lines of a node network and deciding which output it will let through the next stage, based on whether its condition is being met on any given frame.
animBlendNodeAdditiveDA -
This and the next node I already covered in a different post:
https://rigjuice.blogspot.com/2021/06/understandingdefeating-dreaded.html
https://rigjuice.blogspot.com/2021/06/understandingdefeating-dreaded.html
But basically, it's the same as multDoubleLinear but for rotational data instead. Helpful for avoiding generating too many pesky unitConversion nodes.
animBlendNodeAdditiveRot -
The same as animBlendNodeAdditiveDA, but with three channels instead of one.
And that's all just scratching the surface. There are maaaaany utility nodes that ship with Maya, and so few with good documentation. This will hardly be the last time I vomit new possibilities into your screaming face, but these feel to me like the starter pack for doing math in the node editor
No comments:
Post a Comment