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