Local is a good default as is pose. A menu in options is probably the right move. But can we all agree that constraints by default should be targeting the rig in which they exist? Why i have to fill that out for every constraint is beyond me.
1 Like
This is another example where Local can be confusing :
Bones_Space_rotation.blend (144.4 KB)
Because bones have different roll when you rotate the red bone in local space the constrained goes in the wrong direction.
Interesting point ! I add constraints using the Shift-Ctrl-C shortcut and everything is all setup !
Your point make sense tho !
Am I the only one to read manual ?
https://docs.blender.org/manual/en/latest/animation/constraints/interface/common.html#space-types
Pose Space is like World Space, except that your animation will not be messed up, if you transform Armature Object.
So, if you are in favor of World Space, you should be in favor of Pose Space for Bone Constraints.
Local Space is the opposite choice. Manual is mentioning that was kept for backwards compatibility reasons and could disappear in future.
Local Space (Owner Orientation) would make more sense.
That does not make sense to change a Poll in favor of Pose Space to Local Space.
That are opposite choices.
@sozap comparisons, what you are doing in your blend files are confusing.
There are 2 spaces settings. Target Space and Owner Space.
It is only understandable to compare choice made for Target Space, if Owner Space is the same for all constraints.
If you want a default understandable compared to World default for Objects, you should use Pose Space for both Owner Space and Target Space.
If your most frequent usercases are constraints being the most Local as possible, you should use Local for Owner Space and Local (Owner Space) for Target Space.
I think that default should be Pose when constraint is added from menu in Properties Editor.
But it should be Local when constraint is added from Shift Ctrl C menu.
I think that most recent and less problematic Space Types should be used as default.
They were created to improve simplicity of constraints system.
They should not be kept ignored by users, reproducing outdated methods.
I think that both new spaces should be pushed by developers.
3 Likes
Hahaha good points !
And thanks for clarifying what pose space do !
I’m not sure to get you there, constraints uses both settings, like world space means world for target and owner. Feel free to correct the files if needed, I’ll remove them from my post then !
The goal is to help people experience the behaviour of each ones and pick the good one !
Isn’t that confusing ? I think it would be simpler if everything works the same, but I understand that it can make things go faster.
Thanks for clarifying ! Agreed !
Maybe.
It is probably better to keep everything to Pose Space in UI. And let riggers create their operators to precise Local Space
We have 3 different Local Spaces that will work the same for simple cases of simple constraints and differently for advanced cases.
For instance in your blend file about Copy Locations constraints, if you set all Owner space to same Space Type. Behavior will be the same for all Local Target Spaces with a Pose or World Owner Space.
But it will differ if Owner space is Local.
To be able to see a pertinent difference from Local with Parent and Local (Owner Orientation), you need a hierarchy with transformed parents.
None of local space is probably a good default for all constraints as Target Space, but only some of them.
You will use different Target Space according to constraints that will be different to mimic muscles than constraints used to mimic rail of a machine.
Even for same constraints, targets may be totally different.
For instance, you can use a bone of same armature as a target for a Floor Constraint or a Plane object.
In those cases, you will not have same amount of Target Spaces available although that is the same constraint.
1 Like
Interesting !
Do you have some examples on that ? or a tutorial that explain that a bit better ?
I think I always keep Owner and Target in sync and I never had to mix them, but I understand that these choices are here for a reason.
My memory was not very fresh.
In fact, I was thinking about Maintain Volume and Stretch to Constraint. That have no Target Space or no Space at all.
And about mechanical rails when Local With Parent will make sense as Target Space to take into account rotation of parent but Owner will be Pose Space to only obtain a translation.
To be more generic, Owner Space is in what space you want constrained bone to move.
Target Space is in what space, target should be considered, to trigger, impose constraint.
So, Owner Space is relative to bone owner situation in hierarchy of rig, its amplitude of movement.
Target Space is relative to nature of target, its property that should drive the constraint.
Most of times, we are using same Space Types for them.
Because most of times, we are using a constraint to make them match.
1 Like
Thanks ! That makes sense !
I didn’t look into trains yet but what you suggest looks quite clever indeed !
That sounds like one of those lag issues caused by dependency cycles, no ? I haven’t had one for years, in my experience they were mostly a staple of 2.7x.
What do you mean exactly ?
Honestly that doesn’t strike me as a great thing to say. Here is a possible alternative : “Developers aren’t animators or riggers, so they are going to need our feedback to make parenting work right.” Case in point, they’ve fixed the default parenting behaviour and Joseph is asking for feedback on their behalf.
Here is the result on my main character rig :
bones : 295
constraints : 204
WORLD : 169
LOCAL : 21
POSE : 14
Pretty surprised !
Yes, agree with this. Maya does it, it’s very handy.
3 Likes
In this case, I’m also volunteering to create the patch, which I think is a good example of how Blender development should go. Talking to developers, talking to users, gathering information, then implementing changes. I don’t mean that in a self-aggrandizing way; I mean it as a suggestion of how anyone with problems with Blender can fix them. Jump on a developer’s meeting, start a conversation, get the ball rolling 
2 Likes
Yes, that’s great. Putting that code-fu to good use. Thanks !
@pitibonom I get the frustration : often developers have seemed to wave away the -legitimate- requests of riggers and animators to have a more standard approach to parenting, seemingly because, well, they were a little bit disconnected from the industry and what is considered standard by riggers around the world. The animation revamp effort is proving this wrong, though : it’s a congregation of industry professionals and Blender developers, which is… exactly the right mix. Let’s play ball !
4 Likes
Was the use of World Space intentional for a particular reason to avoid Pose Space ?
Or was it used just because it was the default and satisfying ?
Because unless you transform armature object and/or use another object as target, Pose Space should give same result than World.
Can your 169 World constraints be replaced by 169 Pose constraints ?
Are 14 Pose constraints corresponding to a specific constraint type where it is obvious that World space it not sufficient ?
Because if Pose Space can not be ignored in some common uses and is also working in most current ones, that is a better default than World space.
1 Like
I wouldn’t call myself a pro (but I freelance some stuff when I can) and I’d say that I’m more of a character rigger than a mechanical rigger, but I do both.
There is no established way you’re supposed to rig in Blender. I think for those of us that rig, we tend to prefer using bones, because those allow us to control local spaces in more arbitrary ways, and give us more relationship options. But there’s nothing wrong with objects, and people from non-Blender backgrounds tend to prefer objects/empties. The last job I did, the guy wanted object controls, so I did that.
On this question, I prefer leaving the defaults the way that they are. Here are my reasons:
-
The first constraint I ever add to a character rig is an IK constraint to the calf, for which it doesn’t matter; the second constraint I ever add to a character rig is a copy rotation constraint for the foot, which should be in world->world space. The third constraint I ever add is a damped track for the eyes, but some people prefer track-to for eyes, and track-to should be in world->world space as well. I believe that these are also the most common constraints that beginner riggers will be using, and that existing defaults make it so that there is one less thing they have to understand to get started. Beyond this, I don’t think I have any particular preference for local->local or world->world, I use both; but I do help a lot of people on troubleshooting/how to rig, and I suspect that I tell them to use world->world more often than I do to use local->local. “Copy transforms” is probably the constraint I recommend use of most often, and that should basically almost always be world->world.
-
I think the trend should be toward unifying object constraints and bone constraints, not distinguishing them. The distinction is unnecessary and just means that users have to know a few extra special cases; the very existence of object constraints is a frequent cause of beginner rigging problems, when they show me a file where they happened to put a copy rotation on their armature rather than their foot bone. What is good for an object is good for a bone and vice versa. The main thing that needs to happen for this to work is for Blender to realize that unparented objects have a local space-- it just happens to be the same thing as the world space. There are a few cases, like stretch-to or IK, that need expansion (or limitation) of parameters to work with objects without tails, or without an implicit bias to the Y axis.
-
When there is not clear evidence or consensus to the contrary, our bias should be toward, “Don’t change the interface.” It’s like, don’t change your phone number when you don’t have to: it may not be a big thing to learn a change, but it’s still something you’re learning instead of learning something else. And, maybe more importantly, it invalidates some history of Blender support. If world->world was appropriate for some question, I’d just say, “Leave it on defaults.” After the proposed change, that advice will no longer work. So, you get more beginners with questions like, “I’m following this old tutorial, why doesn’t it work?” It’s not a huge thing, but it’s a reason to prefer keeping it the way it is.
Now, ironically, if this question actually had been about pose space, I’d be inclined to agree that pose space is a better default for bone constraints. But pose space is very similar to world space-- the important difference is that pose space scales with your armature scale, so it tends to be a little better than world space for what people want to do with rigs. However, there are a few situations where Blender doesn’t really handle spaces correctly (distances, lengths, like for limit distance, I don’t think it pays any attention to the scale of the chosen space, it uses world scale) so those are things that would need to be fixed before pose space was really as useful a default as it could be.
Edit: If you wanted Blender to be smart, the predicted space wouldn’t depend on what’s being constrained, but on what the target of that constraint is. I think skilled riggers tend to use hotkeys to designate constraints, so the target is often known at the time of constraint creation. If that target is a bone, pose or local space might be appropriate; if that target is an object, it almost never is. However, I’m not a fan of Blender trying to be smart, because the rigger will always have to be smarter than Blender anyways. There is a mental burden to keeping track of, “What will Blender do this time?” and it’s much preferable to just know whether you need to change the space or not.
4 Likes
I find a edge case where Pose space won’t work :
Because the armature as been translated and scaled the copy location doesn’t work anymore.
To be clear, thanks to you, I’ll probably switch to Pose space now when that makes sense.
But if I’m thinking like a beginner that tries to find their way, the most reliable default seems the best to me.
@bandages ! super interesting answer !
One big downside of rigging with objects is that you loose the ability to have all animation of say a character tied to an action. And therefore transfer or version it from one shot to another.
The last good point in favor of armatures is the ability to reset the pose. But I agree that the end goal of the rig is to facilitate automation, if that goal is achieved by just do parenting and locking axis you’re done !
2 Likes
Yeah, I suppose there are a few reasons to prefer doing things with bone targets, you’re right. But also, I think somebody mentioned this earlier, riggers aren’t the only ones using constraints. A good animator should know how to set up a constraint and bake an action really quick, for just a part of their animation, and they do use empties for this purpose a lot.
1 Like
sozap, I far as I have tried to use the child-of constrain it was never clear to me what are the limitations. In some case it is ok and in some case not. For example if I want to constrain the hand of a character to different parts of its own body. A character could change a hold of their hand on their forehead, hips, knees, chest. At first I was thinking that’s a good case to use child-of constrain. And just shift the influence to different bodyparts. But results have been a disaster. The constrain is clearly not suited for that sort of behavior. I solved the rigging by using the armature constrain and specifying the bones I want the characters hands to follow as they would have been their child.
Not sure how easy it is to understand my example. I could create an example file if there is interest to look into improving/clarifying the child-of constrain.
Below is an example tutorial attempting to clarify how to use the child-of constrain. Important notes from the tutorial:
- If someone in production accidently clicks the “set inverse” button in the constraint then the rig breaks and only a rigger can fix it after that. This is a catastrophe waiting to happen in production scenario.
- Can get really complicated quickly. This is not what an animator would like to hear from a constrain expected to be a simple one.
- At the end of the tutorial it is suggested not to use it production. Instead rig the functionality using other constrains. Like I have personally done. I never ever use child-of constraint.
Child Of Constraint Shot Example | Blender Rigging For Animation
https://youtu.be/jXCq8CncEeA?t=218
2 Likes
You can use it in that way.
Where most people get stuck on a child-of is that they think that it replaces the existing parenting. It does not. So if you have a child of on your hand, and you move your arm, your hand is going to move. This is why it works on IK targets (usually): they are root-level.
If you want to child-of a hand or some other parented bone, you do it in two steps: first, you make an unparented bone or empty with a child-of; second, you give the hand a copy transforms constraint targeting that bone or empty. The copy transforms overrides the parenting whereas the child-of does not.
Well, there is such a thing as undo. But yeah, it’d be kind of nice to lock that. (Although that whole 2-layer abstraction thing works, since you can disable selection on the thing with the actual child-of.)
Most of the time that Blender enables complicated constraint stuff, it’s not a good idea. Child-of is a great example of that. Its whole rotation/scale/location, per-axis controls, all of that is just kind of hacked together and doesn’t really make a lot of sense from a mathematic or artistic perspective. It’s usually wise to just ignore all those options-- after which, child-of is about as simple as it’s possible to get…
1 Like
Hello and thanks for your input on that !
Just to be clear, you’re talking from the point of view of an animator ?
To have some kind of hand locked to the head, torso, hips behavior it’s better to build it differently right in the rig. But it’s indeed limited.
To me child of really needs to be used in the context of an animated shot on top of an existing rig.
But yeah even in an animated shot I can see that example failing quickly since you might create a cyclic dependency.
I’m not sure how animators I worked with would do hands constrained on body parts, probably with a lot of manual animation if they need more than what the rig offers. Or by building their mini rigs with empties and copy transforms.
If it becomes really needed, for an especially challenging shot, probably a TD will help setting up basics constraints for the shot.
Cool ! Yeah this guy know what he’s talking about ! Sure if people have the skills to build something with an empty and copy transform as it’s suggested it’s better especially in complex scenarios.
For a simple shot like in the video, Child of can work great and I never recall an issue like someone ruining the shot with set inverse in years. But I don’t work on giant projects with 200 artists 
So I kind of see and agree to issues you’re pointing out, in the meantime I’m not 100% sure how a better system would work especially internally. I don’t have experience in maya, do you know how things works there ?
Feel free to start a topic on that if you want us to look at examples, or maybe @joseph can split it if it gets in the way of this one !
Assuming the edit, I voted for “Local” space as it’s what I’ve used a lot. But I will admit to not adequately knowing the difference between the options in blender. I’ve observed some effects and gotten what I want out of the constraints, maybe I could ask if my assumptions are correct.
I don’t mean to derail the original post though so feel free to ignore the following questions, just seeing if there’s an opportunity to learn.
Is local space the equivalent of connecting the outgoing and incoming transforms? like translate to translate, rotate to rotate, scale to scale, etc?
Is pose space the same as a world space, isolated to what is in the armature? IE. Would moving the transform of the armature affect the results?
Is there a place where this information is shared, explained or demonstrated? Currently the documentation I find leads me here:
Bone Constraints — Blender Manual
where introduction only has an example of a constraint but not any explanation of what the options mean.
1 Like