y about gimbal lock. > Have a look at: > https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation > Also look at the examples from libspnav in libspnav-0.2.3/examples/cube > which is an example implementation of rotation using quaternions. I have looked into quaternions a little, but the thing is that the camera object still wants euler angles. And since the conversion to a rotation matrix was already there, it seemed natural to use that. > I tried your code and it is much better then the current state of the > affair. But it still has a problem: The rotation originates at the > origin of the view / camera. It should rotate the object around the > origin of the object. This is easy to see when you move the object away > from the view / camera origin. Try the cube example from libspnav, this > does it right. (Not left). Well, personally, I find it more intuitive to rotate around the origin of the view. Take for example an scad file that contains several objects that belong together and are placed next to each other. When I want to inspect, say, the leftmost object, I place it in the center of the screen and zoom in. Then, rotating around a point that is currently off-screen would be irritating to me. > There is an other reason: To get X11 events the spacenavd needs to > connect to the X11 server. To do so you have to start it from your > ~/.xsession to get the needed authorization credentials. At least Debian > starts spacenavd at boot time, so it can't connect to the X11server as > it has no authorization credentials. Thus no X11 events from spacenavd. > The AF_UNIX way still works, as it is independent from X11. You can use "spnavd_ctl x11 start" to tell the daemon to connect to the X server once it's started. That works, but it's still a bit of a pain. I'm glad we don't need to to it that way. > Please don't troll. ;-) It's a personal thing between X11 and me. I won't mention it again, promise. ;-) Regards Gert

y also avoid gimbal lock. Thats why they are preferred e.g. in robotics. You need conversions in both cases and they are equivalent. > Well, personally, I find it more intuitive to rotate around the origin > of the view. [...] Probably this is a matter of personal taste or prior experience. The demos from 3Dconnexion, libspnav and SGI (IIRC) rotate around the object origin. > You can use "spnavd_ctl x11 start" to tell the daemon to connect to the > X server once it's started. That works, but it's still a bit of a pain. > I'm glad we don't need to to it that way. "spnavd_ctl x11 start" didn't work for me due to privilege separation issues. -- tschüß, Jochen

ver2 branch to files.openscad.org OpenSCAD-2015.07.20-x86-{32,64}_inputdriver2* Right now, no config at all. I guess we want something similar to the config UI FreeCAD has: http://www.freecadweb.org/wiki/index.php?title=3Dconnexion_input_devices ciao, Torsten.

er automatically so it installed the generic HID driver. I did not try what happens with the official driver installed. ciao, Torsten.

ybe you just got the brand new version? I'll add this to the USB-ID list. cioa, Torsten.

known. Ideally all that would go into spacenavd, but it seems the Win32 port is pretty much dead for years. ciao, Torsten.

2; // wall thickness > pcbThick = 2; // PCB thickness > pcbLen = bY; // length of PCB in slot > lcdX = 51; > lcdY = 72; > rch = 0.1; > > module slot() > cube([wall + rch, pcbLen, pcbThick]); > > module Top() { > translate([-1.5*bX, 0, 0]) { > cube([bX + 4*wall, 3, bZ + 2*wall]); > translate([2 * wall + rch, 3, wall + rch]) > cube([bX - 2*rch, 2, bZ - 2*rch]); > } > } > > module Box() { > difference() { > // exterior; X is thicker for PC board slot > cube([bX + 4*wall, bY + wall, bZ + 2*wall]); > // interior > translate([2*wall, wall, wall]) > cube([bX, bY + rch, bZ]); > // slots for PC board > translate([wall, bY - pcbLen + wall + rch, 32]) > slot(); > translate([2*wall + bX - rch, bY - pcbLen + wall + rch, 32]) > slot(); > // hole for LCD - deprecated > *translate([wall + 5, wall + 16, bZ + wall - rch]) > cube([lcdX, lcdY, wall + 2*rch]); > // perforation for LCD > xMargin = (bX + 4*wall - lcdX) / 2; > difference() { > translate([xMargin, wall + 27, bZ + wall + 2*rch]) > cube([lcdX, lcdY, wall - 2*rch]); > translate([xMargin + 0.25, wall + 27 + 0.25, bZ + wall - > 2*rch]) > cube([lcdX - 0.5, lcdY - 0.5, wall + 4*rch]); > } > // hole for hanging > translate([(bX + 4*wall)/2, 0.85*(bY + 2*wall), -1]) > rotate([0, 0, 90]) > cylinder(h = 10, r = 3, $fn = 3); > // hole for USB > translate([14.5 + 2*wall, -1, 5 + wall]) > cube([12.5, 11.25, 11]); > // hole for DC > translate([45.5 + 2*wall, -1, 4.5 + wall]) > cube([9.5, 11.5, 11]); > } > } > > Box(); > Top();

which would normally not be considered an overhang becomes one. I would like a way to create an object and immediately see the areas that will not print properly; at the moment, I just print and pray.  I recall some slicer that would highlight overhangs in color, but have been unable to find it on the half dozen slicers that I have here at the moment.  Maybe it was the slicer for the Form 2 that I had for a while. Any thoughts about how to visually flag surfaces that could be a printing challenge? Thanks.  This is such an active group, and has so many experienced people, that I thought I would have more success here than in other forums. Jon -- Sent from my desktop computer. I do not receive emails while away from my desk, nor do I receive texts on my main phone number (which is a land line). If you know that I am on the road, please text me. If you know that I am home, please email me.

pyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. -- Sent from: http://forum.openscad.org/