On 07/06/2015 01:35 AM, Gert Menke wrote:

Can you describe the problem with a bit more detail? Gimbal lock
always is a problem with 3 axis rotation. One of the options to
prevent this is to use quaternions for the calculation I think.

Some other notes...

The class name MainWindow is a bit misleading. There are multiple
instances when more than one document is open. Having the event
loop for every instance might not be ideal (in case the library
supports multiple open calls at all).

Calling updateGL() in a timer is going to kill performance for
every non-trivial model. There is already quite a big issue with
render performance due to the legacy OpenGL code.

To get the code included in the official release it would need
to be separated (new driver class maybe?) as there seems to be
no Windows or OSX version of the library yet.

ciao,
Torsten.

Hi Torsten,

thank you for the quick answer.

Am 06.07.2015 um 03:26 schrieb Torsten Paul:

I am looking for a function
f(current_camera_rotation, rotation_values_from_input) ->
new_camera_rotation
that always does what the user expects, regardless of the current
orientation of the object.
(I would like to mimic the behavior of FreeCAD. Blender does it
differently and it's fun to switch between the two, but that's another
story. :-))

When I ignore y and z,
cam.object_rot.x() += x;
does exactly what I would expect: Tilting the controller around the x
axis rotates the object around an axis that is parallel to the camera's
x axis.
That is because X is the "outer ring" of the gimbal. Right?
But,
cam.object_rot.z() += z;
Always rotates around the object's Z axis, which may or may not be
parallel to the camera's Z axis. And the Y axis does something in
between.

I tried to compensate for the effects of the x-rotation for y and z:
double rx = x;
double ry = -cos(cam.object_rot.x()/180.*M_PI)*y +
sin(cam.object_rot.x()/180.*M_PI)*z;
double rz = sin(cam.object_rot.x()/180.*M_PI)*y +
cos(cam.object_rot.x()/180.*M_PI)*z;
but that does not cover all possible cases, and you can rotate the
object into a position where tilting the controller around the Z axis
actually rotates the object around an axis parallel to the camera's X,
not Z.

I imagine it might help to convert the gimbal angles to some kind of
rotation matrix, update the matrix according to the input values, and
convert it back to gimbal angles. That way you probably would not have
to worry about gimbal lock either.
I am not familiar with quaternions and I'm a bit embarrassed to say
that my linear algebra is quite rusty these days, so they might be
exactly what I described, but maybe not.

Good point. I'll look into that.

Ah, you are right. The timer only calls QGLView::rotate (and translate),
which in turn calls updateGL(), when there's actually a movement event
from the controller. However, there is indeed no need to call updateGL()
again in the timer. I'll remove that.

I agree. I'm was wondering what would be a good way to detect the
spacenav library at compile time and only activate the code when the lib
is actually available. I just tried
exists("/usr/include/spnav.h") | exists("/usr/local/include/spnav.h") {
message("spacenav found")
DEFINES += SPACENAV
}
in the openscad.pro file, and it works, but it's not particularly
elegant... Can I tell qmake to check for a file in INCLUDEPATH?
Also, suppose someone who has the spacenav header installed wants to
compile a version without spacenav support (i.E. for distribution), how
can I account for that? I don't know much about autoconf/automake (and I
believe this makes me a happier person), but I guess I am looking for
the qmake-equivalent of ./configure --without-spacenav here. Any ideas?

Gert

Am 06.07.15 um 01:35 schrieb Gert Menke:

Recently I bought a new 3Dconnexion SpaceNavigator to use with OpenSCAD
and FreeCAD on MacOS.

So do I. As Torsten mentioned already: There may be multiple instances
of the class MainWindow. So you can not put the device interaction into
it. I implemented a small class that cares about the USB IO and emits
translate, rotate and button event signals. There is only one instance
of this USB IO class. (Maybe I should make it a singleton.) The
MainWindow instances then connect slots to those signals.

