3d Connexion Inconsistencies - TD 32820 W11 25h2

Hi guys,

Smth has been bugging me for a while now: depending on models of 3d connexions 3D mouse controllers, it doesn’t react the same: in Joystick Chop when usign SpaceNavigator (as it appears in the menu) it behaves as expected (latch) - when you release the mouse, it stays on the last position. This is the old wired model of Spacenavigator. The new wireless model (with the dongle) behaves completely differently and unusable - ( similar to touch mode in DAW) - when you release the button it goes back to initial position.

The weird thing is that in Geometry COMP the viewer it works as expected.

I captured couple of seconds. I didn’t find any options where I can modify it.

Video Project (1)

1 Like

I’ve been using a Speed CHOP as a workaround with my bluetooth SpaceMouse.

Inside of of CameraViewport I drop a Speed CHOP after the Joystick CHOP & then reference that Speed CHOP in the Execute.

That’s brilliant, Brad! I was thinking about doing that also, a little bit hacky, but works. I just don’t see any reason that it works in the geometry viewer, but doesn’t work with Joystick Chop.

Hi @_shandor,

we’ll have a look at this.

cheers
Markus

1 Like

Thanks for the report. I’m not sure why the two models are working differently, but I can at least explain why the Joystick CHOP and the geometry viewers are different.

On Windows, the Joystick CHOP uses Microsoft’s Direct Input library to handle all types of devices, so we’re not doing anything specific for the spacemouse there. We just get the data the library provides, so I’m guessing that the spacemouse is sending information differently to that library.

For the geometry viewers in Geo Comps, POPs or SOPs we are using 3d Connexion’s spacemouse library directly which sounds like it handles the different devices properly.

I don’t know if this would work for you, but have you tried using the Joystick CHOP after disabling the spacemouse driver? We recently found issues on MacOS where the Joystick CHOP only works properly when the driver is disabled.

1 Like

Hi Rob,

Sorry for replying only now on your very informative and detailed post. I was actually waiting to have both devices - wired and wireless at the same location to test the differences.

It’s all confirmed. For some reason, when you choose 3D Universal Receiver in the Joystick Menu, it behaves differently from SpaceNavigator and every movement resets to 0 whereas wired version - when you choose SpaceNavigator in the menu - behaves by incrementing values. Speed Chop and some Lag pretty much fixes which is a great workaround.

I don’t understand what you mean - run without 3D driver. When on Windows, I disable 3Dconnexion broker service and closed all the 3D connexion related autoruns, the behavior is still the same.

I’m sure it’s very low on your to-do list (as it should be), just reporting it back.

Thanks

Shandor

Thanks for the extra info, unfortunately it sounds like the different devices are reporting data differently to the joystick input system so I’m not sure if we can compensate for that on our end.

Our best bet would probably be to add native spacemouse support to the joystick chop, but I’ll admit we’ve got a lot of high priority projects in the works now so I don’t know when or if that might happen.

The issue with the driver is hard to test since we only have access right now to relatively old wired spacemouse hardware, but on MacOS we’ve found the joystick behaviour changes depending on whether you have the 3d connexion drivers enabled or not. When disabled, the joystick chop works as expected, but unfortunately the 3d viewer support does not work. When enabled, the viewer works, but the joystick chop resets to zero similar to what I think you’re describing. This seems to be a recent change with their newer drivers.

But MacOS uses different drivers and joystick interfaces, so it sounds like that isn’t very useful for you anyways.

Sorry I don’t have more helpful information now, but I’m glad you at least seem to have a workaround for the moment.