Would be nice to transfer from CAD to Cura and still be able to use my space mouse when arranging parts to print.
The device Ramblin seems to be talking about: https://www.youtube.com/watch?v=9pAMne1eeTQ
PLUS ONE.
It's one of those things that just make it come together UX wise (for those of us who use da 3D mouse.)
We actually took space mouse support into consideration when we designed the original cura 2.x architecture. But due to time constraints (and the more practical; "I don't have a space mouse") this was never actually done.
Want to borrow mine?
An issue has been made in our internal issue tracker, but to be honest I don't think it'll get made for version 2.4. The beta is due in two weeks, and we have 100 issues left to do (and 48 in progress or testing phases).
Always nice to have an approximate timetable
This just got pushed in "Some future release". Can't wait for the year 3016 ;)
The implementation is quite easy on windows, at least in C++. Probably
maximum one day effort.
That's not the issue. The problem, as ghostkeeper already mentioned is that there is just too much stuff to do / build and always too little time to do it with.
+1 for this
The new product manager for Cura at Ultimaker rejected this issue for being too unimportant. This means that the main developers can't spend time on it.
That's good, it will prove a good exercise for new voluntary developers that want to get acquainted with the code. @ramblinwreckJR could you provide details on how the controls should work, in your opinion? Like: XY pan would do that, XZ pan would do that other thing, ZY pan this, roll would do that, pitch that other stuff, and yaw even that. FreeCAD works wonderfully with the 3dconnexion space mouse, maybe I can get something from its code.
@Ghostkeeper bummer to hear but thanks for following up.
@Patola not sure I understand your question, but I would imagine the ideal is that it works very similarly to another CAD program. In Cura, instead of the body(ies) moving, the relative view moves. To start, keep it simple by following how Cura works now -- just zooming in/out and revolving, both relative to the print space center (I think?). Panning (XY, XZ, YZ) may be harder I suspect. Some CAD programs give the option to have a smart center -- taking into account the body, screen center, etc. I imagine that would be more than necessary for Cura.
Panning relative to the current viewport is already implemented at the moment (shift+drag or middle mouse button drag). If panning needs to be in the global coordinate system (pure X, Y and Z) that shouldn't be very hard to implement.
I think the general goal of this issue is to get close to what the consensus is for most CAD programs, at least the simple bits.
Anyone looking to implement this should take a look at this thread on the 3Dconnexion forum: http://www.3dconnexion.de/forum/viewtopic.php?t=4968
+1 would be nice to have 3d mouse support, but Cura is free so I can't really complain
Did a little research today, here is what I found:
What should the 3d mouse control? The camera or the selected object?
I guess the camera. That's usually what the 3D mouse controls right?
Definitely the camera.
Seems that in Blender their 3D mice implementation is located here: https://github.com/dfelinto/blender/blob/master/intern/ghost/intern/GHOST_NDOFManager.h
Too bad it's in C. I'd hoped for some Python library to exist somewhere.
From a cursory look, it seems to be based on HID devices, and there are a couple of HID-capable python libraries.
Using libUSB seems to be an option.
https://github.com/vpelletier/python-libusb1
But there's also hidapi.
FreeCAD has a much better implementation of the 3D Connexion Space Navigator control than blender. However it's also in C.
@alekseisasin is working on this, maybe he has some insights to share?
suggest adding WIP tag
+1 Would be a nice feature indeed
The attempt from alekseisasin didn't really work well. He was attempting it too close to the metal rather than using drivers, which was supposed to work well on all platforms but didn't work well with all mice and was hard to get right at all.
I faced to difficulties related to the combining all rotation. It is in progress only with low priority
+1
I'm used to work with the 3D mouse in all CAD programs and always find it a pita to get used to different mouse combinations for zooming, shifting etc...
So I would love to see some progress on this topic
BTW:
Thanks for this great program and all the new features. Really appreciate it!
+1
Any news on this? It would be a nice feature to have.
It's super niche, so either someone from the community picks it up or an UM engineer works on it as research or in spare time, but I don't think it'll be finished in one of our sprints....
Actually I dont think this is a niche. It would greatly simplify the use of Cura for us that have a 3d connexion 3D mouse.
With niche I mean that there are a limited amount (relative to total Cura users) of people that will use this, I'm not denying that it would be useful.
I have found a workaround for the meantime.
It comes from the user RsX on thingiverse: https://www.thingiverse.com/thing:2913885
Works great for now, but native control would handle things better
Hello,
Getting SpaceMouse/SpaceBall/SpaceNavigator to work is actually the easy part, even in Python. The devices are regular HID devices and present themselves to the OS as a multi-axis joystick with a lot of buttons (not counting the LCDs some have).
The problem is to do this in a portable way. E.g. in Linux reading this is trivial, see the spacenavig.c example here:
https://janoc.rd-h.com/archives/74
An easy way to make this work in a cross-platform way from Python may be using PyGame's joystick support (saves you messing with the raw HID implementation if you go the libUSB/HIDAPI route), however in Windows/Mac the official "driver" will have the device opened and interfere with this. I believe the official API talks to the Windows/Mac driver using a network socket so you may have to do that to make the life simpler for the user (no need to stop/start the official driver).
For Linux I don't recommend this approach because the official driver is horribly insecure - needs to run as root, requires full access to the X session to be able to pass the events to the client application, etc. - and hasn't been updated in years. Basically an enormous security hole you are opening on your computer whenever this is being used - basically you are one buffer overflow bug triggered from Blender or some other unprivileged app away from having your machine completely pwned. The alternative open source spacenavd uses the same bad design to be compatible (and it hasn't been updated since 2014 neither).
Please, don't do this, there is no reason for such crap to exist in this day and age. A much better solution is to use the approach that e.g. the current SecondLife clients for Linux or the VRPN driver for this use (and which I have implemented). They access the device directly, without any daemons. Modern Linux will permit multiple applications to access the device simultaneously and will route the events to the correct application automatically, the same as keyboard focus is handled. E.g. running multiple SecondLife instances all using the SpaceBall is not a problem - only the one with keyboard focus gets the SpaceBall events.
Here is an example how to read a SpaceNavigator/SpaceBall from Python using the inputs library (if you don't want to deal with PyGame). The device detection is a bit hackish because inputs doesn't seem to expose vendor/product IDs and the code simply takes the first matching device but one can always ask the user to select the desired device from a list. It also throws an exception with my SpaceBall with some of the buttons because this library doesn't expect so many buttons to be present but that shouldn't be an issue with a SpaceNavigator (which has only 2). However, it should be enough to get someone started.
The code was tested in Linux, it should work in Windows/Mac (the library supports them) but I haven't tested that as I don't have access to them.
from inputs import DeviceManager
def main():
devices = DeviceManager()
spaceballs = list(filter(lambda x: "3Dconnexion" in x.name or
"Space" in x.name, devices.other_devices))
if len(spaceballs) > 0:
sb = spaceballs[0]
try:
while True:
for e in sb.read():
print(e.ev_type, e.code, e.state)
except KeyboardInterrupt:
return
else:
print("No SpaceMouse/SpaceBall/SpaceNavigator found!")
if __name__ == '__main__':
main()
@janoc , The problem was not in reading those signals from mouse, it was a bit difficult translate them into camera movements in Cura.
OK, I was reacting to some earlier posts talking about libUSB and drivers.
The simplest way to integrate this would be to add a class simulating a virtual trackball that rotates/translates in response to the SpaceMouse movement. Basically change the position/orientation by an increment proportional to the size of the movement. The rotations are best kept as quaternions because it saves you hassle with gimbal locks but depends on what your scene graph uses. Then you can drive e.g. the active camera from it by sampling the current position/orientation on every frame.
I would also map one button as "clutch" to enable/disable the SpaceMouse in order to avoid drift or inadvertent bumps from affecting the camera and the second button as reset the tracking to home position (it is easy to "get lost").
Just another ME TOO!! note (without the disgusting politics) I love my 3d mouse and think everyone should have one. It makes Blender soo much easier to work with. I'd love to see it work with Cura too ,so I cheer on the developers who are thinking about implementing 3DConnexion Space Mouse support. Incidentally, I like hugging penguins if you know what I mean. :-) (Windose is broken and MacOS is dead)
would this be possible to implement as an extension?
if Cura devs can't make time for it because of the low user impact, it would be nice of one of us 3DConnexion users were able to implement it as an extension for the community.
Thanks!
Yes. We gave this an initial try as well, here: https://github.com/Ultimaker/Cura/commit/8c326a92f0a20ad28a4b15a0aa77f5b0370addcb
But the low-level approach that we were using back then wasn't feasible. We should be using a library or installed firmware or something.
However you should be able to read the interconnection with Cura from that plug-in. In particular, look at the file plugins/SpaceMouse/SpaceMouseCameraTool.py
for the actual commands to Cura's camera.
Yes. We gave this an initial try as well, here: 8c326a9
But the low-level approach that we were using back then wasn't feasible. We should be using a library or installed firmware or something.
The approach using the standard "inputs" module that I have posted above doesn't work? That could possibly save you hassle with evdev, at least in Linux. Not sure about Windows, don't know whether the Space Navigator/Mouse is exposed as a HID device there.
We didn't try that, as the initial try I linked to was made 1.5 years ago.
A simple solution can now be found at https://github.com/smartavionics/RawMouse.
Thank you for that great Plugin!!! Finally the SpaceMouse is Working in Cura.
The only suggestion i have is maybe a better explanation on how to invert axis, or a simple button to change the orientation of all axis.
Thank you very much!
@smartavionics Thank you very much!!
Installation is not possible via the Marketplace yet, is it?
Installation is not possible via the Marketplace yet, is it?
No, you have to get it from https://github.com/smartavionics/RawMouse
So I heard that PrusaSlicer has support for Space Mice(?). How're things looking out for Cura in this regard?
There is a plugin for it, as you can read above.
Yeah I can see that there is a plugin, which I assume is a "quick and dirty" fix to a request which has existed for many years now.
I am specifically thinking about the requirement to stop the 3DxWare in order for the plugin to function: "On Windows, there is a Stop 3DxWare command that disables the normal Spacemouse driver."
..which would mean that if I tab over from F360 to Cura I'd have to do disable drivers in order to get the basic functionality of the 3D-mouse. I don't see myself doing that quite frankly :)
I hope that clarifies the underlying framework for my inquiry.
So my question is: Will Cura implement a functionality which has been shown possible to implement in other open source slicers, such as PrucaSlicer for example? How's that work going? :)
I don't use Windows myself but I believe from what others have reported that you don't actually have to stop the 3dxware driver when using the rawmouse plugin. So maybe it is worth your while to give it a try.
Are you guys saying that this feature request should be closed, with the reason that the plugin exists?
If not, I think my question is still valid.
(I think it's awesome that the plugin exists, don't get me wrong, I'm just trying to keep this feature request alive so that Cura could include a "native support" for 3d mice.)
@smartavionics Correct that you don't have to switch between drivers. I'm on Windows 10 and I'm using Solidwork at the same time as Cura and it works flawlessly. I'm very impressed at how well it works. Thanks again
Hi @jdaubs45 , thanks for confirming that. Glad you like it.
Are you guys saying that this feature request should be closed, with the reason that the plugin exists?
In my opinion: yes. Though it would be nice if the plugin were available from the Marketplace.
We also still have this feature on our backlog. Can't say how long it will take though, as it's been that way for a while and has been attempted once without success; it worked for one specific mouse but not for others.
Most helpful comment
A simple solution can now be found at https://github.com/smartavionics/RawMouse.