I’m not sure. Rhino for Windows uses a newer 3DConnexion SDK (rather than the ancient system we are using on Mac). @LewnWorx description of the current state is accurate:
and that’s what we’re working to fix. We’re working to move to a newer SDK with Rhino for Mac.
Implementing anything on top of the older system is likely difficult and a distraction from moving to the newer one.
Honestly I haven’t tried that yet I don’t think. Is that new to Rhino 8? 
lol just noticed that’s from 2020 
How come I don’t use that one yet…
sounds like Rhino does have to play ball on this still 
I think just ping somem like ‘Rhino devs’ and just tell them get er done or add to the pile 
It not Rhino’s fault Logitech has a monopoly
I’ve patiently waited 14 yrs. So we’re good keep up the good work. We’ll get there eventually. Maybe when Logitech’s patents run out
Those look like 3dconnexion’s dialogues 
I gave up on macs a long time ago…
almost spit out my coffee, but cup was empty atm… brb
Just as a clarification, here is an example of the Fusion360 settings on macOS with the desired orbiting feature:
Thanks a lot and all the best for the development!
A newer SDK would then also improve the implementation of the CADmouse right?
I’m not sure. What would you expect to improve? (What is not working now with the CADmouse?)
this is what their official website says:
All features marked in red dont work on macOS in Rhino according to 3DConnnexion. We just got two SpaceMouse Pro and CADmouse for the office, so I can only report back in a week or so, but it does not look good rn.
Thanks. This makes it more clear what your expectations are. I have and use the CADmouse daily and I didn’t know what I was missing. It works great for me, but I admit that I’d never attempted to use these features.
Once we have a working prototype using the newer SDK to test with, let’s circle back here and see what is still missing (if anything).
Yes, sometimes there is a kind of allegory of the cave situation… I am switching between Windows 20% workstation and Mac 80% and therefore I notice the differences often.
All those shortcuts are one of the main features 3DConnexion is advertising, they even warned me on the phone support, that they are not working on macOS in Rhino and gave me the link mentioned above.
FYI: I’m tracking an overview of these issues in:
RH-82156 3DConnexion features missing in Rhino for Mac
I’ve searched Discourse and YouTrack (our bug tracker) for issues relating to this and I think I’ve captured most of them as bullet items here. My current plan is to revisit this list once we have something new to test and then work iteratively from there, logging separate bugs for those that do not work.
I mostly use the one with only two buttons on it. I gave up trying to use all those feature types along time ago. The only two buttons I use are incase I want to pull up the mouse settings lol.
Someday I might try getting all crazy custom settings again, but I found that technique only lasts for short periods of time until something breaks due to updates or incompatibilities
‘named rotation points’ has always been missing. I think Alibre design and CATIA are some of the only CAD’s I’ve ever seen use that strategy.
But alibre design still to this day lacks major perspective, so I never use the two licenses we have here.
I’m all in on Rhino these days. 
I certainly hope so.
Been using some variety of 3D Connexxion rig since almost the beginning of time. My first one didn’t have a puck, it was a sorta ball on a stick that hooked up with an external power supply and a DB9 to an RS232 serial port which I used in ProE back when it was still ProE and just the ProMold add-on was well worth the price of admission. (yeah, I’m that old).
At any rate, the buttons mapping dialog has never really worked, on my Pilot Pro a couple of the buttons respond and on the enterprise a couple other ones respond.
the push and hold views have never worked right (I kludge around those by having the 3d Connexion driver send macros:
Those look like this:
Which I then have aliases in Rhino to catch and do what the buttons should “just do”:
However the real real real miserable bitch is the puck itself.
For an eternity, I’ve felt like 3DConnexxion has had the axis’s ass backwards.
Right and left is find but up/down/in/out to me are reversed.
You look at you monitor in the xZ plane. therefore the stuff at the top of the window should reflect that, and intuitively if you held planted the puck on the screen with the knob facing you, you’d move it to the right to go right, left to go left, up to move the view up and down to move the view down.
This TRANSLATES to PUSH AWAY in (i.e. up Y) in the puck’s local XYZ space to up in the monitor’s view, (knob facing up being the pucks Z axis) and PULL towards you to go down in the monitors view.
Therefore the zoom in and out is up and down on the puck as you’re “pushing in” to the display and “pulling out” to zoom out.
From the first time I used one (and its silly little “teacup” trainer app, it always felt absolutely counterintuitive with the defaults as the axis’s don’t match physical realty (again the the notion of sticking the whole contraption on the screen.
So I’ve always had to reassign the axises manually to get the desired affect, and ever time I’ve had to reinstall rhino or do something related, I’ve had to go back in and set all that stuff back up.
Until recently. I dunno if Rhino’s changed, or 3DConnexxion has, but at some point relatively recently, I found that everything was acting “inverted” again, and by undoing the axis remapping for the first time in an eternity the puck just worked correctly, and this has always been a Rhino specific thing, as Fusion, Inventor, Autocad and others have had the right orientation out of the box.
There is however, one thing that’s still super annoying which is the whole Gymbol lock thing.
Say you’ve got something near the XY axis and it’s near the zero point of the z plane, and for whatever reason you wanna flip it over typically to select something.
So you zoom in on it and either tilt the puck in the X or Y axis to rotate the view around you. While it will “work” and you can flip it over once inverted? IT gets real weird once you get past a 270 degree rotation. For example if you flip it about the Y axis (by tilting right or left on the puck. Ok fine it’s inverted, but now you want to continue to cruse around the thing further in the same direction.
You tilt again and instead of it continuing the rotation around the y axis it just sort of does an off kilter wobble in a really odd fashion.
Going all the way back to my early days in animation a few decades back, the Electric Image guys dubbed the phenomina Gymbol Lock and it had something to do with the Quaternion math getting funky.
That’s another one that’s Rhino specific (AFAICT) as it doesn’t happen in Fusion.
Now most of these, I’ve gotten used to over the years and I know the quirks, but as you point out, periodically there’s some update or something that Kinna breaks em and I have to go back and rework the stuff.
As a result I don’t leverage the other buttons outside of the views (and “FIT”) nearly as much as I might be able to.
For whatever reason I can’t get the tilt disable button to work at all on my pilot pro (although It does work fine on the enterprise.
ProE had it way back in the day, but I haven’t used it in a good decade so I have no idea if it still exists in Creo, as I don’t use that either, as these days it’s just Rhino and Fusion, and of the two I far prefer Rhino except for the missing parametric stuff and when for that I grudgingly put up with Fusion’s wonkiness.
What I can say, though is the 3DConnexxion stuff is so muscle memory ingrained that on the very rare occasion when I have to hop on Rhino without “the knobs” I’m beyond lost.
Never used a space mouse as I’m just as hardcore about the “big ball” Kensington trackballs, and just as lost with a normal mouse. Anytime I gotta get on a plane and know I’m gonna be in CAD land I gotta drag all that crap with me or I’m utterly useless.
So I’m cautiously hopeful that maybe someday before I go on social security (hit 60 last week) this stuff might finally, actually work right. It’d sure be nice.
Are there developments in the 3DConnexion Mac field? The main thing I am asking for is at least the option to orbit around a center object, as mentioned above…
Additionally it would be great if that center orbit option would also work with Grasshopper geometry that has not been baked yet (This currently also does not work in Windows)
Also: the space mouse orbit does not work at all when one has the Grasshopper window active. One has to first click into Rhino and then orbit, this is a bit cumbersomse
No developments to share just yet, but this is an active area of development between 3DConnexion and McNeel right now. As usual, slow progress…but progress. Stay tuned.
got it, thank you.
Please consider the two additionally mentioned points (orbiting when only GH window is active and orbiting around GH geometry) as well
Please consider a ‘rotation point list’. The user can benefit greatly from actually having the ability of deciding and naming specific locations of rotation points. imo.
i know it’s probably a big factor, and might turn the camera frustum behavior characteristics on it’s head. but that’s a whole nother thing too.
Hi all.
I got a friend working on Rhino 8 with a 3dconnexion spacemouse, on Mac.
He said the settings page is really small, with almost no controls…
When he move the object in normal situations, everything is good, compared to being on windows… but when he rotate the view upside-down (so the Z axis pointing down in screen space) the left-right rotation is reversed!
Is this happening to anybody else?
There is a fix?
On windows in any situation the movements behave always the same, regardless of the orientation.
Thanks in advance.
Yes
Same here.
I guess the rotation is tied to the CPlane not to screen space.
The controls are [still] every limited in MacRhino.
@dan sorry to anny you, but could you confirm these two additional points?
They would enhance my workflow significantly (additional to orbit center object of course)
So here, almost a year later since I last chimed in on this (and in reality I’ve been pinging this whole topic for years now) we apparently still have zero progress.
While I’ve managed to work around some of the stuff via the workarounds already posted above, we still have several annoying issues.
One of which is periodically the view button workarounds just break completely. The way I’ve been doing it for years is to create Aliases (vf for view front, vt for view top and so on) which in turn run a macro that sets the view (or does a zoom_selected for the “fit” button).
Then on the 3d Connexxion side I’ll assign the button to a separate macro created in 3DConnexxion’s driver which types out the alias command in Rhino. So when I hit the “top” view button, the 3DConnexxion driver issues it’s macro (Named Rhino_View_Top) which enters vt, which in turn is the keystrokes for the alias in Rhino that in turn runs the View Top macro in Rhino. Kludgy as hell to set up but mostly works, until it doens’t . Every so often mid session it just all breaks. The incoming “vt” or “vf” alias triggering keystrokes get ignored and the alias doesn’t fire, (about half the time) or the alias fires and the underlying macro it’s tied to doesn’t.
Once this happens I have to essentially redefine everything all over again to get it to work again. This has happened so much, and for so long (I’ve been doing this since either V5 or V6) that I have a notes file I keep with all the crap I have to do to get it all working again saved for those times when I need to do a full “rebuild of this stuff.
Being as its’ been this way for years now, I’m naively holding out hope that it might get fixed before I go on social security, which gives you guys another few years to get it fixed. (And provided it still exists and all our funds haven’t been handed over to the trazillionaires in the form of yet another taxpayer subsidy for the insanely rich, in which case I’ll still be working till I drop dead or get imprisoned for having an opinion that differs from the SanctionedOligarchDoublespeak, whichever comes first).
