3Dconnexion SpaceMouse Horizon Lock Constrain Orbit Missing Feature Video

[Anonymous]

This post is a final act of desperation.

In the video at the bottom of this post I describe how broken the current SpaceMouse implemetation is, and how great the device could be if these, and other problems, were resolved.

I fear it will never be fixed due to these direct quotes...

'The navigation with the SpaceMouse in Fusion 360 was implemented and is maintained by Autodesk directly.' -3Dconnexion

'Those options are controlled by the spacemouse drivers that 3Dconnexion has crafted for their support of Fusion 360.' - Autodesk

If anyone can help me work out HOW the driver and Fusion 360 communicate, please help me out. Does Fusion use the 3Dconnexion SDK to just read the axis values and control the camera transform internally to Fusion 360, OR does 3Dconnexion  remotely control the camera transform from within the driver software somehow. I assume the support is not add-in or script based. If both companies deny all responsibility for maintaining the SpaceMouse functionality, then me posting this fix and offering my code for free is all in vain. Thanks for watching!

SOUND REQUIRED:

And yes... I did actually program my own faux Fusion 360 just to show how things could, and should, be... 😂

[stephen_mcmillan]

Screencast was "pending" for about 8 hours there. I can finally share it. I did the "Turntable" experiment and the results are not correct, so there is certainly a bug in the rotation transformation.

We should agree on terminology though. We are asking for Horizon Lock, but Fusion already has official terminology on this: Constrained Orbit. 

I just want the controller to check the state of this toggle and behave accordingly.

[stephen_mcmillan]

https://knowledge.autodesk.com/community/screencast/bbc16a42-c3f7-4820-acf9-a2ffdc640742 

Link to screencast of "turntable" test. 

Couldn't get the screencast to imbed with "invalid html" error. Oh well, try this link please.

[david_j_calabrese]

Here is how things look in Blender doing a similar move (twisting the 3Dconnexion controller), see video with narration:

3Dconnextion rotating around Z in Blender | Search | Autodesk Knowledge Network

This is the Blender control panel for the 3Dconnexion below which includes Turntable and Horizon Lock. Of note, Blender wrote their own driver. Blender is also free. 🙂

[david_j_calabrese]

Phil E. - As promised, here is a screen-cast from Maya showing the default rotation behavior. Also, I've included an encouraging snap of the Maya 3Dconnexion Advanced Settings which includes a Lock Horizon setting(!) — the Maya developers look to have this code, perhaps they are just down the hall and could share, etc.? 🙂

Here is the screen-cast of the rotation working as expected in Maya:

https://knowledge.autodesk.com/community/screencast/4878d504-10d0-417e-a5bf-ae51c14d20aa

Also, for completeness, the Advanced Settings dialog from Trimble SketchUp, which also has Lock Horizon:

And a screen-cast of rotation working as expected when twisting the controller in SketchUp:

https://knowledge.autodesk.com/community/screencast/0c136b5b-b1a4-475c-ad87-da75c4943f85

[david_j_calabrese]

Also, for reference, the Advanced Settings dialog while using Autodesk 3ds Max, including Lock Horizon:

Here is a video of twist rotation working as expected in 3ds Max:

https://knowledge.autodesk.com/community/screencast/b7561d7e-31e3-4ecf-a1a8-323061eb3b60

And, a long overdue note to Schmiffy - if you have a SpaceMouse Pro or Enterprise with the "Rotation Lock" button on the right, if you're very diligent, you can remember to press this just after you enter Sketch mode, and the device will only translate and zoom, and if you press it again after you Finish the sketch, you'll be able to rotate once more in the regular view. 

[Anonymous]

Perhaps you could change the status of this issue? It is a feature that is common on other CAD programs that, for whatever reasons, has not been implemented/fixed on Fusion360.

In the interest of transparency, please label this issue more accurately. I am not sure what options are available to you, but it most certainly is not "solved".

[Anonymous]

Thanks for the useful suggestion! I did actually set this up and try this when I still owned the SpaceMouse, but it drove me nuts and seemed to make it more work not less to navigate around. I have clearly described the bug in the camera transform to Phil.E and 3DConnexion, and both have logged it as an issue, but nobody at either company can be bothered to fix it. I was so disillusioned I returned my spacemouse, even though the hardware is incredible. Thanks for commenting though! Many people are just as frustrated as me about this issue, which should seemingly have a VERY simple fix.

[Anonymous]

This needs to be in fusion360! The tilt/twist behaviour is totally undesirable for everyone. How are people not on the fences with that being not implented is beyond me.

[seth.madore]

---

@Anonymous wrote:

The tilt/twist behaviour is totally undesirable for everyone. How are people not on the fences with that being not implented is beyond me.

---

That's an awfully broad brush you're painting with there. Speaking as a customer, I find the 3D Mouse behavior quite satisfactory (for the most part), and I've used them in SW, MasterCAM, Esprit and PC-DMIS.

[Anonymous]

Hey, yeah ofc its broad but since this function is well implemented in other autodesk family products it kind of makes zero sense to me why this opt in feature is not part of the fusion implementation 🙂

I've talked to other CAD mains and they all are pretty surprised that this feature is even a thing on other softwares, so I think you guys are missing out big time. Yeah I know you could bind rotate on/off once youre in a sketch but why is that not exposed to the API so the 3d con driver could be "smart" and decide when to enable tilt and when only orbit/pan is a desirable solution. This task is probably a quick "fix" for a junior dev at your company but this qol feature prob doesnt make you any money 😉

[Phil.E]

Hi everyone.

In August, 2020 I posted a request to get more feedback. In the last 6 months several of you have stepped up and made your cases. Thanks for posting your feedback.

