Numeric input for rotational transform resolves to modulo 360. Should it? #40167

New Issue

Sam Brubaker · 2014-05-12T20:14:03+02:00

Sam Brubaker commented

2014-05-12 20:14:03 +02:00

System Information
Version 2.70a official (win 64)

How to reproduce:
Open default scene in Blender, select the Cube, and hit R, {X,Y,Z} to rotate it on an axis.
Enter a large (greater than 360) numeric value and hit enter.
Notice that in the properties side panel (N), the object's rotation transform was resolved to the shortest visual transform. If you entered 720, the transform is 0. if your entered 450, the transform is 90, etc.

Rotation_transform_bug.blend

Is this desirable behavior? I would think that if a user enters a large value for rotation, that's what the user should get. This is especially true for animation when the user wants an object to roll or spin for many revolutions. If the user enters R, Y, 1080, shouldn't it rotate the selected object 1080 degrees?

Having the rotation transform resolve this way also reduces the usefulness of the new modal input. Let's say a user animates a rolling ball of radius rtravellingdblender units. Assuming that radians are being used, to set the rotation, (s)he could simply employ modal input and enterd/r. But no matter what expression the user tries to enter, the transform is always reduced in spite of how large it is.

I'm sorry to file this UI proposal as though it were a bug, but I propose that this "feature" be removed. The user should get what the user enters, not (what the user enters)%360.

**System Information** Version 2.70a official (win 64) How to reproduce: Open default scene in Blender, select the Cube, and hit R, {X,Y,Z} to rotate it on an axis. Enter a large (greater than 360) numeric value and hit enter. Notice that in the properties side panel (N), the object's rotation transform was resolved to the shortest visual transform. If you entered 720, the transform is 0. if your entered 450, the transform is 90, etc. [Rotation_transform_bug.blend](https://archive.blender.org/developer/F88699/Rotation_transform_bug.blend) Is this desirable behavior? I would think that if a user enters a large value for rotation, that's what the user should get. This is especially true for animation when the user wants an object to roll or spin for many revolutions. If the user enters R, Y, 1080, shouldn't it rotate the selected object 1080 degrees? Having the rotation transform resolve this way also reduces the usefulness of the new modal input. Let's say a user animates a rolling ball of radius ***r***travelling***d***blender units. Assuming that radians are being used, to set the rotation, (s)he could simply employ modal input and enter***d/r***. But no matter what expression the user tries to enter, the transform is always reduced in spite of how large it is. I'm sorry to file this UI proposal as though it were a bug, but I propose that this "feature" be removed. The user should get what the user enters, not (what the user enters)%360.

Sam Brubaker commented

2014-05-12 20:14:03 +02:00

Changed status to: 'Open'

Sam Brubaker commented

2014-05-12 20:14:03 +02:00

Added subscriber: @rocketman

Bastien Montagne self-assigned this 2014-05-12 22:14:15 +02:00

Bastien Montagne commented

2014-05-12 22:14:15 +02:00

This is not a feature at all, more like internal limitation… :/

Antonis Ryakiotakis commented

2014-05-13 01:50:09 +02:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2014-05-13 01:50:09 +02:00

I've looked a bit into that. While delimiting the number is easy, finding which axis is the unbounded one in an euler representation is not.
For quaternions, which are the de facto tools for animation this makes even less sense actually because they do not support such big rotations. So to recap, in our current rotation transform this only really makes sense for axis-constrained rotations from an initial rotation of zero. I'd say that people could actually define such rotations through the transform fields directly anyway.

