Anim: Align new bones with the world axes #113138

Sybren A. Stüvel · 2023-10-02T11:13:27+02:00

Sybren A. Stüvel commented

2023-10-02 11:13:27 +02:00

Test builds are available at: https://builder.blender.org/download/patch/PR113138/

This PR consists of two commits that are intended to be kept separate. They are related enough to be in one PR though.

Adding a single bone will now align that bone with the world axes. This means it is added with its tail at (0, length, 0), such that the bone is oriented along the world Y-axis. Previously Blender would align bone-Y with world-Z.

This adjusts the following operators:

New single-bone Armature (Object mode, Shift+A → Armature)
Add Single Bone (Armature Edit mode, Shift+A)

Note that this only applies when using 'Align To: World' (in the operator options resp. the Editing preferences).

'Align To: View' still behaves as before, and
'Align To: 3D Cursor' behaves like 'World' because that option was never handled anyway.

Side-note: there is no 'Local' alignment option, only 'World', 'View', and '3D Cursor'. This is why adding a bone to an existing armature will always counter the armature object's rotation, and align the bone with the world. This behaviour is left as-is in this PR.

**Test builds** are available at: https://builder.blender.org/download/patch/PR113138/ This PR consists of two commits that are intended to be kept separate. They are related enough to be in one PR though. Adding a single bone will now align that bone with the world axes. This means it is added with its tail at `(0, length, 0)`, such that the bone is oriented along the world Y-axis. Previously Blender would align bone-Y with world-Z. This adjusts the following operators: - New single-bone Armature (Object mode, Shift+A → Armature) - Add Single Bone (Armature Edit mode, Shift+A) Note that this only applies when using 'Align To: World' (in the operator options resp. the Editing preferences). - 'Align To: View' still behaves as before, and - 'Align To: 3D Cursor' behaves like 'World' because that option was never handled anyway. ------------------ Side-note: there is no 'Local' alignment option, only 'World', 'View', and '3D Cursor'. This is why adding a bone to an existing armature will always counter the armature object's rotation, and align the bone with the world. This behaviour is left as-is in this PR.

Sybren A. Stüvel added 2 commits 2023-10-02 11:13:40 +02:00

1d896dfb63 Anim: Align the bone of 'Shift-A > Armature' with the Y-axis

Align the default bone that's added to the Armature you get with
'Shift-A > Armature' to the Y-axis. When the alignment is set to 'World'
this will actually align the bone's axes with the world axes.

Note that the 'View' alignment option already aligned the bone along the
Y-axis, so the code has been simplified a bit.

buildbot/vexp-code-patch-coordinator Build done. Details

e31989a726 Anim: align bone with world Y in Armature Edit mode

Pressing Shift+A (Add > Single Bone) in Armature Edit mode will now
align the bone with the world Y-axis instead of the Z-axis. This makes
the bone's axes align with the world axes (instead of aligning bone-Y
with world-Z).

This only applies when using 'Align To: World' in the Editing
preferences. 'Align To: View' still behaves as before, and 'Align To: 3D
Cursor' behaves like 'World' because that option was never handled
anyway.

Sybren A. Stüvel added the

Module

Animation & Rigging

Status

Needs Information from User

labels 2023-10-02 11:13:56 +02:00

Sybren A. Stüvel added this to the 4.1 milestone 2023-10-02 11:13:59 +02:00

Demeter Dzadik commented

2023-10-02 11:55:21 +02:00

I think this makes sense and will benefit the workflow of a few cases:

Wanting to constrain a camera to a basic rig with Copy Transforms should be a bit less confusing now I think (although cameras pointing down by default is still a separate issue).
Assigning a bone shape to a bone in its default position will no longer be 90 degrees rotated on X compared to the shape object itself.

I think this makes sense and will benefit the workflow of a few cases: - Wanting to constrain a camera to a basic rig with Copy Transforms should be a bit less confusing now I think (although cameras pointing down by default is still a separate issue). - Assigning a bone shape to a bone in its default position will no longer be 90 degrees rotated on X compared to the shape object itself.

Daniel Salazar commented

2023-10-05 05:28:27 +02:00

@blender-bot package

Blender Bot commented

2023-10-05 05:28:31 +02:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR113138) when ready.

Sybren A. Stüvel removed this from the 4.1 milestone 2023-10-06 12:00:08 +02:00

Sybren A. Stüvel added this to the Animation & Rigging project 2023-10-06 12:00:10 +02:00