I had a look into the spacenav library too. But it is more or less Linux
only. And, as far as I see it, it can not coexist with the 3Dconnexion
drivers. This is not acceptable for me on MacOS. The best way would be
to use the API of 3Dconnexion. But the license of the API is prohibitive
for Free- / Open Source Software. So I interface to the USB device
directly, reading and interpreting the USB HID reports. This proved to
be quite simple using the HIDAPI library. The later has the advantage of
multi platform support.

You can see my USB IO test code here:
http://forum.openscad.org/Need-help-to-support-3Dconnexion-SpaceNavigator-tp12962.html
It is written on MacOS. I tested it on Linux (Debian, using
hidapi-libusb) and it worked. Maybe you can give it a try with your device.

Same for me.

Attached is the current state of my hack. You need to drop in hid.c for
your platform from hidapi in additoin to the patch.

tschüß,
Jochen

Hi Jochen,

great to see that someone else is working on the same thing too.
I won't be able to work on this until I get home next week, but then
I'll definately have a look at your driver then.

Am 2015-07-06 22:47, schrieb Jochen Kunz:

Sounds good!

Huh. Whithout having looked at the code, I see no reason why it could
not coexist with the 3Dconnexion driver - IF you switch off the X11
event stuff that's mainly there for 3Dconnexion compatibility anyway.
I'm currently connecting to spacenavd via unix socket. I just have to
make sure that X11 does not try to use it as a regular mouse too, and
that I ignore all motion events when my window is not active.
But, assuming spacenavd cannot coexist with the 3Dconnexion driver, your
approach seems to be the best solution.
(Well, actually, fixing spacenavd would be the best solution, but I have
no idea how easy that would be.)

That's so sad and stupid. But then again, the 3Dconnexion drivers are
only available for a very limited number of platforms, and only
maintained for a limited time anyway. (I also have an old Labtec
Spaceball 4000 which still works fine with a RS232/USB adapter and
spacenavd. Even on my Raspberry Pi, if I wanted to. :-) )
(BTW: Doesn't FreeCAD use the proprietary drivers on Windows and OSX?)

I will!

The hack I have at the moment does work moderately well, but I'm still
trying to figure out how to do it completely right.

Thanks!
I will give it a try when I'm back home next week.

I'll attach the current state of my patch too, in case you're interested
in the rotation stuff (even though it's not perfect yet).

Gert

On 7/7/2015 1:56 AM, Gert Menke wrote:

dunno how it works on Linux but on win it seems to talk to spacepilot on
the level "below" regular driver api... I have the spacepilot (the one
HP was selling, not the spacey round new one) and for e.g. freecad don't
see any buttons, only the navigation thingy ... and any settings you
make in driver (sensitivity etc) is completely ignored by the freecad. I
got the dev pack for windows from the 3dconnexion and wanted to add
support for it to the openscad, just I got the dev pack only recently so
not yet even looked at it let alone tried to add support into openscad
:D ..

Von: "Bogdan Kecman" arhi.smece@gmail.com

With the ridiculous license for the official SDK, there is no legal
way to distribute an OpenSCAD version using that SDK (I'm assuming
part of the SDK will be linked to the applciation). You could build
a version for your own personal use, but as there are other options
and people are working on that, I guess it makes more sense to pick
one of those.

ciao,
Torsten.

On 7/7/2015 5:39 PM, Torsten Paul wrote:

I was not reading the license details (as I said, just got the files
recently and some work came and...) but I heard that before... now it is
probably possible to create a wrapper and allow a blob with their sdk to
be downloaded as part of non-open lib usable by openscad .. donno, will
look at it as soon as I have time, missing support for this pilot is a
fairly big issue for me .. so even making patch that works "just for me"
will "work for me" initially ...

otoh making "interface" in the openscad to allow external manipulation
of the 3d object would probably be a good thing irrelevant to the pilot
as then you can easily add support to rotate object controlled by
wiiiiii camera and ir markers on fingers or any other contraption we can
create :D .. so then when openscad export the interface for object
manipulation, we can create completely independent apps that talk to it
and move/rotate object :) ... i will probably try to solve "my problem"
this way.. it's just .. time ..

again, I just posted to say freescad is IMO not using the driver but
talks directly with the pilot since anything set in driver is ignored
and not everything is recognized properly (probably they test with that
aerodynamic version of pilot :D ) .. the "other" thing I wanted to make
myself with - if I make it and it's good enough I share it, if I don't
make it .. well what the hack, would not be the first time :D

On 07/07/2015 05:55 PM, Bogdan Kecman wrote:

No, wrappers don't fix license violations.

Sure, no problem as long as it's not distributed, that's fine.

With multiple people working on getting it to work, I do hope at
least some basic support is not that far away.

Yeah, that could be useful for a number of cases. It might not be
easy to find an interface that makes everybody happy, but I like
the idea :)

