Bone parallel to world z axis flicking when scale in edit mode. #38843

Closed
opened 2014-02-26 02:13:18 +01:00 by Harrison Yu · 23 comments

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.

**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.
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @YonghaiYu

Added subscriber: @YonghaiYu

#38838 was marked as duplicate of this issue

#38838 was marked as duplicate of this issue
Author

Worked: f1a0278
and 2.70 testbuild:4789793

Worked: f1a0278 and 2.70 testbuild:4789793

Added subscriber: @ideasman42

Added subscriber: @ideasman42

This issues was introduced by 3fe487217d

This issues was introduced by 3fe487217d
Bastien Montagne was assigned by Campbell Barton 2014-02-26 02:32:33 +01:00

Added subscriber: @GaiaClary

Added subscriber: @GaiaClary

◀ Merged tasks: #38838.

◀ Merged tasks: #38838.

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 :/

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 :/

This issue was referenced by blender/blender-addons-contrib@65c5be9676

This issue was referenced by blender/blender-addons-contrib@65c5be967668e3d1fa993db644e01f159c522294

This issue was referenced by 65c5be9676

This issue was referenced by 65c5be967668e3d1fa993db644e01f159c522294

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Closed by commit 65c5be9676.

Closed by commit 65c5be9676.

Changed status from 'Resolved' to: 'Open'

Changed status from 'Resolved' to: 'Open'

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.

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.

Added subscriber: @beetlegiest

Added subscriber: @beetlegiest

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'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.

Added subscribers: @BassamKurdali, @JoshuaLeung

Added subscribers: @BassamKurdali, @JoshuaLeung

See D362

See [D362](https://archive.blender.org/developer/D362)…
Member

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 ?

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 ?

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

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…

Closing again, this is a "no good solution" case, you just can’t have a good roll correction in all situations. [D362](https://archive.blender.org/developer/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…
Member

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...

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...
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#38843
No description provided.