Sybren A. Stüvel commented

2023-10-06 12:09:40 +02:00

As an alternative, we could have different alignment options for the default bone placement. Note that the redo panel options of the object-mode Shift+A > Armature will only align the Object, and not the bone inside of it. However, the user preference Editing > New Objects > Align To does (in main) influence that default bone orientation.

I feel that there's room for improvement here. Some possibilities:

Add a new preference Animation > Armature > Default Bone Orientation, with options like:
- "Up in World Space" (Blender's current behaviour)
- "Up in Armature Space" (something new, similar to what Blender does now, but without inverting the object rotation),
- "Align to World" (what this PR does),
- "Align to Armature Space" (something new, ensuring the bone's XYZ axes align with the Armature space XYZ axes),
- and maybe "Align with 3D Cursor" (for completeness).
Instead of having this as preference, add as operator options. This would have to be done twice though, for both "Object mode: Add new Armature object" and "Edit mode: add new Bone". Makes it easier to adjust on a case-by-case basis, but if you don't like the defaults you're forced to keep changing this.
Combination of 1. and 2. This might not be too useful though, as I have the feeling that it would require so many clicks & choices that people will hardly use it, and instead just create a bone with their default (so option 1.) and then manually rotate to their needs.
Something else?

Personally I kinda like option 1. What do others think?

As an alternative, we could have different alignment options for the default bone placement. Note that the redo panel options of the object-mode _Shift+A > Armature_ will only align the Object, and not the bone inside of it. However, the user preference _Editing > New Objects > Align To_ does (in `main`) influence that default bone orientation. I feel that there's room for improvement here. Some possibilities: 1. Add a new preference _Animation > Armature > Default Bone Orientation_, with options like: - "Up in World Space" (Blender's current behaviour) - "Up in Armature Space" (something new, similar to what Blender does now, but without inverting the object rotation), - "Align to World" (what this PR does), - "Align to Armature Space" (something new, ensuring the bone's XYZ axes align with the Armature space XYZ axes), - and maybe "Align with 3D Cursor" (for completeness). 2. Instead of having this as preference, add as operator options. This would have to be done twice though, for both "Object mode: Add new Armature object" and "Edit mode: add new Bone". Makes it easier to adjust on a case-by-case basis, but if you don't like the defaults you're forced to keep changing this. 3. Combination of 1. and 2. This might not be too useful though, as I have the feeling that it would require so many clicks & choices that people will hardly use it, and instead just create a bone with their default (so option 1.) and then manually rotate to their needs. 4. Something else? Personally I kinda like option 1. What do others think?

Demeter Dzadik commented

2023-10-06 12:43:55 +02:00

Maybe worth noting that if we went with #2, the edit mode behaviour could be customized by editing the keymap entry. This won't work for object mode though because that Shift+A just summons a list.

I also prefer #1, but I think the option fits better in Editing->Objects->New Objects.

Maybe worth noting that if we went with #2, the edit mode behaviour could be customized by editing the keymap entry. This won't work for object mode though because that Shift+A just summons a list. I also prefer #1, but I think the option fits better in Editing->Objects->New Objects.

Daniel Salazar commented

2023-10-06 20:54:19 +02:00

I see no real benefit of adding a new option if it's not going to be the default. And if it's the default it will break all tutorials in existence and be less useful for actual rigging (there is a reason why the bones are added upright!). It's fixing one thing by breaking another.

Option 4: What if we change bones to roll on Z for Blender 5.0? :)

I see no real benefit of adding a new option if it's not going to be the default. And if it's the default it will break all tutorials in existence and be less useful for **actual rigging** (there is a reason why the bones are added upright!). It's fixing one thing by breaking another. Option 4: What if we change bones to roll on Z for Blender 5.0? :)

Sybren A. Stüvel commented

2023-10-09 12:29:06 +02:00

I see no real benefit of adding a new option if it's not going to be the default.

Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope".

> I see no real benefit of adding a new option if it's not going to be the default. Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope".

Daniel Salazar commented

2023-10-09 17:55:36 +02:00

I see no real benefit of adding a new option if it's not going to be the default.

Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope".

Would this new preference be on by default?

What type of user is this preference trying to benefit?

> > I see no real benefit of adding a new option if it's not going to be the default. > > Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope". > Would this new preference be on by default? What type of user is this preference trying to benefit?

Armin Halac commented

2023-10-12 10:27:20 +02:00

First-time contributor

I never got what the benefit is of having the bone at any rotation other than zero by default. Feels like a legacy thing.
In my opinion, there is no technical benefit and it adds confusion for new users. So I'd vote to have new bones aligned with the world like all other object types. And I also don't see a reason to add options to have them rotated by default.

I never got what the benefit is of having the bone at any rotation other than zero by default. Feels like a legacy thing. In my opinion, there is no technical benefit and it adds confusion for new users. So I'd vote to have new bones aligned with the world like all other object types. And I also don't see a reason to add options to have them rotated by default.

Ivan Cappiello commented

2023-10-12 10:50:07 +02:00

Thank @dr.sybren for taking care of this. I was so used to it that never questioned why it was like that.
This would solve more than one issue with unexperienced users. Doesn't make sense to me to create a bone not aligned with the world. Do we have a general idea of why bone was added Y upwards originally? usually having some context can lead to better design decisions.

Add a new preference Animation > Armature > Default Bone Orientation, with options like:

"Up in World Space" (Blender's current behaviour)

"Up in Armature Space" (something new, similar to what Blender does now, but without inverting the object rotation),

"Align to World" (what this PR does),

"Align to Armature Space" (something new, ensuring the bone's XYZ axes align with the Armature space XYZ axes),

and maybe "Align with 3D Cursor" (for completeness).

option 1 seems quite reasonable to me, but I'd prefer to have a world orient as default.

Thank @dr.sybren for taking care of this. I was so used to it that never questioned why it was like that. This would solve more than one issue with unexperienced users. Doesn't make sense to me to create a bone not aligned with the world. Do we have a general idea of why bone was added Y upwards originally? usually having some context can lead to better design decisions. > 1. Add a new preference _Animation > Armature > Default Bone Orientation_, with options like: > - "Up in World Space" (Blender's current behaviour) > - "Up in Armature Space" (something new, similar to what Blender does now, but without inverting the object rotation), > - "Align to World" (what this PR does), > - "Align to Armature Space" (something new, ensuring the bone's XYZ axes align with the Armature space XYZ axes), > - and maybe "Align with 3D Cursor" (for completeness). option 1 seems quite reasonable to me, but I'd prefer to have a world orient as default.

👍 2

Daniel Salazar closed this pull request

2023-10-12 22:43:14 +02:00

Daniel Salazar reopened this pull request

2023-10-12 22:43:52 +02:00

Daniel Salazar commented

2023-10-12 22:46:56 +02:00

I see no real benefit of adding a new option if it's not going to be the default.

Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope".

I didn't just say "nope". What i said is this is fixing one problem (misalignment with world) by introducing another (un-intuitive, less useful default that can't be properly seen from front view). The right solution would be to switch bones to Z roll.

> > I see no real benefit of adding a new option if it's not going to be the default. > > Would you care to expand on that? It's hard to use this feedback now, when there's little more info than just "nope". > I didn't just say "nope". What i said is this is fixing one problem (misalignment with world) by introducing another (un-intuitive, less useful default that can't be properly seen from front view). The right solution would be to switch bones to Z roll.

Demeter Dzadik commented

2023-11-21 12:42:39 +01:00

it will break all tutorials in existence

Tutorials are not a relevant concern for development.

be less useful for actual rigging
It's fixing one thing by breaking another
un-intuitive, less useful default

What sort of rigging? Breaking what? Why un-intuitive, why less useful? This stuff is frustrating to read. Please make actual arguments. I've raised two real use cases above where the proposed change would be more intuitive and more useful. (camera constraining and assigning bone shapes)

can't be properly seen from front view

And the current default can't be properly seen from top view.
I assume your point is that front view is the most convenient and most often used when placing bones. I think this is a valid point, but it's not clear if this is actually the reason why you're mentioning this.

I see no real benefit of adding a new option if it's not going to be the default.

Obviously, the benefit is that if you want fresh bones to be properly seen from front view, you can choose that, and if you want fresh bones to align with bone shapes and cameras, you can choose that.
If you mean that it's not worth the added UI clutter in the Preferences, then I agree that we should only add more preferences when a change is really controversial enough to warrant it. You seem to feel quite strongly about keeping things here the way they are, while we want to change them, so, adding a preference seems to make sense to keep everybody happy.

And yes, bone roll being along Z would be nice, but that will break everything for real. This is just a tiny quality of life change. And I still believe this PR is a net positive.

> it will break all tutorials in existence Tutorials are not a relevant concern for development. > be less useful for actual rigging > It's fixing one thing by breaking another > un-intuitive, less useful default What sort of rigging? Breaking what? Why un-intuitive, why less useful? This stuff is frustrating to read. Please make actual arguments. I've raised two real use cases above where the proposed change would be more intuitive and more useful. (camera constraining and assigning bone shapes) > can't be properly seen from front view And the current default can't be properly seen from top view. I assume your point is that front view is the most convenient and most often used when placing bones. I think this is a valid point, but it's not clear if this is actually the reason why you're mentioning this. > I see no real benefit of adding a new option if it's not going to be the default. Obviously, the benefit is that if you want fresh bones to be properly seen from front view, you can choose that, and if you want fresh bones to align with bone shapes and cameras, you can choose that. If you mean that it's not worth the added UI clutter in the Preferences, then I agree that we should only add more preferences when a change is really controversial enough to warrant it. You seem to feel quite strongly about keeping things here the way they are, while we want to change them, so, adding a preference seems to make sense to keep everybody happy. And yes, bone roll being along Z would be nice, but that will break everything for real. This is just a tiny quality of life change. And I still believe this PR is a net positive.

Daniel Salazar commented

2023-11-21 16:26:37 +01:00

I understand and share your frustration. Bone orientation IS wrong and it's not my fault nor yours. And it can't be fixed by turning bones 90 degrees on their "back".

If an architect made the same mistake in a house's blueprint, would it be fixed by building the house sideways?

Of course it wouldn't. You would have to correct the root problem which is the blueprint.

That is the essence of my frustration. This PR does not fix the problem, only moves it further.

I've tried to be as clear as I can. I will step out of the conversation now.

I understand and share your frustration. Bone orientation IS wrong and it's not my fault nor yours. And it can't be fixed by turning bones 90 degrees on their "back". If an architect made the same mistake in a house's blueprint, would it be fixed by building the house sideways? ![image](/attachments/72f62c69-d892-431f-b38f-d5a1385015d4) Of course it wouldn't. You would have to correct the root problem which is the blueprint. That is the essence of my frustration. This PR does not fix the problem, only moves it further. I've tried to be as clear as I can. I will step out of the conversation now.

image.png

198 KiB

Demeter Dzadik commented

2023-11-23 12:52:29 +01:00

We all agree we want bones to no longer have Y as their length axis. But that's way beyond scope for this PR.

I think it would still be nice to avoid these scenarios:

Be new user
Spawn an armature and a Suzanne
Constrain Suzanne to your bone with Copy Transforms
Suzanne gets rotated by 90 degrees
Model a cool bone shape for your bone
Assign it
Your bone shape is rotated by 90 degrees

So, I agree with Ivan, that I would make the World Aligned option the default in the preference.

I wonder what people think of having the preference in Editing->Objects->New Objects rather than Animation > Armature > Default Bone Orientation.

We all agree we want bones to no longer have Y as their length axis. But that's way beyond scope for this PR. I think it would still be nice to avoid these scenarios: - Be new user - Spawn an armature and a Suzanne - Constrain Suzanne to your bone with Copy Transforms - **Suzanne gets rotated by 90 degrees** - Model a cool bone shape for your bone - Assign it - **Your bone shape is rotated by 90 degrees** So, I agree with Ivan, that I would make the World Aligned option the default in the preference. I wonder what people think of having the preference in `Editing->Objects->New Objects` rather than `Animation > Armature > Default Bone Orientation`.

👍 1

Nathan Vegdahl commented

2023-11-23 12:57:45 +01:00

I wonder what people think of having the preference in Editing->Objects->New Objects rather than Animation > Armature > Default Bone Orientation.

I think that actually might make more sense, yeah. Although Armatures are typically used for animation, ultimately they're just objects and can be used for non-animation things as well (like statically posing characters for a still render).

> I wonder what people think of having the preference in `Editing->Objects->New Objects` rather than `Animation > Armature > Default Bone Orientation`. I think that actually might make more sense, yeah. Although Armatures are typically used for animation, ultimately they're just objects and can be used for non-animation things as well (like statically posing characters for a still render).

Daniel Salazar commented

2023-11-23 21:01:10 +01:00

I think it would still be nice to avoid these scenarios:

Be new user

Spawn an armature and a Suzanne

Constrain Suzanne to your bone with Copy Transforms

Suzanne gets rotated by 90 degrees

Model a cool bone shape for your bone

Assign it

Your bone shape is rotated by 90 degrees

This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone)

Let's use the simplest example of a rig (multiple bones) that I can think of. A hose.

Would you rig it like this?

Or like this?

I think everyone knows the correct answer is the second.

So will the world aligned custom bone shapes match in this case? NO!

You see, the custom bone shapes can not match because the bone orientation is simply wrong (as we have already established and agreed on).

With your hypothetical single bone new user rig example you're teaching the new user the wrong way of using armatures, only to match custom bone shapes.

We shouldn't make a rigging decision based on a single bone scenario.

> I think it would still be nice to avoid these scenarios: > - Be new user > - Spawn an armature and a Suzanne > - Constrain Suzanne to your bone with Copy Transforms > - **Suzanne gets rotated by 90 degrees** > - Model a cool bone shape for your bone > - Assign it > - **Your bone shape is rotated by 90 degrees** This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone) Let's use the simplest example of a rig (multiple bones) that I can think of. A hose. ![image](/attachments/cbfcfa6e-9c03-47aa-bb86-cc14f15c9340) Would you rig it like this? ![image](/attachments/7edab09d-3a4e-4b0c-afa9-ad18387af675) Or like this? ![image](/attachments/98991791-88ed-4e66-9377-f1181cb9059d) I think everyone knows the correct answer is the second. So will the world aligned custom bone shapes match in this case? NO! You see, the custom bone shapes can not match because the bone orientation is **simply wrong** (as we have already established and agreed on). With your hypothetical single bone new user rig example you're _teaching the new user the wrong way of using armatures_, only to match custom bone shapes. We shouldn't make a rigging decision based on a single bone scenario.

image.png

96 KiB

image.png

82 KiB

image.png

74 KiB

Demeter Dzadik commented

2023-11-24 12:09:14 +01:00

correct answer is the second.

I agree! So the user story would be something like this:

Be new user
Spawn a cylinder
Spawn a bone
Rotate the bone by 90 degrees
Extrude it up a few times
Model a bone shape and assign
Your bone shapes are rotated by 90 degrees

At no point did the bone shape fail to match the bone orientation, nor did a new user learn anything wrong.
90 degrees of rotation on the bone resulting in 90 degrees of rotation on the bone shape is an intuitive outcome.

> correct answer is the second. I agree! So the user story would be something like this: - Be new user - Spawn a cylinder - Spawn a bone - **Rotate the bone by 90 degrees** - Extrude it up a few times - Model a bone shape and assign - **Your bone shapes are rotated by 90 degrees** At no point did the bone shape fail to match the bone orientation, nor did a new user learn anything wrong. 90 degrees of rotation on the bone resulting in 90 degrees of rotation on the bone shape is an intuitive outcome.

Nathan Vegdahl commented

2023-11-24 15:47:54 +01:00

I'm with @Mets in this case.

Although there will certainly be plenty of vertical-ish bones in a rig, in practice very few (if any) are actually going to be precisely vertically aligned. For example, spines have a curve to them, so none of the bones are actually vertical. So I'll have to adjust their orientation regardless. And even then, most are going to be extruded, not manually rotated into place. So having the new-bone orientation be on its side doesn't make much of a workflow difference there.

Where it does make a difference, however, is when creating new bones for controls like pole targets, eye targets, the root bone, etc. In those cases, the current vertical orientation of new bones just creates work for me, because I have to manually rotate them all to be precisely world-aligned. Which is annoying. Whereas if they were created already world-aligned that would save time and make the workflow much smoother.

I agree that it feels weird to have new bones be on their side. But I think that's just revealing a real weirdness to users that currently we try to sweep under the rug: that bones use the Y axis as their long axis. And I think trying to sweep that weirdness under the rug rather than put it front-and-center causes more confusion than it solves.

I'm with @Mets in this case. Although there will certainly be plenty of vertical-ish bones in a rig, in practice very few (if any) are actually going to be precisely vertically aligned. For example, spines have a curve to them, so none of the bones are actually vertical. So I'll have to adjust their orientation regardless. And even then, most are going to be extruded, not manually rotated into place. So having the new-bone orientation be on its side doesn't make much of a workflow difference there. Where it *does* make a difference, however, is when creating new bones for controls like pole targets, eye targets, the root bone, etc. In those cases, the current vertical orientation of new bones just creates work for me, because I have to manually rotate them all to be precisely world-aligned. Which is annoying. Whereas if they were created already world-aligned that would save time and make the workflow much smoother. I agree that it *feels* weird to have new bones be on their side. But I think that's just revealing a real weirdness to users that currently we try to sweep under the rug: that bones use the Y axis as their long axis. And I think trying to sweep that weirdness under the rug rather than put it front-and-center causes more confusion than it solves.

Sybren A. Stüvel commented

2023-12-11 11:57:00 +01:00

This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone)

