3DConnexion - Connection Breaks Sporadically

[Zaxxon (Zaxxon77)]

Periodically, (but consistently) my SpaceMouse Pro stops working in Rhino 7. I suspect that there is some obscure system level conflict occurring with one of the various other currently running pieces of software that I usually have open alongside multiple instances of Rhino.

Suspects of source of conflict include software that listens to the 3D mouse; Formlabs Preform, a variety of PCB/EDA programs and Gerber viewers, (KiCad, Diptrace etc).

The mouse still works in the other programs - but to get functionality back in Rhino I typically have to restart all sessions. Am not sure if it would be fruitful (given the exponential number of potential unique environmental and software combinational factors), or even absolutely necessary to get at the root of the issue, if only there was a way to re-establish a connection to the device without having to close Rhino, (like a command to re-establish the link) - that would be a huge quality of life improvement.

My SystemInfo

Rhino 7 SR37 2024-4-16 (Rhino 7, 7.37.24107.15001, Git hash:master @ d2e42f70b9d3aa58f6053e2998a0db2abcd7555b)
License type: Commercial, build 2024-04-16
License details: Cloud Zoo

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 64Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1060 6GB (NVidia) Memory: 6GB, Driver date: 6-8-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 536.23
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port 0
- Secondary monitor attached to adapter port 1

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 6-8-2023
Driver Version: 31.0.15.3623
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB

Rhino plugins that do not ship with Rhino
C:\Program Files\Bongo 2.0 (64-bit)\Rhino6\Bongo.20.rhp “Bongo 2.0”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.37.24107.15001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Users\Airtop2\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\PanelingTools\2021.3.2.446\PanelingTools.rhp “PanelingTools”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.37.24107.15001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.37.24107.15001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.37.24107.15001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.37.24107.15001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

[lander (CAD CAM CNC)]

it’s possible it’s related to parallel projection or plan view behavior. but yeah 3d mouses aren’t treated very well by the world yet. devs always putting them on the shelf to collect dust.

[Zaxxon (Zaxxon77)]

@lander

it’s possible it’s related to parallel projection or plan view behavior

Good to know that’s a concern - I’ll keep my eyes peeled for any clues.

@lander

but yeah 3d mouses aren’t treated very well by the world yet

It’s true, yet hard to believe - esp in the increasingly 3D environments we dwell in digitally. I always liken using a just a (standard) mouse to be like to trying to only interact with the work-piece using just a single chopstick - with the other hand tied behind your back, and feet glued to the floor!

At least with a 3D mouse you can “handle” the work, and “walk around” while poking with the chopstick.

[lander (CAD CAM CNC)]

@Zaxxon

I always liken using a just a (standard) mouse to be like to trying to only interact with the using just a single chopstick - with the other hand tied behind your back, and feet glued to the floor!

exactly

@Zaxxon

At least with a 3D mouse you can “handle” the work, and “walk around” while poking with the chopstick.

Ikr.

I think Rhino some day should add a ‘saved rotation points’ list or something.

I heard the gumball can work as a rotation point, but I haven’t explored that yet I don’t think. While I’m skeptical, I hope there’s some cool behavior with it.

I’ll try to add a link to the things I mentioned previously, to add more context… brb.

@Zaxxon

@lander

it’s possible it’s related to parallel projection or plan view behavior

Good to know that’s a concern - I’ll keep my eyes peeled for any clues.

in other words:

@lander

My usual ‘hurdle over the problem’ is to quickly click with the regular mouse into an empty spot in the workspace, in order to correct the glitch.

Sometimes you might even have to invoke a regular rotation with the regular mouse to correct the glitch.

This used to be very frustrating to perform every time to mitigate the issue, but things like this can become subconscious after you do it a million times

It would be great if the world we live in would finally accept the 3D mouses, but they’re still waiting for something …

Well a ‘plan’ view is a parallel view, and the spaceball wont rotate a plan view until it’s rotated with the rotate command and regular mouse, first. So, that’s part of my point, is that option technically is deficient in it’s apparent claim to rotate ‘parallel’ views. And that option is also redundant in that this other option seems to have the same effect: Although, this option might be more related to the ‘regular’ mouse. I did however just notice that even the regular mouse wont rotate …

I’m mostly sharing this info, in case all else fails, because this behavior is basically unavoidable at some point, and I know of other users who might not understand right away that it exists.

Eventually you might be able to isolate it as the pattern becomes more obvious, then maybe we can get the developers to fix it, or unlock it rather. Space mouses deserve to be free

furthermore,

@lander

I did however just notice that even the regular mouse wont rotate the plan view until after it’s been commanded by the rotate command first, only then after will the view rotate normally with the regular mouse.

So maybe the developers are purposely locking up the plan view. There’s definitely better ways of going about this behavior – imo. The lockup is completely unnecessary.

Just a thought. Of course it could be another type of issue, maybe with driver conflicts

[nathanletwory (Nathan 'jesterKing' Letwory)]

@lander

devs always putting them on the shelf to collect dust

Not this dev, I have and use my spacepilot pro daily.

[lander (CAD CAM CNC)]

@nathanletwory

Not this dev, I have and use my spacepilot pro daily.

nice!