ciao,
Torsten.

Am 07.07.15 um 01:56 schrieb Gert Menke:

The driver / daemon jumps on the device and programs it. E.g. setting
the speed / acceleration, tuning the LED on/off, programming the LCD...
When the 3Dconnexion driver and spacenavd try to do this at the same
time I expect to get a confused device.

Something I thought about too. If the client library of spacenavd could
talk to either its own spacenavd or the proprietary 3Dconnexion driver
on all platforms, it would solve all problems. Unfortunately spacenavd
isn't there at the moment. But direct USB HID access turned out to be
that easy that I postponed spacenavd. For now I have enough to do inside
OpenSCAD. Once that is sorted out I may return to the USB HID versus
spacenavd problem.

Corporate lawyers... ;-(

Seconded. Maybe it is best to support spacenavd and direct USB HID
access. There should be no problem for OpenSCAD to use both at the same
time. If you have a newish USB HID install the 3Dconnexion driver and
use the USB direct route. If you have an old (serial) device install
spacenavd instead and be happy. OpenSCAD can probe both interfaces and
use what ever it finds. It is just a matter of trying spnav_open() and
hid_open() until one succeeds, then divert into the suitable subroutine
to do the rest.

AFAIK only on Windows. I tried on MacOS and FreeCAD did not react to the
Space Navigator.

tschüß,
Jochen

Am 07.07.15 um 17:55 schrieb Bogdan Kecman:

I thought about that too. I have some experience with DBus. Adding a
DBus RPC interface to control translation / rotation from outside should
not be that hard. (Once the SpaceNavigator stuff is done. Some parts of
the two problems overlap.) Then you'd need an extra program / process
that fills the gap between the 3dconnexion API and the DBus API of
OpenSCAD. You would have to distribute this as binary only. As it is a
separate process it would not infect OpenSCAD with any poisonous license.

But this would be overcomplicated, IMHO. Talking to the USB HID directly
proved to be simple and is much more efficient.

tschüß,
Jochen

On 7/7/2015 10:26 PM, Jochen Kunz wrote:

Why I think it is a good idea is because it seems that different 3dconn.
devices have slightly different protocol so supporting them all is going
to be pita ..  otoh with the interface supporting "any" device gets
pretty simple

Am 07.07.15 um 01:56 schrieb Gert Menke:

Forgot to mention: I have an old SpaceBall 2003. I used it with my SGIs.
But I never run more then the SGI confidence tests. I should dig it out
and see if I can get it to work with spacenavd. But IIRC it didn't work
anymore when I tried it last time, several years ago... Ahhh, I also
have the buttons and dials boxes... :-)

Attached is my current state of the affair. I moved the event handling
into class QGLView and I handle translate / rotate in separate methods
like you. I switched from signals for event delivery to QEvent
subclasses. This makes it easy to deliver events to the in-focus window
only. See SpaceNav::Impl::operator()( void). It should be easy to modify
for spacenavd.

The button handling needs a bit work. I noticed that this is slightly
different on MacOS compared to Linux and NetBSD. Maybe because the
3Dconnexion driver reprograms the device on MacOS...

The rotation problem is still unresolved.

tschüß,
Jochen

On 07/09/2015 12:34 AM, Jochen Kunz wrote:

Nice, I'll try to provide some simple framework allowing different
driver types. Maybe the events could be renamed to a more general
name to be used by other implementations too.

