A longtime bug in the 3dConnexion spacemouse controller within Rhino is in the “helicopter” mode. There seems to have been some attempt to allow zooming into surfaces by moving towards them but this is not consistent with other software. If whoever implemented this is available to make a small change I’d request: Camera movement within rhino should be in simpler relation with the spacemouse input. That is, translations should create a translation of the camera and target; rotations should rotate the target about the camera. There should be no understanding of context or what you’re pointing at the way there is with the scroll wheel zoom.
AFAIK 3DConnexion maintains the controller themselves.
I’m not sure if I follow what you’re talking about, but from my experience
Helicopter Mode doesn’t have a focus point like
Target Camera Mode has.
Object Mode is a mode I don’t really like, I’ve never really learned to control that properly (controls feel backwards in my mind). My favourite is
Camera Mode since that will do exactly that, translate device input directly into a useful camera (viewport) motion just like you’d be moving the camera around.
For the other modes you can set how the
Rotation Center is set, by default it is on
Auto, but you can change that. Perhaps you need to find the correct combination of settings that work well for you?
Personally I have found navigating using the
Camera Mode fit my usage best, I haven’t really noticed any jerkiness even with
Raytraced mode on. With
Speed set relatively high it is quite nice to fly through scenes with the device.
P.S. I have a SpacePilot Pro
I agree. Object mode and its equivalent in other software always seems backwards to me. I’ve talked to others who feel the same way. Camera mode and Helicopter mode are almost the same. Helicopter translates XY motion to WorldX and WorldY motion while camera mode will translate XY motion into CameraX and CameraY movement. Not much difference but I prefer helicopter since its easier to stay at a single elevation moving around architectural models.
Here’s a video of what I’m talking about. I’m doing my best to move at a constant speed up to and through a small box. See how the camera slows to a stop and then pops through the surface? It doesn’t happen on the second time but does on the 1st and 3rd. Also I have rotation center Auto off and this was done in camera mode.
I’ll reach out to 3dConnexion as well.
That looks weird indeed. I was about to record what I see here, but then I realised I’m VNC’ed into the machine to which the device is attached, so that’ll have to wait till tomorrow. But from what I can recall from my tests today with the SpacePilot PRO the behavior you described didn’t happen for me.
With no response from 3dconnexion yet is there any way to confirm this would be in their driver and not something in the Rhino source?
I realized that I haven’t installed the 3dconnexion driver since I had to re-install Windows 10 (I was on a developer preview build cycle, and that was kinda interfering with my coding work), so I have the device running AFAIK without having the 3dconnexion stuff installed. Perhaps you could try the same?
hmm. I’ll try uninstalling their driver suite and see what happens, but off hand I think the answer is: no spacemouse functionality.
Sorry for the delay on this. I just managed to get @Markus from 3dConnexion hooked into this conversation. He just emailed me this:
I am a bit bogged down at the moment. However, there does appear to be something wrong with the helicopter mode – I suspect it is using the camera target to calculate the speed.
Hey Alexander, I’m looking at your message about the 3d mouse and wondering if you could elaborate on what you mean by "Helicopter translates XY motion to WorldX and WorldY motion while camera mode will translate XY motion into CameraX and CameraY movement. Not much difference but I prefer helicopter since its easier to stay at a single elevation moving around architectural models."
Wondering what you mean by “camera x and camera y”? What’s the difference between camera x and camera y and world x and world y?
I use Rhino on architectural models. Some of them have very complicated long corridors, rooms, subrooms etc. I’ve tried Camera mode and noticed that it has the option to Lock the Horizon. I then tried Helicopter mode and noticed that the Lock the Horizon option is greyed out. Is that maybe because the Horizon is locked automatically in Helicopter mode?
my explanation was a little weird. its an easy difference. if youre looking
straight up and push forward on the mouse one mode moves you forward the
other moves you up. camera x was to refer to the direction the camera is
facing. just try the two modes out and see the difference. since my models
are architectural i always have horizon lock on.
@Alexander_Kaplan, are you still able to repeat the “jerkiness” you originally described with the current WIP? Our testers here are not able to repeat what you were experiencing (which makes it difficult to figure out what to fix…).
Trying now to reproduce it it’s not as bad. The camera still seems to slow down as you get close to surfaces, but maybe that’s intentional.
To reproduce: A vertical plane at the origin, a long lens length in perspective, e.g., 110, and Camera:Show. Moving at a continuous rate through the plane and watching the camera in the top view I can see the camera slow as it approaches the plane (sometimes stopping) then accelerating once it makes it through the plane. In bigger models this makes it hard to, for example, move into and through small objects.
If nobody can reproduce this I’ll chalk it up to user error. I don’t have any way of applying exactly contiuous pressure to the space mouse so it’s hard.
Thanks for the feedback,
Hi Alexander - I can reproduce this, somewhat, with the long lens - the thing does slow down, but here once through the plane, it speeds up again smoothly- if I stop and start the forward progress after passing through the plane, it speeds up quite a bit.
Yes that’s all I’m seeing now too. It seems like there’s some smoothing on the speed that wasn’t there before? Maybe not. I suppose I don’t understand why the movement wouldn’t be totally smooth.
Can you make the video available again, please.
@Alexander_Kaplan, can you make your video available again?
Yes, I will do so as soon as possible.
Can’t confirm that this still happens. Need to update my WIP.
This still happens in current WIP. I see this behavior too. For some mode(s), it seems to happen close to world axis, too.