Let's use the simplest example of a rig (multiple bones) that I can think of. A hose.

I think this is still overly simplified, as an equally simple case can be used as a counter-example: a hose. But then one that's modeled as an actual hose, laying on the floor instead of magically standing straight up like no hose ever does.

I think everyone knows the correct answer is the second.

True, which is easy enough if you rotate the bone by 90° to point upwards, and then subdivide / extrude it to create the other bones.

So will the world aligned custom bone shapes match in this case? NO!

Indeed. It's my hope that, because you had to do that 90° rotation yourself to orient the bones like that, it may make more intuitive sense that you see a similar rotation pop up somewhere else.

You see, the custom bone shapes can not match because the bone orientation is simply wrong (as we have already established and agreed on).

There's little sense beating this dead horse. Even Ton acknowledges that the current bone orientation was an arbitrary choice back in the day, and that it wasn't well thought-out (and, indeed, inconsistent with the rest of Blender and very annoying because of that).

With your hypothetical single bone new user rig example you're teaching the new user the wrong way of using armatures, only to match custom bone shapes.

It's not just to match custom bone shapes, as you can see from Demeter's examples. It's various places where a sudden 90° rotation pops up.

The bigger issue here is that of priorities. Changing the bone axes from Y=roll to Z=roll will break everything, so that shouldn't be done. Introducing adjustable bone axes is IMO the right way to go, as for existing rigs those can default to the existing orientation and for new rigs default to the sensible orientation. That will be a lot of work in order to get it done well and in all the places where this should be taken into account. It's a massive amount of work. We simply don't have the developer power for this, if we also want to do layered animation and all the other things we want to do.

