Currently, the rotation value in the Transform effect is limited to the −360..360 range. Allowing for values outside this range would be useful for keyframing when you need to rotate an object by more than two full turns over a period of time. Currently, the only way to do this elegantly is to use the deprecated Rotate and Shear plugin, which can add a rotation offset every frame.
You could add a keyframe at every complete rotation to reset the range …
But you did say elegant, and I agree this is unnecessarily restrictive, I’ve hit it before as well.
It seems qtblend (which implements “Transform”) places no inherent restriction on this other than the value being a double-precision float - but we can’t just drop the min/max values from the spinbox, because if we do it doesn’t spin …
We can make them arbitrarily large(r) though. Like 36000 or even 360000? Is 1000 turns really enough for anybody ;?
@berndmj Thoughts on this? There’s probably a few other effects with rotation values we should see if we can safely allow larger angles for as well.
I checked it and we could allow values exceeding 360 degrees in either direction (the sign just changes the rotation direction). What would be a reasonable value? 3600 allows for 10 full rotations during the length of the clip with just one keyframe, or more with multiple keyframes, of course. Or we go bonkers and set it to 3.6 billion …
Researching this a bit more, I might revive the Rotate and Shear effect for that specific purpose because that is indeed a great feature of that effect. The way it’s implemented is utterly confusing but with a bit of tweaking I might be able to split this into several effects that are easier to use.
1 Like
Probably the only practical reason to use something less than +/-Bonkers is it seems to also control the size of the spinbox, but in the case of Transform space for the rotation field isn’t really a problem.
I guess we should probably figure out some generic stand in values for “unlimited” that we use consistently for fields that don’t otherwise have a hard or intrinsically sensible limit. We do need to pick something because the QSpinBox default range is 0-99, which is its own brand of bonkers, and if we don’t set min/max in the xml it just locks the value to 0.
… is not the problem for Transform, but all the other effects with a rotation have sliders and that is a problem because a small move of the slider results in a big change. We are losing finer control with that (users will use a slider if it’s there instead of entering a value).
My proposal would be to limit rotation parameters to 36,000 allowing for 100 full rotations for the duration of the clip. I will also work on the affine effect to create one that allows to set a rotation per frame. That should cover all possible use cases.
That’s a good point. Even the translation one has a ‘virtual’ slider if you click and drag (or mouse-wheel) from the text box. You can shift drag for finer grained control, or ctrl drag for coarser changes, but still a good reason to keep “Bonkers” to a more practically reasonable number.
My proposal would be to limit rotation parameters to 36,000 allowing for 100 full rotations
That and reviving the uniquely useful bits of affine sounds like a good plan to me, thanks!
Would it possible to limit the field to a smaller range when dragging the slider but still allow for manually entering values outside those bounds?
Not really with the way the Qt UI controls work. Can you think of a case where you might want more than 100 rotations for a single clip? That’s a pretty rapid rate to spin over most sensible durations, enough that you wouldn’t be likely to notice a glitch if you needed intermediate keyframes to do more than that.
… is working 
Need to fine tune the whole thing and make sure it gels with the deprecated version but a MR should be out there soon.
1 Like
That’s pretty unlikely, and I don’t have a need for more than 100 rotations right now, but it might potentially be used for an animation spanning a long period of time, and even if the range for the rotation is only enlarged by a factor of 100, that would mean that the control is 100 times more sensitive to dragging than before.
Affine has its own limitations: you can only control the rate to a resolution of 0.1 degrees per frame, and you can only set a uniform rate (unless the parameter is keyframable? But then it’s sometimes more convenient to specify angles at the keyframes than rates.).
That we can change to 0.01 if needed. And it’s either fixed rotation per frame or keyframed. The former is easier to do but lacks fine tuning, the latter allows easing but requires more manual effort. Pick your poison …