I don’t have any experience with expressions and I while rewrite my rigging pipeline (for games) I find myself very tempted to start using them. I’ve started messing around with them and they seem pretty convenient much cleaner than having a mess of shader nodes(which are designed for shaders, not rigs) all over the place. The only reason I’ve avoided them in the past is because I’ve heard people say it’s a bad idea to use them.
Does anyone have some experience they can share with me about why you would want to avoid them? How they break? Pros? Cons? Etc? Or am I just being overly-cautious for nothing?
In my experience with them there are a few things wrong with them. For one, they are absolutely based on naming convention, so if at any point you need to change the name of a node that relies on them, you must go through and change the expressions that effect it as well.
Another downside is that expressions are calculated on a per frame basis, so if you have a heavy rig and a ton of expressions working on it, it can really slow things down. When you use utility nodes to piece it together, the only time they calculate is when they’re requested.
Not a huge amount of downside to just utilizing nodes. easy to script out.
At the same time I know that there are limited utility nodes and so some operations just aren’t available (deriving the square root of a number is an example, easy in expressions, not in nodes)
I’ve not dealt with it much, but do expressions adjust for namespaceing? That might be something else to consider.
I’ve always been under the impression that expressions are horrible performance wise and that nodes are way more native. Pretty sure it was an autodesk rep that told me that but I might just have read it somewhere online. That was a few years ago so I don’t know if they’ve gotten any better, but I try to stay clear and stick to nodes.
Havent had any rig that needs to have the squareroot of a number yet =)
[QUOTE=lkruel;5003]
Havent had any rig that needs to have the squareroot of a number yet =)[/QUOTE]
Yeah, the only time I’ve used it in an expression is when setting up a volume changing system for squash and stretch. From Animator Friendly Rigging. It’s not hard to work around with nodes.
If speed isn’t an issue, there are some nice advantages of using an expression in your rig. They work especially well for facial setups. They are easily tweakable, which is handy for adjusting subtle controls in the face.
An expression is also just a bunch of ascii so it can easily be stored in a separate file. This is handy for building a rig through a script; you can have your script just load up the expression from a text file and plop it right in there.
This concept of rig saved as ascii code is kind of interesting. It only works in this case as a sub-set of your entire rig, but it is kind of cool to have your code abstracted out in this form. This fits nicely into our rig build methodology which separates the rig out into as many different ‘source’ assets as possible, so we can re-build our rig instantly whenever we choose.
To elaborate just a bit. We save our rig out into different source parts:
skeleton
mesh
control handles face expression
skin weight information
Build code
When the build code runs, it takes all those elements, slaps 'em together for a final rig.
To come back to topic, hard-coded names in the expression is quite problematic. Breaks very easily.
Awesome. Right now I’m only using them for a “layout mode” where the user can make changes to the rig and then hit a button to build the controls based on joint positions/axes/etc so it’ll be fine for that, but I’ll stick to utility nodes for the final rig.
I like the power proper expression implementation offers. In XSI expressions are used all over the place and allow for much faster setups as compared to building node networks to do simple things like arithmetic.
But as mentioned in Maya expressions are just poorly done which renders them virtually useless. The alternative is to create a new node type that can take an expression in a syntax you desire or mel/python and interpret it at runtime, allowing you to use the power of connections and etc.
The alternative is to create a new node type that can take an expression in a syntax you desire or mel/python and interpret it at runtime, allowing you to use the power of connections and etc.
Would that actually run faster than maya’s expressions? Or do you just mean it would be more convenient?
It would run faster. Since a node is part of the DG it would calculate the same was as a utility node, only when the value is requested and only if the value is changing. And expression calculates always, whether it’s changed or not. Downside to creating your own node though is that the plugin is required to use the rig. Not really a big downside though.
I find that they really aren’t as slow as everyone says - and the “readability” of expressions is WAY higher than a bunch of nodes wired together. It’s much nicer to open a scene with a few nicely named expression, with comments in it than a jumble of nodes. It’s more like looking at source code, then compiled code
They aren’t as bad at updating as people think either: by default they run once per frame or when an input to them changes. If you switch them to evaluate “on demand” they only run when an input changes.
As a test - create a couple spheres, wire B’s translateX to A’s translateY and have it print out some text. On “always evaluate” - if you drag the sphere around in Y, it will print, same as if you drag the time slider. If you drag it around on the XZ plane, it will NOT update! And then if you change it to on demand, it also won’t evaluate if the time changes, only if the attribute it’s reading changes. Not bad.
I think the stigma exists from when we were all using crappy IRIX boxes or something, now with quad core PCs, the execution time of even complex expressions isn’t very noticeable compared to the savings in workflow.
[QUOTE=Count_Zr0;5008]To come back to topic, hard-coded names in the expression is quite problematic. Breaks very easily.[/QUOTE]
Well, in a way yes, in a way no. If you rename on object referenced in an expression, the expression changes to reflect the new name. But if you are writing a script that creates a hard-coded expression, that will be a problem, But then again, any script with hard coded names is a problem too! So I wouldn’t say that’s a problem of expressions, but of the user I build them the same way that scripts build stuff: create it, capture the name, then reference by name. For an expression, you’re just building a big string, so it will take the variable and pass it in and use the final name in the exp string.
Expressions are quick to write and edit, the trade-off is performance and on a large rig, small individual performance savings can add up to quite a lot. There are also some irritations with expressions if you want them to update in real-time rather than per frame.
For example, for some facial mocap tools we wanted some locators to be essentially constrained to a point on a poly mesh. Now, you can do that pretty easily using expressions but only using commands that require full mel syntax rather than the abbreviated expression syntax. They evaluate fine when playing, but they don’t live update in the scene which was no good for us. Utility nodes was the only way of doing it in the end (using curveOnMesh, and curveInfo nodes).
Also, there a lot of quite well hidden nodes that are extremely powerful and you’ll only become aware of with use, so while expressions might seem easier in the short term you’re in danger of limiting yourself by avoiding them.
I build them the same way that scripts build stuff: create it, capture the name, then reference by name. For an expression, you’re just building a big string, so it will take the variable and pass it in and use the final name in the exp string.