I’ve noticed that after I select a surface with the Auto Cplane feature on that the Spacemouse gets sort of stuck, not allowing full rotation of the object even after the cplane is released. The only work around I’ve noticed is to use the Setview command and set it back to “Perspective” again.
Trying to rotate an object while using the Spacemouse, while in perspective mode and viewing from the top or bottom doesn’t really work.
There is a bug that will lock the rotation, but I recommend you have this particular setting (above) turned off.
The hurdle for the bug is to use the ‘regular 2D mouse’ to click in the workspace at a ‘blank area’, momentarily, to trick Rhino and bypass the glitch.
Sometimes, the glitch is so bad you have to use the ‘regular 2D mouse’ to actually rotate the view (the old fashion way) before the ‘super advanced complicated 3D mouse’ will rotate normally again.
It’s unfortunate that the developers keep putting their 3D mouses on the shelves to collect dust. Or maybe this bug would have been fixed 10 yrs ago.
It seems as though that option doesn’t really change that problem. For some reason, I’ve never noticed it before. Right now, however, it seems front and centre. Very strange.
Basically if, while in perspective, you look straight down or up at your object it just… won’t rotate.
Almost like having your power steering lock up. lol!
Yes, I’m very familiar with this particular behavior. The hard part is explaining the intuition with how to deal with it.
It would be nice if Rhino was just more compatible with the 3D world of navigation to begin with.
Basically, if you put aside the odd scenarios where certain commands may end up locking the rotation until you click on the workspace with regular mouse, you then have to understand that even though you uncheck the option to “always pan parallel views” Rhino will still lock the rotation when you do something like ‘say execute the (plan) view command’.
But, once you execute the (rotate) view command and rotate using regular mouse, then the (super advance mouse that hardly anyone still knows how to use or make Rhino work well), will then finally work again. I like teasing Rhino about 3D mouses
Rhino is pretty much all I know, I’ve been working with it since Rhino 5 was launched and nothing else… Except a little bit of blender for random things.
So basically, we’ve landed on; “That’s just how it is”?
Yep. I’ve been dealing with it since, V4/V5. And like I said I’m pretty sure it got worse in V5.
Although, I’m not sure what you’re after here. I might be confusing something.
The moment you do something like “go to top view”, I’m pretty sure that’s similar to “plan-ing” the view, which will cause a scenario whereby the 3D mouse wont ‘rotate’ the view until you do so with the 2D mouse first.
Regardless of whether the “always pan parallel views” is off, the commands themselves that do things like “plan” the view, will cause the lockup.
Hence, bug.
It’s like Rhino forces you to only be able to pan “planned” views, until you invoke the “rotate view” feature, but Rhino also prejudice-ly locks up the 3D mouse, cause we live in flat-land or something.
Yeah, idk, this sounds like a less precise view angle (relative to “top”) for two reasons – 1 the view isn’t ‘parallel’ if it’s not ‘perspective’ and 2 the view is rotated an arbitrary amount ‘from the top’…
Not meaning to question your technique, just not sure what you’re seeing exactly.
It is true that the ‘lock effect’ does also happen without the view being ‘parallel’ but instead being ‘perspective’, so maybe that’s closer to the scenario you’re seeing.
This is potentially a different scenario whereby your brain is interpreting an optical illusion and is seeing the rotation backwards on the screen from what the computer is actually showing you.
Although, I’ve argued with colleagues about this, they always say the computer is doing it wrong, but I always say their brain is seeing it wrong
I’ve experienced this effect plenty of times. And still to this day, I believe it’s our brains playing tricks on us.
But, I suppose it’s possible the computer messes up and does exactly what it appears to do i.e. ‘rotate backwards’.
However, every time I’ve experienced it I usually will slow down the rotation on purpose and ever so slightly wait for my brain to see it correctly. And in doing so, you’ll notice it’s just an optical illusion – imo.
I believe I’ve seen that same illusion in other programs too like CATIA, but it’s been a whille since I’ve tested that.
I think I have just been staring at this way too long this evening and trying to just get a feel for it. Either way, it seems slightly more aggressive of a lockout than in Rhino 7.
I’ll report back after I actually do some modelling, rather than just messing with the new features.
Yeah I think sometimes we hurdle over issues subconsciously, I remember dealing with this exact issue smoothly until a colleague brought it up like 2009 for the first time and I had to explain it in words for the first time. Then all a sudden it was a bigger deal than I originally thought lol.
But yeah, Rhino’s 3D mouse navigation behavior has always been clunky – imo.
You don’t really notice the nuances until you contrast different programs.
For me it was very obvious something was wrong with Rhino in 2008 when I was already so used to other higher end CAD’s at the time – Rhino for me was very hard to get used to.
The funniest one is when I bring up to ppl the scenarios of moving both the 3Dmouse and the 2Dmouse simultaneously – the ppl jus say ‘why would you ever do such a thing’
I’d do that very thing all the time in CATIA, and once I started using Rhino it was a major problem.
I had to train my brain to stop touching the 2D mouse completely every time I touched the 3D mouse – it drove me crazy lol.
Yup, after doing some regular modelling, I can confirm that the navigating with the space mouse is a lot more sticky than it was in version 7. It really starts to lock up the closer you get to a top down or bottom up viewing angle.
Hi
not sure I understand [I didn’t read all of the above conversation ]
But since I can’t see here any issue similar to what you are describing …
Have you unchecked Auto CPlane? It’s not very helpful in most cases.
One thing I set up that I like a lot [for jewellery closeup navigation]. is to use the Rotate Parallel Views option in the 3Dconnexion setting.
Certain situation behave much nicer [when rhino does not need to calculate the perspective distortion]
especially very close up zoom that can feel bogged down in perspective.
[you can make a tool button to toggle it]
That’s a really good point. I think I forgot to mention that
It’s one of those redundant and conflicting parameters that you think Rhino handles but then Logitech tries to sorta handle or something
But the bug I mentioned above, I bet is still propagated into the R8 release, sadly. I’ll have to investigate.
Sounds like you’re describing that proverbial ‘quicksand’ effect when the camera frustum’s target gets to close to the camera iris and gets sticky. That’s probably in R8 as well.
Another example here of the redundancy I mentioned, make sure this command doesn’t have the horizon locked: