Page MenuHome

Rotation pivot uses mesh object instead of pose bone while in weight paint mode
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-5.4.0-7634-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce RTX 2080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: e12eb89f22c6ee17971195e0221a8e8b8ee3db8a (bisected)

Short description of error
The Local, Normal and Gimbal transform orientations seem to be taking their data from the active mesh object instead of the active pose bone, resulting in these transform orientations being unusable now. This is only in weight paint mode. I believe this was introduced fairly recently, and this makes weight painting properly virtually impossible, since every time I want to do something as basic as rotating a bone on its local axis, I have to leave weight paint mode.

Exact steps for others to reproduce the error

  • The above file is already in weight paint mode. The object and bone are oriented differently to illustrate, and the current orientation mode is Local.
  • Press R, X to rotate. The bone rotates around the cube's local axis, which is wrong.
  • Leave weight paint mode, enter pose mode, and try rotating the bone with R, X to see the expected behaviour.

Event Timeline

The same issue is present with cursor snapping. "Snap cursor to selected" snaps to the mesh object rather than bones. I'm guessing it's the same issue, but if not I can open a separate report. I'm also less confident that this didn't always work this way, but I don't think it did. It's definitely wrong either way though.

Sebastian Parborg (zeddb) changed the task status from Needs Triage to Confirmed.EditedFeb 10 2021, 12:52 PM

Can confirm that this doesn't happen with the 2.92 branch. Must be a recent change, bisecting.

Bisected it to: e12eb89f22c6ee17971195e0221a8e8b8ee3db8a

@Germano Cavalcante (mano-wii) It seems like this fix broke local rotation in weight paint mode. From the task it fixed, it seems like this was unintentional.
From the code it is not obvious that it will break this use case. So perhaps we should add a automated test for this to test this quirk?

We can take the example file and do a local transform rotation and check if the bone rotated along the bone local axis as intented.

Just updated my Blender to test, thanks so much for the fix!