search

PatHightree / SpaceNavigator

SpaceNavigator driver for Unity3D
MIT License
173 stars 52 forks source link

Revert to non-HID behaviour? #35

Closed krisrok closed 3 years ago

krisrok commented 3 years ago

hi patrick and first of all thanks for all your work on this codebase!

i guess most of the issues here are related to accessing the hid directly and there being too many (slightly) different devices on the market?

previously, in our team we used the old (driver-dependent) version of your driver. there were no problems in using wired and wireless models of different age for editor as well as runtime.

now the hid approach introduced several oddities, like different axis layouts and differences between editor and runtime.

so what i really want to ask: do you think there is a way to revert back to the non-hid, driver-dependent behaviour like it was before and still leveraging the "new" input system?

PatHightree commented 3 years ago

No, afaik the input system doesn't communicate with proprietary drivers, just HID. Those proprietary drivers can be talked to like I did in the previous architecture. The problem with that is that the 3dconnexion sdk is designed to be integrated into programs by teams with source code access. Ofcourse I don't have source code access to Unity. The previous architecture was very complex under the hood and very brittle because of this. If anyone is passionate about continuing with the old architecture they can always fork this project and give it a shot.

In my opinion, the hardware device differences can be catered for by subclasses in the driver. That's why I put out the beta version, to collect feedback and fix support for variants. But as you may have noticed, my input in this project has been near-zero lately. This is due to personal issues and the fact that the time and energy I have are flowing into other hobbies. Maybe 3dconnexion should fork this project and take it further, they've got the knowledge and hardware that I'm lacking.

krisrok commented 3 years ago

The previous architecture was very complex under the hood and very brittle because of this.

oh ok i never had to deep much deeper than the public api of SpaceNavigator -- it just worked for years, for us at least.

Maybe 3dconnexion should fork this project and take it further, they've got the knowledge and hardware that I'm lacking.

this'd be best for sure. in the meantime we'll have to think of alternatives.

thanks for your input!

krisrok commented 3 years ago

i just read up on the inputsystem docs and with the apis mentioned there it should be possible to use your old (but brittle?) implementation to feed input coming in through the 3dconnexion driver to the input system. this way device differences will be handled by the driver. see here: https://github.com/Unity-Technologies/InputSystem/blob/develop/Packages/com.unity.inputsystem/Documentation~/Devices.md#creating-custom-devices

i guess i'll have a closer look at that when time permits. but if you have some insight to share it'd be great of course .)

PatHightree commented 3 years ago

The beta already uses the custom device mechanism, as 3dconnexion uses unconventional data layouts. The proprietary drivers could probably supply data to that, but then you'd have to revert back to the brittle architecture which I want to leave behind.

krisrok commented 3 years ago

The beta already uses the custom device mechanism, as 3dconnexion uses unconventional data layouts.

yes but the docs article describes two approaches: one is via hid, the other one is via arbitrary input sources ("You have an existing API that generates input, and which you want to reflect into the Input System.").

could you maybe elaborate a bit on what parts/functionality of the old architecture you deemed brittle?

PatHightree commented 3 years ago

Yeah, that's what I meant by proprietary drivers supplying data to the custom device mechanism.

The main problem areas I encountered with the 3dconnexion drivers were:

krisrok commented 3 years ago

Startup, to ensure the sdk code is initialized automatically in editor context Domain reloading when entering/exiting play mode

sounds like the usual unity editor niceties...

Sdk's dependency on closed binaries for functionality, and the issues that arise from shipping those in a player build

you mean the legal side of that?

(IL2CPP creates another platform permuation)

ah that's another point. i vaguely remember we might have run into this issue once. so il2cpp builds are not possible when using the TDx.TDxInput.dll?

ok, i just found a related thread on the 3dconnexion forums. you also responded and stated you already tried to implement their not-very-unity-suited new library.

all this new input leads me to believe this might indeed not be the best of ideas after all :) but i'm not too confident about the viability of the current approach either.

PatHightree commented 3 years ago

Nah, I'm not worried about legal issues for distributing a file from an sdk for the same purpose as the sdk was created for.

It's the issues of getting it to compile on all platforms and in builds. This ends up as a lot of nitty gritty low-level marshalling platform dependent stuff, which is something I want this project to move away from. Hence my move to HID