Using Constraints Vs. Connections With A "blendweighted" Node

[wazawaza]

Hi All,

Sorry if this has been asked before, but i wasn't able to find an answer.

What i'm wondering is what the advantages/disadvantages of using constraints (point, orient, etc) vs connecting attributes that pass through a blendweighted node?

for example, i could pointConstrain an object to two or more other objects, and animate the constraint weights on the constraint node to switch between the controlling objects.

OR

i could connect the controlling objects transform values to the .input array of a "blendWeighted" node, and then connect something else (like a custom attribute) to control the .weight attribute on that blendWeighted node, and have the same result.

I realize that I would have to have a blendWeighted node for each attribute to be controlled, resulting in more nodes than a single constraint node for all the rotations or translations, respectively.

I'm just curious if anyone on here sees advantages/disadvantages to either solution. Performance differences, maybe?

thanks in advance for any thoughts and responses.

[maulik13]

I cant tell much about the difference in performance however they both have very distinct uses.

Constraint strictly follows the transformation from parent. So if the parent object is transformed through another parent the constrained object will still move (because it uses the local transform values). But if that object is connected directly to the parent object using connections in the earlier scenario connected object would not move. Because it only looks for changes in values of global transform node or the values you see in the attribute editor. While being transformed from parent child transform node's values dont change in the attribute editor.

I hope I made some sense to you. It's difficult to explain for me. But you can do this simple example. Take 3 objects.

obj1 constrained to obj2
obj2 parented to obj3
Now move obj3 and it will also affect obj1

obj1 connected to obj2 (just the direct transform attribute connections)
obj2 parented to obj3
Moving obj3 wont affect obj1 in this case.

[wazawaza]

maulik13, thanks so much for your response. That all makes perfect sense, actually. I'm kind of cursing myself for not realizing the global vs local transform values before!

This is good information to consider in making my choice.

I'm still open to any other ideas or comments from others, so if there are any, i would gladly welcome them

thanks!

[joojaa]

PS: You dont actually need to make a blend weighted node, it gets created whenever you key a constraint or connection fi given tyope for that mater.

[maulik13]

no problem wazawaza. This is very useful stuff however I find it's still not good enough because in a scenario where you have more than three objects in a hierarchy, it becomes difficult to have more control. Consider this:

I have joints being driven by child controls and child control is controlled by parent control. (child parent setup so that I assign group movements to parent and individual tweaking using child control)

Now this setup is on a separate rig, and if you want to create similar controls (parent-child) separately on main face and drive those using the earlier controls it becomes very complicated to handle. So far I havent found any decent solution.

[joojaa]

Hmm have you considered moving all the geometries under one transform? This is way underused feature, most rigs you ever dowload have some significant issues on this. Making things unnecessarily complicated for the user.

If you take the tiny rig as a example theres actually no need for most of the constraints in the main rig. The same thing could have been accomplished better and with more verastility by grouping the control shapes under the smae trasform as the lowres proxy as a minimum.

So that would defninitely cut one layer of your rig in wich case youd still not have 3 tiers of control.

[maulik13]

Yes I agree. Unnecessary constraints are not good. I remember thinking on the same line as you have suggested Joojaa. However I had some issues in using the transform of the local rig and move it along with the main rig to keep things together.

Let's imagine a setup where I have a local face rig with joints on the facial muscles. And I drive these joints using the face controllers (they could be either constrained or connected directly with the transform values). So now I have two rigs, one main rig that is a face part of body and one local rig which is just the head with facial muscle joints and controllers on it. How would you make follow the local facial muscle rig with the main face on the body? (the main face on the body may have just one skull joint)

Thanks.

[joojaa]

Well you have very classic thinking here. You should think your way up once when you have it there then unthink your way back.

Quite often you will notice you don't need the constraint, many time ive seen that people use constraint for the sole purpose of switching visibility of parts off, and thats their only need. This is easily handled in other ways.

QUOTE
However I had some issues in using the transform of the local rig and move it along with the main rig to keep things together.

Your not applying attention to what you do, dont double transform things. Nothing constraining solves per see. But actually constraints can make things worse. Its just the only tool you know dissect the rig afetr you've made it.

QUOTE
how would you make follow the local facial muscle rig with the main face on the body? (the main face on the body may have just one skull joint)

Thats a broad question, for starters i don't do osipa style controllers the way osipa does them. Because i dont need to i can eliminate many of the things in the rigging process.

Anyway the real question is why do you need to have the rigs separated form the main rig? One typical insane situation arises when people use blend shapes (the question is the same just one step further) and then they amke a separate head that the wrap up to the full body. Why? You could as easily just transport the blend shapes to the main body and read the data form same source. This way you could still do a all the same things but without the wrap wich si by far one of the msot costly nodes around.

So what you can have is 2 rigs taht are in all other repects identical and shared instead.

QUOTE
Yes I agree. Unnecessary constraints are not good

But most disturbingly people dont KNOW other methods than constraining, so they just containers unnecessarily even when they dont need to i mean tiny has atleast 3 layers it definitively does not need for anything.

As i said most people are NOT aware that what they consider as objects are not just one node, so whle they normally do this:

CODE
object
  +----object
     +----object

is actually:
CODE
transform
  +----shape
  +----transform
     +----shape
     +----tarsnform
         +----shape

from this follows inability to see that transforms are interchangeable wich means many times a simple constraint can be done like this:

CODE
transform
  +----shape
  +----controlRigShape
  +----transform
     +----shape
     +----controlRigShape
     +----trensform
         +----shape
         +----controlRigShape

Now since the contol rig is usually lighter you can easily be transformed to something totally else even tough its transform appears to be elsewhere because it counter trasforms, making it easy to make selection interdictions taht dont break.

A second tings people never seem to do is set default manipulators to their transforms, this allows you to make rigs that magically appear on context, since the default transform van be directed to ANY context so you could have traslate rotate for object but as well you could have a point on curve manipulator.

Most users are not even aware of this feature.

This also eliminates need for many gimics people use because the controll does not drive itself.

[maulik13]

As always, thanks for your detailed explanation. It has brought more thinking to me in how we can bring things together with simple methods. Especially transform hierarchy.

In answer to your question , why I need a separate rig:

I have a jaw open, eyelid joints on one rig. Now if I put the muscle joints on the same rig it's a very complicated skin weighting, since a single vertex might be driven by more than 5 joints easily. And normalization will definitely drive me crazy there. Maya is not at all good in mirroring weights with a dense mesh. So it will be really tough (or impossible in some cases) to paint weights precisely. that's why I separated things into two rigs and it was quite manageable and easier to paint skin weight.

In the last code, you basically made the two shapes driven by a common transform node right?