Node for blending multiple spaces (much like a switch statement)
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 :/
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.
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.
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.
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! ;)
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.
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 ;)
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.
http://www.rihamtoulan.com/space-switch-setup-tool/
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.
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.
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!
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.
it's tempting to write a node that cover the calculations of a body part.
Is that better than creating a spaghetti connection?
What does that plugin do? Does it counter animate the control curve whenever we switch the space? :D