Make unit conversion node optional and off by default for 'Multiply Divide' node

[johnkeates2865]

I would love to disable Mayas insistance that 'unit conversion' nodes should be inserted everywhere. I often use 'Multiply Divide' nodes between two connections of a similar type and I end up with two unit conversion nodes per axis, which are just converting one way then converting back again pointlessly (and using resources presumably). I can set them all to '1' in which case they do nothing and the behavior is the same. They also aggravate node editor issues of muddled appearance and general annoying behavior.

I would suggest that unit conversion nodes aren't applicable to 'multiply divide' nodes, or most other nodes for that matter.

[zewt]

The problem is that turning it off for multiplyDivide would cause problems when connecting non-angular attributes.  For example, create a floating-point (non-angular) attribute, and connect it -> multiplyDivide -> transform.rotate.  The attribute is typically in degrees, and multiplyDivide sees it in degrees, and it needs to be converted to radians for the angle attribute.  Without the multiplyDivide, the rotate would get the wrong value.  The conversions make it so all angular attributes are in radians and all non-angular attributes are in degrees (actually the angular working units setting), so they always round-trip to the right units.

This isn't a problem if user attributes are created as angle attributes instead of floats, and then the conversions really are redundant.  But, the add attribute UI doesn't expose this and most people probably don't know anything about angular attributes, so it would probably cause a lot of confusion.

Having an option to not create these could be useful for people who really know what they're doing.  (I don't think I'd use that myself, though, since it would cause intermediate angle attributes to be displayed in radians, which is a lot harder to read.)  I'm surprised there isn't at least a connectAttr flag to tell it not to create conversions.  It seems like the only place they give any control over this is with expressions...

Personally, I'd be happy if the node editor could just make unit conversions completely transparent.  If it detected a "standard angle conversion" unitConversion node (one with exactly one input and one output connection, and a correct conversion factor for the attribute types), just graph through it as if it's not there.  Just show a fake graph connection between the real attributes (as if they're directly connected), with a symbol on the connection line to indicate the hidden conversion and allow clicking it to display it.  It's been a while since we've seen any updates to the node editor, though.  Hope it gets a turn soon.

[johnkeates2865]

I hear what you are saying but I really won't get confused if I deliberately negate the creation of conversion nodes in a lot of cases (like going to a multiply divide node and back where the actual number is of no concern, just the multiplier).

I agree that a tag when scripting connections would help a lot.

[jwlove]

As zewt mentioned, the unit conversion nodes are kind of required to ensure the math is correct...  This is due to attribute types (such as doubleLinear, doubleAngle, float, etc).  It's not really that the visible number is getting changed, it's the actual underlying data type in memory.

There's another idea here for creating a better suite of math nodes and part of the discussion involves making unique math nodes for the different attr types (like a multiplyDivide node with doubleAngle input/output attrs instead of floats so you can directly connect in and out to rotates).

Personally, I prefer knowing about and seeing any unit conversion nodes just to ensure I know exactly how the data is flowing through the node graph even though I hate them...  I think more specialized math nodes will lead to a cleaner, more understandable node graph... which I think is the crux of your request.

Sure, the highly specialized and granulated math nodes will be daunting to new users, but they can start with the original nodes, and then replace them with the 'better' ones in their files as they learn more and get to the point where unitConversion nodes actually annoy them as much as they do you and me.

[johnkeates2865]

I understand what the unit conversion nodes are for but it makes no sense to have one going into a multiply divide node, then another coming out of it which does the opposite job. If the multiply divide is multiplying by .5 then that halves whatever the value is it is of zero interest what type that data represents. I often make unit conversion nodes myself to stop the node editor shuffling my nodes about when it makes them and I set them to 1 (effectively switched off) and everything works fine.

[jwlove]

hmm... interesting point - I see what you're saying now.... but I think that if you've set the conversion factors to 1 and they still work you've been lucky - maybe it only works that way in certain situations.

I did a test where I created 3 locators.  I connected the rx of the first two into input1X and input2X of a multiply divide node then spit the outputX into the third locator.  I rotated each of the first two by 5, making the third's rotation be 25.

Then, I set the conversion factor of the first two unitConversion nodes to 1 so the actual radian value goes into the multiplyDivide.  The third locator's value is not 25 whether I set its conversion factor to 1 or not (it's actually ~0.008 with the conversion factor left alone and ~0.436 with the conversion factor set to 1).

maybe I'm doing something wrong?

[johnkeates2865]

I just did this:

Make two cubes, then connect the rotation x of one cube to a unit conversion node set to 1, which goes into a multiply divide node, then to another unit conversion set to 1, then to the second cubes x rotation.

Now you can use the multiply divide node to scale the influence of the first cube on the second.

If you want to do that with all three axes, then that is 6 unit conversion nodes, all doing nothing.

Maybe it isn't right to have unit conversion nodes off by default for multiply divide nodes, but at least can it be an option?

[jwlove]

right, I understand that particular setup you're doing in that cube test... but if you plug rotations from something else into the input2, and set the conversion factor to 1, it doesn't multiply the way you expect.  The only way to ensure it works in all situations is to actually convert the input data in all situations where the data types are mismatched.  If someone doesn't know what they're doing, they can royally hose themselves by turning off unitConversion node creation, and then blame Maya for their own misunderstanding of how Maya actually works (not saying you would... but it would be extremely easy for less technically minded people to do).

That's why I think it would be better to implement new specialized math nodes that can internally handle those conversions....  If the nodes aren't granulated out by attr type, then perhaps there's a quick way to have a single node accept either doubleLinear or doubleAngle compatible connections and then convert the data internally as needed... The only thing I don't know about that is if it would impact the node's speed too much to have to check for and then do that conversion if needed...  Maybe the node could be given an input doubleLinear plug and an input doubleAngle plug that the user chooses which to use, and it will only evaluate the one plugged in (causing an error if both are used?).

[johnkeates2865]

What you are saying makes a lot of sense. I started thinking down that road myself.

Another aspect to it is that sometimes I want to output from one attribute to a bunch of other nodes. If it were up to Maya, you would end up with a unit conversion per connection, so I tend to use the unit conversion node that was created and connect from there to the multiple other nodes.

Also, I often connect from a user-attribute and maya will make a unit conversion node - which makes no sense as how does it know what the user attribute represents or how I want its effect to be scaled? I would prefer to do my scaling with a multiply divide node as they are easier to deal with generally and I can plug something into the input2 to control the multiplier in the rig - but I still need the unit conversion there (probably set to 1).

[Anonymous]

I switch angular to radians in preferences->settings I make connections between nodes than I switch back angular to degrees