Copy Rotation World Space to World Space flips when applying Mix Before, After or Legacy #85350

Closed
opened 2021-02-04 00:02:40 +01:00 by Colin Knueppel · 10 comments

System Information
Operating system: Windows 10
Graphics card: Radeon RX Vega

Blender Version
Broken: (example: 2.91, edbf15d3c0, master, 2018-11-28, as found on the splash screen)
Worked: not since implementation in f4056e9ec3

Short description of error

Exact steps for others to reproduce the error

  1. Create a single bone armature.
  2. Shift + D duplicate bone and offset location for clarity.
  3. Ctrl + Tab into Pose mode.
  4. Select original bone and shift select the second bone.
  5. Ctrl + Shift + C to Copy Rotation constraint the duplicate to the original.
  6. Select the constrained bone and change Mix setting to before original and observe the immediate flip.
    The flip is the bug.

#85349.blend

Expected behavior is to have the bone orientation match the world orientation of the the target and animate as though the world space of the target is its base pose. World Space to World Space should align absolutely, and if the purpose of some of these mixes is to allow the users to animate over a constraint, the base behavior should still work as expected.

Without this working as expected, people need to devise work arounds using more bones and constraints, which could be time consumptively non-obvious, clutter the rig with added bones/constraints, and convolute what could otherwise be an intuitive and concise solution.

Thanks for your time and consideration.

Sincerely,
Colin

**System Information** Operating system: Windows 10 Graphics card: Radeon RX Vega **Blender Version** Broken: (example: 2.91, edbf15d3c044, master, 2018-11-28, as found on the splash screen) Worked: not since implementation in f4056e9ec3 **Short description of error** **Exact steps for others to reproduce the error** 1. Create a single bone armature. 2. Shift + D duplicate bone and offset location for clarity. 3. Ctrl + Tab into Pose mode. 4. Select original bone and shift select the second bone. 5. Ctrl + Shift + C to Copy Rotation constraint the duplicate to the original. 6. Select the constrained bone and change Mix setting to before original and observe the immediate flip. The flip is the bug. [#85349.blend](https://archive.blender.org/developer/F9632506/T85349.blend) Expected behavior is to have the bone orientation match the world orientation of the the target and animate as though the world space of the target is its base pose. World Space to World Space should align absolutely, and if the purpose of some of these mixes is to allow the users to animate over a constraint, the base behavior should still work as expected. Without this working as expected, people need to devise work arounds using more bones and constraints, which could be time consumptively non-obvious, clutter the rig with added bones/constraints, and convolute what could otherwise be an intuitive and concise solution. Thanks for your time and consideration. Sincerely, Colin
Author

Added subscriber: @colleyd

Added subscriber: @colleyd
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Member

Might be me, but I also cannot make sense of it "not working" in anything but local space.

Implemented in f4056e9ec3

Might be me, but I also cannot make sense of it "not working" in anything but local space. Implemented in f4056e9ec3
Member

Added subscriber: @angavrilov

Added subscriber: @angavrilov
Member

@angavrilov: are we doing something wrong?

@angavrilov: are we doing something wrong?

First, as soon as this is arguing how things 'should' work, this is definitely a feature request and not a bug. Second, space and mix mode are completely unrelated and in a node system would be separate nodes. You effectively are arguing that different settings of a coordinate space conversion node 'should' affect what a matrix math node does.

First, as soon as this is arguing how things 'should' work, this is definitely a feature request and not a bug. Second, space and mix mode are completely unrelated and in a node system would be separate nodes. You effectively are arguing that different settings of a coordinate space conversion node 'should' affect what a matrix math node does.
Member

Added subscriber: @wbmoss_dev

Added subscriber: @wbmoss_dev
Member

A solution may be to separate Owner space into Read and Write spaces. For this case, Owner Read=Local and Owner Write=World. This leads to

Owner World = Target World @ Owner Local

as desired.

A solution may be to separate Owner space into Read and Write spaces. For this case, Owner Read=Local and Owner Write=World. This leads to Owner World = Target World @ Owner Local as desired.
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:35:54 +01:00
Member

This isn't a bug, but rather an easy point of confusion. Basically, the situation is the following:

  • Perhaps weirdly, Blender doesn't create new bones in an "untransformed" position. Any bone that is pointing up is actually (in terms of world space) rotated 90 degrees to do so. And that is the default position of new bones (including the default bone in a new armature). An untransformed bone (in terms of world space) would actually be pointing back, down the positive Y axis.
  • Due to this, the world-space rotation of the default (pointing up) bone is actually 90 degrees.
  • Therefore, with two pointing-up bones and a constraint operating in world space, if you set the mix mode to anything other than Replace (all of which try to combine the rotations of the two bones), the transform system correctly-but-confusingly sees two 90-degree world-space rotations.
  • Therefore, when those two rotations are combined, you get a 180-degree rotation, which puts the bone pointing away from the positive Y axis.

Since this isn't a bug, I'm closing the issue. However, I do think this indicates we might want to re-think what the default position of new bones is, so that simple tests like this reveal what's going on in a more straightforward way to users.

We could also try to figure out a way to make it more obvious/clear how spaces and mix modes interact. But I think there are some fundamentally tricky-to-wrap-your-head-around things about it, so I doubt something as simple as e.g. label changes or better tool tips would make a meaningful difference here (although improvements there are always welcome). I suspect it would need to be something like adding visualizations in the 3d viewport of what's going on, which would be a significant feature to design and implement.

This isn't a bug, but rather an easy point of confusion. Basically, the situation is the following: - Perhaps weirdly, Blender doesn't create new bones in an "untransformed" position. Any bone that is pointing up is actually (in terms of world space) rotated 90 degrees to do so. And that is the default position of new bones (including the default bone in a new armature). An untransformed bone (in terms of world space) would actually be pointing **back**, down the positive Y axis. - Due to this, the world-space rotation of the default (pointing up) bone is actually 90 degrees. - Therefore, with two pointing-up bones and a constraint operating in world space, if you set the mix mode to anything other than `Replace` (all of which try to *combine* the rotations of the two bones), the transform system correctly-but-confusingly sees two 90-degree world-space rotations. - Therefore, when those two rotations are combined, you get a 180-degree rotation, which puts the bone pointing *away* from the positive Y axis. Since this isn't a bug, I'm closing the issue. However, I do think this indicates we might want to re-think what the default position of new bones is, so that simple tests like this reveal what's going on in a more straightforward way to users. We could also try to figure out a way to make it more obvious/clear how spaces and mix modes interact. But I think there are some fundamentally tricky-to-wrap-your-head-around things about it, so I doubt something as simple as e.g. label changes or better tool tips would make a meaningful difference here (although improvements there are always welcome). I suspect it would need to be something like adding visualizations in the 3d viewport of what's going on, which would be a significant feature to design and implement.
Blender Bot added
Status
Archived
and removed
Status
Confirmed
labels 2023-05-08 12:26:02 +02:00
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
5 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#85350
No description provided.