Please pardon detailed / geeky / noob question about _mechanical_ rigging. I just finished some rigging training and now I seem to always want an armature ;) .
Trivial example. Say I want to animate (L/R/S) a detached mesh (say Cube) using an armature bone. There seem to be at least 3 methods to get the same look:
I'm guessing that there is a difference in processing "cost", maybe #1 < #2 < #3 (based on how much control you have) ? #1 looks desirable from simplicity standpoint.
Any other non-obvious gotchas? More complicated scenarios would probably affect the answer.
Thanks in advance.
Hey techworker1 ,
I'm no rigger,
I can't imagine how these people do it, always covered in oil.
Oh now I get it, animation rigging.
Yeah, don't know much about that either.
I would suggest your on the right track,
with your simple cube example, the simple option (#1), would suffice.
Different scenarios would call for a different solution
I will tag @waylow because, well who better.
Over to you Wayne!
Thanks @adrian2301 .
There seems to be one general advantage to constraints which I neglected to mention.
I guess I am a compulsive organizer, using hierarchies - always have an Outliner on every screen. (Way back before Collections, I often used Empties for organization.) The inconvenience is that the desired Container hierarchy isn't always identical to the parenting one. It's easy to end up with a lot of object links in containers, which are messy. With minimal parenting and constraints, you can put objects into any collection with less noise. Maybe my odd way of looking at things... It might actually be important if you are also doing fancy things with layers and compositing.
I can't wait to see what @waylow has to say (his training has made me an Armature addict ;) ).
For questions like this, context is everything. What is it you need the rig to do is the important question. That being said, in your particular scenario, none of the above would be necessary as you could animate a standalone cube directly. The beauty of an armature is being able to animate lots of things while having all your controls and keyframes in one place. In this case option 1 & 2 are functionally the same (assuming weights of 100%). I can’t think of any situation in which 3 would be desirable, but that doesn’t mean there isn’t one.
Aside from the tutorials here, there are some pretty good mechanical rigging tutorials on the Level Pixel Level youtube channel.
Hi Techie.
I think you are almost spot on the money with your assumptions there.
It 'costs' more to use modifiers, weighting and constraints. Parenting is cheaper, however, if you need to bend/twist or whatever, you can't do that with parenting.
How much more does it 'cost'. I don't know to tell you the truth. But in your cube example of 8 verts, it would cost difference is about 0.
If the computer has to do a bunch of calculations on 1 million verts, then it would have a much bigger difference.
Of the examples above, I think the most costly is the armature modifier with weighting. That is because it has to do calculations on each vert in the object (even if it's not 'deforming' and just essentially being parented along for the ride). Again, less verts means less cost.
How do you decide which way to go?
I try to choose simplicity first. Sometimes that means consistency. If all the parts use the armature modifier, except for one. That might drive me nuts haha. So I would probably make them ALL use the armature mod.
But if that has a noticeable effect on the performance, then straight parenting (bone) for any part that doesn't need to bend is the way to go.
Here's another thought about this topic that I'll just pop here (which I would need to look into to know the answer).
What's the difference with parenting with the Copy Transforms (or any other constraint like Child-of) and straight parenting?
I think the difference would be when the calculations take place. Parenting happens first then Drivers and Constraints (don't know the exact order).
Essentially the outcome would be the same (final matrix), but the calculations along the way would be different.
(for example - local_space matrix and local_space_with_parent matrix would probably be the same whereas with the armature modifier and object parent, these would be different)
I hope that kind of makes sense - I'm just thinking through this stuff out loud though, so it might not be accurate.
Perfect sense. Calculation order is sometimes important, but not obvious, as when you described the "override transform" on a custom control bone.