Page MenuHome

Bone parallel to world z axis flicking when scale in edit mode.
Closed, ResolvedPublic

Description

System Information
windows 7 pro 64bit,gtx 580

Blender Version
Broken:9c755ef

Short description of error
Bone parallel to world z axis flicking when scale in edit mode.

Exact steps for others to reproduce the error
Add an armature, switch to edit mode ,select and scale the default bone.

Event Timeline

Harrison Yu (harrisyu) updated the task description. (Show Details)
Harrison Yu (harrisyu) raised the priority of this task from to Needs Triage by Developer.
Harrison Yu (harrisyu) set Type to Bug.

Worked: f1a0278
and 2.70 testbuild:4789793

I won’t say how much I’m tired of this bone edit mode… Will try to fix that, should not be hard to hack it here :/

Re-opening. This still causes a glitch with roll compared to 2.69.

Simple example:

  • default blend
  • add bone
  • enter editmode
  • select all
  • rotate

roll jumps.

I've been looking at this ticket, the jump is related to the viewport when you start a translation. It is kinda inconsistent what the bone does when you rotate it. If you view the bone looking down depending on the viewport it will rotate differently. If your looking up at the bone it behaves differently than if your looking down, and the jump seems to be dependent on where your viewing. The jump seems to be in the code that normalizes the bone position to see if it is z-axis. If you watch the z vector it jumps from 1 to .6 and I'm guessing thats why the jump is roughly 30+ degrees when it jumps. I just wanted to share what I found already before I checked out for evening, so maybe someone could at least not have to spend as much time debugging. If its still issue tomorrow I'll try and chase down the actual positioning issue to code.

I'd like to propose to distinguish between "horizontal" bones and "vertical" bones" and setup a rule set like this:

Definition:

Horizontal bone: a bone laying in the X-Y plane
Vertical bone: a bone laying in the Y-Z plane

  • horizontal bones (and all angles +- 45 degrees relative to the X-Y plane) should get their local Z-axis aligned to global Z
  • vertical bones (and all angles +- 45 degrees relative to the Y-Z plane) should get their local X-axis aligned to global X

The above rules would allow to have a human rig in T-Pose where legs and spine bones all have local X axes aligned to global X axis, while arm bones all have local Z aligned to global Z and all bones would have consistent bone roll values (mostly around 0). I agree that bones with a 45 degree angle still would be flipping candidates though.

Finally: Since the Bone roll is (as far as i understand it) a rotation angle around the local Y axis of the bone i do not understand why the roll changes between 0 and 90 degrees while i rotate the bone around the global Y axis. Shouldn't (in the current solution) the Bone roll behave the same like when i rotate around the global X axis where it is either 0 or 180 ?

Bastien Montagne (mont29) closed this task as Resolved.Feb 27 2014, 8:53 PM

Closing again, this is a "no good solution" case, you just can’t have a good roll correction in all situations.

D362 is worse imho, either we keep current behavior or we revert to 2.69 code. I would keep current one, because at least you will always get the same result if e.g. you rotate 180° at once, or three times 60°. And 2.69 code also produced weird roll jumps in some cases…

I would actually prefer to switch back to 2.69 behavior because there the orientation of the local X/Z axes is much less confusing compared to the current solution where the bone roll value is calculated in a consistent way, but imo still not in a way that is meaningful to the user...