Community input needed: should bone constraints default to Local Space?

I think it would be great to have the ability to set defaults for all constraints and modifiers.

2 Likes

Lol ! in some ways I feel less ashamed of never using them, is it what we call an emotional transfer ? :smiley:

Rigify standard :

bones : 918 ; constraints : 1271
WORLD : 962
LOCAL : 283
CUSTOM : 24
POSE : 2

Rigify Basic :

bones : 222 ; constraints : 209
WORLD : 186
LOCAL : 17
CUSTOM : 4
POSE : 2

Having the possibility to set a default could be really great !
I think @Ascalon summed up really well how I feel about it, world isn’t the best choice but it’s the most predictable, and as default it makes sense !

And I realized that it’s used more than I expected, so I think I’d choose to keep things as they are, but I’ll wait since I’m curious about hearing other opinions and sleep on the idea for a while !

3 Likes

After doing a lot of rigging for different projects I ended up building my own auto-rig system.
Which is quite similar to rigify : it’s based on small building blocks ( arm, eye, finger) that are assembled. So rigging a character, a vehicle or a props can be done with the same system.

Most of the time I focus on feature really specific and I don’t have a lot of repetitive tasks. Most of the work is in fact more about special cases, weight paint, deformations and shape keys.

I think it’s the natural process of a rigger, the more they progress the more they want to automate, especially since building a whole character with production feature is a lot of work, and when you have like 10 of them for a particular project …

Anyway, when rigging you have to do a bunch of many repetitive tasks :
naming, setting deform / non-deform, locking axes, changing Quaternion to XYZ Euler ( That default can be changed I think)
Sometime I even name constraints, so yeah there is a lot of “administrative/paper work” anyway.

If that’s not too complicated I think it’s the best ! It would be great to test working with local for a bunch of time to see how that feels !

2 Likes

Many food points voiced here. Sounds like keeping Global and adding a setting to choose a Local as default, or any other option, would be great.

2 Likes

The vast majority of cases World Space is the go to method for making sure things are working as they should. As someone who quite recently got into rigging in Blender for some portfolio projects, Local Space is needed for things like IK/FK switches with Limit modifier constraints, but for things like copying transform values from your control rig to your skeleton rig I use World Space.

I have yet to experiment with all of them to know all the edge cases, but personally I would like to see the option for modifiers to remember previous settings while working with them. This is not for just bone constraint modifiers, but for all modifier types. No setting will ever be perfect in every scenario, but if you have already used a setting it then becomes more likely that you’ll need it again. Adjusting the base values and making Blender remember them would be the most ideal solution.

4 Likes

This is an interesting perspective; you’re definitely a minority here, but an important one :grin: feel free to vote “no”, that poll will be helpful for getting a quick vibe

2 Likes

Many users seem to be really frustrated with the child-of constrain. I personally have given up on it. Perhaps the name is misleading. Perhaps documentation is not clear. Or something else not optimal. Hope see a similar thread about this one.

2 Likes

Accidentally voted yes already. Oops. :partying_face:

Anyway, here’s a typical example of where I used World Space for Copy Transforms to transfer over my transform data to the skeleton. It is a separate armature object because it is generally a bad idea to mix your controls with your skeleton if you wish to create more advanced controls down the line like IK/FK switches. As long as the control bones match the skeleton bones, World Space will just transfer over everything with no issue.

2 Likes

I’m not sure what you’re referring to, but by design that constraint is used when animating, like if the character grab an object on the table, you want to use it and animate the influence.

Some people use it to build the rigs which in general I tend to avoid and I find that quite cumbersome !

1 Like

I too gave up on Child-of when I realised that the modifier does not actually make the child work with the parent in all cases. I noticed a lot of unwanted transformations when using it and just doing regular parent bones with Connected disabled worked in every scenario, unless the bone existed in another armature. Didn’t help that resetting your transform values with Child-of doesn’t actually reset the rig back to zero unless you reset twice, which just led to parts of the mesh falling behind the rest of the rig, and even created animation artefacts during export.

Really do not recommend.

You can edit your vote, I voted NO for now !

1 Like

You and I have very different rigging philosophies :slight_smile: nothing wrong with that, of course

It’s the method I was taught from using Maya at school. Clean skeleton rigs make a lot of sense to me since it completely avoids export contaminations by having to hide/unhide things you do not want for your rig inside a game engine. :smiley:

1 Like

There’s some other riggers I’d love to hear from: @Pxy-Gnomes comes to mind, as does @etn249

1 Like

I’m not sure why this is being considered ? local space and world space have different uses. There’s also more than one way to rig a cat in Blender. I haven’t counted but I would say I use both equally frequently.

“Local space with owner orientation” is pretty new and mimics the way some constraints work in Maya (by accounting for the difference in rest pose between the two bones), but I’ve yet to fit it inside my rigs. It could be a candidate for the default choice as well.