I've attached the hidapi.pri I'm using for testing. At least on
Debian, hidapi comes with pkg-config support. This should work on
Linux and MacOS (tested only on my Debian system so far). Windows
builds use the MXE cross build environment which does not seem to
have hidapi, but that should be easy to solve by either adding it
to MXE or including the two files directly. Good thing is MXE has
libusb already.

To use hidapi.pri, it needs to be added to (similar to harfbuzz)

openscad.pro:CONFIG += hidapi

common.pri:include(hidapi.pri)

ciao,
Torsten.

Am 09.07.15 um 00:57 schrieb Torsten Paul:

Realistically there are only two alternatives: Raw USB access (via
HIDAPI) or spacenavd. They can coexist and it seems there is no need for
runtime configuration to switch between those two. Detection can be
automatic. You probably wane compile time switches to disable one or
both options. I'll have a look at spacenavd later. The only Space
Navigator / HIDAPI specific parts are in SpaceNav::Impl::operator(). It
should be simple to add support for spacenavd.

There are more things to do. We want a configuration menu to assign
different functions to the buttons of the device. Probably we want a
local speed setting. I can't help much here as I have no clue about Qt
GUI programming. (And I am not much interested to gain that skill. I am
fine with "reconfiguration by recompilation". ;-) )

Depending how things work out it may be necessary to add some device
description. I.e. a way to determine the total number of buttons of the
currently connected device, nim. / max. axis scaling factor, ... For now
I avoided this, there are more basic things to do for now.

The SpaceNav classes could be renamed to e.g. SixDoFDev (Six Dimensions
of Freedom Device) or the like. They are not Space Navigator specific.

Thanks for the help. I plan to do some testing on Debian. But I have to
install it on my old laptop first... This way I can build an interface
to spacenavd based on Gerts work.

I haven't used it since 1993 and don't plan to change this in the near
future. So I can't provide much help in that department. ;-)

tschüß,
Jochen

On 07/09/2015 10:39 PM, Jochen Kunz wrote:

For the Space Navigator devices that's probably the case, but
there are other devices that could be used as well like joysticks,
the remote interface discussed lately or maybe there are other
3d mouse devices with more reasonable licensed SDKs.
No need for something hugely complicated, the event stuff you
wrote covers probably already quite a big part of it.

I think it makes sense to first get things working with same
sane default settings and add config options in the next step.

Yep, something like that.

Well, I'm not using it either except for testing. The number of
OpenSCAD users running the Windows version is quite large though,
so it does matter a lot. No need to worry, I'll try to take care
of that part (even if a bit grumpily ;-).

ciao,
Torsten.

tp3 wrote

Oh good, I was lurking while waiting for a Windows mention.
If there is a commitment (obviously no absolutes) to getting it working, I'm
happy to buy one and help with testing.

Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/Working-on-SpacePilot-support-need-help-with-rotation-tp13057p13114.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Am 13.07.15 um 21:41 schrieb Torsten Paul:

Congratulations. :-)

Probably this would be a worthwhile interface to add.

Have you tried spacenavd?
On Debian the libspnav-dev package comes with test and demo code. The
"cube" demo didn't work out of the box as it used the X11 protocol but
"simple_af_unix" did work.

I expect that we will go with spacenavd / libspnav on Linux. It seems
the best option there.

For MacOS it may be better to avoid HIDAPI and use the native MacOS
systemcalls.

The problem with rotation is gimbal lock. The "cube" example in libspnav
shows how to do the rotation and avoid this by using quaternions. I try
to understand this and port it to OpenSCAD. But my math-foo is a bit rusty.

Fits. The first byte is the report ID. What ID did you get? The
remaining 12 bytes are the six axes as int16_t. Can you determine how
this int16_t are mapped to the axes? And what is the USB vendor /
product ID? This information may be sufficient for me to add MacOS
support for this gadget.

Probably. What does "lsusb -v" show? Look for "Report ID" 1, 2, 3.

tschüß,
Jochen