iTaSC ignores location of disconnected bones. #33275

Closed
opened 2012-11-23 16:55:10 +01:00 by Tobias Oelgarte · 8 comments

%%%I appended an example file. If you drag the currently selected bone along y then you see that the legacy solver respects the location of the disconnected bone. But if you set the solver from legacy to iTaSC, then this location is always ignored, not influencing the result at all. The bone won't move.%%%

%%%I appended an example file. If you drag the currently selected bone along y then you see that the legacy solver respects the location of the disconnected bone. But if you set the solver from legacy to iTaSC, then this location is always ignored, not influencing the result at all. The bone won't move.%%%

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%It looks to me the iTasc behavior is correct: the bone is locked in all its rotation (it will stay aligned to the previous at all time), the displacement of the bone head is set in edit mode and not supposed to change in pose mode, hence no move action should work on that bone,

On the other hand, I can see that the legacy mode allows to change the head displacement in pose mode. I don't find that very logical; it seems to be a specific facility for disjoint bones. Can you explain why you think this is a iTasc bug and why changing the displacement in pose mode is useful (you can always change it in edit mode)?%%%

%%%It looks to me the iTasc behavior is correct: the bone is locked in all its rotation (it will stay aligned to the previous at all time), the displacement of the bone head is set in edit mode and not supposed to change in pose mode, hence no move action should work on that bone, On the other hand, I can see that the legacy mode allows to change the head displacement in pose mode. I don't find that very logical; it seems to be a specific facility for disjoint bones. Can you explain why you think this is a iTasc bug and why changing the displacement in pose mode is useful (you can always change it in edit mode)?%%%

%%%I think that if the iterations are set to 0 or the bone tip is already at the target, then the IK solver should have no effect, while it does in this case. If the user is allowed to change the pose head, then the IK solver might as well preserve that change and not undo it? The specific use case here I don't know, but disjoint bones are used a lot in complex animation rigs.%%%

%%%I think that if the iterations are set to 0 or the bone tip is already at the target, then the IK solver should have no effect, while it does in this case. If the user is allowed to change the pose head, then the IK solver might as well preserve that change and not undo it? The specific use case here I don't know, but disjoint bones are used a lot in complex animation rigs.%%%
Member

%%%I looked further into this. Disconnected bones are indeed handled specially in Blender: translation on a disconnected bone in pose mode moves the bone head while translation on a connected bone is converted automatically into a rotation. This causes problems to iTaSC in two ways: 1) change in the bone head cannot be applied to the iTaSC representation of the armature because there is no joint angles associated with it (only a fixed segment representing the displacement). 2) even if the iTaSC scene was rebuilt for every manual change of pose, that wouldn't work because iTaSC uses the rest pose, and not the current pose to build the internal armature representation.

I'll check how the legacy solver uses the current pose to build the armature and see if I can copy the method to iTaSC.
%%%

%%%I looked further into this. Disconnected bones are indeed handled specially in Blender: translation on a disconnected bone in pose mode moves the bone head while translation on a connected bone is converted automatically into a rotation. This causes problems to iTaSC in two ways: 1) change in the bone head cannot be applied to the iTaSC representation of the armature because there is no joint angles associated with it (only a fixed segment representing the displacement). 2) even if the iTaSC scene was rebuilt for every manual change of pose, that wouldn't work because iTaSC uses the rest pose, and not the current pose to build the internal armature representation. I'll check how the legacy solver uses the current pose to build the armature and see if I can copy the method to iTaSC. %%%

%%%It is useful for mechanical rigs where a part can expand in length (like a spring) or is modified in some other way, while the overall structure depends on fixed joints. Here is the complete example that lead me to write this report: http://www.blendpolis.de/viewtopic.php?f=14&t=42009%%%

%%%It is useful for mechanical rigs where a part can expand in length (like a spring) or is modified in some other way, while the overall structure depends on fixed joints. Here is the complete example that lead me to write this report: http://www.blendpolis.de/viewtopic.php?f=14&t=42009%%%
Member

%%%bug fixed in revision 53411. The behavior of iTaSC in animation mode is now identical to the legacy solver.
%%%

%%%bug fixed in revision 53411. The behavior of iTaSC in animation mode is now identical to the legacy solver. %%%

%%%I can confirm this is fixed, so closing the report.%%%

%%%I can confirm this is fixed, so closing the report.%%%

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
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
3 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#33275
No description provided.