Alternately, it would be slick if we could use a VRPN device as our input, since then we'd get all the spacemice on all platforms, plus DIY stuff, etc.

Was going to ask what VRPN, but google. I recently got a Quest 2 and was wondering how hard it would be to get SolveSpace running on that. Initially it could just be 2 floating windows with, as you say, some VR manipulation like spacemouse. It could later move to something more interesting perhaps moving around in model space and putting up a semi-transparent plane just for 2D sketches. Oh to have time...

:-D I bought a SpaceExplorer off of eBay a couple of months back (because of this #847) and just had to write a library. Then I found the the one you found - it is too early WIP, so I wrote the USB device support :-) (FreeSpacenav/libspnavdev#1)

Then I was thinking of doing (something similar to) what you just did here :-)

By the way the official 3Dconnexion SDK supports x64 in it's newer versions. I have not registered with them and downloaded it from the official site, but here is the newest copy I could find on GitHub:
https://github.com/n8vm/Foton/tree/master/external/spacemouse
look in /Lib/x64
The latest date in the headers is 2018-02-19, while our current one is from 2005.

When I got the SpaceExplorer I updated the official library locally (by replacing our files with a minimal working set from the above link) and it compiles and works without any changes to the SolveSpace source code.

So this may be a simple and cleaner way to support 3Dconnexion on x64 on Windows. But I have not read the license carefully (says a lot of things about "do not copy", distribute etc.) and that is why I did not make a pull request.

What do you guys think? And @jwesthues ?

P.S. Yes is is more fun to write our own - and since these devices have been around for 30+ years the protocol(s) are well known - but it will be much more work to support all models (especially the buttons beyond "Fit") well.

@rpavlik Why are you using an x64 build of SolveSpace - do you notice some benefit? Or just for experimentation?

Assuming the relevant license is

https://github.com/n8vm/Foton/blob/master/external/spacemouse/Doc/LicenseAgreementSDK.txt ,

the new official driver license is quite different from the old one. The advertising clause in (2) is obnoxious, but we could comply. The confidentiality clause in (5) is the bigger problem, and seems fundamentally inconsistent with use in any free software project. I doubt anyone at 3Dconnexion would sue us, but I'd rather be strictly compliant than rely on that.

So I'd be inclined either to keep the old official drivers, or to move to non-official drivers (which as you note may have worse compatibility across their line, but would also remove our only binary dependency). Thoughts?

Jonathan, after posting my comment I decided not to be lazy, read the license (the same one you linked) carefully and came pretty much to the same conclusion as you did.

The confidentiality clause makes it pretty much a "no go", but here is a full list of problems I noticed (IANAL):

1. "non-transferable" "non-sublicensable"
2. We could add the "attribution" on the site - since that is our ""Help" file (or equivalent)" - so not a big problem.
3. OK
4. OK
5. Completely incompatible with GPL, we will be violating this clause as soon as we commit it to GitHub (we may not be violating GPL since one can always compile without the library).
6. Termination... what we want to do immediately activates this clause.
7. "Nice" :-D:
   "3Dconnexion may, in its sole discretion, modify portions of this Agreement at any time."

So I'll continue to work on the library (libspnavdev) and perhaps when it becomes good enough to merge we can keep both. If the 3Dconnection software is installed and si is linked - use it. Otherwise use our own.

By the way for just 6DOF motion events with USB devices it works just fine already. The button abstraction will need another (non-existing at his point) layer.

Yesterday I committed initial rough support for (ancient) RS-232 devices. This is another advantage of writing our own library - we can support all old devices on all platforms (unlike the official driver).
They seem to be well made and last long (apart from the sticky soft touch coating) so they are easy to find and are cheap second hand, which is an advantage for our users. I bought my SpaceBall 3003 for 15€ :-)

I default to 64 bit builds of stuff these days even on Windows. (And actually I first tried the ci build, which is also 64) I assume it's somewhat faster because of newer instruction sets.

VRPN is bsl-1.0 licensed (very permissive) and has both serial and hid space nav drivers in it. I only started this because there was already that one driver and I assumed it would be easier, but it's probably easiest to just generalize the 6dof input a bit more and make a VRPN module. Then you can even have your space mouse networked 😁

@rpavlik is there any chance VRPN could work with the emscrpten version? Solvespace can run in the web browser on the Quest and probably other VR setuos.

Why are you using an x64 build of SolveSpace - do you notice some benefit?

I've crashed the 32-bit windows build of SolveSpace simply because working on a model required more than 3GB of RAM, so yes there's definitely a benefit to using x64 builds :-) (Or whatever the user-space virtual address space limit is on Windows, it might only be 2GB I forget)

I've crashed the 32-bit windows build of SolveSpace simply because working on a model required more than 3GB of RAM, so yes there's definitely a benefit to using x64 builds :-)

Yes, after this #1002 on a fast machine it is possible :-) Before it became unusably slow before hitting 2GB of RAM.

Win32 processes have a 2GB limit on 32bit Windows by default. The upper 2GB are reserved for the kernel. There is a switch in boot.ini that increases that limit to 3GB for executables linked with the /LARGEADDRESSAWARE option. It sets a single bit in the PE header. I think we should enable it but I need to read a bit more regarding unforseen side effects.

On 64bit Windows such executables can access up to 4GB of RAM.

I asked a question about the license in the 3Dconnexion forum https://forum.3dconnexion.com/viewtopic.php?f=19&t=39870#p83415

@ruevs just a thought regarding licensing: Wouldn't it suffice to pull in the .dll from GAC and be compliant? The user would need the have the driver package installed anyway. That's windows-related only of course.

@ruevs just a thought regarding licensing: Wouldn't it suffice to pull in the .dll from GAC and be compliant? The user would need the have the driver package installed anyway. That's windows-related only of course.

We do not need to "pull the DLL" from the Global Assembly Cache - it "Just Works". Our problem is that we use their header files and we link against a small static library "siapp.lib" and the (new) license states:

5. Confidentiality
   The source code and instructions contained in the 3DCONNEXION SDK are trade secrets of 3Dconnexion and you agree to maintain the confidentiality of such source code

Ok thanks for clarifying.

It's been a while.

The original libspnavdev is "dead".

So I updated master on my fork (https://github.com/ruevs/libspnavdev) to my working implementation and added build instructions. It should work with all SmaceMouse devices and I have tested it with nine of them.

Since 64 bit SolveSpace on Windows seems to be more and more needed (faster SolveSpace, faster PCs, bigger models, 3/4Gb RAM runs out) I updated my branch based on @rpavlik's here https://github.com/ruevs/solvespace/tree/rpavlik/libspnavdev. It is rebased on master and links to the latest version of libspnavdev. To test it make sure to get submodules recursively (I include HIDAPI as a submodule) and build a 64 bit SolveSpace on Windows.

@phkahler @rpavlik @jwesthues we should consider if we want to merge it.

P.S. The 3DoF (USB) devices that I tested are marked here
https://github.com/ruevs/solvespace/blob/72a4d8026942717f1dae6d8c3fd41bcf23d73300/src/platform/spnavdevice.cpp#L107
if you have others - please test if they work.

Note to self on the subject of licensing - when Thomas Buck implemented 3Dconnexion support on macOS in fb62e04 he considered the license restrictions of the official SDK: