If one is trying to make a unified node by combining multiple nodes into a single group, it is often desirable to treat the group container as the node control source. This is particularly useful if one hopes to ultimately have the groups controls driven by other, different expressions; however, motion blur stops functioning on transformation nodes in groups if those transform controls, like translate and rotate, are linked to the group controls using an expression vs hard linked with an alias. Unfortunately hard links transfer the expressions from the group controls to the nodes inside the group causing expressions to break from scope issues (they can’t see the nodes outside the group) as well as the inability to properly clear expressions off the nodes inside the group without navigating into the group it self. Thus why it is desirable to not use hard links for any group controls where expressions might be used on the group it self; however, as mentioned, this breaks the ability to use motion blur on transformation nodes inside those groups, because the problem comes from the transformations them selves and not the motion blur controls.
Hi Bill,
I couldn’t fully understand your point. Maybe a sample project and/or a video would help?
Fred
Turns out I did a piece of a video on just this.
I know motion blur works with expressions, because if I put frame*30 in the rotation and turn on motion blur it works fine, but if it’s controlled by a group level control for the rotation with thisGroup.Transform1rotate.get() as the expression on the groups Transform1 node’s rotate control it does not work.