Page MenuHome

Numeric input for rotational transform resolves to modulo 360. Should it?
Closed, ArchivedPublic


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.

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.


To Do

Event Timeline

Sam Brubaker (rocketman) set Type to Bug.
Sam Brubaker (rocketman) created this task.
Sam Brubaker (rocketman) raised the priority of this task from to Needs Triage by Developer.

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

Bastien Montagne (mont29) triaged this task as Normal priority.May 12 2014, 10:14 PM

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)

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?

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 @Antony Riakiotakis (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).

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

1diff --git a/source/blender/editors/transform/transform.c b/source/blender/editors/transform/transform.c
2index b88c388..be9c3cc 100644
3--- a/source/blender/editors/transform/transform.c
4+++ b/source/blender/editors/transform/transform.c
5@@ -3881,10 +3881,7 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2]))
7 applySnapping(t, &final);
9- if (applyNumInput(&t->num, &final)) {
10- /* Clamp between -PI and PI */
11- final = angle_wrap_rad(final);
12- }
13+ applyNumInput(&t->num, &final);
15 if (hasNumInput(&t->num)) {
16 char c[NUM_STR_REP_LEN];
17@@ -3902,10 +3899,23 @@ static void applyRotation(TransInfo *t, const int UNUSED(mval[2]))
18 ofs += BLI_snprintf(str + ofs, MAX_INFO_LEN - ofs, IFACE_(" Proportional size: %.2f"), t->prop_size);
19 }
21- t->values[0] = final;
23- applyRotationValue(t, final, t->axis);
25+ /* We have to split rotation in ~170° steps, bigger steps won't work well.
26+ * This is not an issue with dragged-rotation, since it is called usually with much smaller steps.
27+ * But when using numinput, without that user cannot get rotations > (-180, 180).
28+ * See T40167.
29+ */
30+ {
31+ const float sign = (final < 0) ? -1.0f : 1.0f;
32+ const float step = DEG2RADF(170.0f) * sign;
33+ float virtual_final;
34+ for (virtual_final = t->values[0] + step; (final - virtual_final) * sign > 0.0f; virtual_final += step) {
35+ t->values[0] = virtual_final;
36+ applyRotationValue(t, virtual_final, t->axis);
37+ }
38+ t->values[0] = final;
39+ applyRotationValue(t, final, t->axis);
40+ }
42 recalcData(t);
44 ED_area_headerprint(t->sa, str);

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...

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.

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!

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 (campbellbarton) lowered the priority of this task from Normal to Confirmed, Low.

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

@Bastien Montagne (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.

Bastien Montagne (mont29) closed this task as Archived.Jul 13 2014, 6:59 PM

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