Hello all,
Firstly apologies for the long post and thanks in advance if you make it to the end!
A bit of context before I get to the main point… I’m completely new to Rhino, but have been a daily user of other 3D software for many years (Vectorworks, C4D etc), so pretty competent in a 3D CAD environment. I just wanted to mention this in the hope of filtering out any ‘noob doesn’t get it’ type responses!
Just want to say… the ability to own a perpetual license in today’s software economy is an absolute dream and I really hope to get to love Rhino during my 90 day evaluation period, before I jump ship from Vectorworks.
I’m learning Rhino 8 on an M4 MacBook Pro, but I’m having difficulty fluidly navigating the viewports with both Magic Mouse and trackpad. I’ll try my best to describe the issues here (I’ve done a fair bit of googling and forum trawling but had no luck finding any solutions).
Navigation is split between Panning, Rotating and Zooming. There seems to be two methods to use these actions to navigate the workspace:
-
Magic Mouse scrolling/swiping/gestures with Shift/CMD, and
-
Click and drag RMB (2-finger click on trackpad) with Shift/CMD.
-
MM scrolling/gestures feels much more intuitive and user friendly, but with undesirable navigation behaviour
-
RMB navigation is slightly more awkward, but behaves in a desirable way (except zooming).
Panning:
Panning using either method works as expected.
Desired action and behaviour: as is, works great.
Rotating:
When rotating by MM scrolling/swiping, there doesn’t seem to be any logical pivot point that the camera rotates around, it seems to find an arbitrary point in space which is not user definable. This makes it difficult to orient the camera relative to the model you’re working on. Also, occasionally when using method 1, the pivot point unexpectedly centres to the camera which results in the camera position becoming fixed, and any subsequent rotating rotates the camera and not the view. It seems like this odd behaviour is triggered by holding the option key and then scrolling to zoom. The only way I’ve found to remedy this is to use zoom extents command, which resets the orbit behaviour.
When orbiting by clicking and dragging RMB, the camera rotates around whatever point on the model the cursor was hovering over. For me, this is exactly the behaviour I would like, but I can’t see any settings to attribute this behaviour to method 1 (scrolling/swiping - not just RMB). I can’t understand why this rotating behaviour differs between scrolling versus RMB. it seems as though RMB engages a command, whereas swiping doesn’t.
Desired action and behaviour: simply use scrolling/swiping to orbit the model, with the pivot point specified by cursor position (as it does by using RMB). If this isn’t possible because of a need to click to start the rotate process, then being able to use Option key would be a good alternative.
Zooming:
Using method 1, camera movement only zooms to the viewport centre, which isn’t helpful unless what you want to zoom in on is exactly in the middle of the frame. Using method 2 however (RMB click-and-drag), zooms to whatever the cursor is hovering over. This would be the desirable behaviour, except that the zoom direction doesn’t correlate with method 1 when zoom scale factor is more than 1.00. The result is that when scrolling to zoom, scrolling down pulls the model towards the camera, but when using RMB and dragging down, it pushes the model away from the camera. This is particularly unintuitive, and as with rotating, it doesn’t make sense that there are two differing and conflicting behaviours to do the same thing.
Desired action and behaviour: CMD+scroll zooms to cursor location. Scroll down zooms in, scroll up zooms out.
I hope this makes sense, it was quite difficult to put it into words! I also hope this doesn’t come across like I’m bashing Rhino, I’m really keen to leave Vectorworks’ extortionate subscription plan to adopt a new program, this navigation issue just feels like quite a sticking point for me at this stage.
It would be great to hear from McNeel folk with any insights.
Thanks again,
Calum