Final note: The reason this works in manual transform is that the tool searches for the closest previous euler to the current. However, again this is not guaranteed to be meaningful (as I mentioned above, if you try from a rotated initial position, you can't really predict the outcome easily, even in a constrained rotation)

I've looked a bit into that. While delimiting the number is easy, finding which axis is the unbounded one in an euler representation is not. For quaternions, which are the de facto tools for animation this makes even less sense actually because they do not support such big rotations. So to recap, in our current rotation transform this only really makes sense for axis-constrained rotations from an initial rotation of zero. I'd say that people could actually define such rotations through the transform fields directly anyway. Final note: The reason this works in manual transform is that the tool searches for the closest previous euler to the current. However, again this is not guaranteed to be meaningful (as I mentioned above, if you try from a rotated initial position, you can't really predict the outcome easily, even in a constrained rotation)

Sam Brubaker commented

2014-05-13 15:36:02 +02:00

Thanks, devs!

Perhaps the input could be de-limited only in actions for which it is appropriate. But for what it's worth, I'd rather be able to break something than have to deal with artificial restraints. That's more like the spirit of Blender, right?

Thanks, devs! Perhaps the input could be de-limited only in actions for which it is appropriate. But for what it's worth, I'd rather be able to break something than have to deal with artificial restraints. That's more like the spirit of Blender, right?

Bastien Montagne commented

2014-05-13 15:41:03 +02:00

There is no artificial restraint here… making current code handle rotations over ~180° in a single step just does not work, this is not noticeable with usual drag-rotate (as @Psy-Fi said, each step during such rotation is always way below 180°), but it breaks with numinput. Matrices or quaternions are just not made to support such behavior.

Would not consider this a bug, though, more like an internal limitation (will tweak the output text to make it appear in user feedback).

There is no artificial restraint here… making current code handle rotations over ~180° in a single step just does not work, this is not noticeable with usual drag-rotate (as @Psy-Fi said, each step during such rotation is always way below 180°), but it breaks with numinput. Matrices or quaternions are just not made to support such behavior. Would not consider this a bug, though, more like an internal limitation (will tweak the output text to make it appear in user feedback).

Bastien Montagne commented

2014-05-13 16:48:38 +02:00

Added subscriber: @ideasman42

Bastien Montagne commented

2014-05-13 16:48:38 +02:00

Humm… in fact it is possible to hack around this, by forcing rotation steps below 170° or so… See patch below (@ideasman42 need your advice here, do we want to support that? If yes, would do the same for trackball too).

P61: #40167

diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c
index b88c388..be9c3cc 100644
--- a/source/blender/editors/transform/transform.c
+++ b/source/blender/editors/transform/transform.c
@@ -3881,10 +3881,7 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2]))
 
 	applySnapping(t, &final);
 
-	if (applyNumInput(&t->num, &final)) {
-		/* Clamp between -PI and PI */
-		final = angle_wrap_rad(final);
-	}
+	applyNumInput(&t->num, &final);
 
 	if (hasNumInput(&t->num)) {
 		char c[NUM_STR_REP_LEN];
@@ -3902,10 +3899,23 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2]))
 		ofs += BLI_snprintf(str + ofs, MAX_INFO_LEN - ofs, IFACE_(" Proportional size: %.2f"), t->prop_size);
 	}
 
-	t->values- [x] = final;
-	
-	applyRotationValue(t, final, t->axis);
-	
+	/* We have to split rotation in ~170° steps, bigger steps won't work well.
+	 * This is not an issue with dragged-rotation, since it is called usually with much smaller steps.
+	 * But when using numinput, without that user cannot get rotations > (-180, 180).
+	 * See #40167.
+	 */
+	{
+		const float sign = (final < 0) ? -1.0f : 1.0f;
+		const float step = DEG2RADF(170.0f) * sign;
+		float virtual_final;
+		for (virtual_final = t->values- [x] + step; (final - virtual_final) * sign > 0.0f; virtual_final += step) {
+			t->values- [x] = virtual_final;
+			applyRotationValue(t, virtual_final, t->axis);
+		}
+		t->values- [x] = final;
+		applyRotationValue(t, final, t->axis);
+	}
+
 	recalcData(t);
 	
 	ED_area_headerprint(t->sa, str);

