Why is it that for normal vectors Z is the primary axis, yet for bones it is Y?
I can’t be the only one who finds this discrepancy confusing, right?
Please explain to me the logic of this.
To illustrate, here a bone is being grabbed along Local Z while the Axis Display is indicating it is the bone’s Y axis:
This is a big WTF point for me in rigging and I finally need to ask.
Hopefully someone can enlighten me. Thanks.
You’re confused between armature coordinates and bone coordinates. An armature has its own local coordinates, and each bone of the armature has its own coordinates…
This may help:
No object has a “primary” axis - all 3D objects, irrespective of product or type have three axes - X, Y and Z all of equal importance.
Bones ALWAYS “roll” about their Y axis in Blender and “pivot” about their X and Z axes. If these axes lie coincident to any other axis system in use, you can use either for rotations.
A bone does not have a “normal” axis, its longitudinal (from tail to head of the bone) axis is Y, this applies to many other scenarios in Blender as well, for example commonly used Track-To constraints.
To rotate a bone about it’s own axes rather than the Global, View or any other axis, select the bone, key r to rotate, then yy to rotate it about it’s own Y axis, or xx for the X axis, zz for the Z axis.
You can rotate a bone so that it lies upon another Global, View, Normal, etc. axis, then you can either key r followed by the bone’s axis, key the axis letter twice, or the Global/Normal/View/etc. axis letter once.
To a mathematician, and therefore the Blender programmers, “Normal” means “At right angles to” - please don’t confuse this term with “normal” meaning “commonly expected”, it is not the case.
Exactly the same principles apply to moving a bone with the g (grab) command.
If you follow these principles, you will know where you are and what is happening, just remember, the longitudinal axis of a bone is alway Y. You can also confuse yourself by seeing the Z axis of a bone pointing towards negative Global Z axis, this is not necessarily a problem and it can be changed by “normalising” the bone (CTRL-N and select orientation mode). This may however, make the bone’s X axis point to negative Global X, but it does not matter, just rotate the bone about it’s own axes rather than any other axis system. Bones axes obey the Left Hand Rule for orientation, and this does NOT change if you rotate or roll the bone, therefor the bone cannot always follow the Global/Normal/View/Whatever axis system also in place for other objects.
Cheers, Clock.
By the way, putting “WTF” statements in your posts does not endear you to those who’s help you seek, politeness is not a chargeable item.
Thanks Clockmender!
Your reply partially answers my question, but also brings up more.
Let’s see… first of all no vulgarity intended by ‘WTF’, however point taken. I should have explained my rigging woes with a picture.
A bone does not have a “normal” axis, its longitudinal (from tail to head of the bone) axis is Y, this applies to many other scenarios in Blender as well, for example commonly used Track-To constraints.
Yes, Track-To constraints have been messing me up for the same reason! Glad you pointed that out.
So I see why I was confused: I had the Transform Orientation set to Local so it was using the Z axis of the whole armature, but actually if I want to translate along the bone’s Y Axis I need to set the Transform Orientation to Normal. And I know you said bones don’t have normal vectors, but a bone’s pivot axis (Y) is treated as the “normal” in this mode.
Agreed, “primary” was not the best choice of wording. I wanted to describe how one axis rolls while the other two pivot.
That said, the axis orientations of bones still seem mismatched to me. Here’s why:
This may however, make the bone’s X axis point to negative Global X, but it does not matter, just rotate the bone about it’s own axes rather than any other axis system.
I’m not familiar with negative axes yet - do those occur when you scale a bone by a negative value?
Bones axes obey the Left Hand Rule for orientation
I wasn’t sure how the Left Hand Rule is defined, but this helped:
So I guess the definition is: The Z Axis is represented by one’s middle finger.
Or alternatively: The X Axis is represented by one’s thumb.
Is it that while Blender’s Z Axis was set to be the “up-down” axis for Global and Local coordinates (setting it apart from other 3D software) the bone coordinates were left the same as other 3D software?
I mean, is there a reason you know of why the roll axis is Z for some types of data and Y for others?
Hello Sir!
I do not know the precise reason why a bone’s longitudinal axis is Y, I just accept it as being the case. For me the easy way to manipulate bones is to grab (g) or rotate ® them about their own axes by keying xx, yy, or zz then the rotation amount or LMB. You can always enter values into the bone’s Transform Entry Boxes as well and then just RMB the new value and select “Insert Single Keyframe” or “Insert Keyframes” rather than try to manipulate the bones in the 3D view. BTW Transformation Constraints for bones should use “Local” as the coordinate system, not Global, or anything else in most cases to avoid unexpected results, like them not working at all!
Negative axes are merely the inverse vector of a positive axis value, so for example -Z is downwards in the Global system. For my mind, it makes sense for the X and Y axes to lie flat on the “Top” view and to add depth as the third or Z axis in the vertical direction. This makes the “front” view; X from left to right, Z from down to up and Y from front to back. I started 3D modelling in 1981 on an Intergraph system and this was how it was arranged back in the “olde” days! Blender uses the same system now. What this means is that the depth, or “normal to the viewing plane” on the front view is positive Y and is therefore consistent with the bone axis system. I know other objects have a different perception of their “normal to plane” axis, but I cannot offer an explanation as to why, I am happy to accept that this is so, even if it is ,to quote Mr. Spock, “Illogical”. To be honest I hardly ever use the “Normal” axis system, preferring to use Global or View orientation, after I have aligned the view, instead.
One example of an inconsistency that you may encounter is moving a camera along its “Viewing” axis. For some reason I have yet to fathom out, if you want to move a camera closer to its viewed objects, but not change its viewed orientation, you move it in it’s own -Z axis, I do this by keying g zz and a negative value for closer, or positive value for further away, or use the LMB. This also means that if you want to add a Track To constraint to the camera you must use -Z as the target axis and set Y as the “Up” axis, curious, but I just accept that.
I think that because bones can move or rotate so much relative to the Global axis system, that it is better to accept that Y always goes from tail to head and that manipulations are best handled by the bone’s Transform boxes or by keying double axis notations, e.g. xx, in the 3D view. For example if you lay a bone horizontally along the Y axis, its positive X and Z axes will not necessarily lie along the same positive Global axes.
I hope this answers your questions, if not the exact reasons why things are so. Perhaps a Blender programmer might reply to this post with an explanation as to why things are as they are. Last point - please, for my benefit, only use the term “normal” when you mean “perpendicular” rather than “usually” as it confuses my old brain when reading posts! :spin::spin:
Cheers, Clock.
Thanks again!
Fair enough. I will add it to the “just accept it” folder in my brain.
I know other objects have a different perception of their “normal to plane” axis, but I cannot offer an explanation as to why, I am happy to accept that this is so, even if it is ,to quote Mr. Spock, “Illogical”.
Illogical indeed 
I am reminded of the Blender Guru clouds tutorial
of always needing to rotate particles in relation to their emitters. That is when I found out I was not alone in feeling dis-oriented.
One example of an inconsistency that you may encounter is moving a camera along its “Viewing” axis.
I know what you mean. I think this was odd to me only the first time I tried positioning a camera by coordinates. Then once I realized that a camera with its rotation coordinates zeroed-out points “down” (in relation to the World grid), it made perfect sense. I started to think of the Z Axis as the axis that objects should be expected to rotate about. Because when you are in Camera View and you rotate the camera, it’s rotating around its Z Axis. And I started to think of everything I model in Blender as if I were looking down on a desk top (the grid). I think this Z-centric way of thinking is why I am so surprised to find that with bones Y is the new Z, so to speak.
Cheers,
QA
Pleased to help.
Cheers Clock.
Sorry if this is an illegal dead bump
But I hope with the announcement of
Support for game engines
That the Blender dev team will realize their local Y axis bones are not so compatible with some if not all game engines Including Maya.
I personally hope they let us change it to whatever we want or at least an option for Z forward so that there’s full Compatibility with the Source Engine and Maya and so on…
Some game engines just don’t have any re-targeting at all, and what are we supposed to do but live with crappy Import Exports that shrink the bones and use a Sphere object as a visual for a bone…
Yes, but that would instantly break every armature that has ever so-far been made using Blender.
If you needed to move the model to some other system that used different axes for different things, then an import / export algorithm could trivially do that, simply re-arranging the 3-tuple as required by the different pieces of external software.
It was pretty much Z up before Maya. That followed cad cam right hand cartesian standards. Many game engines then went along with Maya Y up. I think your question needs to be put to Maya as to why they didn’t follow the established standard like 3d max, and UE4. NO?
I think it’s better to adapt to the environment via Blender than to ask those people to change something that would effect everything.
If you know your trigonometry, it is general consensus for the past couple of thousand years (Euclid) - looking down onto your paper note book from above 
The vertical arrangement (display, blackboard… Y+ up) is rotated system - secondary.
All I was saying is, the Blender devs announced a while ago, something about supporting game engines more.
So I hope they do something like let us change the local bone axis to whatever we want, since Exporter Plugin devs sometimes are a bit weird, they refuse to rotate the bones on export “Because it would confuse people” and leave us with scaled down bones using a sphere as a bone shape and you cant attach any Bone Constraints because of it, forcing me to think about learning Maya just to use the shitty skeleton. (Thanks Garry’s Mod)
And forget about asking Maya to change history to adapt to Blenders bone axis, forget about asking already made games to change theirs too.
Sure but the “Dev” of the Export / Import plugin refuses to rotate the bones lol
He doesnt understand that its annoying what he has done, just because It would confuse people
Sure confuse people that they have a normal skeleton… and not something using Spheres as bone joints, unable to use Bone Constraints on them.
If you add the “fee-chur” of letting the artist specify “whatever bone you want,” you’ve just added tremendous complexities that could ripple throughout the system. (And this principle would be true whether “the system” were Maya, or Blender, or anything-else.)
I second @sundialsvc4 suggestion to convert during export. All axes are orthogonal, you can literally just swap the Y and Z values of the bone matrix (easier said than done ofc, you need to change the add-on code and debug).
Sure but issue comes when the Dev of the importer refuses to convert the axis on Export
And a Community just sits there and has to accept the broken Skeleton it becomes, cant animate with most of the Bone Constraints because they dont work for the strange axis of Z forward for the Source engine.
It only works fine and dandy in Maya
This sounds like something that would be best solved in the python exporter. Whatever the blender foundation will do regarding “better support for game engines” it is not going to happen any time soon.
On the other hand, it seems like your problem could be solved right now with a simple change to the exporter you are using. I would ask for help in either the volunteer or python coding section of this site. If it is really a simple change, I’m sure someone won’t mind doing that for free.
By the way, which exporter are you using?
We have to deal with bones like these
Cant get Bone Constrains to work on something like this.
The dev refused to implement the option (again) to swap axis for Blender, to have normal bones, “Because it would confuse people”.
But I say it only makes things worse.
