Details

Reviewers

Commits

rB81dc76c19cff: Fix T63570: Proportional editing resets scaling along Y and Z axis on mouse…

Summary

applyResize(...) considers that t->values always represents a ratio.
But this is only true with the MOUSEMOVE event.
The solution proposed is to never change t->values the result of the final transformation is now written to t->value_final.

Report: T63570

Diff Detail

Repository

rB Blender

Branch

master

Build Status

Buildable 4006
Build 4006: arc lint + arc unit

Event Timeline

Germano Cavalcante (mano-wii) created this revision.Jul 10 2019, 12:55 AM

Harbormaster completed remote builds in B4006: Diff 16285.Jul 10 2019, 12:56 AM

This comment has been deleted.

Do not write on t->values when applying transformations.

Harbormaster completed remote builds in B4039: Diff 16338.Jul 12 2019, 2:04 PM

Germano Cavalcante (mano-wii) edited the summary of this revision. (Show Details)Jul 14 2019, 3:58 PM

Comments and rename T_AUTOVALUES to T_INPUT_IS_VALUE_FINAL

Harbormaster completed remote builds in B4253: Diff 16782.Aug 2 2019, 5:13 AM

Looks good and tested, it seems to work well for UV/sequencer/extrude-tool, interactive & redo transform.

Would still like it to be very clear when to use each of these values, since auto-values used to be an exception and now this is using both values and values_final together in a way thats easier to mix-up.

source/blender/editors/transform/transform.h
665–672 ↗	(On Diff #16782)	It wouldn't hurt to be a bit more explicit about when each of these is used. Which has snapping applied, number input applied, constraints applied? What space are they in? That the final version is used as input when the flag is set.
672 ↗	(On Diff #16782)	Should be `values_final` for consistency, same for flag.
771 ↗	(On Diff #16782)	Even though auto-values didn't have comments, this could, 1-2 lines explaining why it's needed.