1 Like

It would be helpful if you could run sozap’s script on some rigs and see if you use more or less of either :slight_smile: at this point, I think the consideration has shifted more towards an option in the preferences to choose the default

1 Like

I might not be the best person to ask this question, this is an area I’m less familiar with as I’m not primarily a rigger and I couldn’t explain what the different spaces do. I think I will skip voting on this one.

2 Likes

I understand Blender leadership has a ‘generalistic’ philosophy regarding the way the Blender UI is presented. In this sense, the “logic of Blender” often overrides the “logic of common users”; sometimes, pressure from the community or even more recently, partners and creditors, has provide strong demands that requires Blender to change on certain aspects. An older example I remember was the decision of changing the RMB-Click standard.

So, in the case of the Spaces discussion:
in terms of software Logic, because the Armature is an Object, and whatever Bone that it possess is structurally and immediately ‘Parented’ to it, World Space as default seems a bit ‘offset’; but it looks good in terms of a default setting for the entire UI, except that it contradicts the structural hierarchy which already is part of the ‘Outside World’ × ‘Inside Object’ problematic. And it’s not just a question of Global Coordinates × Local Coordinates, since these two concepts only relate to Locations, there isn’t a concept such as “Pose Coordinates” because it would work the same way as “Local Coordinates” except focusing on the Origin of the Armature Object instead of the root Position (on Edit Mode) of a particular Bone. There is even more ‘satefy’ to have Pose Space instead of World Space as default in the case of Bone Constraints, even though it’s seldom used on 3D Character Rigging/Animation projects. There could be exceptions to this of course, because some Bone Constraints might be meant to use in relation to some World, like ‘physics’ stuff (imagine horizontal water, and the Armature Object itself was Rotated wildly for some reason); but that would be the case in which we would require to specifically swap to World Space because that is what will make the Bone respect the World orientations and not the Armature Object’s orientation (in the case the latter was the default).

Furthermore, I believe Pose Space could be called in a more understandable way, such as “Armature Space” in the case of Bone Constraints or just “Object Space” in the case of any Target/Owner Space in the UI I guess).

Note: To be fair, I hope I’m not making any radical mistake in these explanations. So, please correct me if you see anything inconsistent.

In the case of Local Space for Bone Constraints being default, I believe this would be handier of course for 3D Character Rigging, but conceptually it would be inaccurate: fundamentally, through Bone Constraints, Bones would need to relate to their holistic ‘Parent’ thing, their first ‘root’ thing, which is their Armature Object, which could also mean their ‘root’ Origin. Thus, first, we need to recognize who are our ‘root’ Parents (Pose Space), then we can take account of ourselves (Local Space). It also makes little sense in my opinion, when dealing with Bone Constraints, to start looking first at the vastness of the cosmos (World Space as default), or to our own arm or cell (Local Space as default), if we do not recognize our own body first, our immediately ‘true’ Parent (Pose Space as default).

What I would like to have though in UI of the Bone Constraints, is some sort of Operator or Keyboard Shorcut that would immediately swap everything (Target Space & Owner Space) especially to Local Space, since this is the most fundamental trick at least for 3D Character Rigging I guess. ¡That would be handy! :star_struck:
I wonder if this couldn’t be set as a Adjust Last Operation Region input, whenever we Add a new Bone Constraint: it would be optional therefore: “Set All Spaces To [ ? ]”. And have Pose Space as default by the way… ¿and perhaps have the last choice made remain ‘recorded’ if Adding even more Bone Constraints? so that we could indeed have this automatic Local Spaces settings that many Riggers are looking forward to. :scream_cat:

1 Like

Hello !

So I slept a bit over the idea !
Here is simple test file to demonstrate all the behaviour on a copy location constraints,
that way you can test and see what default would work.


Bones_Space.blend (145.5 KB)

In that simple example Local seems confusing to me,
World is still quite predictable and don’t introduce much confusion.
Local Owner Space looks like what ones would expect when adding a constraint, but since I never used it yet, I’m a bit worried about advocating it as default !

While world seems clunky I really think it’s a safe default !

In general constraints are still a bit like voodoo to me. Just when I think I have it sorted another case comes up and I am baffled once again. And I am always trying all the combinations just to get them to work at all.

I think there was some development discussion about this related to dependency graph a while ago. Like there are some limitations currently that can only be handled by being able to sort dependencies for all cases.

Anyway, no vote for me because it is rarely that you have one constraint in any kind of rig set up and there are all kinds of variables and stuff that winds up broken - or so it seems to someone who is rig challenged such as myself. So I don’t even know if it is me or Blender or both. But I am always desperately trying all the combinations.

In theory of course local makes sense because bones need to operate in local space most of the time.

But if it changed to local I might still find myself fumbling about just trying to get it to work the way I expected.

1 Like