I've removed the solved flag from this post. I don't know who marked it solved, but it's correct to remove it since the issue is not solved. That's done now.

Regarding the ease of fixing this: It's not a job for a jr. developer. It will also require more than a day or two as has been suggested. I've added all of your feedback to the improvement ticket and will update this thread when there is something to report. 

[Anonymous]

Thank you! Here is another link but you guys prob know how to read a SDK docu(I hope) 🙂

https://forum.3dconnexion.com/viewtopic.php?t=39526

[stephen_mcmillan]

I suggest the ideal implementation is to give both sides their preference by having the spacemouse control honor the toggle setting of "Free Orbit" or "Constrained Orbit".

[Anonymous]

Ofc this has to be a optional pref feature in the 3dxware software or a native fusion prefs option to choose from.

Like those examples. Maya/3ds max has those too afaik and has been posted here by others also 🙂 

 

[Anonymous]

---

@Phil.E wrote:...I've removed the solved flag from this post. I don't know who marked it solved, but it's correct to remove it since the issue is not solved. That's done now.

---

Just FYI, it is still showing as "solved" for me in the first post;

[carlinohefner]

Hi Phil! I too am very interested in this as I recently purchased a spacemouse and found that it only uses "free orbit" and not "constrained orbit" regardless of which option is selected in the Fusion 360 view menu (bottom of screen). 

I see the last reply was 2 weeks ago and am wondering if there's been any progress in this yet?
Something that I hope can ease the implementation of this feature is to use the existing "Constrained orbit" logic that Fusion 360 already has, and reuse the same menu option at the bottom to determine whether the spacemouse uses free or constrained orbit.

I don't believe new movement logic needs to be developed at all for the spacemouse if it can piggyback off the existing constrained orbit logic that most users enjoy when using shift+middle button to orbit.

And thanks again for removing the solved status and adding it to the list to fix!

[Anonymous]

Like phil.e said, this is very low on the "improvement" list since its not considered broken. Inventor/fusion/alias/catia/creo/spaceclaim for example all use this system where the spacemouse rotates freely inside the viewport. Tools like maya/3ds max/zbrush/blender/MoI/Rhinoceros/sketchup have a proper horizon lock or constrained type movement which is more desirable imho or simply give users choice what they want. The prof. CAD industry seems to be not interested in that, or users are simply not aware that this kind of system could even be achieved or offered. So we can only hope that they have resources to make this happen, which I sadly doubt in the next months or years time frame 😕 (I mean this thread has hardly generated any traction so low/zeroish prio)

The spacemouse sdk offers all those functions to be implemented inside the companies program. So its at autodesk to use them to its full advantage 🙂

[EricY_Design]

Absolutely agree, the problem's been there for years...

Does it go away temporary after doing one of these?

1. Use the Constrained Orbit tool to orbit for any amount (with regular mouse)
2. Choose a face on the View Cube (e.g. Top/Bottom/Left/Right/Front/Rear)
3. Choose a Named View from the browser

If so then I think this might be a Free Orbit problem in general. I posted about it here:

https://forums.autodesk.com/t5/fusion-360-support/free-orbit-bug-closer-to-a-fix/m-p/10168742/highli...

I was able to trigger and workaround it reliably, there's a pattern.

[EricY_Design]

Basically Free Orbit left/right (Spinning in 3DConnexion) in general can have a bug that adds a small camera twist that throws off the intended orbit. This bug is intermittent and has been overlooked for a long time.

Requests to fix the bug seems to be mistaken for feature request for a "lock horizon" feature when the 3DConnexion driver could do much more than that all along.

[carlinohefner]

Thanks, I tried to reproduce as you described, however the problem does not go away temporarily after trying any/all of those steps.
I believe we might be talking about 2 very related but fundamentally different issues:
You describe an issue where using free orbit from a horizontal plane adds a bit of twist to the camera. I've found that in free orbit, it's extremely difficult to move the mouse (regular mouse or space mouse) perfectly in only 1 axis, so as you add a bit of pitch input, the orbit starts to experience roll as well. This is the expected behavior of free orbit, as it orbits around the plane of the camera and not the horizon.
The issue I describe is that despite selecting constrained orbit, the spacemouse still uses free orbit. This could be either a bug or a feature, but with lack of clarity around the constrained orbit feature, it's impossible to determine.
If the constrained orbit option is expected to apply to all input devices, then we have a bug regarding the spacemouse.
If the constrained orbit option only applies to mouse input, then we have a feature (or lack thereof) that the spacemouse always uses freeorbit.

However what is very obvious due to the number of posts and comments regarding this: many users are desiring constrained orbit when using the spacemouse. I hope Autodesk can acknowledge the number of people who have requested this across multiple threads (most of which have been dismissed for varying reasons, mainly misunderstandings of the request) and put some priority on adding the ability to use the spacemouse in constrained orbit mode. This can be done by applying the existing constrained orbit option and logic to all input devices, instead of making it local to the mouse only.
As a software dev, I feel that since the logic already exists, it likely is a quick task for one of the experienced devs at autodesk to implement to all devices, but of course without understanding how it's truly implemented, I shouldn't speculate on the effort, as a poor/messy implementation could make it extremely difficult to map to other devices.

That being said, I'm taking time to get used to orbiting with the spacemouse as it is, and it's a bit like flying a helicopter: you need to learn how to coordinate multiple inputs (in this case, orbit + roll) to keep the horizon level. And it's kinda fun to be honest, however even though I've gotten decently good at it, it is still faster to orbit with the mouse using constrained orbit, as it requires less thought/effort, which dampens an otherwise great experience with fusion + spacemouse.