Humm… in fact it is possible to hack around this, by forcing rotation steps below 170° or so… See patch below (@ideasman42 need your advice here, do we want to support that? If yes, would do the same for trackball too). [P61: #40167](https://archive.blender.org/developer/P61.txt) ```diff diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c index b88c388..be9c3cc 100644 --- a/source/blender/editors/transform/transform.c +++ b/source/blender/editors/transform/transform.c @@ -3881,10 +3881,7 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2])) applySnapping(t, &final); - if (applyNumInput(&t->num, &final)) { - /* Clamp between -PI and PI */ - final = angle_wrap_rad(final); - } + applyNumInput(&t->num, &final); if (hasNumInput(&t->num)) { char c[NUM_STR_REP_LEN]; @@ -3902,10 +3899,23 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2])) ofs += BLI_snprintf(str + ofs, MAX_INFO_LEN - ofs, IFACE_(" Proportional size: %.2f"), t->prop_size); } - t->values- [x] = final; - - applyRotationValue(t, final, t->axis); - + /* We have to split rotation in ~170° steps, bigger steps won't work well. + * This is not an issue with dragged-rotation, since it is called usually with much smaller steps. + * But when using numinput, without that user cannot get rotations > (-180, 180). + * See #40167. + */ + { + const float sign = (final < 0) ? -1.0f : 1.0f; + const float step = DEG2RADF(170.0f) * sign; + float virtual_final; + for (virtual_final = t->values- [x] + step; (final - virtual_final) * sign > 0.0f; virtual_final += step) { + t->values- [x] = virtual_final; + applyRotationValue(t, virtual_final, t->axis); + } + t->values- [x] = final; + applyRotationValue(t, final, t->axis); + } + recalcData(t); ED_area_headerprint(t->sa, str); ```

Antonis Ryakiotakis commented

2014-05-13 16:55:56 +02:00

I was thinking about this too. It's ultra hacky and better only enable for numeric input if we do...alternative I was thinking of is to find the axis with the greatest euler contribution and somehow factor it in t->ext->rot so the closest euler matches. Math magic is required there of course and this might break in other non-trivial cases...

Bastien Montagne commented

2014-05-13 16:59:45 +02:00

Well, in case raw 'final' value is < 170°, there is no changes anyway…

And I’d rather keep it simple and predictable, or not do it at all. Current patch simply mimics what would happen if we where reaching e.g. '400°' by mouse-grabbing instead of direct typing - so gives nice predictable results, also consistent with what you get with mouse rotation.

Well, in case raw 'final' value is < 170°, there is no changes anyway… And I’d rather keep it simple and predictable, or not do it at all. Current patch simply mimics what would happen if we where reaching e.g. '400°' by mouse-grabbing instead of direct typing - so gives nice predictable results, also consistent with what you get with mouse rotation.

Antonis Ryakiotakis commented

2014-05-13 17:04:41 +02:00

It's just computational overhead, especially for very large rotations or many elements (OK, not that common a case, I know). But rotation code is hacky and dirty already so I guess...why not? Hur, hur hur!

Fazekas Laszlo commented

2014-05-14 08:33:19 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-05-14 08:33:19 +02:00

Calculated only once when the you press the Enter so maybe it is not so confusing to wait. It could be useful for some animation cases.

Campbell Barton commented

2014-05-15 07:15:25 +02:00

Added subscriber: @mont29

Campbell Barton commented

2014-05-15 07:15:25 +02:00

We had users notice this before, its not a bug really.

@mont29 - assume your proposed change only works in some cases.

Its probably redundant for edimode and objects with quaternion rotation.

the fix seems a bit hackish, but its not easy to do this correctly either.

We could have applyRotationValue calculate the number of times to apply the rotation, then use a clever method to extrapolate those values when applied to a euler.

Set as TODO, we better not attempt this kind of change before release.

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Transform

We had users notice this before, its not a bug really. @mont29 - assume your proposed change only works in some cases. Its probably redundant for edimode and objects with quaternion rotation. the fix seems a bit hackish, but its not easy to do this **correctly** either. We could have `applyRotationValue` calculate the number of times to apply the rotation, then use a clever method to extrapolate those values when applied to a euler. Set as TODO, we better not attempt this kind of change before release. http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Transform

Bastien Montagne commented

2014-07-13 18:59:33 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2014-07-13 18:59:33 +02:00

Bastien Montagne commented

2014-07-13 18:59:33 +02:00

Closing this task, it’s now listed in our TODO list on wiki, no point in keeping this one open. :)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Numeric input for rotational transform resolves to modulo 360. Should it? #40167