has been shut down on the 6th of March 2021. You can read a bit more about it here.

You are currently reading an archived copy of the latest content, with all the usernames deleted.

Node for blending multiple spaces (much like a switch statement)

by user21 posted 15-12-2017 | 13 comments

Hi all,

maybe I'm just missin somethin ... but I am looking for a node that works like the condition node, just with more than one condition (basically a switch statement). Wanting to setup multiple parent spaces for my rig I don't want to create a stacked blend setup - would much prefer one single node! - don't need the blending part, just the switch. I'm probably going to write a tool for it buit if there is a node, I'll take it! For now I am using Set Driven Keys instead to do the switch :/


by user113 posted 03-01-2018

Would love to build a new node type for this i.e. a ooo (offset, orbit and orient or a origin-offset) constraint giving you control over positional offset and orientation about it. Maya's constraints either a) store a local offset to the entire transform space in the case of a orientConstraint. Or store localized offsets for each target in the case of a parentConstraint. The problem is the order of operation which i suspect is a s * t * r or t * r * s which can cause issues with multiple parent constraints with different skip options.

Really you want to control two things - a) the orbit of a position around a target and rotation around that position. Lower levels of control i.e. the orbit rotation controlled by another target is a cool feature but the minutiae of it gets unwieldy to work out for an animator.

It would be far cheaper to build a node for this than to handle all the connections involved.


by user36 posted 17-12-2017

You could try using a 'choice' node. Attach the world matrix attribute of two transforms into the choice inputs and run the output through a decompose matrix, then into the resulting transform. So, two nodes. I don't really do this in my own workflow, so there might be issues, but I just tested it and it seems to work.


by user3 posted 18-12-2017

I did give that a go at one point, but as far as I remember (it's been a while now), I was having issues with parallel not evaluating it properly, meaning that if you have keys on the choice node and switch the matrices during playback the state of parallel says "Rebuild Required" and it slows down quite a bit.

I might have done something wrong of course, or it might have been a bug, so definitely give it a go if you find it interesting.


by user21 posted 18-12-2017

Thanks! I might try it later! For now I wrote a nice swtiching tool that handles aligning the controls so there is no pop when switching. Still need to write the UI though! ;)


by user3 posted 15-12-2017

Yeah, would have been great to have something like that by default in maya, but if there is I haven't found it. That being said, writing a custom node to do it is fairly simple.

Alternatively, if you are not one of those people who avoid expressions at all costs, they might be a good option.


by user21 posted 15-12-2017

Thanks! And you're right, of course! Expressions can do it of course. I do always try to avoid them as I always had the impression they slow the rig down.. But I might be wrong. I have used them a lot in the past!

But I guess I could just do it with a script that would also handlie keeping the limbs in position when switchen spaces. I could maybe even put it on a marking menu ... Just have to find a way to "attach" the Menu the the control... well one thing at a time ;)


by user3 posted 18-12-2017

Oh yeah, you can definitely do that! I did get the impression that you were looking for a node to handle just switching the indices of the space attribute, but in any case, a full space switch tool is always handy.

I remember seeing this once recently and maybe you could find some benefit of looking through it as depending on the way you set up your space switches it might or might not be helpful.


by user113 posted 03-01-2018

Don't use expressions in production rigs - only for prototyping and then convert them to a plugin node. They are considered "unsafe" in the evaluation graph and will block everything else until they've evaluated.


by user3 posted 05-01-2018

Interesting, I've known that to be the case for ages, but about an year ago I started actually testing whether there's any truth to the myth and it seemed to me that using them in a reasonable way always works fine with very similar performance to node networks (the differences were negligible).

When I say in a reasonable way, I mean avoid storing/using variables as that tends to slow things down a bit and also make sure the expressions don't depend on each other as that would result in waiting around.

Another issue I had was when setting them to evaluate on demand only sometimes they would just stop evaluating after a few keyframes were created. I am not sure what is causing it and have not investigated it, but using them in always evaluate has been working, without hindering performance (in those specific cases, I was comparing them to node networks that do the exact same thing).

That being said, I use them only when I need some trig functions at home, as I avoid writing plugins for my own rigs, just so they are more easily distributable.

With all that said, can you share some insight or resources about how they could block evaluation or anything else to watch out for when working with them? I am keen to learn more about working with them.


by user113 posted 06-01-2018

Sure, I did a class on it a month or so back directly about the evaluation graph, the dg and dag, how when parallel evaluation is on it will build is own internal graph of how to best divvy up the dg for optimal evaluations. I’ll try to remember the general gist of it.

So different node types run in different model you have global, global serial and serial. Also you have clusters - these are groups of nodes who’s connection eventual get back to them non directly ie cycles (which are fine in the graph but get their own block in the evaluation graph). Direct attribute connection cycles though are big no no.

So most nodes will run global, constraints are put into a clusters as they have feedback loops.

Python nodes are considered global serial as they use the GIl (global interpreter lock) and the node will be handled on a single thread. So not as fast but the rule here is to make simple nodes with python and write bigger nodes with c++.

Expression are considered unsafe by default mainly because Maya does not know in thread terms what it’s evaluating and so could be dangerous - they get relegated to being serial ie must be completely evaluated before others.

This can be a major slow down as you could have a graph with lots of connections going to single expression node and the entire connections to it will get considered unsafe! And will not get spread across the threads and must get evaluated in its entirety before moving ahead.

Now there is LOTS of minutia to this, as some thing will run faster in dg and not parallel just because the way they are constructed.

The take away was that you MUST always profile your work with a biggish cache ~200mb/~50 frames and really look at what nodes/connections are causing slow downs.

Take-always: Python nodes run in global serial expressions are considered unsafe and relegated to serial. Node construction plays a high role in how it parallizes. Profile, profile, profile!


by user3 posted 02-02-2018

This is really helpful! Thanks a lot!

I really need to add some kind of notification system, so I don't miss valuable comments like this one.


by user9 posted 05-01-2018

it's tempting to write a node that cover the calculations of a body part.

Is that better than creating a spaghetti connection?


by user9 posted 29-12-2017

What does that plugin do? Does it counter animate the control curve whenever we switch the space? :D