So that's why I thought this PR might be a relatively minor amount of work, and still bring us some level of clarity. As I describe above, it should reduce the number of unexpected 90° turns, because the initial placement of new bones aligns with Blender's axis orientation.

> This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone) > > Let's use the simplest example of a rig (multiple bones) that I can think of. A hose. I think this is still overly simplified, as an equally simple case can be used as a counter-example: a hose. But then one that's modeled as an actual hose, laying on the floor instead of magically standing straight up like no hose ever does. > I think everyone knows the correct answer is the second. True, which is easy enough if you rotate the bone by 90° to point upwards, and then subdivide / extrude it to create the other bones. > So will the world aligned custom bone shapes match in this case? NO! Indeed. It's my hope that, because you had to do that 90° rotation yourself to orient the bones like that, it may make more intuitive sense that you see a similar rotation pop up somewhere else. > You see, the custom bone shapes can not match because the bone orientation is **simply wrong** (as we have already established and agreed on). There's little sense beating this dead horse. Even Ton acknowledges that the current bone orientation was an arbitrary choice back in the day, and that it wasn't well thought-out (and, indeed, inconsistent with the rest of Blender and very annoying because of that). > With your hypothetical single bone new user rig example you're _teaching the new user the wrong way of using armatures_, only to match custom bone shapes. It's not just to match custom bone shapes, as you can see from Demeter's examples. It's various places where a sudden 90° rotation pops up. The bigger issue here is that of priorities. Changing the bone axes from Y=roll to Z=roll will break everything, so that shouldn't be done. Introducing adjustable bone axes is IMO the right way to go, as for existing rigs those can default to the existing orientation and for new rigs default to the sensible orientation. That will be a lot of work in order to get it done well and in all the places where this should be taken into account. It's a massive amount of work. We simply don't have the developer power for this, if we also want to do layered animation and all the other things we want to do. So that's why I thought this PR might be a relatively minor amount of work, and still bring us some level of clarity. As I describe above, it should reduce the number of unexpected 90° turns, because the initial placement of new bones aligns with Blender's axis orientation.

