RotateCamera speed (lookaround) - possible tweak?

Serengeti (Rhino WIP)
1

Hi @Pascal,

We have been running into this rotation problems every now and then but could not pinpoint or understand the behavior. I think I got it now and will try to explain:

When rotating with Ctrl+Alt+RMB, the perceived “speed” depends on the lens length (wider lens=slower speed).
This becomes an issue when working with zoomed-in cameras. At some point the pan becomes unusable because it is way too fast.

You can test it out in the attached file. Try Ctrl+Alt+RMB rotation - you will see a big difference between V1 and V3.
Pan_speed_sample.3dm (76.6 KB)

The constant speed would be much better/desired behavior and would feel most natural. It seems like “under the hood”, the camera rotation angle could be screen-movement-dependent, and not global, if it makes sense.
Imagine that the rotation angle is driven by the pixel distance on the screen, and not constant angle-per-pixel…

@Mikko - is that something you can comment on?

cheers,

–jarek

1 Like
2

Hi Jarek - Yeah… I get you - I’ll make a bug track item so that it gets on someone’s list - it may be Mikko’s.
https://mcneel.myjetbrains.com/youtrack/issue/RH-40927

thanks,

-Pascal

3

Hi Pascal,

Thanks, don’t see the YT item, but if it is of any help, I made a quick test of the camera rotation based on screen-space mouse movement, so the speed is not dependent on the lens. Would be great if Ctrl+Alt+RMB behaved like this.
It shows well with the above test file and various lens lengths.

LensIndependentConstantSpeedCameraRotation.rvb (793 Bytes)

–jarek

4

hi @Pascal, thanks for adding this to the pile!
If not too much trouble would could you make it public on YT?

–jarek

5

Yep - done - shout if I mis-represented…

-Pascal

1 Like
6

Hi Guys,

I need to revive this old request. With many improvements in Rhino even since, this issue now got promoted to the “top 3” Rhino workflow nuisances over here, and seems like it could be a low hanging fruit to fix.

Let me explain a bit more why this is important and problematic:
In our work, most of the projects and modeling effort is strictly view-based. Obviously while modeling we spin the view all around as everybody else, but once the cameras / named views are set and selected, the model and scene are constantly evaluated from the given view, whether there are more problems to fix, details to add etc.
So in order to keep the camera in place while looking around and at close-ups, the view navigation is a combo of ZoomLens (Ctrl+Alt+Shift+RMB) and RotateCamera (Ctrl+Alt+RMB).
This is where the problem begins - from around Lens=300+, the RotateCamera moves way too fast, and with higher values, which is not uncommon with how we need to work to see model detail, a tiny mouse move rotates the view into the outer space…

I don’t think this is by design, I can’t imagine anyone finds this behavior useful, so hopefully a tweak to make it more intuitive would not create problems somewhere else.

I did my homework to try to figure out where the problem is. It seems like Rhino currently is measuring the screen pixel distance of the cursor movement, and multiplies it by a fixed angle to rotate camera in that direction. Which results in OK-experience in “normal” lens scenarios (10mm-200mm), and really bad experience with higher values: the higher the faster/more unusable.

What seems to work instead for an intuitive camera rotation speed regardless of the current lens value is the “adaptive” angle approach, where the camera rotates by an angle that is connecting previous and current cursor position on each cursor move (Vector: CursorA-CameraPoint remapped to Vector: CursorB-CameraPoint rotation type)

I wrote a quick scripted testing tool to compare both rotation modes, I hope you can check it out:
RotateCameraTest.rvb (3.5 KB)
[LMB-drag to rotate, SPACE toggles the mode, ESC to exit]

Here is a sample test file with NamedViews with various lenses:
RotateCameraTest.3dm (4.6 MB)

This is easier explained visually (follow the cursor movement in relationship to how much the camera rotates in both modes):

@mikko, I am guessing this may be your turf, would it be possible to fix this and implement the intuitive rotation method for the reasons mentioned above? It’s currently a struggle pretty much on every project over here.

thank you,

–jarek