❤️ 2

Daniel Salazar commented

2023-12-11 18:43:43 +01:00

This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone)

Let's use the simplest example of a rig (multiple bones) that I can think of. A hose.

I think this is still overly simplified, as an equally simple case can be used as a counter-example: a hose. But then one that's modeled as an actual hose, laying on the floor instead of magically standing straight up like no hose ever does.

I was planning to leave this topic alone but the misunderstandings should be cleared.

My example doesn't fall apart; it works regardless of the orientation.

Here's the hose laying on the ground:

Bones do have an intrinsic UP side, which is dictated by any kind of chain. The Up of each bone is it's Local Y, because it's the only way a chain can be formed.

For example, this is not a valid Blender chain, even if hierarchically it's the same.

You certainly don't rig like this

You rig like this

So in essence, for any bone (regardless of it's orientation) Local Y is Up. This doesn't match the rest of Blender, we all know that and this patch doesn't fix that, it's just encouraging users to rig incorrectly by pretending a Bone's Local Z is Up.

> > This 1 bone scenario falls apart with any sort of actual rig (a chain of more than 1 bone) > > > > Let's use the simplest example of a rig (multiple bones) that I can think of. A hose. > > I think this is still overly simplified, as an equally simple case can be used as a counter-example: a hose. But then one that's modeled as an actual hose, laying on the floor instead of magically standing straight up like no hose ever does. I was planning to leave this topic alone but the misunderstandings should be cleared. My example doesn't fall apart; it works regardless of the orientation. Here's the hose laying on the ground: ![image](/attachments/fa5dc041-e9ce-4dfe-b06e-92cda7a56890) Bones **do** have an intrinsic UP side, which is dictated by any kind of **chain**. The Up of **each bone** is it's **Local Y**, because it's the only way a chain can be formed. For example, this is not a valid Blender chain, even if hierarchically it's the same. ![image](/attachments/b385398d-f489-4b72-b569-a47aee75880c) You certainly don't rig like this ![image](/attachments/06b512e9-aafe-4a18-a0af-7a6f658dc8af) You rig like this ![image](/attachments/e7249898-8316-487c-a9cc-7fbad8432b08) So in essence, for any bone (regardless of it's orientation) **Local Y is Up**. This doesn't match the rest of Blender, we all know that and this patch doesn't fix that, it's just encouraging users to rig incorrectly by pretending a Bone's Local Z is Up.

image.png

83 KiB

image.png

149 KiB

image.png

129 KiB

image.png

74 KiB

Nathan Vegdahl commented

2023-12-12 11:25:37 +01:00

So in essence, for any bone (regardless of it's orientation) Local Y is Up.

I think this is also a misunderstanding. Local Y isn't actually up for bones, it's just the lengthwise axis. Bone axes don't have any intrinsic relationship to up (or left, or forward, or any other direction).

Having said that, I do agree that conceptually it feels better to have the lengthwise axis point up for new bones. In 3d space, up is in some sense the "not like the others" axis (both other axes are horizontal, whereas up is vertical, which is special from a human perspective). And similarly a bone's lengthwise axis is also its "not like the others" axis. So having those match when first creating a bone feels right.

But I would still argue that it's more practically important for the actual axes (in terms of XYZ) to be aligned when creating a new bone, as I outlined elsewhere in this thread. It's just really unfortunate that we have to make a choice between those two things in Blender, due to the mismatch between its z-up and y-lengthwise conventions.

> So in essence, for any bone (regardless of it's orientation) **Local Y is Up**. I think this is also a misunderstanding. Local Y isn't actually up for bones, it's just the lengthwise axis. Bone axes don't have any intrinsic relationship to up (or left, or forward, or any other direction). Having said that, I do agree that conceptually it feels better to have the lengthwise axis point up for new bones. In 3d space, up is in some sense the "not like the others" axis (both other axes are horizontal, whereas up is vertical, which is special from a human perspective). And similarly a bone's lengthwise axis is also its "not like the others" axis. So having those match when first creating a bone feels right. But I would still argue that it's more practically important for the actual axes (in terms of XYZ) to be aligned when creating a new bone, as I outlined elsewhere in this thread. It's just really unfortunate that we have to make a choice between those two things in Blender, due to the mismatch between its z-up and y-lengthwise conventions.

👍 1

buildbot/vexp-code-patch-coordinator Build done.

Details

Merge conflict checking is in progress. Try again in few moments.

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u pr/align-default-bone-to-y:dr.sybren-pr/align-default-bone-to-y

git checkout dr.sybren-pr/align-default-bone-to-y

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Anim: Align new bones with the world axes #113138

Checkout